Unanswered Question
Jun 22nd, 2010

Has anyone managed to get the ASA (8.2) working with LDAP/ AD to perform authorization/ group mapping's based on AD group membership?

I found numerous postings on these forums, but not anyone who has managed to get it working.

We have several groups where we are using the drop down selector and would like to leverage AD groups for access.  If the user is a member of the group, then they can sign in.  If not, they get denied access.  It sounds pretty straight forward, but it doesn't seem to work like it is supposed to.  Our user community pretty much will only use AnyConnect.

Thanks in advance.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
charlesdf22 Tue, 06/22/2010 - 03:18

The first article is the one that I have been following and does not work.  It has been noted many, many times in these forums.

The second article covers dial-in access allow or permit which is not quite what we need.

charlesdf22 Tue, 06/22/2010 - 03:26

Actually.... it turns out we may have found a potential fix here...

The documentation refers to Radius-Class, which doesn't seem to accomplish anything.

It looks like Tunnel-Group-Lock is the key.  However, it's denying everything right now, which I guess it better than what it was doing before.

Jennifer Halim Tue, 06/22/2010 - 03:38

The map name would be "map-name  memberOf IETF-Radius-Class".

Please run "debug ldap 255" and try to authenticate with the user, and it will show you the full path of the CN memberOf for that user, and on the actual LDAP mapping, you would need to include that.

charlesdf22 Tue, 06/22/2010 - 04:38

I have that, just like the doc says and it still does not work correctly.  The issue is that it sees the group mapping, verifies it and then lets the user in with another group.  It seems the authorization is busted and doesn't really do anything.

Just like here:

Kind of here:

It looks like they never got it working here:

Does anyone have any idea what the Tunnel lock stuff does?

Jennifer Halim Tue, 06/22/2010 - 04:45

Don't worry about tunnel group lock, it is not what you are after.

Can you please share your configuration, and also advise which group-policy is the user supposed to be connected in, and which group-policy does the user actually get connected to ("show vpn-sessiondb svc filter name " output will show which group-policy the user is actually dropped in after the ldap attribute mapping). Thanks.

charlesdf22 Tue, 06/22/2010 - 05:15

ldap attribute-map ad-members

  map-name  memberOf IETF-Radius-Class

  map-value memberOf "CN=NS-ILO-Admins,OU=Groups,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com" eng-test

Here is the debug for the groups:
[258] memberOf: value = CN=NS-OU-Admins,OU=Groups,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=
[258] mapped to IETF-Radius-Class: value = CN=NS-OU-Admins,OU=Groups,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com
[258] mapped to LDAP-Class: value = CN=NS-OU-Admins,OU=Groups,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com
[258] memberOf: value = CN=ACS-Server-Admins,OU=ACS,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,D
[258] mapped to IETF-Radius-Class: value = CN=ACS-Server-Admins,OU=ACS,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com
[258] mapped to LDAP-Class: value = CN=ACS-Server-Admins,OU=ACS,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com
[258] memberOf: value = CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com
[258] mapped to IETF-Radius-Class: value = CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com
[258] mapped to LDAP-Class: value = CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com
Session Type: IPsec
Username     : USERNAME                   Index        : 16
ATestinggned IP  :          Public IP    : X.X.X.X
Protocol     : IKE IPsec
License      : IPsec
Encryption   : AES128                 Hashing      : SHA1
Bytes Tx     : 1970                   Bytes Rx     : 1698
Group Policy : CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com
Tunnel Group : eng-test
Login Time   : 08:09:19 EDT Tue Jun 22 2010
Duration     : 0h:02m:09s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : Static                 VLAN         : 3036
As you can see, it's just picking whatever group it feels like and not the correct one.
Jennifer Halim Tue, 06/22/2010 - 05:23

The map-value that you have configured is for the following:

map-value memberOf "CN=NS-ILO-Admins,OU=Groups,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com" eng-test

However, base on the debug, the user is not a member of the above configured map value.

If you change the map-value to the following for example:

map-value memberOf "CN=NS-OU-Admins,OU=Groups,OU=Network Services,OU=X,OU=Depts,DC=X,DC=company,DC=com" eng-test

Then, that particular user will be put into the correct group-policy (name: eng-test), assuming you have configured group-policy with "eng-test" as its name.

charlesdf22 Tue, 06/22/2010 - 05:43

That is correct.  Even though the user is not a member of that group, they are ending up in that group-policy.

Jennifer Halim Tue, 06/22/2010 - 05:50

Sorry, I don't think I understand it.

There are 2 different configuration policies:

1) tunnel-group

2) group-policy

"eng-test" configured I believe is the tunnel-group. Do you also have group-policy named "eng-test" as well? ie: having both tunnel-group and group-policy with the name "eng-test"?

From the "show vpn-sessiondb svc" output provided earlier, the user is connected to the following:

Group Policy : CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com
Tunnel Group : eng-test

So the group-policy assigned is "CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com" which is just a false group-policy as I don't think you have group-policy with name "CN=X-TS-Users,OU=Groups,OU=Testing,OU=X,OU=Depts,DC=X,DC=company,DC=com" configured.

The mapping is done on group-policy, not on tunnel-group. You can configure 1 tunnel-group where all the users are connected to, however, having different users being mapped to different group-policy (where all the specific policies are configured).

Please share the following output to understand what is actually configured:

show run tunnel-group

show run group-policy

charlesdf22 Tue, 06/22/2010 - 07:18

tunnel-group eng-test type remote-access

tunnel-group eng-test general-attributes

address-pool eng-test

authentication-server-group Win-Domain

default-group-policy eng-test

tunnel-group eng-test webvpn-attributes

group-alias Engineering-testing enable

tunnel-group eng-test ipsec-attributes

pre-shared-key *****

tunnel-group wireless type remote-access

tunnel-group wireless general-attributes

address-pool wireless

authentication-server-group Win-Domain

default-group-policy wireless

tunnel-group wireless webvpn-attributes

group-alias Wireless enable

group-policy DfltGrpPolicy attributes

banner value Testing

vpn-idle-timeout 90

vpn-tunnel-protocol IPSec svc webvpn

split-tunnel-policy tunnelspecified

split-tunnel-network-list value Standard-Split

nem enable

group-policy eng-test internal

group-policy eng-test attributes

vpn-tunnel-protocol IPSec svc webvpn

vlan 3036

address-pools none

ipv6-address-pools none


  svc ask enable

group-policy wireless internal

group-policy wireless attributes

vpn-tunnel-protocol IPSec svc webvpn

vlan 3011

address-pools none

ipv6-address-pools none


  svc ask enable

charlesdf22 Tue, 06/22/2010 - 07:40

this is the same exact issue.

Basically, I will have up to 20 different groups that a user can select.

For example, engineering, sales, administration, management.

Some users will need to access different groups based upon their needs.  Someone from engineering will need to select the drop down (or url) to access the management group so they can make switch changes.

My basic need is that the system has to check an LDAP group, determine memberOf and allow access.  This sounds like basic authorization, is it not?

Jennifer Halim Wed, 06/23/2010 - 05:46

It is absolutely  basic authorization, however, the ldap mapping has been configured incorrectly.

You would need to map the correct ldap path of that user to a group-policy as advised earlier.


This Discussion

Related Content