I’ve been doing some work in the EMC vLabs and I thought I’d take note of how to join an Isilon cluster to Active Directory. The cluster in this example is running 3 Isilon virtual nodes with OneFS 126.96.36.199.
Once you’ve logged in, click on Cluster Management and Access Management. Under Access Management, click on Active Directory. Note that there are no Active Directory providers configured in this example.
Click on “Join a domain”. You can then specify the Domain Name, etc. You can also specify the OU and Machine Account if required.
Once you click on Join, you’ll be joined to the AD.
To confirm this, you can also use isi auth status to confirm the status.
And that’s it. As always, I recommend you use a directory service of some type on all of your devices for authentication.
I’m surprised that I haven’t done an article on configuring Active Directory (AD) authentication on the VNX. It’s pretty easy to do, and a good idea. Big thanks to Sean Thulin for documenting this in a clear and concise fashion, and to EMC Support‘s website for filling in some of the blanks I had (via Primus emc308583).
Firstly, you should have DNS configured on your array. This is just a basic thing that you should do. Stop making excuses.
For AD authentication, you need the following information:
Domain Controller (DC) hostname;
A basic account on AD with read permission on AD on Users and Group containers – this account is called the Bind DN; and
Full path information for the Bind DN, the User container, and the Group container.
To obtain this, log in to a Windows computer with dsquery installed. You don’t need Domain Admin rights to get this information.
To determine the DC hostname, run set | findstr “LOGONSERVER” to return the hostname.
If there isn’t a Bind DN account created, you’ll need one. This can be a normal user account with the password preferably set to “Not Expired” to avoid issues down the track. Once the user is created anywhere in AD, use Dsquery thusly:
The above is fully qualified path name for the account “ldap_account,” which will be used as the Bind DN. You’ll need access to the password of this service account.
The User container is where the VNX will look for the user login be used for authentication. In this example the user name is “Storage User”.
C:\Users\dan>dsquery user -name "Storage User"
"CN=Storage User,OU=Storage Admins,OU=Administrators,DC=domain,DC=com"
The User Container path here that you need to note is: OU=Storage Admins,OU=Administrators,DC=domain,DC=com
For the group, you can do the same thing. In a number of environments, this will be the same location as the Users.
C:\Users\dan>dsquery group -name "Storage Admins"
"CN=Storage Admins,OU=Storage Admin Groups,OU=Administrators,DC=domain,DC=com"
The path name for group container is : OU=Storage Admin Groups,OU=Administrators,DC=domain,DC=com
Now you’re ready to set things up. Go to Domain -> Manage LDAP and configure using the above collected information.
You can configure two service connections. These would usually be DCs that are at discrete data centres.
Click on Add or Modify.
Here’s what you need to fill in:
Host Name or IP Address – Use the FQDN, it’s 2015 and DNS should work in your environment;
Port 389 for LDAP, 636 for LDAPS – This will change depending on whether you select LDAP or LDAPS as the protocol;
Server Type – Choose “Active Directory”;
Domain Name – Specify the domain name;
BindDN – This is where you put the distinguished name of the LDAP service account;
Bind Password – The password for the LDAP service account;
Confirm Bind Password – Confirmed;
User Search Path – This is the info we got earlier;
Group Search Path – Ditto; and
Add certificate – If you’re using LDAPS, you’ll need this.
Note that it is recommended to use group names with no special characters and with fewer than 32 characters. The main roles include:
Operator – Read-only privilege for storage and domain operations; no privilege for security operations.
Network Administrator – All operator privileges and privileges to configure DNS, IP settings, and SNMP.
NAS Administrator – Full privileges for file operations. Operator privileges for block and security operations.
SAN Administrator – Full privileges for block operations. Operator privileges for file and security operations.
Storage Administrator – Full privileges for file and block operations. Operator privileges for security operations.
Security Administrator – Full privileges for security operations including domains. Operator privileges for file and block operations.
Administrator – Full privileges for file, block, and security operations. This role is the most privileged role.
VM Administrator – Enables you to view and monitor basic storage components of your VNX system through vCenter by using VMware’s vSphere Storage APIs for Storage Awareness (VASA).
Note that some of these roles apply to “Unified” configs (NAS), rather than block-only.
Don’t forget to synchronise the information once you’ve created the connections. And that’s it. you should now be able to log in to your VNX with your AD credentials. Just make sure “Use LDAP” is ticked.
I spoke about restarting some ESXi services when joining a domain in this post. Here’s how you might want to do it with PowerCLI. Firstly, you may need to modify the execution policy for PowerCLI. It’s worth checking out the Microsoft URL in the test here, as it’s very useful background on what you’re actually doing by setting this policy. Also, big thanks to my colleague Michael for coming up with the syntax here, he’s really the brains behind the operation.
PowerCLI C:\Windows\system32> Set-ExecutionPolicy RemoteSigned
Execution Policy ChangeThe execution policy helps protect you from scripts that you do not trust.Changing the execution policy might expose you to the security risks describedin the about_Execution_Policies help topic athttp://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change theexecution policy?[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):
Then when you connect to your vCenter host, you’ll get warned about the certificate. This assumes that you’re not using the right certificates in your environment (why are you like this?).
PowerCLI C:\Windows\system32> Connect-VIServer 172.16.200.200WARNING: There were one or more problems with the server certificate for theserver 172.16.200.200:443:* The X509 chain could not be built up to the root certificate.* The certificate's CN name does not match the passed value.Certificate: [Subject] OID.1.2.840.1135188.8.131.52="1382062929,d8ba9993,564d7761726520496e632e",CN=localhost.localdom, Efirstname.lastname@example.org, OU=VMware vCenter ServerCertificate, O="VMware, Inc.", L=Palo Alto, S=California, C=US[Issuer] Eemail@example.com, CN=localhost.localdom CA af1bb298, O="VMware,Inc.", L=Palo Alto, S=California, C=US[Serial Number] 01[Not Before] 17/10/2013 12:22:09 PM[Not After] 16/10/2023 12:22:10 PM[Thumbprint] 4883C2F3DCD6E6F8693200E41BDE2A41A88C3930The server certificate is not valid.WARNING: THE DEFAULT BEHAVIOR UPON INVALID SERVER CERTIFICATE WILL CHANGE IN AFUTURE RELEASE. To ensure scripts are not affected by the change, useSet-PowerCLIConfiguration to set a value for the InvalidCertificateActionoption.Name Port User---- ---- ----172.16.200.200 443 root
You can then get down to it. Firstly, you can join the domain with this command.
#To Join the domain: #get cred for joining the domain$cred=get-credential
get-vmhost | Get-VMHostAuthentication | Set-VMHostAuthentication -JoinDomain -Domain "network.internal" -Credential $cred
Once you’ve done that, you might need to restart those services I spoke about at the end of a previous post.