Cisco – LDAP AAA Error ‘AAA Server has been removed”

KB ID 0001271 

Problem

Seen while attempting to test AAA authentication via LDAP to a Windows domain Controller.

Authentication test to host {IP-Address} failed. Following error occurred – 

ERROR: Authentication Server not responding: AAA Server has been removed

Solution

This is a terribly ambiguous error! What it means is that the ASA cannot bind to active directory, either because;

  • The ASA bind account password is wrong.
  • The ASA bind username, (or path to the user object) is wrong.
  • You have set the LDAP server group to use LDAPS (port 636) and the server specified as an LDAP  host is not authenticating via LDAPS.
  • There is no connectivity between the ASA and the LDAP server.

You can narrow it down by running the following debug;

[box]debug ldap 255[/box]

In the following output you can see either the username or the password is wrong;

[box]

Petes-ASA(config)# debug ldap 255
debug ldap  enabled at level 255
[-2147483629] Session Start
[-2147483629] New request Session, context 0x00007fffbcc69c88, reqType = Authentication
[-2147483629] Fiber started
[-2147483629] Creating LDAP context with uri=ldap://192.168.110.10:389
[-2147483629] Connect to LDAP server: ldap://192.168.110.10:389, status = Successful
[-2147483629] supportedLDAPVersion: value = 3
[-2147483629] supportedLDAPVersion: value = 2
[-2147483629] Binding as asa
[-2147483629] Performing Simple authentication for asa to 192.168.110.10
[-2147483629] Simple authentication for asa returned code (49) Invalid credentials
[-2147483629] Failed to bind as administrator returned code (-1) Can't contact LDAP server
[-2147483629] Fiber exit Tx=207 bytes Rx=720 bytes, status=-2
[-2147483629] Session End

[/box]

In the following output you can see the firewall is trying to connect over LDAPS but the server is not configured, (or not answering on TCP 636);

[box]

Petes-ASA(config)# debug ldap 255
debug ldap  enabled at level 255
[-2147483625] Session Start
[-2147483625] New request Session, context 0x00007fffbcc69c88, reqType = Authentication
[-2147483625] Fiber started
[-2147483625] Creating LDAP context with uri=ldaps://192.168.110.10:636
[-2147483625] Connect to LDAP server: ldaps://192.168.110.10:636, status = Failed
[-2147483625] Unable to read rootDSE. Can't contact LDAP server.
[-2147483625] Fiber exit Tx=0 bytes Rx=0 bytes, status=-2
[-2147483625] Session End

[/box]

 

Related Articles, References, Credits, or External Links

Cisco – Testing AAA Authentication (Cisco ASA and IOS)

Cisco ASA – AnyConnect Authentication via LDAP and Domain User Groups

10 thoughts on “Cisco – LDAP AAA Error ‘AAA Server has been removed”

    • SO i’m having the same issue. It appears to be a software version related issue. LDAPS works fine on asa version 9.12, but fails like above on versions 9.14/9.16. What config parameter am I missing

  1. Had an issue with ldap auth from Cisco ASA to the AD server, service has been working fine for over 6 months and just stopped working yesterday, showing similar results as above,though port was correct, issue was resolved by amending ldap-login-dn string from CN=username,OU=xxx DC=xxx etc, to ldap-login-dn “username@domain”

    No idea why it stopped working but this change fixed it

    Hope this helps someone else

  2. I had “Unable to read rootDSE. Can’t contact LDAP server” twice, with two different ASA 5506 firewalls over the last few weeks.

    My config was right, and LDAP tools proved that.

    I found that both of my ASA’s out of the box were running 9.8 (2), I upgraded them to 9.9 (2) and it started working straight away, must be a bug.

  3. I had a strange one in that we received this error from our ASA trying LDAP auth for just a single AD user that used to work fine before. I replicated the issue with multiple LDAP servers and with 2 separate ASA devices. Every other user was fine except one. I also found that it only failed when using LDAP over SSL (tcp port 636). When I configured a test aaa-server to the same LDAP servers without SSL (port 389), it was successful. The fix was removing a non-existent Exchange Global Address List from the user’s AD attribute for ‘showInAddressBook’. Once the stale/deleted entry was gone, the ASA could successfully authorize the AD user with LDAP over SSL again. The same stale attribute also caused attempts to Copy the AD user (to another test account) to fail with the error: “Windows cannot create the object because: The name reference is invalid.”. This was also resolved once the old value was removed from showInAddressBook. I drove myself crazy digging into this for 4 days, so I hope this is helpful to someone else.

  4. This was real great help, i was able to find that the AD path was incorrect and the AD user was being found.
    In addition to troubleshooting using the “dsquery user -samid usernamehere” helped identify the correct path.

Leave a Reply

Your email address will not be published. Required fields are marked *