Calyx RIM Administration

LDAP Troubleshooting

Calyx RIM can have issues with LDAP due to its restrictions and limitations.
Question Answer
What does the error javax.naming.LimitExceededException: [LDAP: error code 11 - Administrative Limit Exceeded] ; mean in the logs? How do I fix it? This error indicates that an LDAP server limit set by an administrative authority has been exceeded. This can be a search time or result limit. This can usually be remedied by specifying an LDAP directory manager in the user.ldap.user property or by increasing the administrative limit on the LDAP server.
My user and group objects are not being found by the Add User/Group Wizard in the Calyx RIM Security Admin Module. What can I do to change this? My company uses custom objectClasses to represent Users and Groups. How do I make Calyx RIM aware of them? Calyx RIM provides two properties for specifying the LDAP search criteria to use in retrieving Users and Groups. The defaults are specified below, and can be overridden by specifying the following properties in the insight.var file. Note that the value of these properties must be a valid LDAP query. ldap.group.object.search=(objectClass=Group) ldap.user.object.search=(|(objectClass=User)(objectClass=userProxy))
After all this, I still can't log in... even with my default admin, what is going on? Most likely this indicates a problem with connecting to the LDAP server. It could mean that your settings are incorrect in the insight.var file (Remember, LDAP implementations unlike Microsoft Windows are often case sensitive). It could also mean that there are problems physically connecting to the LDAP server (try pinging it from the machine that Calyx RIM resides on). The best thing to do at this point is enable DEBUG output in the log4j.xml file and make sure that you have the following category enabled as well: <category name="com.draagon"> <priority value="DEBUG"/> </category> This will indicate what type of connection problem is occurring.
How can I prevent duplicate users/groups in Calyx RIM?

A: When a user/group is added/logs in to Calyx RIM, we store a uniquebindvalue in the database along with the users current DN. The uniquebindvalue is derived from the value specified in the insight.var for user/group binding. This defaults to the CN. Note that this must be assumed to be unique otherwise there is no guarantee that the user that is logging in is indeed the user that is attempting to login. This is the first place where many clients have problems because they don't specify an attribute that is unique in their LDAP system as the bind attribute.

When a user's DN changes (because they move to a different department/domain, etc.) and an attempt is made to login to Calyx RIM with that user, we attempt to first look up the user by DN, if the user doesn't exist in LDAP, we then search LDAP from the base specified in the insight.var for the bind attribute (also specified in the insight.var) that has the same value as the uniquebindvalue stored in the insight database. This is another area where we see many problems. These mainly involve one of the following:

  • The value of the uniquely bound attribute changes as a result of the LDAP change (This violates our assumption that the uniquebindvalue is indeed a unique value, at this point, Calyx RIM is unable to recover because neither the uniquebindvalue or DN exist in LDAP anymore). The solution here has been to be aware of this change when it occurs in LDAP and manually update the insight database's uniquebindvalue.
  • The change in DN is brought about by a change in LDAP implementation (switching from AD to iPlanet, etc.). This is fine as long as the proper changes are made to the insight.var (this is rarely done, our clients swap out LDAP implementations and expect what worked for AD to also work for iPlanet) and the value of the new uniquely bound attribute is the same as that stored in the insight database (case included). All of this must be done before logging into Calyx RIM (otherwise a duplicate entry is created). The solution to this problem is to make sure the insight.var is configured correctly for your ldap implementation and to follow all the rules for a uniquebindvalue change specified above.
  • When a group is moved in ldap the DN will change. Since we don't currently have a uniquebindvalue concept for groups, adding this group again will cause a duplicate entry in Calyx RIM. The best current solution here is to manually update the group's DN in the Calyx RIM database when you know that the group's DN has changed.
Can I create an ldap user if there is a comma (,) character in the name?

A: Yes. If there is a comma (,) character in the ldap lookup user (user.ldap.user) name, use a double backslash (\\) in front of the comma in the insight.var file as escape characters.

Example: user.ldap.user=CN=test\\, insightadmin,OU=group,DC=domain,DC=com

This allows the user.default.admin to be specified as user.default.admin=CN=test, insightadmin,OU=group,DC=domain,DC=com in the insight.var file.

Can I create an ldap user if there is a forward slash (/) character in the name? Yes. If there is a forward slash (/) character in the ldap lookup user ( user.ldap.use r) name, " LDAPTrimQuotes=true " must be added to the insight.var file to properly add users with names containing special characters.