This is a summary document of several things I learned while implementing LDAP authentication at one of our clients.
Since this is in a public forum, I have put some generic terms in here, but hopefully this is helpful to anyone implementing LDAP as their authentication method for an internal group.
As background, my background is technical, but I've been out of the weeds for a while. I have not done a ton with LDAP and AD in the past and relied on input from Jive and the IT group to get some questions answered. This document will not answer all your questions, but hopefully answers some and gets you to a solution more quickly.
- We have 4000+ users around the globe
- Our Active Directory has much to be desired in terms of consistency and data quality
- Most of our users, but not all, are in one domain
- We have about 200 users who are NOT in our AD nor will they ever be, but we still need to manage them.
Two Primary Filters
There are two critical Jive system properties that need to be set to filter permission groups and users.
- ldap.groupSearchFilter = (&(objectClass=group)(name=XXXXX-Jive*))
This filter dicates what Active Directory groups get carried over into Jive. If there is no filter, every single AD group a person is in will be created in Jive and you will end up with a large number of unnecessary permission groups. We were in a situation where we needed to create new AD groups (long story)and so we named them consistently and then filtered everything but that naming convention out. This is working extremely well for us.
- ldap.searchFilter = (&(objectCategory=User)(! (userAccountControl:1.2.840.1135220.127.116.113:=2))(| (memberOf=CN=XXXXX-YYYY-North America,OU=JIVE,OU=Applications,DC=XX,DC=group,DC=local)(memberOf=CN=XXXXX-YYYY-Latin America,OU=JIVE,OU=Applications,DC=XX,DC=group,DC=local) ))
Our AD contained thousands of users and we only wanted a subset of them in Jive. The "userAccountControl" indicates we only want active users.
The rest of the filter says that anyone in one of these AD groups can login. This allows us to filter by specific AD groups that we can control. (Note: We have about 8 AD groups listed in our "Or" statement here and I've simplified it here.).
- When changing system properties, they generally do not require a restart. However, generally does not mean always. I found that to truly test out the system property change, I needed to do a restart.
- Spaces/blanks in your filter syntax matter. There should be no spaces.
- I used the Apache Directory Studio to test all of my filter changes. This tool worked very well to help me understand if my filter was working.
- Apache Directory Studio is an excellent tool for querying LDAP and testing filers. It is free and relatively easy to setup.
Federated vs Non-Federated Users
We ran a Pilot for several months using Jive administered IDs. As we moved towards production and turned on LDAP authentication, Jive converted all of these IDs to Federated IDs. This worked really well, but a few things to call out:
- We were fortunate in that we setup almost all of our Jive user IDs to match the persons network ID. This made conversion much easier.
- We had some users outside the company that do not authenticate against LDAP and these are non-federated IDs. This works fine, but you need to administer them manually.
- If you have a Federated ID that needs to be non-federated, Jive needs to make this change on their end. Easy to do, but they need to do it.
LDAP Sync With Jive
At the time of this writing, we are not yet syncing with LDAP on a regular basis. We are using the "lazy load" process by which a user gets created in Jive the first time they login. This works fine for creation.
When the user leaves the company, they will no longer be able to authenticate against Jive. However, their license is still active and they still look like an active user i the system. Thus, we will need to turn on a sync between LDAP and Jive in the near future in order to disable the people who leave the company. This is not hard to do, but be aware of it.
Possible Issues to Consider
We will be using the Outlook Connector and Office Connectors in the near future. During our pilot testing, we have seen some flaky issues with how those passwords are stored and how Jive "remembers" them. I am not yet crystal clear on how this works and the documentation is sparse. We need to figure out the details of this before we roll this out more broadly. In our pilot, we saw a number of people get their accounts locked when their network password changed. That is, the old password was stored with Outlook, tried to login 3x with it, and locked the account.
We've also seen some flakiness with users who have checked the "Remember Me" option. We ended up disabling this as we had concerns that this too was being stored and locking out users. (This may not be accurate, but it is not clear in our minds how this is working...better to be safe than sorry at this point!)