Disallowing certain OU from logging into VPN.

[acadia]

I've got a ASA5510 with ASA8.3(1), and it's working fine with several group policies, currently handling IPSec and SSL connections. It is authenticating against our AD servers (radius) and I am wondering if it is possible to simply disallow members of a certain OU from connecting.  We have a "portal" OU in AD for users who need certain AD functionality, but we wish to disallow them from having VPN access.  Could someone point me towards a way to do this, if possible?

Thanks.

[Yudong Wu]

You can follow the attached example configuration.

Basically, you can do a LDAP map to map that OU to a group-policy which will deny the vpn access.

[acadia]

I've found lots of this information dictating how to do Group policy and Dynamic Access Policies with LDAP info, but, as I stated, I am using Radius, not LDAP, for authentication.  Short of reworking how the VPN handles authentication, is it possible to do what I'm trying to do?

[Yudong Wu]

If you are using Radius, you just need it to return a "IETF-Radius-Class-25 Attribute" to ASA (based on OU which you would like to deny VPN access), ASA will map this attribute to group-policy name directly.

What kind of Radius server are you using? It should be able to return the above attribute based on OU.

[acadia]

I'm not sure what the radius server is, truth to tell. That falls into someone else's department. I just know that I utilize it when needed for authentication against our active directory users (4000+ of them).  I've read about "IETF-Radius-Class-25 Attribute", and I've tried to create a dynamic access policy based on that, but it seems to let the portal OU in regardless of the fact.  Is this a non-default feature of a Radius server that I will have to get the Systems team to configure?

What is the "radius ID" number I would need to match the ou against in the dynamic access policy info, or is there another way I should be doing this?

[kaachary]

Can you provide the output of "debug aaa common 255" when you try to connect. You should be able to see the attribute returned in the debugs, and basis that create the DAP.