ASA VPN with LDAP authentication

sunnyhansen · ‎10-07-2009

We currently use a Cisco ASA (5510, 8.2) IPsec VPN client with RADIUS as a backend authentication service. We have configured IAS on one of our domain controllers to issue a RADIUS Accept/Deny based on the users' group membership within a "VPN Users" group. The IAS policy rules makes this very easy (it understands Windows group membership), and we like using groups because it is easy to send mail to all VPN users.

The things we don't like about using RADIUS is the idea that IAS has to be configured as a middleman service, and sometimes IAS does not always successfully start after a system reboot (we are not sure why).

We were wondering if it was possible to skip the middleman and use LDAP directly, pointing to our pool of domain controllers. There are many LDAP examples out on the net, but they consist of using an LDAP Attribute map to either use the "Remote Access Permission" of the user's DialIn profile, or by associating an AD group to a Cisco policy.

The former does not fit our model because it bypasses the group membership concept and requires VPN control via profile. The latter does not fit because, while we do have a "VPN Users" group to map in the affirmative, we do not have an inverse to map to a Deny policy. There is no "NOT" logical operator in the LDAP Attribute mapping.

Does anyone know a way to accomplish what we are after, using LDAP rather than RADIUS, where a single group can determine Accept (and more importantly, absence equals Deny)?

Erick Delgado · ‎10-07-2009

Hi,

This setup is not very hard.

Configure LDAP on the ASA and under User Directory Subtree point to the only group that will have VPN access.

Also there are another workaround but that one is the easiest.

If you need any help let me know.

Jatin Katyal · ‎10-08-2009

Hi,

I believe that second option you've mentioned will work for you. Why? using that if you map single AD group to right cisco policy. then this will work the way you want; where absence means deny to other users.

Here is con fig example you may try:

Configuration for restricting access to a particular windows group on AD/LDAP

group-policy noaccess internal

group-policy noaccess attributes

vpn-simultaneous-logins 0

address-pools none

ldap attribute-map LDAP-MAP

map-name memberOf IETF-Radius-Class

map-value memberOf

aaa-server LDAP-AD protocol ldap

aaa-server LDAP-AD host

server-port 389

ldap-base-dn

ldap-scope subtree

ldap-naming-attribute sAMAccountName

ldap-login-dn

ldap-login-password

server-type microsoft

ldap-attribute-map LDAP-MAP

group-policy internal

group-policy attributes

vpn-simultaneous-logins 3

vpn-tunnel-protocol IPSec l2tp-ipsec ...

address-pools value

.....

tunnel-group type remote-access

tunnel-group general-attributes

authentication-server-group LDAP-AD

default-group-policy noaccess

HTH

JK

-Plz rate helpful posts-

~Jatin

sunnyhansen · ‎10-11-2009

Thanks JK, I was thinking along those same lines, but came away stumped. Was your example a "theoretical" or verified?

When I changed from RADIUS to LDAP and applied the Attribute Map - leaving default Group Policy as FullVPN - anyone in the Directory could successfully authenticate and gain a connection. (And I do mean *anyone* - the "VPN Users" AD group membership was not honored.)

As soon as I changed the default Group Policy to NoVPN - hoping the FullVPN Attribute Mapping would supercede - nobody could login. We get 3 password prompts followed by an authentication error.

It would seem unlikely that it truly is an "authentication error" since the same LDAP user/pass works when the default Group Policy allows access.

reggiestration · ‎10-08-2009

Hi,

You mention:

"Configure LDAP on the ASA and under User Directory Subtree point to the only group that will have VPN access."

Could you please provide details on how to configure this? Thanks!

sunnyhansen · ‎10-09-2009

An 'OU' is not the same as a group. Users are typically spread throughout the hierarchy, and they are made members of a CN=groupName object using the memberOf attribute. Your subtree method ignores the 'group' and instead assumes that everyone to be authenticated is under the same OU. This is not my situation.

The memberOf LDAP Attribute Map method to associate a group policy for the allowed users is the most promising, provided I can also get a default no-access policy in place to handle the non-membership case. (As 'jkatyal' described.)

Jatin Katyal · ‎10-12-2009

Hi,

I have configured this in customer scenarios around 20 times with DN as a group name and it worked like a charm.

Let me tell you that if you use OU instead of GROUP you woon't see OU getting mapped with LDAP attrbute map.

Also, please help me with the following

sh run from ASA

debug ldap 255

HTH

JK

Plz rate helpful posts-

~Jatin

mgander · ‎10-20-2009

JK,

Thank you so much for this... it worked great.

The only other thing I had to do was this:

group-policy attributes

group-lock value

also, not sure why, but it wouldn't work when I inherited the 'simultaneous logins' from the default group policy - I had to explicitly tell simultaneous logins to each group policy (like you did in your example).

Right now I have 4 different AD groups linked to VPN group policies.

It is working great - but for each one, I had to set up a unique LDAP aaa-server entry so I could tell it to use a unique LDAP attribute map.

Is there a way to have *ONE* LDAP aaa-server entry with *ONE* attribute map that has several map-values? Or is the only way to have multiple aaa-server and attribute map entries?

Thanks,

MG