cancel
Showing results for 
Search instead for 
Did you mean: 

How to move users across different domain components in Active Directoty Using SAP IdM

0 Kudos

Hi Experts,

I am trying to move a user which is created under a domain component 'ou=testSAP,ou=test,dc=uk,dc=abc,dc=com' to 'ou=test_IdM,ou=test,dc=abc,dc=com'. Domain (ou=testSAP,ou=test,dc=uk,dc=abc,dc=com) is the child domain of later(ou=test_IdM,ou=test,dc=abc,dc=com) in Active Directory .

I am using modrdn to do the above operation however, I am facing below error while doing so.

Exception from Modify operation:javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100781, data 0, 1 access pointsref 1

please help me , if there is any way to achieve movement of users across multiple domain components.dc-changes.pngdc-changes2.png


Accepted Solutions (1)

Accepted Solutions (1)

former_member201064
Active Participant

Hello,

well, no. There's either the migration with ADMT or the re-creation in the newer domain with all AD groups in the other domain. We did both, nowadays my colleagues are using the ADMT and then I post-migrate them.

Here's what we did and how we do it now.

IdM batch job:

As I have an AD OU entry type I just needed to replace it from old to new domain and then rerun the creation with uProvision. And of course a delete on the old domain. Using a matching table I replaced AD groups from old to new domain. As I have only the own generated passwords from the initial load, I handed out a list with these for each migration.

From the IdM point of view it was quite easy, cannot remember any bigger problems I had with my jobs. From AD point, well... Some of the users worked normal on with their user, leave the usual stuff like password or smartcard issues out. Yet, some programs need to have the same GUID and / or sidHistory. After the fourth run with a total of not even 100 of some 6000 users this was seen as a problem too big to solve in masses. So it was decided to not continue that way.

ADMT migration:

Biggest advantage is that the history of the AD user stays as is (GUID in sidhistory set, someone correct me if I'm wrong). The ADMT seems to do a quite good job, from my point of view. I don't know if there are bigger issues then the "I cannot migrate, the mail address is there already". That can be prevented by asking the IdM guy (so, me) beforehand.

Then I have to go into the portal and cross-check some of our portal applications and if they now have the correct groups of the new domain.

I also have a "reprovision a user to all its groups" task which I can execute if needed. In the newer past that wasn't needed anymore.

The system/only privileges, the domain check boxes, the AD OU and DN/ACCOUNT attributes get adapted every night anyway, so not really something to do there for me.

From time to time someone asks me about the effort needed for the "rest" of the now 3-4000 something users (would have to check how many there are). I calculated roughly 5 minutes per user, 15 min for the IT users and 1 hour for special like AD team or me. 🙂

Conclusion:

Don't do it in IdM, only post-migration things.

Best regards

Dominik

Answers (1)

Answers (1)

normann
Advisor
Advisor
0 Kudos

Hello,

have you tried using the GUID instead of the DN as the identifier (first line)? Its the same when you want to change first or last name, its always better to use GUID. I know the standard connector does not use GUID, but its possible to extend the connector in a way that it uses the GUID instead of the DN.

Regards

Norman