ACS 5.1: Group mapping for RSA SecurID Token Server store in an Identity Store Sequence

Unanswered Question
Aug 26th, 2010

I have a need to authenticate and authorize users on a NAS via RADIUS against both SecurID and Active Directory using a Cisco ACS 5.1 appliance, but I need to ensure that the AD-authenticated users are in a particular AD group before authorizing.  The problem is that the SecurID users usernames are identical to their AD usernames, and I don't want SecurID users to be able to login with their AD credentials (bypassing SecurID) unless they're in that particular AD group.

I was able to setup SecurID and AD external Identity Stores and put them in an Identity Store Sequence with SecurID first and AD second. I configured the SecurID store to treat authentication rejects as "user not found" rather than "authentication failed," so the fall-through from SecurID to AD works for non-SecurID users, but I can't figure out how to enforce the AD group requirement for users with a SecurID account.

I can design a Network Access Service Authorization Policy to require that an authenticated user be a member of a specific group--either a mapped Identity Group or an AD group--in order to be permitted access, but SecurID-authenticated users aren't assigned to any groups. I can't seem to map authenticated SecurID users to internal Identity Groups, because there doesn't seem to be a SecurID dictionary on the ACS by which to accomplish the mapping with a Network Access Service Group Mapping Policy.

Anyone have any idea how I can accomplish this?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
jrabinow Thu, 08/26/2010 - 11:11

You can try and put the Active Directory in the list of databases for "Additional Attribute Retrieval Search List"

Then in cases where authentication against securID succeeds active directory will be accessed to retrieve attributes

Therefore in both use cases attribute directory attributes will be available for the authorization policy

gglynn Thu, 08/26/2010 - 11:21

Good to know, but that actually won't help in this case, because I want the user to be able to login if he's in the NonSecurIDVPNAccess group *or* he uses a SecurID to login. If I just do the AD attribute lookup, a user not in that group who successfully authenticates with a SecurID would still be denied access.  What I really need is to be able to map all SecurID authenticated users to a single internal Identity Group and filter on that in the Authorization Policy.  Is this at all possible?


This Discussion