Showing results for 
Search instead for 
Did you mean: 
Greeshma Bernad
Cisco Employee
Cisco Employee





This document discusses how to configure Unified Communication Manager Directory Integration in a Multi-Forest Environment.







Ensure that you meet these requirements:


  • Have knowledge of deploying and configuring Cisco Unified Communications Manager directory integration.

  • Are responsible for deploying, configuring, and maintaining Microsoft Active Directory Application Mode 2003 or Microsoft Active Directory Lightweight Directory Services 2008.

  • Your number of User Accounts to be synchronized does not exceed 60,000 accounts per Unified CM Publisher. When more than 60,000 accounts need to be synchronized, the IP Phone Services SDK must be used to provide a custom directory. Refer to the Cisco Developer Network for additional details.


Note: LDAP authentication user search base must match the ADAM domain as well as if the search base shows "LDAP user search base is formed using the User ID information" you have selected an attribute that cannot be used.


Components Used



The information in this document is based on these software and hardware versions:


  • Cisco Unified Communications Manager, Release 8.0(1), or later

  • Microsoft Active Directory Application Mode 2003 or Lightweight Directory Services 2008


The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.






Refer to the Cisco Technical Tips Conventions for more information on document conventions.



Background Information



Microsoft Active Directory Lightweight Directory Service (AD LDS), formerly known as Active Directory Application Mode (ADAM), can be used to provide directory services for directory-enabled applications. Instead of using your organization’s Active Directory Domain Service (AD DS) to store the directory-enabled application data, AD LDS can be used to store the data. AD LDS can be used in conjunction with AD DS, so that you can have a central location for security accounts (AD DS) and another location to support the application configuration and directory data (AD LDS). Using AD LDS, you can reduce the overhead associated with Active Directory (AD) replication. You do not have to extend the AD schema to support the application, and you can partition the directory structure, so that the AD LDS service is only deployed to the servers that need to support the directory-enabled application.



Many differences exist between ADAM and Active Directory. ADAM can only deliver some of the AD functions, as shown here:





This document describes the mechanisms that allow Cisco Unified Communications Manager (Unified CM), or any other Cisco products that use the Cisco Unified CM Directory Integration Service (DirSync), to get user information and perform authentication from different AD forests, that can exist in different forests. To achieve this objective, we use ADAM, which can synchronize its user database with different AD domain controllers or other Lightweight Directory Access Protocol (LDAP) sources.



ADAM can create a database of users and store the user details. Single Sign On (SSO) functionalities are desired to avoid end users having to maintain different sets of credentials in different systems; therefore, ADAM bind redirection is used. ADAM bind redirection is a special function for applications that support LDAP bind as an authentication mechanism. In some cases, the special schema, or naming context, may force you to avoid AD, making ADAM a necessary choice.



A special user proxy object in ADAM maps to a regular AD user account. The user proxy does not have an actual password stored in the ADAM object itself. When performing its normal bind operation, the application checks the ID locally but checks the password against Active Directory in the background, as Figure 1 illustrates. The application does not need to be aware of this AD interaction


Figure 1: ADAM User Proxy Password Authentication




ADAM bind redirection should be used only in special cases where an application can perform a simple LDAP bind to ADAM. However, the application still needs to associate the user with a security principal in AD.


ADAM bind redirection occurs when a bind to ADAM is attempted using a special object called a proxy object. A proxy object is an object in ADAM that represents a security principal in AD. Each proxy object in ADAM contains the SID of a user in AD. When a user attempts to bind to a proxy object, ADAM takes the SID that is stored in the proxy object, together with the password that is supplied at bind time, and presents the SID and the password to AD for authentication. A proxy object in ADAM does not store a password, and users cannot change their AD passwords through ADAM proxy objects.


The password is presented in plain text to ADAM because the initial bind request is a simple LDAP bind request. For this reason, an SSL connection is required by default between the directory client and ADAM. ADAM uses Windows Security APIs to present the password to AD.


For more information about bind redirection, refer to Understanding ADAM bind redirection.


Note: The requirement for SSL when using bind redirection should not be disabled in a production environment.


Active Directory Multiple Forest Support Scenario in Unified CM


For the purpose of explaining the method, we imagine a scenario where Cisco Systems (Forest 2) has acquired two other companies: WebEx (Forest 1) and Tandberg (Forest 3). In the migration phase, we integrate the AD structure of each company, which allows the deployment of a single Cisco Unified Communications cluster.


Figure 2: Example of Multi-Forest Scenario





In our example, company Cisco (Forest 2) has two domains: Forest root domain called CISCO (DNS, and a sub-domain called EMERG (DNS Both domains have a domain controller (DC) that is also a Global Catalog, and each one is hosted in Windows 2008 Server SP2.


Company WebEx (Forest 1) has a single domain with a DC that is also a Global Catalog, and it is hosted in Windows 2003 R2 Server SP2.


Company Tandberg (Forest 3) has a single domain with a DC that is also a Global Catalog, and it is hosted in Windows 2008 Server SP2.


AD LDS is installed in the DC for domain CISCO; in fact, any machine anywhere in one of the three forests can be used. The DNS infrastructure must be in place such that domains in one forest can communicate with domains in other forests and can establish the appropriate trust relationships and validations between the forests.


Domain Trust Relationship


For the authentication of the users to succeed, you need to have a trust between the domain where the ADAM instance is hosted and the other domain(s) that hosts the user accounts. This trust can be a one-way trust if required (outgoing trust from the domain that hosts the ADAM instance to the domain(s) that host the user accounts). Thus, the ADAM instance can forward the authentication requests to DCs in those account domains.


Furthermore, you need a user account from both account domains that have access to all attributes of all user accounts in the domain. ADAMSync uses this account to synchronize the account domain users to ADAM.


Finally, the machine that runs ADAM must be able to find all domains (DNS), find domain controllers in both domains (using DNS), and connect to these DCs.


Perform these steps to set up the inter trust relationships:


  1. Open Active Directory Domains and Trusts, choose the domain that hosts AD LDS, right-click on the domain, and choose Properties.


  2. Figure 3: Active Directory Domains and Trusts Window

  4. ucm-multi-forest-04.gif

  5. Note: The domain functional level and the forest functional level should specify 2003 or higher.

  6. Go to the Trusts tab, and click New Trust.


    Figure 4: Trusts Tab



    1. Follow the wizard and provide the name of the domain with which you want to establish the trust and click Next.


      Figure 5: New Trust Wizard Name Entry



  7. In the Trust Type window, choose Forest trust and click Next.


    Figure 6: Trust Type



  8. In the Direction of Trust window, choose One-way: outgoing (required) and click Next.


    Figure 7: Direction of Trust



  9. In the Sides of Trust window, allow the wizard to configure both domains. To do so, choose Both this domain and the specified domain and click Next.


    Figure 8: Sides of Trust



  10. In the User Name and Password window, provide the credentials for the other domain. Click Next.


    Figure 9: User Name and Password



  11. In the Outgoing Trust Authentication Level—Local Forest window, choose Forest-wide authentication. Click Next.


    Figure 10: Outgoing Trust Authentication Level—Local Forest



  12. In the Confirm Outgoing Trust window, choose Yes, confirm the outgoing trust and click Next.


    Figure 11: Confirm Outgoing Trust



    This displays after you run this process for both the Tandberg and WebEx domains:


    Figure 12: Properties Window, Trusts Tab



    The emerg domain displays by default, because it is a child domain.


Install AD LDS


Perform these steps to install AD LDS:


    1. Open Server Manager, click Roles, and choose add New.


Figure 13: Server Manager



  1. In the Select Server Roles window, choose Active Directory Lightweight Directory Services and click Next.


    Figure 14: Select Server Roles



    AD LDS services installation.


    Figure 15: Installation Progress




Install the Instance for Multiple-Forest Support


AD LDS can run different instances of the services with different ports, which allows for different user directory “applications” to be run on the same machine. By default, AD LDS chooses ports 389/LDAP and 636/LDAPS. If the system already has any kind of LDAP services running, however, it uses ports 50000/LDAP and 50001/LDAPS. Each instance has a pair of ports that increment based on the previous numbers used.


In some cases, due to a Microsoft bug, the ports are already in use by the Microsoft DNS server and the instance wizard shows an error, which is not self explanatory. To resolve this error, reserve the ports in the tcp/ip stack. If you find this problem, refer to AD LDS service start fails with error "setup could not start the service..." + error code 8007041d


Perform these installation steps:


  1. In the Server Manager, choose Roles > AD LDS.

  2. Choose Click here to create an AD LDS instance.


    Figure 16: Active Directory Lightweight Directory Services Window



  3. In the Setup Options window, choose A unique instance. Click Next.


    Figure 17: Setup Options Window



  4. In the Instance Name window, provide the name of the instance. In our example, this is MultiForest. Click Next.


    Figure 18: Instance Name Window



  5. In the Ports window, choose the ports or allow the system to choose them for you. Click Next.


    Figure 19: Ports Window



  6. In the Application Directory Partition window, provide a partition name for the instance. Do not provide a "CN" such as the one provided in the example of the wizard, because most of the time that will create an error in the Schemas. In our scenario, we choose the same partition as the AD DC that hosts AD LDS (dc=Cisco,dc=com). Click Next.


    Figure 20: Application Directory Partition



  7. In the Service Account Selection window, provide an account to start the server. Click Next.


    Figure 21: Service Account Selection



  8. Provide the name of the user that has administrative permissions. Click Next.


    Figure 22: AD LDS Administrators



  9. Import the highlighted default LDIF files to build the schema. Click Next.


    Figure 23: Importing LDIF Files



    Note: If ADAM is being installed on a Windows 2003 server, Figure 23 shows only four options: MS-AZMan.LDF, MS-InetOrgPerson.LDF, MS-User.LDF, and MS-UserProxy.LDF. From these four, select only MS-User.LDF and MS-InetOrgPerson.LDF.


Copy the Schema from Each Domain to ADAM


This process needs to be repeated for each domain for which you need to synchronize. This example only shows the process against one of the domains in the scenario.


Perform these steps:


  1. Open the AD DS/LDS schema analyzer (ADSchemaAnalyzer.exe) in the directory C:\windows\adam.

  2. Choose File > Load target schema.


    Figure 24: AD DS/LDS Schema Analyzer



  3. Provide the credentials of the source AD DC from which you want to import.


    Figure 25: Load target schema



  4. Choose File > Load base schema.


    Figure 26: File > Load base schema



  5. Specify the AD LDS to which you want to connect and extend the schema.


    Figure 27: Load base schema



  6. Choose Schema > Mark all non-present elements as included.


    Figure 28: Mark all non-present elements as included



  7. Choose File > Create LDIF file. In this example, the file being created via this step is diff-schema.ldf. To simplify the process, the file should be created in C:\windows\adam.


    Figure 29: Create LDIF file



    One option to help organize the files that need to be generated is to create a separate directory. This directory allows the files to be separated from the main C:\windows\adam directory.

  8. Open a command prompt and create a log directory in the C:\windows\adam directory:

    cd \windows\adam
    mkdir logs
  9. Import the ldif schema (created using the ADSchemaAnalyzer) to AD LDS:

    ldifde -i -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext -f diff-schema.ldf -j c:\windows\adam\logs

    Refer to Using LDIFDE to import and export directory objects to Active Directory for additional ldifde options and command formats.


    Figure 30: Importing the LDIF Schema




Extend the AD LDS Schema with the User-Proxy Objects


The object for the proxy authentication needs to be created and the object class user is not used. The object class being created, userProxy, allows the bind redirection. The object class detail needs to be created in an LDIF file. The file is a creation of a new file, which in this example, is MS-UserProxy-Cisco.ldf. This new file is generated from the original MS-UserProxy.ldf and edited, using a text editor, so that it has this content (or see Attachments at the end of this document):


# @@UI-Description: AD LDS simple userProxy class.
# This file contains user extensions for default ADAM schema.
# It should be imported with the following command:
# ldifde -i -f MS-UserProxy-Cisco.ldf -s server:port -b username domain password -k -j . -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
dn: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: top
objectClass: classSchema
cn: User-Proxy
subClassOf: top
governsID: 1.2.840.113556.1.5.246
schemaIDGUID:: bxjWYLbzmEiwrWU1r8B2IA==
rDNAttID: cn
showInAdvancedViewOnly: TRUE
adminDisplayName: User-Proxy
adminDescription: Sample class for bind proxy implementation.
objectClassCategory: 1
lDAPDisplayName: userProxy
systemOnly: FALSE
possSuperiors: domainDNS
possSuperiors: organizationalUnit
possSuperiors: container
possSuperiors: organization
defaultHidingValue: TRUE
defaultObjectCategory: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
systemAuxiliaryClass: msDS-BindProxy
systemMayContain: userPrincipalName
systemMayContain: givenName
systemMayContain: middleName
systemMayContain: sn
systemMayContain: manager
systemMayContain: department
systemMayContain: telephoneNumber
systemMayContain: mail
systemMayContain: title
systemMayContain: homephone
systemMayContain: mobile
systemMayContain: pager
systemMayContain: msDS-UserAccountDisabled
systemMayContain: samAccountName
systemMayContain: employeeNumber

changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1


Perform these steps:


  1. Save the MS-UserProxy-Cisco.ldf file in the C:\windows\adam directory.

  2. Import the new object class to AD LDS:

    ldifde -i -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext -f MS-UserProxy-Cisco.ldf -j c:\windows\adam\logs


  3. If ADAM is being installed on a Windows 2003 server, run this command as well:

    ldifde -i -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext -f MS-AdamSyncMetaData.ldf -j c:\windows\adam\logs


Import the Users from AD DC to AD LDS


The user from each domain now needs to be imported to AD LDS.


Note: This step needs to be repeated for each domain that needs to synchronize. This example only shows the process against one of the domains.


Perform these steps:


  1. Starting with the original MS-AdamSyncConf.xml, create an XML file for each domain that needs to be synchronized and modify the file with the details specific to each domain to have the following content:

    <?xml version="1.0"?>











  2. In this file, these tags should be replaced to match the domain:

    • <source-ad-name> - Use the DNS name of the domain (e.g.,

    • <source-ad-partition> - Use the root partition from the source AD DC that you want to import from (for example dc=Cisco, dc=com, or dc=Tandberg, dc=com).

    • <base-dn> - Choose the container from which to import. For example, if all users of the domain are required, this should be the same as <source-ad-partition>, but if users are from a specific organizational unit (for example, Finance OU), it should be something like OU=Finance,DC=Cisco,DC=com.

  3. Save the newly created XML file in the C:\windows\adam directory.

  4. Open a command window:

    cd \windows\adam
  5. Run this command:

    ADAMSync /install localhost:50000 AdamSyncConfCisco.xml /log logs\install.log

    Note: The file AdamSyncConfCisco.xml is the newly created XML file.

  6. Synchronize the users with this command:

    ADAMSync /sync localhost:50000 "dc=cisco,dc=com" /log logs\sync.log

    The result should be something similar to Figure 31:


    Figure 31: User Synchronization Results



  7. To perform a periodic sync from AD to ADAM, use the Task Scheduler in Windows.

  8. Create a .cmd or .bat file with this content:

    cd \Windows\ADAM
    ADAMSync /install localhost:50000 AdamSyncConfCisco.xml /log logs\install.log
    ADAMSync /sync localhost:50000 "dc=cisco,dc=com" /log logs\sync.log
  9. Schedule the task to run the .cmd or .bat file as required. This ensures that additions, modifications, and deletions in AD also get reflected in ADAM.

  10. You can create another .cmd or .bat file and schedule it to perform a periodic sync from the other forest.


Create the User in AD LDS for Unified CM Synchronization and Authentication


Perform these steps:


  1. From the Administrator tools in the Start menu, open ADSI Edit.

  2. On the Action menu, choose Connect to.

  3. Connect to base DN of the AD LDS tree (DC=Cisco,DC=com) and specify the host and port where it is hosted (localhost:50000). Click OK.


    Figure 32: Connection Settings



  4. Right-click on the base DN, then choose New > Object.


    Figure 33: Create New Object



  5. Select a class of user. Click Next.


    Figure 34: Select New User Class



  6. In this example, “root” was chosen. (Any name can be chosen here.)


    Figure 35: Name an Object Attribute



  7. Provide a password for the new user, right-click on the user, and choose Reset Password.


    Figure 36: Reset New User Password



  8. Enable the new user, which is disabled by default. Right-click on the user and choose Properties.


    Figure 37: Enable New User



  9. Browse to the msDS-UserAccountDisabled attribute.


    Figure 38: Attribute Editor for User Account



  10. Choose Edit and change the value to False.


    Figure 39: Boolean Attribute Editor



  11. The new user needs to be added to one group that has read permission to the AD LDS. In this example, Administrators was chosen.

  12. Browse to the CN=Roles container, right-click on the CN=Administrators group, and choose Properties.


    Figure 40: Properties of CN=Administrators



  13. Browse to the member attribute, and click Edit.


    Figure 41: Attribute Editor for member Attribute



  14. Add the new Distinguished Name (DN) that was previously created (cn=root,dc=Cisco,dc=com) to this group.


    Figure 42: Add Distinguished Name



  15. Update the schema and restart AD LDS.


    Figure 43: Update Schema Now




    Figure 44: Restart AD LDS




Configure Bind Redirection


By default, binding to ADAM with bind redirection requires an SSL connection. SSL requires the installation and use of certificates on the computer that is running ADAM and on the computer that connects to ADAM as a client. If certificates are not installed in your ADAM test environment, you can disable the requirement for SSL as an alternative.


Note: Disabling the requirement for SSL for bind redirection causes the password of a Windows security principal to pass to the computer that is running ADAM without encryption. Thus, you should only disable the SSL requirement in a test environment.


By default, SSL is enabled. Perform these steps:


  1. Generate the certificate for ADAM/AD LDS. Consult Microsoft documentation for information regarding ADAM/AD LDS certification generation.

  2. Upload the ADAM/AD LDS certificate to the Unified CM. Refer to the Cisco Unified Communications Operating System Administration Guide for additional details.

  3. Choose the checkbox to use SSL in LDAP Directory page and LDAP Authentication page.

  4. Enter 50001 (in our example) for the LDAP port, which is the SSL port number given while installing ADAM/AD LDS instance.


To disable the SSL requirement for bind redirection, perform these steps:


  1. Click Start, point to Administrative Tools, and click ADSI Edit.

  2. On the Action menu, choose Connect to.

  3. Under computer, type localhost:50000 (This is the ADAM host and port.)




  4. Under Connection point, choose Select a well-known Naming Context > Configuration. Click OK.

  5. In the console tree, browse to this container object in the configuration partition: CN=Windows NT,CN=Services.

  6. Right-click CN=Directory Service, and then choose Properties.




  7. In Attributes, click msDS-Other-Settings, and then click Edit.

  8. In Values, click RequireSecureProxyBind=1, and then click Remove.

  9. In Value to add, type RequireSecureProxyBind=0, click Add, and then click OK.

  10. Restart AD LDS for the changes to take effect.


For more information, refer to Managing Authentication in ADAM


Configure Unified CM


ADAM/AD LDS synchronization and authentication is supported in Unified CM version 8.0(1) and later.


Perform these steps:


  1. Choose System > LDAP > LDAP System.

    Perform these steps in order to map the Cisco UserID to mail, employeeNumber, or telephoneNumber:

    1. Choose Microsoft Active Directory Application Mode.

    2. Choose from any of the following LDAP userid attributes: mail, employeeNumber, or telephoneNumber.


      Figure 45: LDAP System Configuration




    Perform these steps in order to map the Cisco UserID to samAccountName as the LDAP userid attribute:

    1. Choose Microsoft Active Directory (rather than Microsoft Active Directory Application Mode).

    2. Choose sAMAccountName from the LDAP userid attribute drop-down list.


      Figure 46: LDAP System Configuration



  2. Configure LDAP synchronization with the credentials of the user that was created in AD LDS (e.g., cn=root,dc=cisco,dc=com). If SSL is desired and the steps to use SSL have been completed, specify the appropriate port (e.g. 50001), and choose Use SSL.


    Figure 47: LDAP Directory



  3. Configure LDAP authentication with the credentials of the user that was created in AD LDS. If SSL is desired and the steps to use SSL have been completed, specify the appropriate port (e.g. 50001), and choose Use SSL.


    Figure 48: LDAP Authentication




Note: After the users from AD LDS have been synchronized into Unified CM, the users must be configured and assigned to the Standard CCM Users group. Any attempt with LDAP Authentication will fail if the users are not assigned to the user group.


Create a Custom LDAP Filter in Unified CM


The user object class is no longer being used; therefore, the LDAP filter needs to be changed to use userProxy instead.


The default filter must be changed.


Default Filter




Create the Custom Filter (Required):




Perform these steps in order to create the custom filter on Unified CM 8.0(1):


  1. Log in to Cisco Unified CM Administration using a web browser

  2. Select the LDAP Custom Filter option from the LDAP configuration menu.

  3. Create a new filter using the example above

  4. Save the filter

  5. Assign the filter to each applicable Synchronization Agreement


    Figure 49: LDAP Filter Configuration




This filter is used in the LDAP directory page while configuring LDAP synchronization agreement as shown in Figure 47.


Related Information




Level 5
Level 5

Hi Greeshma,

How are you? Very nice document.



Level 1
Level 1

I second that comment Ashok. This is a very informative document thanks for you efforts Gresshma!

Ahmed Elnagar
Level 1
Level 1

I have a question here.

I have two domains; say for example and

I am integrating with ADAM using SAMAaccount

I have the following users and; user has extension 4000 and is the same "they use dialing prefix to call each other as they are registered to the same CUCM".

Now they want to use the  extensio mobility service; user is going to enter his samaaccount and pin code on the phone...and samaaccount is the same!!! how CUCM is going to handle this case?

Level 1
Level 1

Hi Ahmed,

Hopefully someone who has tried this will comment but as you are using active directory you could get your users to sign into the extension mobility service with the User Principal Name (UPN) maybe?

So users would be signing in with exactley the names you specify above ( and


Community Member
  1. The MS-UserProxy-Cisco.ldf shown was incorrect. It was missing spaces, line feeds and a "-" at the end. I attached the LDIF (see Attachments) since things seem to get lost in the translation to HTML.
  2. Along the same vein, the command lines shown were wrapped so I unwrapped them.
  3. The screenshots are tiny. Any way to make them more legible? Putting them inline and large would be nice--having to click to enlarge and click again to close the screenshot gets annoying
  4. It looks like Figures 47-49 are missing.


Level 1
Level 1

Are there any implementation plans of other authentication methods besides LDAP bind (e.g. Kerberos)? IMO, LDS does not seem to be the most elegant solution.


Muhammad Raza
Level 3
Level 3

excellent and dedicated effort, bravo.

Level 1
Level 1

In this example,is it possible to hide tandberg's corporate directy information on a given number cisco employee telephone.?

Thanks in advance

Level 1
Level 1

This looks like it will help solve several issues with AD integration. Can I just clarify the following please and forgive me if I have missed any information to the post:

Is the solution one validated by Cisco and Supported via TAC?

Has the solution actually been implemented in a live production network?

I just need to clarify as there is no reference to this "fix" within the current Unified Communications Manager SRND


Level 1
Level 1

Wanted to add a couple things that were unique to my environment. Thanks Gabriel for this, helped a whole lot.

Cisco Employee
Cisco Employee


I have two domains having different forest  , and i am integrate ADAM server on a doamin

I am successfully able to sync the users of both the domains into the ADAM server.

now i am getting issue while authentication the users of domain T2 however i am successfully able to authenticate the users of domain

Error :

Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 576, v1db1

Error 0x8009030C The logon attempt failed.

Note :

1- i have created forest trust for both the domains.

2- Users sync by adamsync /sync of Doamin T1 created under  partitions of ADAM instance 1 . see beow pic

Doamin T2.png

3- Users of doamin T2 created under Users Role , see below pic

Doamin T1.png

Level 1
Level 1

I just had a 4 1/2 hour call with TAC over this Doc Setup,   We have an existing 9.1.x CUCM / IMP / CUC system and we are already MS AD Integrated in all our Cisco products .    We have assumed management of 2 other companies.  We have set up the Domain trusts between these new company's DCs an our Corporate DCs.   The trusts are working fine.

We did the LDS setup on one of our DC's which is supposed to allow CUCM etc. to allow users from these other domains to use CUCM / Jabber etc.   Very soon, I will need to extend our corporate CUCM to these other companies -- and they are keeping their respective AD domains.

Near the end of this document, the section, Configure Unified CM, is what causes us concerns and questions.  I understand I need to point CUCM to the DC where LDS is installed.  However, the LDAP System Configuration screen states I must delete ALL LDAP Directories BEFORE making any changes  and create the Microsoft ADAM or Lightweight Directory Services.  Well I have LDAP Userids associated in my Phones and in the DNs!  TAC says I must delete the definition and it will "break" the the userids I have already assocaites to ALL my devices and DN's.   Not acceptable (TAC agreed),  But what is just confusing is that in the same step it tells me to add back in the Microsoft Active Directory following the step where I defined the LDS.

TAC points out that this document was created from a lab environment and a "1st time setup" where this multi-forest environent pre-existing and not a live, CUCM setup in a single domain who must convert to multi-forest setup.   TAC beleives there are flaws in the doc and is going to go back and ask some more questions to TAC team members. 

I am hoping someone out here has done this change in a live existing environment and coment on the issues here.


Community Member

I have the same scenario and in our test environment, I still have not been able to edit the LDAP connection. What I have found is that after you delete the current connection you are warned that it will delete all users, however they are just marked Inactive.

I'll report back once the new connection is in place to see if they are once again marked Active.

Any other advise is appreciated!

Community Member

We are running into the same issue. I am running through a test and will post back when I'm through. In the event that you have this figured out I would love to hear about it.

Level 1
Level 1

Here is what TAC responded in the case I opened on this issue:

"I did some more research about the concern we had about deleting the users from CM, and in fact there is no

way to accomplish this in a smoother way since the deletion of users will cause the association with devices to be deleted.

If the users are maintained locally as we discusses they will authenticate with the CM and not the LDAP which is not desirable in your set up."

Basically, since this is a live environnment and we are already AD integrated, I can't get the LDS setup to work w/o major risks.  TAC said I could BAT export Phone / Users, do the LDS steps outlined in the doc (which breaks the current AD association to the devices), then use the BAT to import the file to reassociate the AD users to devices.   The other alternative was to add the users in the trusted domain to our AD domain -- which reallty makes no sense since that is why we have the trust between the 2 AD domains in the first place! 

The TAC engineer said he has checked this out with others in the dept and all are in agreement.   As it stands, I do not think we are going to try it since I really have done much with BAT and don't want to risk creating huge headaches in my live environment!

I am hoping someone can update this document  / process to reflect doing this in an established live environment!


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: