I've successfully created a AnyConnect VPN configuration on my Cisco ASA and it authenticates to RSA secureID to use the token code. However what I'd like to do now is an AD lookup on the username and based on what group they are in, assign them the correct group-policy. I know this isn't possible using ACS. I'm not sure if RSA has this capabilities. Perhaps the ASA can do this using identity firewall?

  • You're authenticating using the token server, but you want to use A/D for authorization? I think the only way you could do it is to make an LDAP query to A/D, but your usernames will have to match. You will also need to modify permissions so that ASA/ACS/RSA can see the group membership attributes.
    – Ron Trunk
    Jan 10, 2014 at 19:21
  • "it authenticates to RSA secureID to use the token code" is this your primary authentication? My asa is configured to auth against AD and then auth against mirrored AD in the cloud for two factor. Jan 10, 2014 at 19:33
  • so you should auth against internal directory first, then a secondary for two factor, the the ASA gets group information for your dynamic access policies Jan 10, 2014 at 19:34

2 Answers 2


My understanding is that when using the SDI protocol for RSA integration, you cannot pass group/class info. However, if you reach the RSA server using RADIUS, then the RSA server can be configured to return a RADIUS Class attribute of the format "OU=group-policy-name;" which is then used to match a group-policy name in the ASA config. I've done it this way with another customer. For example:

aaa-server RSA protocol radius
aaa-server RSA (inside) host
 key *****
 authentication-port 1812
 accounting-port 1813

Then, you would have a group-policy that fails closed (I usually call it "NOACCESS") that sets "vpn-simultaneous-logins" to 0 which drops the connection, like so:

group-policy NOACCESS internal
group-policy NOACCESS attributes
 vpn-simultaneous-logins 0

You would then have one or more group-policies that describe your VPN users and override the "vpn-simultaneous-logins" value with a non-zero value (I usually set it back to the default value of 3), like this:

group-policy Users internal
group-policy Users attributes
 vpn-simultaneous-logins 3
 <other VPN policy settings go here>

Finally, your tunnel-group would be set to use the RSA server (via RADIUS) for the authentication server, and then the default group policy is set to the "NOACCESS" group to force the group to fail closed if the RADIUS Class value isn't returned:

tunnel-group RA-VPN type remote-access
tunnel-group RA-VPN general-attributes
 authentication-server-group RSA
 default-group-policy NOACCESS

The important notes with this solution are:

  • The Class attribute returned by RADIUS must be (without quotes, note the very important semi-colon) "OU=group-policy-name;"
  • The "group-policy-name" returned in the Class attribute must be an exact match for the group-policy name configured in the ASA, including matching case.

The behavior is that the user's session will inherit the default group-policy value of "NOACCESS" and be assigned the attribute of "vpn-simultaneous-logins 0" if no matching RADIUS Class attribute is returned. If a Class attribute which matches the name of a group-policy in the ASA is returned, the user session is assigned that group-policy instead, which then overrides the inherited default "vpn-simultaneous-logins" value and allows them to continue their login.

I've used this RADIUS configuration regularly for years, and a customer I worked with discovered the RSA requirement that RADIUS be used to pass the Class attribute for group assignment. Unfortunately I do not know the RSA setup to do the group mapping or return the attributes, but this thread and this thread may prove helpful there.


I was able to figure this out within ACS. The missing piece was that I needed to create an identity store sequence. This allows me to authenticate to one place (RSA) and do an additional attribute lookup in another place (AD).

Thanks for the help though. You guys made me think of it differently which ultimately solved it!

More information on this topic can be found at Cisco's website, Managing Users and Identity Stores.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.