cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
29074
Views
25
Helpful
21
Replies

UCS Manager and Active Directory integration

simon.geary
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

21 Replies 21

cpaggen
Cisco Employee
Cisco Employee

You can use the Adam Schema Editor which is part of the Adam Schema Tools suite: http://technet.microsoft.com/en-us/library/cc757747%28WS.10%29.aspx

Add the CiscoAVPair attribute with Unique X500 ID 1.3.6.1.4.1.9.287247.1 then edit the user schema properties and add the CiscoAVPair attribute to the user class.

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
Level 1
Level 1

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

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?

Did you ever figure this out? We are having the same issue. We can see the request go out to LDAP, the CiscoAVPair is looked up and found (from network trace) but still no go!

Cheers,

Milos

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.

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.

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

I never did get this working. I switched to Radius off the AD server and that is working fine...

Cheers,

Milos

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

ncowger
Level 1
Level 1

Here.  It's not straight forward.  Here it is on IAS for Win2003

HAROLD MEIER
Level 1
Level 1

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: