When an AD (Active Directory) user object name is changed (userPrincipalName,sAMAccountName, or other attributes) and later another AD object is created with the original name of the first user object, a conflict in the LDAPSync'ed repository occurs.
This is caused by the fact that user_name attribute of the dm_user objects is not changed during LDAP Synchronization (by default user rename option is disabled in LDAP config object) - thus another object with same value can't be created (as this field is unique).
Another conflict situation could be when 1 repository is sync'ed against several AD domains and some user name values might be equal across domains.
The steps to solve this conflict are:
1. Rename the old user object in the repository
(user_login_name has changed while user_name still holds the old value).
For this: open DA, Users section, search for the user, right-click on it and choose Reassign User option.
In the Reassign field enter the new user name (should be current user_login_name value).
Select the option 'Run the Reassign job Now'.
If the user has locked objects, perhaps it's better to select Checked Out Objects Leave all locked (though if the user is inactive, perhaps it's better to unlock).
Press Ok to perform the changes, which will start the dm_UserRename job shortly.
2. Check the dm_UserRename job report
Search for the dm_UserRename job and check if it is running or already completed (after your change at step 1), or if it didn’t start yet (CS can be loaded with other jobs) wait until it runs. Notice that usually the job is in inactive state, but this is normal.
After the run has completed (see Last Run column value), view the job report (from context menu) and check that the user has been renamed, if there were some issues or if some repository objects still have references to the old value.
3. Run immediately the dm_LDAPSynchronization job (optional)
Running this job manually is not mandatory as it usually runs by schedule. However, if the user updates are urgent, the job can be run manually, but an additional trick must be performed in order to not disturb the time intervals of the synchronizations. Perform the following steps:
a) Retrieve the a_last_run and a_last_no from the ldap config object and store them:
DQL> select a_last_run,a_last_no from dm_ldap_config
a_last_run a_last_no
================ ============
20091105210022.0Z 195290415
b) Store the current value of dm_ldap_config.per_search_filter, then change it (to update only the 1 required user) to:
DQL> update dm_ldap_config object set per_search_filter='(&(userPrincipalName=MY_USER*)(mail=*))'
(assuming 'MY_USER' is the new user to be created, which failed due to the conflict. You can leave the old filter and just add an additional contidion: (userPrincipalName=MY_USER*) )
c) Run the dm_LDAPSynchronization job. Check the report and see if the user has been created properly. Also check the user is indeed created (using DA/samson/other client)
d) Restore previous ldap config object settings:
update dm_ldap_config object set a_last_run='20091105210022.0Z',set a_last_no='195290415', set per_search_filter='[ORIGINAL_VALUE]'
This is caused by the fact that user_name attribute of the dm_user objects is not changed during LDAP Synchronization (by default user rename option is disabled in LDAP config object) - thus another object with same value can't be created (as this field is unique).
Another conflict situation could be when 1 repository is sync'ed against several AD domains and some user name values might be equal across domains.
The steps to solve this conflict are:
1. Rename the old user object in the repository
(user_login_name has changed while user_name still holds the old value).
For this: open DA, Users section, search for the user, right-click on it and choose Reassign User option.
In the Reassign field enter the new user name (should be current user_login_name value).
Select the option 'Run the Reassign job Now'.
If the user has locked objects, perhaps it's better to select Checked Out Objects Leave all locked (though if the user is inactive, perhaps it's better to unlock).
Press Ok to perform the changes, which will start the dm_UserRename job shortly.
2. Check the dm_UserRename job report
Search for the dm_UserRename job and check if it is running or already completed (after your change at step 1), or if it didn’t start yet (CS can be loaded with other jobs) wait until it runs. Notice that usually the job is in inactive state, but this is normal.
After the run has completed (see Last Run column value), view the job report (from context menu) and check that the user has been renamed, if there were some issues or if some repository objects still have references to the old value.
3. Run immediately the dm_LDAPSynchronization job (optional)
Running this job manually is not mandatory as it usually runs by schedule. However, if the user updates are urgent, the job can be run manually, but an additional trick must be performed in order to not disturb the time intervals of the synchronizations. Perform the following steps:
a) Retrieve the a_last_run and a_last_no from the ldap config object and store them:
DQL> select a_last_run,a_last_no from dm_ldap_config
a_last_run a_last_no
================ ============
20091105210022.0Z 195290415
b) Store the current value of dm_ldap_config.per_search_filter, then change it (to update only the 1 required user) to:
DQL> update dm_ldap_config object set per_search_filter='(&(userPrincipalName=MY_USER*)(mail=*))'
(assuming 'MY_USER' is the new user to be created, which failed due to the conflict. You can leave the old filter and just add an additional contidion: (userPrincipalName=MY_USER*) )
c) Run the dm_LDAPSynchronization job. Check the report and see if the user has been created properly. Also check the user is indeed created (using DA/samson/other client)
d) Restore previous ldap config object settings:
update dm_ldap_config object set a_last_run='20091105210022.0Z',set a_last_no='195290415', set per_search_filter='[ORIGINAL_VALUE]'
No comments:
Post a Comment