10-07-2009 04:14 PM - edited 03-10-2019 04:43 PM
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)?
10-07-2009 05:19 PM
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.
10-08-2009 03:55 AM
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
group-policy
vpn-simultaneous-logins 3
vpn-tunnel-protocol IPSec l2tp-ipsec ...
address-pools value
.....
.....
tunnel-group
tunnel-group
authentication-server-group LDAP-AD
default-group-policy noaccess
HTH
JK
-Plz rate helpful posts-
10-11-2009 10:11 PM
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.
10-08-2009 06:53 AM
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!
10-09-2009 08:52 AM
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.)
10-12-2009 04:32 AM
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-
10-20-2009 09:42 AM
JK,
Thank you so much for this... it worked great.
The only other thing I had to do was this:
group-policy
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: