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

KB ID 0001271 Dtd 11/01/17

Problem

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

AAA Server has been removed

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;

debug ldap 255

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

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

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);

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

 

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

Author: PeteLong

Share This Post On

6 Comments

  1. Thanks…The Debug output showed me exactly what was wrong with my configuration!

    Post a Reply
    • Glad to help, thanks for the feedback!
      P

      Post a Reply
  2. 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

    Post a Reply
  3. 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.

    Post a Reply
  4. 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.

    Post a Reply

Submit a Comment

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