Communications Manager LDAP Groups Caveat

If you’re wanting to LDAP synchronize Active Directory distribution groups for use with Cisco Jabber you’ll want to pay close attention to the ‘Synchronize’ setting. This setting is found on the ‘LDAP Directory’ configuration page. TLDR – If you’re using different synchronization agreements for users and groups the user directory synchronization must also be selected for ‘Users and Groups’.

Why and what’s happening inside the DirSync service?

If the directory synchronization agreement is set for ‘Users Only’ the LDAP search filter looks like this:
LDAPUsers

If the directory synchronization agreement is set for ‘Users and Groups’ the LDAP search filter looks like this:
LDAPUsersandGroups

You’ll notice at the bottom of the second screenshot the ‘memberof’ attribute request. This is where the user synchronization agreement requests the all of the groups the user is a member of. This also means that if this is the first time you’re setting up the agreements you’ll have to synchronize groups and then users. If you’re adding groups you have to run a full sync on both agreements.

So again — if you’re using different synchronization agreements for users and groups because you’re looking in different containers both agreements need to be set for Synchronize: ‘Users and Groups’. Obviously if you’re using one synchronization agreement to import both users and groups in a single container you wouldn’t run into this little caveat.

I got tripped up on this recently because the setting would seemingly imply it’s what you’re importing and not the search filter. It took a couple of packet captures to figure it out. PCAP or didn’t happen!

CCM packet cap:
utils network capture eth0 file packetcap1 count 100000 size all

jabber

2 thoughts on “Communications Manager LDAP Groups Caveat

  1. I’ve been playing with this myself just now and am a bit baffled. You mentioned the use case of having two different directory sync agreements for users and groups. In my case I have configured one as OU=Groups,dc=ad,… since this container contains our replicated Unix groups which we use to group access. I left the user filter as . In a separate agreement, I leave the group filter as none and set the container as OU=People,dc=ad,… The people sync in but no groups ever seem to show up, even with it set to sync users and groups.

    I tried to game it by building a bogus filter with a non-existent object class in case it needs that, but, ultimately I can either move up to dc=ad, … and sync everything, which nets me 16k groups (not my mess, I promise!) or I just get the users and no groups.

    Is a split configuration actually something that functions without “preloading” groups or something or playing with the database? I’d have the same problem if we created a container for distribution groups specifically for this, I don’t want to sync the entire AD structure’s worth of items, and AD’s LDAP filtering just isn’t good enough (and this does not work with AD LDS per doc).

    I figured since the relationships are given unique ID values in the DB that this doesn’t really work in a split arrangement, but I don’t really know. Any thoughts?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.