11-09-2012 05:59 AM - edited 03-16-2019 02:06 PM
Hello,
I want to make an EMCC within a LDAP domain.
And I have a problem of LDAP selection and want to find a solution from you.
I explain :
1. There are two(2) CUCM clusters
2. In this cluster, there is a domain : Mydomain.local.
3. Inside this domain there are many organization units.
4. I want that some organization units(OU) authenticates in one CUCM cluster, and other OU authenticates on the seconf cluster.
Example : Team1&Team2 with CUCM-cluster1, and Team3&Team3 in CUCM-cluster2.
What can I insert in the field LDAP user search base in the LDAP authentication, so that these users can use EMCC.
regards,
Antra
11-09-2012 06:11 AM
You can configure up to 5 OUs for the LDAP sync in each CUCM, just configure the two OUs you need in each cluster.
OR point to the root, and use a user which ONLY has READ privileges on T1/T2 for Cluster A and a similar user for cluster B
HTH
java
if this helps, please rate
www.cisco.com/go/pdihelpdesk
11-09-2012 06:25 AM
Jamie,
Pointing to the root may not work. Because for EMCC to work, the users on each cluster must be unique. Pointin to the root will mean that all users in the domain will be available to both clusters.
So I suggest using different OU in his search base so that each cluster will have unique users
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
11-09-2012 07:04 AM
aokanlawon,
Jaime suggested to use two different users for the sync, that have read access to a different set of OUs. In that way it would only sync users for cluster 1 or cluster 2, hence they would be unique across the clusters.
Like this,
Syncuser_1 has read access to ou team1 and team 2. Syncuser_2 has read access to ou team3 and team 4. Cluster 1 uses syncuser_1 and cluster 2 uses syncuser_2, even if the ldap search point to the root only seen users will be synced to each cluster.
Please remember to rate helpful responses and identify helpful or correct answers.
11-12-2012 04:25 AM
Hello al,
Thank you very much for your replies.
Roger, so what is the string I have to enter in the "User Search base field".
If the LDAP authentication can use LDAP custom filter, then problem is resolved. But it is not the case in CUCM 8.6.
Is there any link for documentations about this syncuser?
aokanlawon,
Pointing to the root doesn't work. I already tried it along time ago.
And ho to use this different OU inside one string of LDAP search base?
The figure below give more complex LDAP. I've just added some organizational in subt-tree levels.
The request doesn't change : There is an LDAP
1. Team1 and Team2 have to authenticate in CUCM-Cluster1
2. Team3 and Team4 have to authenticate in CUCM-ClusterB.
What is the string in the LDAP search base on each LDAP authentication field parameter.
Regards,
Antra
11-12-2012 07:34 AM
In the LDAP Manager Distinguished Name you should use different users on the two clusters. For example CUCM_Cluster-A uses CUCM_sync_1@Mydomain.local and CUCM_Cluster-B uses CUCM_sync_2@Mydomain.local. On these users you set the right in AD to only have read access to the needed OU's. For example CUCM_sync_1 has read access only to ou=team1 and ou=team2. CUCM_sync_2 has read access only to ou=team3 and ou=team4. Then you set the LDAP User Search Base to point to the root of your AD, just as you have in your picture. This will result in that only seen users, restricted by the rights set in AD, will be synced to the two clusters.
Please remember to rate helpful responses and identify helpful or correct answers.
11-13-2012 04:48 AM
Hello,
Thanks for your support.
I understand now. And I've checked in the AD (Ms Win2008) but no success... for the moment.
I can't find where is the menu which send me on the LDAP-right-Access for the user.
I'll try find out and give you updates about this LDAP-user right on AD.
Regards,
Antra
11-13-2012 05:01 AM
The below is taken from this URL,
http://technet.microsoft.com/en-us/library/cc961985.aspx
In Active Directory, you can control which users have the right to perform a particular operation on an object or one of its properties just as you do in the NTFS file system—by setting permissions. However, there are certain operations that have semantics that are not tied to specific properties. These operations might also require access control. For example, you can grant users a Send As right that an email program can use to determine whether a particular user can send mail on another user's behalf. Access controls on custom actions or operations are called extended rights .
Extended rights are not defined by an access mask. Instead, each extended right is identified by a globally unique identifier (GUID). This GUID corresponds to a controlAccessRight object that is stored in the Extended-Rights container within a forest's Configuration container. An ACE that grants an extended right specifies a GUID corresponding to a particular controlAccessRight object.
The list of extended rights is not fixed. Developers can create new extended rights for custom operations by adding controlAccessRights objects to the Extended-Rights container for a forest. For information about creating extended rights, see the Microsoft Platform Software Development Kit (SDK) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources .
You can view the Configuration container and see the extended rights defined for your forest by using ADSI Edit. To see the complete set of extended rights defined for your forest, open ADSI Edit, connect to the Configuration container, and then click the Extended-Rights container. Figure 12.5 shows the Extended-Rights container for one forest.
Please remember to rate helpful responses and identify helpful or correct answers.
11-13-2012 07:29 AM
There is another way we have done this and you can explore that option too...
You can use AD attributes and filters on each cluster.... (in my cluster I use "extensionAttribute15")
For users that need to reside in Cluster 1, in AD configure an Attribute on each user such as this..
extensionAttribute15=CLA, then on the Custom filter in CUCM for Cluster A you will have this in addition to the rest of your defiled filters
(extensionAttribute15=CLA)....
And you will do this also for users going to cluster B...
AD attribute on user
extensionAttribute15=CLB
your custom filter in CUCM will be,
(extensionAttribute15=CLB)
Now when CUCM import these users from the root OU, it will apply the defined filter and will only import users matching the applied filters.
So cluster A will only have users enabled with AD attributes for that cluster etc
The only downside to this is from an admin perspective where when a user is added, depending on which cluster the user needs to reside on, this AD attribute will need to be filled in...
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide