I went ahead and changed the User Manager to the database.DbUserManager and only used the Ldap class for the Auth Manager. Things are working as I expected now. It would be nice if this was and install option.
The technique of switching to DbUserManager fixed some login exceptions I was experiencing when authenticating against OpenLDAP 2.3.30 with samba schema.
Thanks for following up on your post!
Is this correct? Should User Manger be
No, it should be LdapUserManager, which does store group and Clearspace settings in the Clearspace database and only uses Ldap for authentication. If you use DbUserManager instead of LdapUserManager in combination with LdapAuthFactory, you'll eventually run into a situation where a user gets created in the Db but never in your Ldap repository, which means they'll never be able to login.
In our organization we don't have write access to the corporate LDAP (actually AD) server, so we could never create LDAP users. Could you explain again the suggested settings for a read only LDAP repository were only the authentication is supposed to go through LDAP but groups and other Clearspace specific info should go in the DB? Ideally I had hoped it that there could be multiple authentication fallbacks so that if LDAP failed then clearspace could also fall back to the database DB users so that I could create admin users or utility users that do not live in the corporate LDAP directory.
I had just started evaluating the software and have installed Clearspace in pure LDAP mode. The performance was slow as molasses!!
I had to changed the following system properties to restore some usability to the system.
AuthFactory.className = com.jivesoftware.base.ldap.LdapAuthFactory
GroupManager.className = com.jivesoftware.base.database.DbGroupManager
UserManager.className = com.jivesoftware.base.database.DbUserManager
Couple of highlights about our environment
1) We use Active Directoy
2) The LDAP user we use in Clearspace does not have admin privileges.
3) We do not have permissions to write to Active Directory.
4) Not ever user in Active Directoy needs to be a user in Clearspace.
I also noticed that the members of the groups in active directory were not been read at all. My assessment of the state of LDAP implementation in Clearspace is that it is very lacking. It tries to deliver on too many features and fails on some basic points.
Because of the default LDAP properties, the software had a super sluggish response. That is itself an indication that the LDAP implementation is not production quality.
I hope the next implementation will allow easy setup of the following:
1) Implement LDAP Authentication only
2) User Management in Clearspace
3) Do not import every singe user/group from LDAP to clear space automatically..( maybe on demand)
4) Group management in clearspace.