A user abc which is in xyz.com domain is coming through F5 to RSA for authentication.
but already that user is (abc)present in def.com domain which is currently integrated with RSA.
will the user abc be authenticated from current setup which is using def.com domain?
if not, what changes we have to make in current setup?
because after sometime the users which are in xyz.com domain will be disabled in def.com domain.
please confirm.
and what if we disable the user in existing domain, will it be authenticated then?
because after sometime user will be coming from xyz.com domain only, it will be disabled in def.com domain?
if the userID is mapped to UPN then there will be a problem while exporting/importing as well, right?
how can i eliminate this issue?
and what if we disable the user in existing domain, will it be authenticated then?
I think you could export users and tokens from the Identity Source where UserID maps to UPN.
https://community.rsa.com/docs/DOC-77476
https://community.rsa.com/docs/DOC-77031
Then create a new Identity Source mapped to SamAccountname
https://community.rsa.com/docs/DOC-45370
https://community.rsa.com/docs/DOC-47041
Cleanup and unlink the original Identity Source with UPN mapping,
Then import the Users and Tokens back into the Primary, and the import should find the same users based on all the other details such as first and last name, Distinguished Name, even their ObjectGUID should be the same, but they will now be mapped to SamAccountName. Users would need to logon with SamAccountNames now.
You may be able to do this:
overview: if users are in security console as upn (userid@domain1.com) and moving to (userid@domain2.com)
strip old domain information away from userid's,
export them,
clean system,
import users,
add domain info back
1) make a backup
2) authentication outage starts
3) edit ldap map page and map all users by samaccountname (userid only will be listed and not userid@domain1.com)
[this strips domain info from userid]
4) export users and tokens, export all users and tokens that are being converted to new domain
5) break the user search filter in operations console so no users are listed in security console but the connection still exists
example of broken user search filter: (&(objectClass=User)&(objectcategory=falseitem))
6) run a cleanup unresolvable users job, to erase all info about those ldap users, and put tokens into the
unassigned pile
7) unlink the old identity source
8) and create a new identity source connection in ops console for the new domain, link to system, map the userid as samaccountname and not UPN name
9) import the users and tokens and match them to the new identity source, you should find a match for each user and a warning for each that an unassigned token is being assigned to imported user (the report job for imported users and tokens will show how the import job ran and what any errors or warnings are about)
10) now edit the map page in operations console and switch to UPN name, now all users are listed with new domain info (userid@domain2.com) and now have all tokens assigned as before
11) authentication outage ends
Inorder to avoid a downtime you could standup a 3rd staging server import the backup from production server and then that acts as your source for exporting users and tokens so that the production is not disrupted.
thanks for all the replies.
and what if we disable the user in existing domain, will it be authenticated then?
because after sometime user will be coming from xyz.com domain only, it will be disabled in def.com domain?
If the user is disabled in external identity source then the user shall not be able to authenticate. I am assuming that your identity source linked to def.com are mapped to UPN ??
no, it is mapped to sAMACCOUNTNAME.
if user is disabled in RSA only, will it authenticate?
Also if i configure identity source of def.com domain as well, will the searching happen in this identity source or old one?
If the user if disabled in RSA, the authentications for that user shall fail.
Also if i configure identity source of def.com domain as well, will the searching happen in this identity source or old one? This needs more clarity, does this mean that your new server is going to have mappings to both domains and they shall be mapped to UserPrincipalName instead of samaccountname ?
yes, end of the deployment new server will have mapping to only xyz.com from where the user will come and most probably UserID will be mapped to samaccountname.
###correcting the staement###
so if i configure identity source of xyz.com domain as well, will the searching happen in this identity source or old one i.e. def.com?
Actually the purpose is:
"we have created a new domain xyz.com which is for new RSA setup but because new RSA setup is not yet build.
so to check and make it work client want to authenticate users of xyz.com domain with existing RSA setup where def.com identity source is configured."
thats why i aksed if we configure new domain identity source in existing domain , will it authenticate the user in case we disable the same user in existing RSA which use def.com identity source?
userID is mapped to samaccountname.
You may have xyz.com domain mapped to RSA AM with userprincipalname instead of samaccountname and this avoids duplication of accounts. This shall need some further investigation before making those configuration changes and hence it would be better if you can create a case with us to look into this further.
Refer 000036161 - How to open a technical support case via the Case Management portal on RSA Link
-Sri
It depends on how the external LDAP Identity Source is configured.
If the UserID maps to SamAccountName, it should not matter, because the domain is not used as part of the UserID
But if UserId maps to UPN, or email or something that contains the Domain, then this could be a problem, or difficulty for Authentication Manager in resolving the UserID