How to Configure Unified Communication Manager Directory Integration in a Multi-Forest Environment

Document

Apr 29, 2011 12:21 AM
Apr 29th, 2011

Introduction

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

Prerequisites

1. Requirements

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.

2. 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.

3. Conventions

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:

ucm-multi-forest-01.gif

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

ucm-multi-forest-02.gif

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

ucm-multi-forest-03.gif

In our example, company Cisco (Forest 2) has two domains: Forest root domain called CISCO (DNS cisco.com), and a sub-domain called EMERG (DNS emerg.cisco.com). 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
  3. ucm-multi-forest-04.gif

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

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

    Figure 4: Trusts Tab

    ucm-multi-forest-05.gif

    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

      ucm-multi-forest-06.gif

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

    Figure 6: Trust Type

    ucm-multi-forest-07.gif

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

    Figure 7: Direction of Trust

    ucm-multi-forest-08.gif

  8. 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

    ucm-multi-forest-09.gif

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

    Figure 9: User Name and Password

    ucm-multi-forest-10.gif

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

    Figure 10: Outgoing Trust Authentication Level—Local Forest

    ucm-multi-forest-11.gif

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

    Figure 11: Confirm Outgoing Trust

    ucm-multi-forest-12.gif

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

    Figure 12: Properties Window, Trusts Tab

    ucm-multi-forest-13.gif

    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.

  2. Figure 13: Server Manager

    ucm-multi-forest-14.gif

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

    Figure 14: Select Server Roles

    ucm-multi-forest-15.gif

    AD LDS services installation.

    Figure 15: Installation Progress

    ucm-multi-forest-16.gif

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 leavingcisco.com.

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

    ucm-multi-forest-17.gif

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

    Figure 17: Setup Options Window

    ucm-multi-forest-18.gif

  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

    ucm-multi-forest-19.gif

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

    Figure 19: Ports Window

    ucm-multi-forest-20.gif

  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

    ucm-multi-forest-21.gif

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

    Figure 21: Service Account Selection

    ucm-multi-forest-22.gif

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

    Figure 22: AD LDS Administrators

    ucm-multi-forest-23.gif

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

    Figure 23: Importing LDIF Files

    ucm-multi-forest-24.gif

    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

    ucm-multi-forest-25.gif

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

    Figure 25: Load target schema

    ucm-multi-forest-26.gif

  4. Choose File > Load base schema.

    Figure 26: File > Load base schema

    ucm-multi-forest-27.gif

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

    Figure 27: Load base schema

    ucm-multi-forest-28.gif

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

    Figure 28: Mark all non-present elements as included

    ucm-multi-forest-29.gif

  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

    ucm-multi-forest-30.gif

    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 leavingcisco.com for additional ldifde options and command formats.

    Figure 30: Importing the LDIF Schema

    ucm-multi-forest-31.gif

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
defaultSecurityDescriptor:
D:(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)S:
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

dn:
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

    ucm-multi-forest-32.gif

  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"?>
    <doc>
    <configuration>
    <description>cisco.com</description>

    <security-mode>object</security-mode>
    <source-ad-name>cisco.com</source-ad-name>
    <source-ad-partition>dc=cisco,dc=com</source-ad-partition>
    <source-ad-account></source-ad-account>
    <account-domain></account-domain>

    <target-dn>dc=cisco,dc=com</target-dn>
    <query>
    <base-dn>dc=cisco,dc=com</base-dn>
    <object-filter>
    (&#124;(&amp;(objectClass=user)(objectCategory=person))
    (&amp;(objectClass=user)(isDeleted=TRUE)))
    </object-filter>

    <attributes>
    <include>objectSID</include>
    <include>mail</include>
    <include>userPrincipalName</include>
    <include>middleName</include>

    <include>manager</include>
    <include>givenName</include>
    <include>sn</include>
    <include>department</include>
    <include>telephoneNumber</include>

    <include>title</include>
    <include>homephone</include>
    <include>mobile</include>
    <include>pager</include>
    <include>msDS-UserAccountDisabled</include>

    <include>samAccountName</include>
    <include>employeeNumber</include>
    <exclude></exclude>
    </attributes>
    </query>
    <user-proxy>

    <source-object-class>user</source-object-class>
    <target-object-class>userProxy</target-object-class>
    </user-proxy>
    <schedule>
    <aging>
    <frequency>0</frequency>

    <num-objects>0</num-objects>
    </aging>
    <schtasks-cmd></schtasks-cmd>
    </schedule>
    </configuration>
    <synchronizer-state>
    <dirsync-cookie></dirsync-cookie>

    <status></status>
    <authoritative-adam-instance></authoritative-adam-instance>
    <configuration-file-guid></configuration-file-guid>
    <last-sync-attempt-time></last-sync-attempt-time>
    <last-sync-success-time></last-sync-success-time>
    <last-sync-error-time></last-sync-error-time>

    <last-sync-error-string></last-sync-error-string>
    <consecutive-sync-failures></consecutive-sync-failures>
    <user-credentials></user-credentials>
    <runs-since-last-object-update></runs-since-last-object-update>
    <runs-since-last-full-sync></runs-since-last-full-sync>
    </synchronizer-state>

    </doc>
  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., cisco.com).

    • <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

    ucm-multi-forest-33.gif

  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

    ucm-multi-forest-34.gif

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

    Figure 33: Create New Object

    ucm-multi-forest-35.gif

  5. Select a class of user. Click Next.

    Figure 34: Select New User Class

    ucm-multi-forest-36.gif

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

    Figure 35: Name an Object Attribute

    ucm-multi-forest-37.gif

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

    Figure 36: Reset New User Password

    ucm-multi-forest-38.gif

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

    Figure 37: Enable New User

    ucm-multi-forest-39.gif

  9. Browse to the msDS-UserAccountDisabled attribute.

    Figure 38: Attribute Editor for User Account

    ucm-multi-forest-40.gif

  10. Choose Edit and change the value to False.

    Figure 39: Boolean Attribute Editor

    ucm-multi-forest-41.gif

  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

    ucm-multi-forest-42.gif

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

    Figure 41: Attribute Editor for member Attribute

    ucm-multi-forest-43.gif

  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

    ucm-multi-forest-44.gif

  15. Update the schema and restart AD LDS.

    Figure 43: Update Schema Now

    ucm-multi-forest-45.gif

    Figure 44: Restart AD LDS

    ucm-multi-forest-46.gif

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.)

    ucm-multi-forest-52.gif

  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.

    ucm-multi-forest-53.gif

  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 leavingcisco.com.

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

      ucm-multi-forest-47.gif

    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

      ucm-multi-forest-48.gif

  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

(&(objectClass=user)(!(objectClass=Computer))(!(msDS-UserAccountDisabled=TRUE)))

Create the Custom Filter (Required):

(&(objectClass=userProxy)(!(objectClass=Computer))(!(msDS-UserAccountDisabled=TRUE)))

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


--

Average Rating: 5 (4 ratings)

Comments

Ahmed Elnagar Sun, 11/27/2011 - 03:59

I have a question here.

I have two domains; say for example cisco.com and webex.com

I am integrating with ADAM using SAMAaccount

I have the following users

voice@cisco.com and voice@webex.com; cisco.com user has extension 4000 and webex.com 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?

williamsmj7@car... Mon, 11/28/2011 - 01:01 (reply to Ahmed Elnagar)

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 (voice@cisco.com and voice@webex.com).

Mike

gabrielsroka Fri, 12/02/2011 - 15:58
  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.

Thanks.

tikhonovoleg Fri, 12/09/2011 - 01:44

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.

Cheers.

csco11063007 Mon, 10/01/2012 - 11:03

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

Thanks in advance

steve.blunt Tue, 02/19/2013 - 02:41

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

Thanks

shkhande Tue, 09/10/2013 - 07:13

Hi,

I have two domains having different forest  T1.com  ,T2.com and i am integrate ADAM server on a doamin test.com.

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 T1.com

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

perrymcgrew Tue, 11/26/2013 - 10:29

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.

Thanks....

mdflowers Tue, 12/03/2013 - 10:36 (reply to perrymcgrew)

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.

mdflowers Mon, 04/21/2014 - 13:28 (reply to mdflowers)

We just completed the migration to ADAM and it was pulled off without a hitch.

 

After some extensive testing, we were comfortable that even though you get a message that ALL user accounts will be deleted, when you remove the LDAP Directory, they are only marked "Inactive" until the garbage process runs at 3 AM (hard coded local time), at which point they are marked "Pending Delete". At the next run of the garbage process, they are deleted. Since this change only takes less than one hour, this isn't an issue.

We removed the old LDAP Directory that pointed to a single forest AD and created the new one to point to ADAM and did a full sync. All "Inactive users became "Active" and we were back up in less then 1 hour.

The key here is to Leave the Directory Source listed as Active Directory, even though you are using ADAM or LDS.

 

tpfrankli Mon, 04/21/2014 - 13:39 (reply to mdflowers)

Thanks for the followup that gives me some hope for doing this in my environment. I've been running some tests with 8.6 and even changing the Directory from Active Directory over to ADAM the inactive users still seem to get marked active as long as the UserID matches.

mdflowers Mon, 04/21/2014 - 13:48 (reply to tpfrankli)

That is exactly right, as long as that userid stays the same, they come back as active. We even did an expert of the CUCM user DB and the GUID is unchanged as long as the userid field stays the same (SamAccountName).

mdflowers Tue, 12/03/2013 - 09:53

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!

perrymcgrew Wed, 12/04/2013 - 05:09

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!

Perry

mdflowers Wed, 12/04/2013 - 05:59 (reply to perrymcgrew)

We completed a start to finish test yesterday and here is what we found:

Step one, we deleted all users in test environment along with all LDAP connections. We then configured an LDAP connection to the "old" domain and ran the sync. This imported all 1900 users that are within the range of the filter I specified. We then configured a few of those users with device associations, group membership and IPCC Extension. The selected users were then assigned some skills and resource groups in the UCCX.

Step two was to delete the current LDAP connection, which set all of the users to "Inactive". As I understand it, the users are not deleted until the garbage process runs. (we are trying to determine when that process runs)

The users that we set up in UCCX we place in an "Inactive" state and were not showing as a resource.

Step three, we created the connection to ADAM and ran the sync process. That brought in an additional 400 or so users (which was expected) and marked ALL users Active once again.

When we looked at the test users that were configured in UCCX, they went from the "Inactive" container to "Active" as a resource. All device associations were maintained.

Questions that remain:

1. When does the garbage process run

2. Each user has GUID which seems to be unchanged in UCM, but in our case will change when they finally migrate from "old domain" to "new domain". Are the GUIDs assigned by UCM and domain memberships ignored, as long as the USERID remains unchanged, or are the GUIDs part of the record that gets imported from AD/ADAM or are they assigned by the UCM

3. What is e preferred method of backing up the UCM/UCCX in the event we need to roll back

We are also going to open a TAC case and run this by them.

Any thoughts are welcome....

tpfrankli Mon, 04/21/2014 - 13:16 (reply to mdflowers)

Any further word on this? I'm doing the exact same thing. My only other thought is to wait for 10.x of CUCM and then convert all my AD users into local users change the LDAP sync then change them all back.

Actions

Login or Register to take actions

This Document

Posted April 29, 2011 at 12:21 AM
Stats:
Comments:20 Avg. Rating:5
Views:26253 Contributors:13
Shares:1

Related Content

Documents Leaderboard