Internal database to AD mapping

[JackAlexander]

Is there any way to map an internal database user to an Active Directory user if all users are already setup in the internal database but we want to use the Cloud service now which relies on AD?  

[EdwardDavis · Accepted solution]

On RSA Authentication Manager, internal database users can be converted to ldap users by: export/import

(make a backup first)

-have an existing connection to ldap where you can list users on the external identity source

do not edit these users or assign them anything yet, they need to be 'unregistered users' 

-for current internal database users

ensure the first name, last name, and default login userid match the target external ldap names/userid

-use the export/import users and tokens feature to export users and tokens from internal database

this keeps token and pin data intact inside the exported file

-now delete the users from the internal database. This puts tokens in the unassigned list.

-import the users and tokens, and on import, choose to import them to the specific external identity source

tokens will get assigned back to the same users and pins are retained

Run a report 'imported users and tokens report' to check for warnings or errors.

There should be one warning message per user about taking an unassigned token and assigning it to the imported user.

[JackAlexander]

Thanks, just tried testing this and it didn't work.  Will open a support ticket.  Start of the error states principal with userid already exists in realm.

[EdwardDavis]

In general....

If you deleted the internal users, the target ldap userids must not be registered. Import will collide on registered users. For any ldap connection when you first set it up and list ldap users, none of them are 'registered' and there are no stored artifacts about them in the database, the list of users is a real-time lookup at ldap. If you do anything to one of these users such as assign a token or edit their account in any way, they become 'registered' and a permanent database artifact will be created. Simply unassigning any tokens will not unregister an ldap user. To unregister ldap users and clean up the internal database, you need to (a) make the user or users not listable in the security console, by adjusting the ldap filter in the operations console, and (b) run an identity source cleanup job. (c) now, fix the operations console filter so the users show back up, but now they are unregistered and database artifacts removed, and you should not have any 'userid exists in the realm' issues on import.

simple example of breaking the user search filter in operations console,

so all users on the connection become orphans, and you can run a cleanup job and unregister users on this ldap connection:

existing filter: (&(objectClass=User)&(objectcategory=person))

broken filter: (&(objectClass=User)&(objectcategory=fluffy))

I used 'fluffy' just as some random word that is not any existing attribute in ldap. This makes the filter return no users. Now when listing users in security console for this ldap connection, none are found, and if any were registered in the past, they will show as objects to remove on the 'cleanup unresolvable users' preview in security console.

[JackAlexander]

Yes indeed you were correct, thanks!

[JackAlexander]

Sorry just following on from this, is there any way of exporting or copying agents and user group membership from one Authentication manager deployment to another much like the same way of exporting/importing users?

[EdwardDavis]

No that is not exportable. If you have a config like that with a ton of changes and want to move it, then you need to make a backup and restore it to another primary and then delete things you don't want.