UCS Manager and Active Directory integration

Answered Question
Apr 1st, 2010

I am looking to create an LDAP authentication provider in UCS manager that will authenticate users against Active Directory. I see from the UCS configuration guide that a schema change is required to add a new attribute to user accounts, and the guide details what the new attribute should be. However there are no detailed instructions on how to make the change in AD. I imagine some sort of LDIFDE import is required but does anyone have more detailed steps on how to do this?


Thanks

Correct Answer by cpaggen about 6 years 10 months ago

You can ssh into your UCS, go to the NxOS prompt and test authentication as follows:


laurel-A(nxos)# test aaa group ldap cpaggen cisco
user has been authenticated
laurel-A(nxos)# test aaa group ldap cpaggen cisco1
user has failed authentication
laurel-A(nxos)# test aaa group ldap foo doesntexist
user has failed authentication
laurel-A(nxos)#


Make sure that part works. The role assignment comes from CiscoAVPair and the value must be shell:roles="admin" if you'd like the user to be an admin. CiscoAVPair needs to be an attribute of the user object.I'm attaching a Wireshark screenshot of a successful authentication and authorization.


You'll also find the user definition and my UCS configuration.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
HAROLD MEIER Wed, 05/26/2010 - 11:00

Are there any more detailed whitepapers describing the steps required on both sides of the

configuration for AD integration with UCSM? The only instructions I see for this are in the UCS Manager Configuration Guide.

Also, has anyone used SSL with AD?

simon.geary Mon, 04/05/2010 - 10:10

I was able to get this done by saving the object as an ldf file and then importing it using ldifde -i -f c:\import.ldf


One warning though. The Cisco documentation has a value of 0x4 for the instanceType attribute but this caused an import error and the value had to be changed to 4 before it would work.


This is the content of import.ldf that worked:


dn: cn=CiscoAVPair,cn=schema,cn=configuration,dc=company,dc=com
changeType: Add
cn: CiscoAVPair
objectClass: top
objectClass: attributeSchema
distinguishedName: CN=CiscoAVPair,CN=Schema,CN=Configuration,dc=company,dc=com
instanceType: 4
attributeID: 1.3.6.1.4.1.9.287247.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
adminDisplayName: CiscoAVPair
adminDescription: UCS User Authorization Field
oMSyntax: 64
lDAPDisplayName: CiscoAVPair
name: CiscoAVPair

simon.geary Wed, 04/07/2010 - 06:13

Just following up on this as I have another problem. Has anyone out there actually managed to get this sort of integration working?


I have now added the new CiscoAVPair attribute and added this to the user class so I can edit the new attribute using ADSI edit. What value do you use for the attribute though? I have tried admin and shell:roles="admin" but still can't log on, either using domainname\username or just username. I see the authentication request using the bind DN in my domain controller event logs so I know an attempt is being made. Can anyone give me any tips?

Correct Answer
cpaggen Wed, 04/28/2010 - 11:52

You can ssh into your UCS, go to the NxOS prompt and test authentication as follows:


laurel-A(nxos)# test aaa group ldap cpaggen cisco
user has been authenticated
laurel-A(nxos)# test aaa group ldap cpaggen cisco1
user has failed authentication
laurel-A(nxos)# test aaa group ldap foo doesntexist
user has failed authentication
laurel-A(nxos)#


Make sure that part works. The role assignment comes from CiscoAVPair and the value must be shell:roles="admin" if you'd like the user to be an admin. CiscoAVPair needs to be an attribute of the user object.I'm attaching a Wireshark screenshot of a successful authentication and authorization.


You'll also find the user definition and my UCS configuration.

Attachment: 
simon.geary Mon, 05/03/2010 - 11:34

Thanks for that, I now finally have it working. The only change I had to make was add in a value for the Filter field. The guide says this field is optional but it doesn't seem to work without it. One word of warning though, when I tried a filter of uid=$userid I got completely locked out, none of our user accounts have the uid attribute populated. Luckily enough I had a console session still open and changed this to sAMAccountName=$userid and now it works a treat. Thanks for the help.

Nuno Filipe Alv... Wed, 06/23/2010 - 05:08

Hello All ...


Can someone point me to this guide ? Everyone is mentioning it but I can't find it anywhere.


Is there a guide for Active Directory integration with UCSM ?


Thanks


Nuno Ferreira

kingttx12 Fri, 01/14/2011 - 14:48

EDIT: Ahhhhhh!! Nevermind. In the documentation I was looking over (old 1.1 version) and further down in this topic, I completely missed the "Key" field for the LDAP Provider configuration. Since it was under SSL, I kept skimming over that tidbit thinking it was related to SSL somehow. Eck!


Good to go now!

=======================

I've tried this in various configurations for the LDAP provider and such, and I cannot get a successful authentication using the 'test' command. I finally installed Wireshark and found I'm getting "In order to perform this operation a successful bind must be completed on the connection."


Reading elsewhere, this seems to happen on simple binds with AD. Where to go from here I have no idea. I have tried both the domain Administrator account and another user I created in the default User container, all using the correct password, and AD replies over the wire with this error.


Message was edited by: Thomas King

HAROLD MEIER Wed, 08/04/2010 - 20:42

I just got through with a TAC case regarding this configuration. Here’s a run through of my steps and lessons learned:

1)     Create the CiscoAVPair attribute in AD. This guide was a help for me. Even though it's for the C-Series CIMC, it explains the steps a little better than the UCS docs, and it tells you how to do it with the AD schema MMC snap in instead of constructing an ldif. Also, don't try to use an existing attribute. If it does not use the same data type, then it won't work, and I found no other existing attributes that natively use the "Case Sensitive String" aka Unicode string type. http://www.cisco.com/en/US/docs/unified_computing/ucs/c/sw/cli/config/guide/1.1.2/Cisco_CIMC_CLI_Configuration_Guide_1_1_2_chapter6.html#concept_AC4EC4E9FA3F4536A26BAD49734F23D0

2)     The easiest way to edit the CiscoAVPair attribute is using ADSI edit or the new Attribute Editor in Active Directory Users and Computers tool for Windows 7. Some people recommend writing a custom app or script that just enters the string for you. I might do that if I have a lot of users.

a)     The most basic string for the CiscoAVPair is shell:roles="admin".  The default roles are:
aaa
admin
network
operations
read-only
server-equipment
server-profile
server-security
storage

b)    If you are leveraging RBAC in a multitenant UCS then you may also want to specify a Locale. To do that, after the shell:rolles=”role” add shell:locales=”locale1”. Locale1 is the default root locale and is optional. You can create your own locales under User Services in UCS and specify them in the CiscoAVPair attribute in this way.

3)     To configure the LDAP settings in UCS you must translate the labels in UCS to names AD administrators understand:

a)     Timeout = number of seconds until timeout

b)    Attribute = CiscoAVPair

c)     Base DN = Distinguished name of the domain. (ex. DC=cisco,DC=com)

d)    Filter = mapping to which attribute in AD the user will type into the username field. The format for this field is attribute=$userid, so if you're using sAMAccountName (aka the regular old username) then set this to sAMAccountName=$userid. Another attribute I found useful is userPrincipalName. If you have a multi domain forest where account names are only unique when you add the @domain.name to the username then userPrincipalName might be useful.

e)     In the “Create LDAP Provider” dialog, in the field marked "Hostname (or IP Address)" use neither. If you plan to encrypt your login passwords over SSL, then this needs to be the Fully Qualified Domain Name of the domain controller. It also needs to match the Subject Name on the certificate your DC uses to negotiate an LDAP SSL session. More on that later.

f)     Bind DN = Distinguished name of the account you will use to read the other user accounts. (ex. cn=user,OU=users,DC=cisco,DC=com) Contrary to Cisco documentation, this does not need to be an administrator account. It just needs access to bind to the domain over ldap, and it needs read access to the user accounts and the CiscoAVPair attribute. By default any user account has these privileges.

g)    Port=389 never change this unless your DC is setup to use LDAP over a custom port. If you're enabling SSL do NOT change this to the LDAP SSL port of 636. Just leave it 389. UCS will negotiate a TLS session on port 636 for SSL, but it will start the conversation unencrypted on 389.

h)     Enable SSL (don't do this yet)

i)      Key=the password for the "Bind DN" account.

4)     In the UCSM GUI under the Admin tab expand User Management -> Authorization, and set default to ldap but leave console set to local. In case you lock yourself out of the GUI the console port will allow you to log in via the local admin account. In that (*ahem* unlikely) event when you do lock yourself out, here are the commands to change back to local:
scope security
set authentication default local
commit-buffer

It’s also worth noting that when you save the changes to the Authorization default. There seems to be a grace period during which it will try LDAP but still fail over to local, if you’re quick to test you may not lock yourself out.

5)     Test it out unencrypted to confirm everything works before attempting SSL. Don’t do this if you don’t trust your network or change your password after you try this.

6)     If you have an existing AD Enterprise PKI then you already have a chain of trusted certificate authorities. If not, get one, and follow best practices in doing so. The documentation TAC follows will take you through setting up a standalone root CA, issuing certs for it and for your DC, and trusting the new root CA in UCS. This is not best practice. Odds are good; if you’re in a larger enterprise, then you’ve got an Enterprise root that may or may not be shut down and locked in a closet somewhere, and you have a subordinate issuing CA actually doing the day to day certificate management. If you’re in this camp then follow these steps:

a)     Log into your DC that will be used for LDAP. Run MMC and add the Certificates snap-in. Point the snap-in to the computer account certificate store for the local computer.

b)    Expand the certificates (Local Computer), expand Personal, and click on Certificates. You should have a list of certs issued already to your DC. Find one preferably with an expiration date in the future that lists “Server Authentication” under the “Intended Purposes” column. The issued by column should show the name of one of your subordinate CAs. Open it.

c)     Examine the properties of the certificate. Take note of the Subject Name attribute. This should be the FQDN of the domain controller. This needs to match what you entered into the Hostname (or IP Address) field of your LDAP provider in UCS manager.

d)    Still in the certificate properties, click the Certification Path tab. It should show a tree leading up to your subordinate CA(s) and your root. Double click the root.

e)     In the root certificate’s dialog click the details tab and click “Copy to File” to open a Certificate Export Wizard. Choose the Base-64 export format and save it to a file.

f)     Repeat this process for all the CAs in the certification path. You do not need to export the DC certificate, just the CAs.

g)    Close all the certificate dialogs and the certificates MMC.

h)     Back in the UCS Manager, in the Admin tab click on Key Management. Click the Trusted Points tab, and add a trusted point.

i)      The name doesn’t matter. Give it a name you’ll understand like DomainNameCAChain. In the Certificate Chain field add the contents of the root CA’s certificate file you just exported.

j)      Here’s where I get a bit fuzzy. TAC couldn’t tell me if I needed the whole chain or just the root. Since their docs only covered using a standalone root they didn’t know how to create a chain trusted point. So in addition to a root-only trusted point I also added a Trusted Point with all the CAs’ certificates chained one after another, in order, up the chain. This was accepted as valid. If I tried to add just a subordinate CA to a trusted point, UCS would not accept it. The only ones it would accept were either the root, or a chain all the way up to the root. One of these days I’m going to try removing one or the other to see if LDAP SSL breaks.

k)     Go back to your LDAP provider and check the SSL box.

7)     Test encrypted login. To see if it’s working, log into a console or SSH session and type the following:
scope monitoring
set syslog file level debugging
connect nxos
debug ldap all

Now try to login using ldap over SSL and see if the debug output shows a line which reads ldap: ldap_client_auth_init: - ldap_start_tls success

To turn off debugging type undebug all.

HAROLD MEIER Thu, 09/30/2010 - 09:11

Some additional points of clarification on the syntax of the CiscoAVPair attribute in AD:


Without the CiscoAVPair attribute or if it is unset, a remotely authenticated user will still have read only access to UCSM.


CiscoAVPair Syntax:
Locales:
•      Single locale
     shell:locales="locale1”
•       Multiple locales, more locales can be added by separating with spaces.
     shell:locales="locale1 locale2"


Roles:
•      Single role
     shell:roles="role1”
•       Multiple roles, more roles can be added by separating with spaces.
     shell:roles="role1 role2"


Passing both roles and locales:
Include both in the same field separated by a space
[ shell:roles=”role1” shell:locales=”locale1 local2” ]

So how about 1.4?  Anyone managed to get the Active Directory groups working yet?  From what I've read, using the method we no

longer have to extend the schema or use the custom attribute method.  We're simply supposed to map a role to an AD group and be good to

go?  I'd love to hear if anyone has been able to get this working yet!


Thanks in advance.

HAROLD MEIER Mon, 01/31/2011 - 12:13

We just upgraded to 1.4 last night, so I'll be looking into the process and reporting any gotchas in the documentation.

David McFarland Mon, 01/31/2011 - 13:24

Harold,


I've gone through a few of thes setups at various sites and have found two common issues that are being run into:


1) Now is not the time to enable SSL. Do this as a separate exercise. It is more involved than "tic-ing" SSL enable

2) Make sure your BindDN account/password is working. There is no indication in the UCS GUI that the BindDN account and password is valid and correct. It will just fail later when you attempt to authenticate with a user account. The BindDN account must be able to browse the AD tree. It must be at least a read-only account. It does not need admin privs.


As I collect more feedback, I'll upgrade the guide.

HAROLD MEIER Wed, 02/02/2011 - 13:14

David,


The only thing that got me was I was migrating from a 1.3 working LDAP config to a group-based 1.4 LDAP config. The existing LDAP providers were not group-enabled, and there was no way in the GUI to enable them after the fact. It may have been possible using the CLI, but I deleted and recreated the providers one by one, and I was able to group-enable them at that time.


As far as setting up SSL, you're absolutely right. If you're starting from scratch wait till you have it working, then try SSL. It appears that the SSL setup with Trusted Points and Key Rings has not changed. When I checked the SSL box on the re-created providers it just worked. So from an upgrade perspective that's good. I'm assuming that the initial setup hasn't changed from the above guide, so it's still a bit complex to get going the first time.


Lastly thanks for the tip to install a local Authentication Domain before testing out the new config. That's a life saver.

alberto.yanes Mon, 08/08/2011 - 13:02

I have LDAP authentication working with no problem but I need to enable SSL.

After everything was working, I went back and checked the enable SSL checkbox and I lost connectivity with the server.

I also try changing the port from 389 to 636 and got same results.


Anyone knows/has the procedure to enable SSL?? maybe I am missing something on the AD side.


Thanks,

Alberto

rshughes80 Wed, 10/10/2012 - 06:47

Thanks Harold. We successfully implemented this with only installing the root CA for our forest. Thanks!

cy-harrild Sat, 10/20/2012 - 16:27

This may seem a bit academic at this point but why use LDAP against Active Directory, which requires a schema extension and heap of messing around, when RADIUS takes a whole lot less time to implement, ties policies to AD groups and can be made to service other devices (like Cisco MDS)?

Actions

This Discussion

Related Content