EMC – Isilon – Joining Active Directory

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 7.1.0.0.

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.

Isilon_AD1

Click on “Join a domain”. You can then specify the Domain Name, etc. You can also specify the OU and Machine Account if required.

Isilon_AD2

Once you click on Join, you’ll be joined to the AD.

Isilon_AD3

To confirm this, you can also use isi auth status to confirm the status.

Isilon_AD4

And that’s it. As always, I recommend you use a directory service of some type on all of your devices for authentication.

EMC – VNX – Configuring LDAP 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).

DNS

Firstly, you should have DNS configured on your array. This is just a basic thing that you should do. Stop making excuses.

Dsquery

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:

C:\Users\dan>dsquery user -name ldap_account

You’ll get this:

"CN=ldap_account,OU=Service Accounts,DC=domain,DC=com"

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

Manage LDAP

Now you’re ready to set things up. Go to Domain -> Manage LDAP  and configure using the above collected information.

LDAP1

You can configure two service connections. These would usually be DCs that are at discrete data centres.

LDAP2

Click on Add or Modify.

LDAP3

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.

Role Mapping

LDAP4

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.

Conclusion

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.

VMware – Joining an ESXi 5.5 Host to Active Directory with PowerCLI

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 Change
The execution policy helps protect you from scripts that you do not trust.
Changing the execution policy might expose you to the security risks described
in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the
execution 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.200
WARNING: There were one or more problems with the server certificate for the
server 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.113549.1.9.2="1382062929,d8ba9993,564d7761726520496e632e",
CN=localhost.localdom, [email protected], OU=VMware vCenter Server
Certificate, O="VMware, Inc.", L=Palo Alto, S=California, C=US

[Issuer]
  [email protected], 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]
  4883C2F3DCD6E6F8693200E41BDE2A41A88C3930

The server certificate is not valid.

WARNING: THE DEFAULT BEHAVIOR UPON INVALID SERVER CERTIFICATE WILL CHANGE IN A
FUTURE RELEASE. To ensure scripts are not affected by the change, use
Set-PowerCLIConfiguration to set a value for the InvalidCertificateAction
option.

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.

 

#To restart these pesky services:

Get-VMHost | Get-VMHostService | ?{"lsassd","lwiod","netlogond" -contains $_.Key} | Restart-VMHostService

 

Once you’ve done that, you can check if it’s all working with this command.

 

#check to see if you have any auth issues

get-vmhost | Get-VMHostAuthentication

 

And you should be good to go.

New Article – Joining an ESXi Host to an Active Directory Domain

I’ve added a very basic article to the Articles page on Joining an ESXi Host to an Active Directory Domain. I’ll probably update it in the next few weeks with more information on why you would do this.