%ASA-6-113013: AAA unable to complete the request Error : reason = AAA Server has been removed : user =

[Steven Carnahan]

We have one user that suddenly is not able to access our VPN.  What we have tried:

1. We have removed/added her from the AD Group,

2. We have removed/added her to the MFA Group.

3. We have changed her password.

She was working fine through 3/21 when suddenly she started getting the error shown below:

From the ASA log:

%ASA-6-113013: AAA unable to complete the request Error : reason = AAA Server has been removed : user = aerickson

From the client screen:

Running "Debug LDAP 255" on the ASA shows this for the failing user:

Here is what the debug shows:

[2189012] Session Start

[2189012] New request Session, context 0x00002aaad8aa37f0, reqType = Authentication

[2189012] Fiber started

[2189012] Creating LDAP context with uri=ldaps://10.200.3.64:636

[2189012] Connect to LDAP server: ldaps://10.200.3.64:636, status = Successful

[2189012] supportedLDAPVersion: value = 3

[2189012] supportedLDAPVersion: value = 2

[2189012] Binding as LDAP

[2189012] Performing Simple authentication for LDAP to 10.200.3.64

[2189012] LDAP Search:

        Base DN = [DC=HAYDEN,DC=LOCAL]

        Filter  = [sAMAccountName=aerickson]

        Scope   = [SUBTREE]

[2189012] Request for aerickson returned code (-1) Can't contact LDAP server

[2189012] Talking to Active Directory server 10.200.3.64

[2189012] Failed to get Active Directory current time, ret code(-1) Can't contact LDAP server

[2189012] Fiber exit Tx=246 bytes Rx=62088 bytes, status=-3

[2189012] Session End

That is all that shows up for this user as compared to another user that successfully connects.

[2192574] Session Start
[2192574] New request Session, context 0x00002aaad8aa37f0, reqType = Authenticat                                                                                                  ion
[2192574] Fiber started
[2192574] Creating LDAP context with uri=ldaps://10.200.3.64:636
[2192574] Connect to LDAP server: ldaps://10.200.3.64:636, status = Successful
[2192574] supportedLDAPVersion: value = 3
[2192574] supportedLDAPVersion: value = 2
[2192574] Binding as LDAP
[2192574] Performing Simple authentication for LDAP to 10.200.3.64
[2192574] LDAP Search:
        Base DN = [DC=HAYDEN,DC=LOCAL]
        Filter  = [sAMAccountName=bschrempp]
        Scope   = [SUBTREE]
[2192574] User DN = [CN=Ben M. Schrempp,OU=IT,OU=Users,OU=BR02 Hayden,OU=Branche                                                                                                  s,DC=HAYDEN,DC=LOCAL]
[2192574] Talking to Active Directory server 10.200.3.64
[2192574] Reading password policy for bschrempp, dn:CN=Ben M. Schrempp,OU=IT,OU=                                                                                                  Users,OU=BR02 Hayden,OU=Branches,DC=HAYDEN,DC=LOCAL
[2192574] Read bad password count 0

There is a lot more for the successful user.

[drllewellyn]

This post described the same exact problem we had.  I 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 with debug ldap 255, packet captures, and combing through all user AD attributes.  I hope this is helpful to someone else. -Dave /4L

[dmillington]

Also had this issue. 

We have two AD groups to put users into either Full Tunnel mode or Split Tunnel. I'm normally split tunnel, but move back and forth for testing. 

I believe the trigger was a group that was added to my user account after I finished working one day. The next day I couldn't connect to split tunnel on any of our vpn nodes. The all have the same AD config and servers. I could connect when Full Tunnel was added to my user account. Management tunnel also continued to work. 

The fix was removing any reference to our tunnel group objects then reapplying.