I have a CUCM currently sync'ing users via AD. A subsidiary company will also reside on this CUCM but have their own AD forest with a trust relationship. From what I can tell, I need LDS to do this:
What I'm unsure of is the process to convert AD to LDS on a live system. If there is documentation, please point me in the right direction. Here are the steps I've come up with:
- Install LDS w/Multiple forest support, but don't import users
- Use LDAP browser to ensure connection / credentials are good
During maintenance window:
- Delete LDAP directory from CUCM / I'm thinking users will become inactive
- Change LDAP system to LDS, set up new directory and filters
- Migrate a test group of users...make sure they sync...if so...import all...if not....should be easy to roll back from here. The test users imported should go from inactive to Active
- Migrate the rest of the users
- Test functionality (logins, Jabber, etc)
If someone has done something similar I'd love to hear your process, or if there are documented steps that would help too!
I'm looking at doing this as well. I've built a test environment (CUCM/CUC/CUPS and 2 different DCs for 2 domains, 1 AD-LDS server joined to the second domain) and am basically trying to do the same steps you outlined.
I'm having an issue on "Import the new object class to AD LDS" step listed in this article (this is just getting the AD users imported into AD-LDS from each domain).
I get the same error described in here:
Have you had any luck with this?
I'm looking to complete this on a production environment soon.
I just found the error is with this attribute, which is not in 2012R2 default user attributes, apparently:
No, my customer decided not to go forward with LDS. I do have another implementation in production...but I didn't not set that one up --- I looked through my old emails and I didn't see anything referencing that particular attribute. I did find this bug:
I am looking to do the same thing, convert from AD to LDS to support multiple forests. Using CUCM: 22.214.171.12400-52
Today we use AD directory integration with sAMAccountName as the LDAP Attribute for User ID. If we switch to LDS, I imagine I would use mail or uid for the LDAP Attribute for User ID.
I have read through this guide as well:
My question is where most of the phones, Jabber CSF accounts, buddy list for Jabber, etc are associated today to the sAMAccountName, when the switch to LDS is made on CUCM, what happens to all those associations?
I would like to hear if anyone done this in a production environment and if so were there any other significant impacts?
Thanks for any help and guidance.