What's the maximum number of LDAP Directories configurable in CCM 7?

Answered Question
Mar 8th, 2010

Hey guys,

Does anyone know the maximum number of LDAP directories configurable in CCM7?

I have a client that has users spread across about 25 OU's.

Any recommendations?  Is there a server that could gather all of these accounts and serve them up to CCM under just one context?

I have this problem too.
0 votes
Correct Answer by David Hailey about 6 years 9 months ago

You can configure up to 5 LDAP agreements.  In your case, you'll need to set your search at the root and then use AD permissions to deny the LDAP user the ability to see objects it shouldn't see.

Hailey

Please rate helpful posts!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Correct Answer
David Hailey Mon, 03/08/2010 - 18:33

You can configure up to 5 LDAP agreements.  In your case, you'll need to set your search at the root and then use AD permissions to deny the LDAP user the ability to see objects it shouldn't see.

Hailey

Please rate helpful posts!

WSonnylal Wed, 03/10/2010 - 06:11

So each agreement can point to a different search space or "OU" in LDAP?

David Hailey Wed, 03/10/2010 - 06:50

From the SRND, this pretty much sums up what you're asking but is official from Cisco:

The synchronization is performed by a process called Cisco DirSync, which is enabled through the Serviceability web page. When enabled, it allows one to five synchronization agreements to be configured in the system. An agreement specifies a search base that is a position in the LDAP tree where Unified CM will begin its search for user accounts to import. Unified CM can import only users that exist in the domain specified by the search base for a particular synchronization agreement.

So, you can only use type of import (i.e., AD, Sun, etc) - if you go AD, that's the only choice.  You can then set up separate agreements which specify specific OU's in AD that you'd like to search for users.

Again, in the original case of having 25 OU's, then you could consider the following:

Reorganization of the AD tree.  Break those 25 OU's into 5 logical groups or a single group (i.e., Users) where you'd set up an agreement for.  If you don't maintain AD, this isn't likely to happen.

You can set your search base as the root of the AD tree.  You would then need to use permissions within AD to limit the objects and containers that your LDAP Dir Sync user can actually access.  Again, this could get a bit involved depending on what you're dealing with in AD and, if you don’t control AD, you'll have to do some convincing here to get this done.  But this is an option and it works - have done it elsewhere.

Set the search base and get everything.  I don't recommend doing this unless you have no other alternative.

Hailey

Please rate helpful posts!

Adam Richardson Tue, 06/08/2010 - 08:03

"You can set your search base as the root of the AD tree.  You would then need to use permissions within AD to limit the objects and containers that your LDAP Dir Sync user can actually access.  Again, this could get a bit involved depending on what you're dealing with in AD and, if you don’t control AD, you'll have to do some convincing here to get this done.  But this is an option and it works - have done it elsewhere."

I am being told by the customer's AD support that this cannot be done.  Where can I find how to accomplish this in AD?

Any assistance would be great.

Thanks,

~Adam

William Bell Tue, 06/08/2010 - 08:15

The only other alternative is to leverage LDAP filtering.  Essentially, identify an attribute that you can (or have already) set on all use objects that you may be interested in and then add that attribute to the LDAP filtering string.  In CUCM 7x, this isn't straight forward but is possible and would be supported by TAC.  In CUCM 8.x the GUI has been updated to include an easier modification.  More on this in a sec.

I have customers that have used an attribute like ipPhone or employeeID to filter out use objects they want to replicate.  You could also use one of the built-in AD "custom" attributes or add your own.  The idea is that you use an attribute which can be properly captured in an LDAP search query.  You also make sure that the attribute(s) capture the users you want and (by definition) filter those you don't.

Again, with CUCM 7x you have to jump through an extra hurdle.  But it isn't all that bad.  I wrote up an example on how to do it here:

http://www.netcraftsmen.net/resources/blogs/axl-sql-toolkit-part-3-updating-cucm-dirsync-ldap-filter-by-example.html

HTH.

Regards,
Bill

Please remember to rate helpful posts.

David Hailey Tue, 06/08/2010 - 13:50

Yeah, to clarify - what your customer is likely telling you is not that what you proposed cannot technically be done.  The translation is probably closer to "we're not doing that".  What was noted can be done; however, it requires buy-in from the folks that management that environment to put the proper permissions in place for the DirSync account to only read the objects that are desired.  It's not uncommon to get push back on that.

So, Bill provides an alternative to that and his blog is really good.  I won't elaborate on that further because the blog is very detailed and worth the read.

The last thing is that if you read from the root and the customer doesn't buy-in to filtering what is pulled into CUCM by setting the appropriate permissions then you'll essentially pull in users, service accounts, and so on.  When they look in the corporate directory and notice the first sign of "junk" (or something they don't think should be in the corporate directory on the phone) then you'll be able to explain how it got there.

Hailey

Please rate helpful posts!

Actions

This Discussion

Related Content