11-23-2010 11:37 AM - edited 03-10-2019 05:36 PM
Hi all,
I'm having problems configuring VPN clients authentication against an LDAP server. The main problem is when the ASA has to decide a group-policy for the non-compliance users.
I use LDAP attribute-maps in the ASA to map the memberOf parameter to the Cisco Group-policy attribute, then I associate memberOf with the AD group that the user must belong to has VPN access and the rigth group-policy. This works correctly.
But the problem is when the remote user isn't in the correct AD group, I set a default-policy-group with no access to this kind of users. After that, all the users (allowed and not allowed) fall in the same default-group-policy with no VPN access.
There is the ASA configuration:
ldap attribute-map LDAP
map-name memberOf Group-Policy
map-value memberOf "cn=ASA_VPN,ou=ASA_VPN,ou=My Group,dc=xxx,dc=com" RemoteAccess
aaa-server LDAP protocol ldap
aaa-server LDAP (inside) host 10.0.0.3
ldap-base-dn ou="My Group", dc=xxx, dc=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password ********
ldap-login-dn cn=user, ou="My Group", dc=xxx, dc=com
server-type microsoft
ldap-attribute-map LDAP
group-policy NOACCESS internal
group-policy NOACCESS attributes
vpn-simultaneous-logins 0
group-policy RemoteAccess internal
group-policy RemoteAccess attributes
dns-server value 10.0.0.3
vpn-tunnel-protocol IPSec
default-domain value xxx.com
tunnel-group RemoteAccess type remote-access
tunnel-group RemoteAccess general-attributes
address-pool POOL
authentication-server-group LDAP
default-group-policy NOACCESS
tunnel-group RemoteAccess ipsec-attributes
pre-shared-key *******
As you can see, I have followed all the examples availables in the web to solve the problem but I can't obtain a good result.
Somebody has an solution for this problem????
Regards,
Guzmán
Solved! Go to Solution.
12-03-2010 06:19 AM
Guzman,
this should definitely work, i.e. the deny part is already working ok and the user that has the correct memberOf attribute should definitely get mapped to the Allow-Access policy and so should be allowed in.
I'm thinking of this being a bug as well, but I had a quick look and did not see anything matching, and if this were a bug in 8.2.3. then I would not expect you to be the first customer to experience this, so I'm still more inclined to think it is something in the config that we are overlooking (I know frome experience typo's can sometimes be extremely hard to spot).
Could you get "debug aaa common 255" as well please, maybe that will tell us something.
BTW, just to be sure: you did not configure anything (like vpn-simultaneous-logins) in the DfltGrpPolicy, did you? Just double checking since your Allow-Access policy would then inherit that.
Maybe as another test, explicitly configure a non-zero value for that parameter in the Allow-Access policy, i.e.
group-policy Allow-Access attrib
vpn-simultaneous-logins 10
Herbert
11-28-2010 02:01 PM
Hi Guzmán
can you get the output of "debug ldap 255" when an authorised user tries to connect?
This should show what memberOf attributes are being received from the LDAP server (and normally also which group-policy it is being mapped to).
hth
Herbert
11-29-2010 04:36 AM
Hi Herbert, thanks for your answer.
I saw the output of the "debug ldap 255" command previously and it was the base to make the config that I've pasted in my previous post.
My problem is when an attribute isn't present in the parameters that the LDAP server pass back to the ASA when authenticate a user, how can I represent these in the ldap attribute-map?
I didn't find documents that explain or shows a configuration to represent values that aren't present in the LDAP attributes pass to the NAS (an ASA in this case).
For example:
I map the group with privileges to remote access to the memberOf attribute in an LDAP attribute-map. All the rest of the groups must be not allowed to access but I doesn't want to make this association for each case in the LDAP attribute-map. There is a way to map a generic attribute with wildrcards for example?
I hope that I was clear now with my problem and someone can help me.
Regards,
Guzmán
11-29-2010 09:01 AM
Guzman,
Can you please provide an example of what it is that you are trying to accomplish? In your original post I did recreate your issue and was able to get the mapping to successfully work. I would like you make the changes to your map-value under your ldap attribute-map since the behavior seems to be case sensitive.
What attributes is the LDAP server handing back, because for every user that authenticates it would be safe to assume that there all the DN's are being handed back for each of the users that successfully authenticates.