User migration

[SumitKumar4]

We moved on user1 from ab.com domain to de.com domain in AD.

disabled user in ab.com domain.

now we are seeing that user1 don't have any token and new token is also not able to assign to the user. getting error like already token assigned and that token itself is not searchable in RSA now.

if we are moving user from one domain to other through AD, does token also moves with the user? 

can somebody help here?

Also, how to mover user with token from 1 identity source(ab.com) to other (de.com)? is it possible?

both identity source are in same setup.

[SumitKumar4]

can someone please address the above query?

[SGTech]

Hi Sumit Kumar,

Up to my knowledge when user moved to other domain objectSID will change for that user, this may cause this issue, can you check if this user is in un resolvable users list, if yes delete un resolvable user may help you assign new to ken to the user in domain de.com. can you try this and let me know.

before you clear un resolvable users take backup of RSA am server.

Thanks

Rajesh Gogineni [M.Tech Products Pte ltd]

[SumitKumar4]

How to check if the user is in unresolvable users list?

[SGTech]

In Secruity Console:

Select Identity from Dropdown 

[SumitKumar4]

and after this clicking on next will give me all the users which are unresolvable?

and identity source should be the old one, right?

[SGTech]

Yes, you must choose old identity source and clear them.

after clear them try to find token and assign to user in de.com

[SumitKumar4]

Thanks, i'll check this in troubleshooting.

[JayGuillette]

You did not move the user from ab.com domain to de.com, you created a duplicate user in de.com and disabled that same userID in ab.com, therefore the normal self-healing of the RSA Authentication Manager Identity Source could not learn the new distinguished name, DN for this user.  The user already exists in the domain error is indicating that you have duplicate userIDs.  When you assigned a token to user1@ab.com you created a pointer in the AM internal Database to user1, typically to user1's ObjectGUID in AD. If you would like to see this internal database link to the Identity Source ObjectGUID, look at KB https://community.rsa.com/docs/DOC-45944 

Or in context look at this posting

https://community.rsa.com/message/911126?commentID=911126#comment-911126 

Disabling User1 in ab.com means the pointer to the objectGuid is still valid, so Clean-up will not remove it.  You either have to;

 1. delete user1 in ab.com

 2. move user1 in ab.com out of scope or out of sight within the Identity Source.  This may not be possible is your Identity Source scope is at the top of the Domain, e.g. User Base DN:  dc=ab, dc=com

you could move user1 out of scope if User Base DN: ou=Users, dc=ab, dc=com, by moving user1 out of the Users organizational unit, ou.

 3. unlinking the Identity Source pointing to ab.com

Then cleanup would remove the pointer to objectGUID for user1 in ab.com, but you should have done this before creating duplicate user1 in de.com

[JayGuillette]

So Rajesh from M-Tech was on the right track, it was the objectGUID or objectSID for two user1's that caused the problem.  And of Course Rajesh gives sound advice when he reminds you to take a backup of the AM database before doing something like what could be a significant change - clean-up.  This is why Clean-up has options like wait 7 days (in case they make a mistake in AD / LDAP) or sets a limit of 50, if 50 users are found for a clean-up job that could be a mistake in AD, so an automatic clean-up won't work, you have to do a manual clean-up