UCS Manager 2.2.6f LDAP Authentication Issue

[Burak Atasal]

Hello Community,

I currently integrated an Active Directory to newly deployed UCS Manager 2.2.6f and i had various different problems like bind user password standard, secure LDAP connection issues but solved all of it and finally succeed to authenticate and authorized LDAP users. 

But now i have just another weird issue. A user can login to GUI with LDAP credentials but sometimes cannot login to very same GUI with using very same credentials. For example i logged in with my test LDAP user last night and configured the syslog and snmp settings but when i came to premisses in the morning i was not able to connect with same user for 10-15 minutes. While i waiting for customer to access FIs over console to troubleshoot it i tried one more time and logged in to UCS Manager from GUI again. 

It seems like sometimes something goes wrong between LDAP and UCSM but couldn't figure it out yet. I was wondering if anyone else here experienced the same thing before or have any clue that what might be the cause of this. There is nothing in the events, logs or anywhere else about failed logins at all.

I did this configuration many times before and this is the first time i'm having this so it'll be good to know the cause. 

Many thanks in advance for the comments and ideas.

[Kirk J]

Greetings.

Open a couple of ssh cli sessions to the UCSM with the local admin account.  Make sure you enable logging the sessions to file.

On one of the ssh sessions run the following:

#connect nxos

(nxos)# test aaa group ldap <username> <password>

(nxos)# test aaa server ldap <LDAP-server-IP-address> <username> <password>  (Do this for all your listed ldap servers in your ucsm config)

Exit the nxos mode, and log into the local mgmt for each FI:

#connect local-mgmt a/b

local-mgmt#ping x.x.x.x (Do this for all ldap servers IPs and fqdn)

local-mgmt#telnet x.x.x.x <ldap-port>  (do this for all ldap servers IPs and fqdn)

Example #telnet 192.168.1.12 389

The ping and telnet exercises are looking for name resolution/connectivity issues to ldap servers.

On your 2nd SSH session enable some debug output (make sure you have this ssh session being logged to file as these next steps will generate a lot of output)

#connect nxos

nxos#debug aaa aaa-requests

nxos#debug ldap aaa-request-lowlevel

nxos#debug ldap aaa-request

nxos#terminal monitor

Test your ldap logins through the GUI or CLI.

When you want to disable the debug output, go to the other ssh session not showing the ldap debug output, and run following command:

nxos#undebug all

Once you are seeing the log in problems (as it sounds like it's sporadic), I would run through all steps just outlined, and in that order.

If all the ping/telnet tests are fine while the problems seem to be active, and the debug output isn't clear on what kind of problem is occurring, then you will probably want to open a TAC case and provide a summary of your testing, along with the debug output.

Thanks,

Kirk...

[Burak Atasal]

Hi Kirk,

Thank you for the reply. I did all those tests and debugs many times and didn't have any problem at all but as i said sometimes fails and sometimes works. Mostly works today but i'm not sure it will remain that way. That's why i wanted to ask if anyone has any idea or previous experience with similar or same situation. 

I'll post if i find anything related to this. 

Kind regards.

[Kirk J]

Ldap/AAA auth requires healthy management services.

Can you check the following on both FIs:

#connect local a/b

local-mgmt#show cluster ext

local-mgmt#show pmon st

Looking to make sure the pmon state output doesn't show any instances of restarted processes or cores, and that the cluster state looks healthy from both FIs.

If all this still looks good, I would record the time stamps of when the failed login attempts occurred, along with the failed login ID, generate a UCSM tech support, and open a TAC case.

Thanks,

Kirk...