Bulk Grant Access to Jabber

[broncosjkb]

Hello I have had this question for some time. I would like to know if there is an easy way to grant access to Jabber during an LDAP sync. Specifically if I can just add users to an AD group that when processed by CUCM, will give them the necessary permissions to access jabber.

I need to grant users access to jabber by adding them to the 'standard CTI enabled' and the 'standard CCM End Users' groups and selecting the two related check boxes on their user profile. The latter I am able to do through the Bulk admin tool but to add the users to the groups in mass, I must find the groups themselves and add user by department (not all depts get access to jabber so its not all users). This requires three separate actions; Bulk update, first group, second group. How can I automate this so when new users are added, I can grant them access without the administrative overhead?

[Jaime Valencia · Accepted solution]

CUCM 11.5+ where you configure the LDAP agreement in that same page you can add information under Group Information, rank, access controls groups and feature group template. That is only applicable for new users brought through that LDAP agreement and would affect anyone who is synced with it.

[broncosjkb]

Hey Jaime, thank you for the reply, I think this is what I am looking for. I went ahead and created a Group template. If I can apply that template and the groups to users that I put into an AD group, im set. I'm still wondering how to exactly tie that template + group info to an AD group specifically. The last two lines of that section reference directory numbers which these users will not have.

Do you possibly know of some good documentation regarding this section? 

Thank again!

James

[Nithin Eluvathingal]

You can apply both feature group template and access control group on LDAP directory page.  while synching new users the Feature and control groups will get applied. 

Add required informations on below fileds.

 

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/CUCM_BK_SE5DAF88_00_cucm-system-configuration-guide-1151/CUCM_BK_SE5DAF88_00_cucm-system-configuration-guide-1151_chapter_0100101.html

[Roger Kallberg · Accepted solution]

If you need to apply these settings for a specific group of people and base this on membership in a group in AD you’d need to create an LDAP filter and include this as one of the filter criteria’s. If you search the community for LDAP filters you’ll find quite a lot of posts around this. Once you have the filter you need to create another LDAP sync definition that runs before the current one. This is to have the settings set on the users that match the group and then also get the rest of the users into the system by the original LDAP sync definition. Remember as Java wrote that the settings are only set on the user during the very first sync, this is why you need to have the one that uses a filter to run before the other one.

One thing to keep in mind is that CM uses a default LDAP filter for AD, even if there are no filter defined in the system. When you create your own filter it’s recommended to include the content of this default filter as part of the custom filter. Have a look at at the CM system configuration guide for details on this.

[broncosjkb]

Hey Thanks everybody! I did end up getting this sorted out. For anyone else with this issue, here is what I did.

Created an AD group

Created an LDAP custom filter to grab that group

Created and additional LDAP directory config using the new filter

On this directory, I added the group info (Access Control groups and my Jabber template) and hit save

Now this new synch runs one hour before my other sync.

Thank you all for your support on this

[broncosjkb]

I would like to ask if having multiple LDAP directories can cause issues with authentication?

Just forewarning to anyone who was going to go the same route as me. I completely broke LDAP authentication.

[Jaime Valencia]

No, you can have multiple LDAP agreements, the one thing to consider is that you only have ONE LDAP authentication agreement and it needs to point high enough in the tree to cover all the LDAP agreements you configured.

Adding LDAP agreements would not break authentication for users if it was working before, they're separate configurations.

[Roger Kallberg]

No that’s not what caused the authentication to not work. Directory synchronisation and authentication is two different things in CM that has its own configuration items.

We used to have multiple directory synchronisation setups and it did not have any effect on authentication.

[Nithin Eluvathingal]

assume that your AD domain is abc.com and you have OU's staff, user, it etc... 

Since you can create multiple  LDAP directories, you can use either  entire domain as search base I.e DC=abc,DC=com or you can keep it based on OU. I.e OU=user,DC=abc,DC=com

For LDAP authentication settings,Navigate to CUCM Administration > System > LDAP Authentication

But  authentication can be only one. so to cover the entire domain. use  

search base DC=abc, DC=com

[broncosjkb]

Interesting. It sounds like what I did may not have been the root cause then. It seemed like right after I made the change, LDAP broke. I was unable to sign into jabber or authenticate into the CUCM admin page with my AD account. I was also making some application dial rule changes at the same time, which should not have caused issues. I'm thinking I might have synced myself into this new group and stripped my admin rights or something weird. In my panic to bring fix this issue, I did not take a good approach to remediation and just deleted all the work I had done so far, which fixed the issue.

 I have had about enough troubleshooting for the day, but I will probably re-create the directory tomorrow and see if anything breaks.

Just to confirm, I can have two LDAP directories for the same Domain without causing issues with authentication. I was just thinking of these as Sync configurations, would that be correct?

Thank you all again for your replies

James

[Nithin Eluvathingal]

It depends on your Domain Tree.

Domain :- abc.com

Assume you have two main OU, OU:- new user and OU:- user.

OU:- new user

Assume two sub OU's ,  OU staff and OU IT is under User.

OU:- user

            OU:- staff

            OU:- It

LDAP autenticaion work for a secario where your LDAP directory search base has OU=staff,DC=abc,DC=COM,  OU=it ,DC=abc,DC=COM and with Authentication search base  OU=user ,DC=abc,DC=COM.

But if you add third  LDAP directory with search base, OU=new user,DC=abc,DC=COM

Authentication wont work with OU=user ,DC=abc,DC=COM.

It should cover the entire domain and you need DC=abc,DC=COM to cover all the OU's

[Roger Kallberg]

Also please remember that whatever changes you do to the directory synchronisation will only affect new users. Any users already synced to CM will not be affected by your change.

Can you please take screenshots of both your directory synchronisations configuration and your authentication configuration so that we can validate it?

[Adam Pawlowski]

LDAP authentication shouldn't break, as was said there's only one authentication relationship that can be set. What may have bit you is that if you use multiple relationships, they do go in time order and you have to make sure that the earlier sync has all the groups you want. In that case, that means CCM End User, Standard CTI, etc. Then after syncing remove the other sync so you are not moving the users back and forth and negating what you've done.

If you don't use rank, I would recommend that you don't touch them. It almost sounds like a way to group users, but it is not, it's a permissions system. If you apply a rank like "CTI Users" to try and differentiate users, you'll break things as the permissions will also be assigned a rank that's applicable and it won't apply to users who aren't in that rank or higher.

You can also do this with AXL or database query. I have created an access control group that has Standard CCM End User Access, Standard CTI Control Enabled, Allow Control of Rollover and Xfr, etc. I applied this group to the sync and then used AXL to apply it to the end users. I can then modify the group to assign whatever permissions in the future, to avoid this problem later on if you need something else added.