Just did this. The ldap search filter can be modified either through the sql command or (preferred) via the SOAP interface into CUCM via the axl toolkit. I had an 'official' Cisco doc on this but not handy. A quick google search yields the following, which looks close:
http://uccert.wikidot.com/forum/t-134148/ldap-filters
Basically,
1) Turn on SOAP server in servicibility
2) Point browser at axl toolkit on CUCM & download to pc with java installed
3) Grab & edit sample .xml file referenced on that site to suit your environment / needs
4) Run the full command line as found in the readme / other docs with axl toolkit. For -inputfile specify your newly modified xml file.
5)This all assumes you'd already configured LDAP and/or LDAP authentication and have enabled the dirsync process under servicibility. NOTE THAT YOU MUST STOP AND START DIRSYNC AFTER ANY CHANGE TO THE SEARCHFILTER
OK, now I'm going to be _really_ nice and throw out the caveats / things I found out the hard way.
1) When you initially configure LDAP, it'll check the credentials and complain right away if the user specified for LDAP interface doesn't work (bad password, etc)
2) Some idiot determined the data type / lenght for storing the search filter string in the CUCM database. It seems to have a limit (as of 7.0.2) of 256 characters. Now think what that means when your trying to search more than one group in your filter (since you can have only 1 ldap search filter). Think about that since you have to specify the full pathing for the OU and group names, etc. That's right, you run out of usable string length REAL fast.
We were trying to search 3 groups (normal users, CUCM administrators and a third group for future flexibility) and this led to breaking the search filter after having it working with 2 groups. A quick sql query confirmed that the string in the database had been trunkated at 256 characters.
I could probably hv backed the string down to two groups but was afraid that with even two, as I moved out to other hospitals for implementation that some of them had longer OU names, etc and might still run out of string space.
Did some more research and found a MS technet article about doing nested or recursive group searches in ldap filters. It involves inserting a special OID into the search filter string that 'tells it' to search recursively. Then I was able to take the CUCM-admins and my special-purpose group and just make those groups members of the main CUCM-users group for the site and the net effect was that users from all three groups were returned when searching just the CUCM-users group. I should MENTION that we did see some impact when we switched to the nested groups search string. The 'normal' string would search 30,000 users (from the top) and return appropriate group members in about a second. The nested groups search string actually takes about 7 seconds. Both of these are tested and timed using ldapsearch command from a linux box against activedirectory (recommend you get familiar with the tool or something similar for testing filters).
3) The "hardest" thing about getting through this the first time is figuring out the syntax to 'escape' any characters in the filter that need escaping (& is shown as an example but [before nesting] I had needed an | as well & it took some trying to figure that out.
4) You would think that this should apply to Unity Connection. Not exactly. Kept trying via SOAP / AXL and kept rejecting. Finally RTFM and found that the ldap filter is actually exposed in the web gui for direct entry (sans any escaping).
I guess it's too much to ask that unity connection being based on same appliance / os, have the same look, feel & function of CUCM. Too much to hope that the freaking BUs could walk across the hall and come to a 'standard' look, feel & operation. Despite John's concern and comments year after year at Networkers about BU coordination.
Hope this helps -Bill
