I’m still trying to catch up with the items on my “to blog” list and lately I’ve been asked about configuring Cisco UCS B Series Infrastructure’s UCS Manager to authenticate with Active Directory & LDAP accounts and since I documented the process a few months back, I figure I should take the time now to write this post. I was actually very impressed with the changes Cisco has made with integrating UCS Manager with AD integration since the early days when you were required to make changes to the Active Directory’s schema. With the new guide:
CAE 1.4.1
UCS LDAP and Multiple Authentication Server Configuration
PDF Filename: UCS-1-4-1-LDAP-AD-v2.pdf
… you no longer need to make any changes to your Active Directory’s schema. I found the configuration document easy to follow and I’m sure most administrators will applaud to the Cisco development team’s effort to simplify the process.
The document’s easy enough to follow so this post serves more to include screenshots of the process rather than really explaining too much about what’s going on. For more information about the steps, please refer to the document I mentioned above.
Prerequisites
Prior to starting the configuration, you’ll need to gather the following information and perform a few tasks within the Active Directory you intend on using to authenticate against:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Creating Active Directory Account for Binding with your AD:
As the document states, you’ll need to configure an account in your Active Directory domain for UCS Manager to use for binding against it. This account should not have administrative permissions because all it is really used for is to bind against AD and any account that is a part of the Domain Users group (which is the default) should be able to bind to AD.
Cisco’s document provides the example with an account named ucsbind but it’s your choice to name it whatever you want.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Creating Active Directory Security Groups:
Create the following groups in the OU of your choice:
- ucsaaa
- ucsadmin
- ucsnetwork
- ucsoperation
- ucssecurity
- ucsstorage
As shown in the screenshot provided in Cisco’s document:
… you can configure the scope of these groups as Global but if you have a multi-domain and/or forest environment, you can change the scope to, say, Universal if needed. Also, these groups actually mirror the ones that are predefined in UCS Manager so while the document suggests you use the exactly same names, you are free to change it to whatever you like.
Once these groups have been created, you can either create new accounts to assign to these groups or use existing accounts (i.e. such as admin accounts you use to administer AD).
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Your Domain’s DN (Distinguished Name):
The DN of your domain is typically the FQDN of your domain in the format of DC=DomainName,DC=TLD and while I can’t think of another situation where this wouldn’t apply, you can find this with a tool such as ADSIEdit which can be found in the Windows Support Tools package for Windows Server 2003 or on a Windows Server 2008 domain controller (installed by default) or a Windows Server 2008 server with Remote Administration Tools installed via Features.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
The DN (Distinguish Name) of the groups you’ve configured previously:
Next, we’ll need to determine what the DNs are for the groups you’ve configured to mirror the UCS Manager ones. This can be found the same way as what you did with the domain:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
The DN (Distinguish Name) of the account you’re using to bind to AD:
As with the previous DN requirements, you’ll also need to obtain the DN of the account you’re using to bind to Active Directory. You can get this via the same method mentioned above.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
SAM Account Names of the users you've added to the security groups:
The last prerequisite mentioned in the configuration document is to obtain the sAMAccountName attribute of the accounts you’ve added to the security groups because when you actually log into UCSM with these accounts, you use their sAMAccountName attribute as the login name.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Configuring a backdoor
Now that we’ve completed the prerequisites, proceed with logging into UCS Manager to create the domain.
Note: As the document states, it is best to have a console session to your 6120/6140 fabric interconnect in case you accidentally make a mistake with your configuration because if you do, you’ll be locked out.
What I was a bit confused about at the end is that the backdoor account mentioned doesn’t appear necessary because I noticed that the 6120/6140 actually retains a local domain that it labels as being Native. I haven’t been able to do more testing and maybe I’ve simply misunderstood the document so it’s up to you to decide whether you want to create another domain named local as the document suggests.
Just so I demonstrate every step in the document, I’ll proceed with creating this backdoor:
Configuring LDAP
Now that we’ve configured the backdoor domain as suggested by the document, proceed with configuring UCS Manager’s LDAP node with the following:
Timeout: 30 (Default)
Attribute: <Blank> (Default)
Base DN: <yourDomain’sDN>
Filter: sAMAccountName=$userid
Once you’ve filled out the fields, proceed with saving the configuration:
Once the configuration has been saved, you can use your console (in my case it’s an SSH session) to verify your configuration by executing:
scope security
show detail
scope ldap
show detail
Configuring LDAP Providers
Once we’ve completed configuring the LDAP general settings, we can proceed with configuring the LDAP Providers:
Configure the settings as follows:
Hostname (or IP Address): <yourDomainController’sIPorName>
Order: lowest-available (Default)
Bind DN: <theBindAccount’sDN>
Base DN: <yourDomain’sDN>
Port: 389 (Default)
Enable SSL: <blank> (Default)
Filter: sAMAccountName=$userid
Attribute: <blank> (Default)
Password: <yourPassword>
Confirm Password: <yourPassword>
Timeout: 30 (Default)
Note: The example above uses the regular LDAP port 389 to bind to a domain controller in Active Directory but if your environment requires secure LDAP to bind to the domain controller, you will need to change it to 636.
Now that we’ve created the settings for the provider, we will need to configure the group rule so UCS Manager will allow logins to authenticate against groups:
Make sure you select enable for the Group Authorization option:
Note: If you’re like me who likes to follow every step outlined in the guide, you will notice that there’s a discrepancy between what is shown in the screenshots between the GUI and the console:
**Notice how the document shows us that the execution of the following commands:
scope security
scope ldap
scope server 10.x.x.x
scope ldap-group-rule
show detail
… shows that Group Traversal is set to Recursive but in the GUI example above, it’s set to non-recursive?
For my thoughts about this, see one of my earlier blog posts here:
Cisco UCS Manager 1.4.x LDAP / AD authentication configuration – Is Group Recursion supposed to be set to “non-recursive” or “recursive”?
http://terenceluk.blogspot.com/2011/03/cisco-ucs-manager-ldap-ad.html
Configure LDAP Provider Groups
Now that we’ve completed the configuration of the LDAP Providers proceed with navigating to the LDAP Provider Groups tab to configure a predefined provider (defined in the previous step):
As shown in the configuration document, we can verify the settings in the console by executing:
scope auth-server-group <LDAP Provider Group name>
show detail
show server-ref detail
Configure LDAP Group Map
Now that we’ve completed LDAP Provider Group with the account we’re using to bind to the Active Directory, we can proceed with mapping the AD groups we’ve configured in the prerequisites section to the native groups in UCS Manager:
As shown in the following screen shot, you will need to refer to the DNs you’ve documented in the prerequisites section to each group in UCS Manager:
I had mine pasted into notepad so I simply just copied and pasted the DNs in as such:
CN=ucsaaa,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsadmin,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsfacility-manager,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsnetwork,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsoperations,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsread-only,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsserver-equipment,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsserver-profile,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsserver-security,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
CN=ucsucsstorage,OU=Groups,OU=Accounts,DC=CONTOSO,DC=BIZ
Once you’ve completed all the LDAP Group Maps, you’ll see something similar to the following:
Configuring the Active Directory Domain
Now that we’ve completed all of the LDAP configuration, we can (finally) configure the Active Directory domain that we will be authenticating against:
Configure the fields as follows:
Name: <Name of your domain>
Realm: ldap
Provider Group: <The provider you configured in previous steps>
Once completed, you’ll see your Active Directory domain listed:
I’m not sure what I did wrong but I went through the steps to test via the CLI but couldn’t get the commands to work:
Testing Active Directory Authentication
Now that the configuration is complete, we can proceed with testing login with Active Directory accounts. If you’ve configured UCS Manager correctly, you will now see your Active Directory domain listed in the Domain drop down box:
**Notice how there’s a native domain listed? This is why I don’t understand why we needed to configure a local domain.
Once logged in, you’ll be able to see the details of your session under the Remotely Authenticated Users:
As I mentioned earlier, the document doesn’t specify the differences between non-recursive and recursive for Group Recursion and through my quick tests, both work. For my thoughts, visit my blog post here:
Cisco UCS Manager 1.4.x LDAP / AD authentication configuration – Is Group Recursion supposed to be set to “non-recursive” or “recursive”?
http://terenceluk.blogspot.com/2011/03/cisco-ucs-manager-ldap-ad.html
Hope this helps anyone that needs to visually see the process. I’d have to say I was impressed with how easy it was to configure UCS Manager to integrate with Active Directory by following the Cisco guide.
2 comments:
Hi Terence,
Wonderful post !!!
One query regarding distinguish name for Base DN, in your example base DN didn't have OU defined I have seen some configurations that include OU as well in Base DN.Request to you tell me what is relevance to include OU in base DN ?
MY email id : prashant_c8@rediffmail.com
http://in.linkedin.com/pub/prashant-chaudhary-ccie-23655-jncie-866-jncip-1313/25/109/200/
Regards
Prashant
Just out of curiosity, I see TONS of examples using AD as the LDAP provider, but do you have any advice on getting a Cisco UCS to authenticate to an OpenLDAP provider like FreeIPA? I've scoured the internet, and I can't seem to locate any examples of this scenario.
Post a Comment