SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.

RSA Multi Factor Authentication unregister LDAP ID from prior token

We are evaluating the RSA Authentication Agent on a few of our Windows servers to determine if RSA Multi Factor Authentication will meet our needs. We are trying to setup alias authentication, allowing two separate LDAP IDs (user normal and user admin) the ability to use the same token to authenticate to agented servers. Unfortunately, it appears both accounts were assigned tokens at some point so they are both "registered" in RSA. We would like to determine how we can go about "unregistering" one of the accounts so it can be utilized as an alias to the other account. In our scenario, we would like to unregister the user admin account so it can be added as an alias to the user normal account. 

The following comment from the above thread appears to indicate there is a way to correct this issue...

Yes.  what would mess this up is if both UserIDs, the real one and the alias one, were both assigned tokens at one point, so they would be 'registered' in RSA.  If that happened there are ways to fix it, but you only want one UserID pointing to the real SamAccountName in Acitve Directory, and the other exists in AD, but RSA thinks it is just an alias for the first UserID.

Here's a PowerPoint on external Identity Sources, if you need to understand that the RSA database has a pointer, called exuid, that points to the real User in AD or LDAP, typically the exuid points to the ObjectGUID in LDAP.

Thank you.

Labels (1)
1 Reply
Apprised Contributor Apprised Contributor
Apprised Contributor

One way to do this is to block the single UserID (samAccountName or UPN) in the Identity Source filter, effectively blocking the UserID that will be the alias, then running a clean-up job to un-register that UserID and unassign any tokens.  Difficulty might be if you need to do this to dozens or hundreds of users, or if you have 29 Identity Sources and do not know where this alias resides.


Here is an example using the default User search filter and a samAccountName UserID that is Jay.Guillette

In the operations console - Deployment Configuration - Identity Sources - Manage Existing.  Edit the IS 

tab over to MAP and scroll down to Directory Configuration - Users, to the Search Filter and basically you change the User Map filter from





Then run a clean up now in the Security Console - Setup - Identity Sources - Clean Up unresolvable Users



Then change the filter back to default or original in the Identity Source Map.


Variation on this would be to remove UserIDs from the Internal Database using PGSQL from Linux.  You could investigate that option by referring to 

Which explains how to access SQL and how to query / select UserIDs in the internal DB.  You could try deleting that userID mapped to the alias to unregister the user.  Backup the database before hand.