Wireless Access

I had to rename my domain on one of the domain controllers I use for LDAP.  After the rename, I changed the DC parameter of my Admin-DN and Base-DN settings for that LDAP server in the Aruba Controller.  I now get an "Authentication Server out of service" error.  The LDAP server is enabled in the config, and I have ran the "aaa inservice <group> <server>" command several times, but I cannot access the server.  I know the LDAP server is functioning as I have other systems accessing it via LDAP.  Whatever I do, the Aruba controller will not activate this particular LDAP server.  I complete removed the LDAP configuration for this server and added it back, but same result.  Any ideas?

Hi Tom,

Not sure what type of LDAP we are running, please confirm if is LDAP authentication on the AD Domain behind Radius server.
Make sure admin bound happens against the server else controller will take the server out of service.
It is worth to verify the adminpassword is correct.

Below command will help us to understand for adminbound against the server.

Aruba) # show aaa authentication-server LDAP test-authsrvr status

LDAP Server Table
-----------------
LDAP Server Attribute Value
--------------------- -----
Priority 10
Name test-authsrvr
Hostname 138.83.168.133
AuthPort 389
AuthSSLPort 636
Retries 3
Timeout 30
AdminDN CN=SVC-guest,OU=SVC,OU=FNA,DC=us1,DC=ent,DC=arubanetworks,DC=com
AdminPasswd arubatest123
BaseDN dc=us1,dc=ent,dc=arubatac,dc=com
KeyAttribute sAMAccountName
Filter (objectclass=*)
Allow Cleartext yes
Status Enabled
InService Up
InitDone yes
AdminBound Yes=========> Verify admin bound shows up fine
Connection Type clear text
Server Down no =============> Make sure server is active.
Marked For Delete no
In Use Callback Set no
RefCount 0
RebindTimerSet no
RebindCount 2
ReqViolationCount 0

On the controller please enable below debugging which could fetch more info.

#configure termiinal
#logging level debugging security subcat authmgr
#logging level debuggin security subcat aaa

Enable pcap  on the controller to capture tcp session packets against the server.

#packet-capture tcp 389

Since we have this issue after changing the domain, we could also try installing ldp.exe (software available from web)
on the server or any PC; bound  the user with server  which is not working to look and verify the AdminDN and BaseDN matches with what we had configured on controller. Once user is bounded against the LDAP; go to view tree structure which will fetch the admindn & basedn automatically. 

Connect the client to SSID couple of times to fail so that simultaneously on the other hand; collect security logs and the filter.pcap from logs.tar  on the controller would give us more info about client behaviour.

Please upload the output so that we could review the status.

Thank you,
Sriram S

Thanks for the reply.  We restored the domain controller from a recent backup, and left it the way it was, so everything is working now.  I believe the problem may have been with the SSL cert on the DC, which we did not change when we renamed the DC.