Anyconnect + LDAP AAA - not getting groups for some?

[Jeff Cooper]

I have a couple hundred ASAs out in the field and they all started having the same problem.  They use anyconnect with LDAP authentication.  I use an attribute map and successfully get users into their group-policy based on their active-directory group membership.  Been working great for a while...

UNTIL

recently...   Recently, I'm getting some environments where windows 2012 has been added to the domain.   Any new user I create in these environments, will not pull group membership in LDAP.  Says login failed.

Specifically:

I'm running 8.45.   I run ldap debug, and for an existing user, they login and debug shows the complete group membership from Active Directory.  And consequently, they successfully get their group-policy assignment based on an AD group.  I enter in a new user, I don't get any group memberships in my LDAP results.  I create a new user by copying an existing user in AD and login with that - still no group membership info.  I've been working on this since October and I can't make any sense of it.  My ldap look account successfully binds and I get successful authentication for the user.   But again, no group membership info.  I use a user that's existed in the domain, and I get all the group membership info and group-policy is assigned.

I have this same issue across multiple customers who've added windows 2012 to their domain.  Worked perfectly with new users, but now, new users dont show their group memberships.  I've configured AAA to authenticate against various domain controllers in the domain as well.

Any assistance would be appreciated.  Thanks.

---

This is an ldap debug from an account I created by copying an account that successfuly authenticates (and pulls group memberships from ldap).     Since I have had this working 100% across all our installations until about 5-6 months ago, I've not included a ldap debug of a successful anyconnect login. 

[54] Session Start

[54] New request Session, context 0xd872610c, reqType = Authentication

[54] Fiber started

[54] Creating LDAP context with uri=ldap://10.0.0.5:3268

[54] Connect to LDAP server:

ldap://10.0.0.5:3268

, status = Successful

[54] supportedLDAPVersion: value = 3

[54] supportedLDAPVersion: value = 2

[54] Binding as

ASA-LDAP-LOOKUP@entre.local

[54] Performing Simple authentication for

ASA-LDAP-LOOKUP@entre.local

to 10.0.0.5

[54] LDAP Search:

        Base DN = [DC=entre,DC=local]

        Filter  = [sAMAccountName=testtest]

        Scope   = [SUBTREE]

[54] User DN = [CN=testtest,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Entre,DC=local]

[54] Talking to Active Directory server 10.0.0.5

[54] Reading password policy for testtest, dn:CN=testtest,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Entre,DC=local

[54] Binding as testtest

[54] Performing Simple authentication for testtest to 10.0.0.5

[54] Processing LDAP response for user testtest

[54] Message (testtest):

[54] Authentication successful for testtest to 10.0.0.5

[54] Retrieved User Attributes:

[54]    objectClass: value = top

[54]    objectClass: value = person

[54]    objectClass: value = organizationalPerson

[54]    objectClass: value = user

[54]    cn: value = testtest

[54]    c: value = US

[54]    l: value = Chicago

[54]    st: value = IL

[54]    title: value = Cisco Manager

[54]    postalCode: value = 60601

[54]    givenName: value = testtest

[54]    distinguishedName: value = CN=testtest,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Entre,DC=local

[54]    displayName: value = testtest

[54]    co: value = United States

[54]    department: value = Professional Services

[54]    company: value = Computer Solutions

[54]    publicDelegates: value = CN=ComputerSolutions,OU=Distribution Groups,OU=MyBusiness,DC=Entre,DC=local

[54]    publicDelegates: value = CN=Mike Broski,OU=Special,DC=Entre,DC=local

[54]    publicDelegates: value = CN=Beth Harris,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Entre,DC=local

[54]    mDBUseDefaults: value = TRUE

[54]    protocolSettings: value = OWA..1

[54]    protocolSettings: value = HTTP..1..1............

[54]    name: value = testtest

[54]    objectGUID: value = ....;.gF...?..}.

[54]    primaryGroupID: value = 513

[54]    objectSid: value = ............M....qp&|t.Zi...

[54]    sAMAccountName: value = testtest

[54]    sAMAccountType: value = 805306368

[54]    showInAddressBook: value = CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=ENTRE,CN=Microso

[54]    showInAddressBook: value = CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Cont

[54]    userPrincipalName: value =

testtest@Entre.local

[54]    objectCategory: value = CN=Person,CN=Schema,CN=Configuration,DC=Entre,DC=local

[54]    msExchHomeServerName: value = /o=ENTRE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=

[54]    msExchUserAccountControl: value = 0

[54] Fiber exit Tx=572 bytes Rx=2597 bytes, status=1

[54] Session End

[pf]

Did you found a solution to this problem? I got same problem with a new Windows2012 Installation.

Ldap gives groups only for Administrator user but not for newly created ones

[Jeff Cooper]

I had to look back as to when I posted this.  We upgraded to 9.0, etc and currently are running 9.13-2.   In the spring we went thru a massive cutover of clients to sslvpn instead of open RDP.  We ran into this about 1/3rd of the places.   We opened a TAC case and they found when running LDAP browser, attributes were NOT showing up in AD queries.   We opened a Microsoft case and they did not like the LDAP browser cisco was using and used their own.   Using their own, they showed the group attributes were showing up.  Personally, I've known Microsoft to be a pain in their support calls.  LDAP is LDAP as far as a group attribute query.   Anyway, I digress.   Microsoft said it was fine and cisco consistently showed thru various browsers that it wasn't working with AD.

But interesting you asked if i had resolved it.  I've not messed with it since spring, and then I decided to test again this past weekend (6+ months since the issue)..   And i'll be darn if it didnt work everywhere i was having issues.

Best I can say is it's either the 9.13-2 version we're running or a MS update that occurred in the last 6 months.  We've ran 9.0x and 9.12 way back when testing and upgrading client ASAs - problem still existed.  We put on 9.13-2 maybe 30 days ago?

I know this isn't a definitive answer, but perhaps there's MS updates you're missing, or perhaps the issue was on Cisco's side, whereas 9.13-2 has resolved the mysterious issue.

[pf]

I had 9.1.3 on the ASA an upgraded now to 9.13-2. Still same issue, no groups are shown with the users expect of the Administrator.

debug ldap 255 shows:

16] Authentication successful for sdag to 192.168.20.80

[16] Retrieved User Attributes:

[16]    objectClass: value = top

[16]    objectClass: value = person

[16]    objectClass: value = organizationalPerson

[16]    objectClass: value = user

[16]    cn: value = sdag

[16]    distinguishedName: value = CN=sdag,OU=Lieferanten,OU=Users,OU=xxxx,DC=xxxx,DC=local

[16]    displayName: value = sdag

[16]    homeMTA: value = CN=Microsoft MTA,CN=SRVSBS01,CN=Servers,CN=erste administrative gruppe,CN=Admini

[16]    proxyAddresses: value = smtp:sdag@mail.xxxxx

with Administrator

[18] Message (Administrator):

[18] Authentication successful for Administrator to 192.168.20.80

[18] Retrieved User Attributes:

[18]    objectClass: value = top

[18]    objectClass: value = person

[18]    objectClass: value = organizationalPerson

[18]    objectClass: value = user

[18]    cn: value = Administrator

[18]    description: value = Vordefiniertes Konto f..r die Verwaltung des Computers bzw. der Dom..ne

[18]    distinguishedName: value = CN=Administrator,CN=Users,DC=xxxxx,DC=local

[18]    instanceType: value = 4

[18]    whenCreated: value = 20081201134058.0Z

[18]    whenChanged: value = 20131126141559.0Z

[18]    displayName: value = Administrator

[18]    uSNCreated: value = 12298

[18]    memberOf: value = CN=G_SSLVPN,OU=Service,OU=Groups,OU=xxxx,DC=xxxx,DC=local

[18]            mapped to Group-Policy: value = ssl_admin

[18]            mapped to LDAP-Class: value = ssl_admin

So I will ask our server guy to check the updates on this server.

[Jeff Cooper]

yeah have him check for updates and let me know..   i'd like to know if it's a win update or whatnot..  

that's kind of what we were running into..  admin accounts in general seemed to work ok..    but then if you changed a user to an admin group, it was like the LDAP lookup didnt see the change and they still didnt work..    on the other hand, was like some long long established account would work, but newly created accounts wouldn't work..  yeah, really messed with the head

so i was pleasantly surprised it just up and worked this weekend..