Query about LDAP - 2 Directories

[pablo.beraldi]

Dear,

I have the following scenario.

1 LDAP authentication to AD 1
1 LDAP directory to AD1

Now, as the client wants to migrate from AD, what he was wanting is first to add 1 LDAP Directory pointing to a specific OU of AD2, to see if it brings me the user and what happens.

I configured it, it did not give an error but when I synchronize it does not bring anything.

Looking at the documentation, I know that a CUCM 12.5 can have more than 10 different directories, but only one authentication.

This is possible

What is configured is:
1 LDAP authentication to AD 1
1 LDAP directory to AD1
1 LDAP directory to AD2.

If yes, can you see in a log what is happening? why don't you bring me those users?

Thanks

[Jaime Valencia]

Are they in the same forest?

[pablo.beraldi]

I'm going to ask, since I don't know too much about active directory.

Now I ask you, if they are not in the same Forest, is it not possible to synchronize users?
As they are migrating domain, all these tests are to see the steps of change of domain, AD, and that everything continues to work.

[Jaime Valencia]

Yes, but you would need LDS/ADAM for that to work

Also, consider this:

For AD deployments, the ObjectGUID is used internally in Unified CM as the key attribute of a user. The attribute in AD that corresponds to the Unified CM User ID may be changed in AD. For example, if sAMAccountname is being used, a user may change their sAMAccountname in AD, and the corresponding user record in Unified CM would be updated.

With all other LDAP platforms, the attribute that is mapped to User ID is the key for that account in Unified CM. Changing that attribute in LDAP will result in a new user being created in Unified CM, and the original user will be marked inactive.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/directry.html

[pablo.beraldi]

If he had read that.
My idea was, so that the change is by parts the following.

In Domain 1 they are already working there I do not modify anything.
In domain 2 I asked to create SRV pointing to the hostA of the cluster.
I already have Jabber service discovery.
There is a relationship of trust between the two ADs, which is why they can already be logged in with DOminio2.
Now, domain 1 will be canceled at some point, for this my idea was to pass the users in production as local users.
Then synchronize with the new AD and see what happens with those user that brings me.
For that test it was what I was doing, but only with a specific OU where there were only two users.

Maybe what I should do is build a multi forest UCM?

https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-80/111979-ucm-multi-forest-00.html

What do you think?

Thanks.

[Jaime Valencia · Accepted solution]

Well, here's the thing. If they're on different forests, you cannot test that without LDS/ADAM. But in doing so, you would end up with a different ObjectGUID, so, you would need to basically do the same plan of turning users into local users prior to integrating again and depending on what you use for userID, might need to change a lot of things.

And if you don't want to have LDS/ADAM after the tests, then you'd have the same scenario if you want to have a single forest integration.

It would be up to you to choose which option would be best for you, you could also go with the plan of turning users into local and then integrate with the new AD, if the userIDs are the same, they would sync and become LDAP active.

[pablo.beraldi]

Thank you.

What I would do would be the following since the users who use jabber are 50.
Pass them to local users.
Put the password back on them.
Let them work locally while I sync the new AD.

Here comes the other point that I just saw. I have checked to pass a user to local and then I have re-synchronized the AD, this same user ID, it goes from local user to LDAP again.

I don't know if this same behavior will happen against a new AD that is in another Forest but that the user ID is the same.

Thanks