I got a little further after having to drop the clearspace tables 3-4 times to due the large user base imports. Here is what I did:
1) On a new install create a user account i know exists in ldap and make it a space admin, make sure the password is set to the same as the ldap instance.
2) Add the Ldap properties via the property editor:
ldap.adminPassword = hidden
ldap.baseDN = CN=users,DC=mycompany,DC=com
ldap.emailField = mail
ldap.groupDescriptionField = description
ldap.groupMemberField = member
ldap.groupNameField = cn
ldap.groupSearchFilter = (member=) ldap.host = ldap.mycompany.com ldap.nameField = name ldap.port = 389 ldap.searchFilter = (sAMAccountName=)
ldap.sslEnabled = false
ldap.user.defaultEmailVisible = false
ldap.usernameField = sAMAccountName
ldap.adminDN = CN=ldap_user,CN=users,DC=my_company,DC=com
3) Now switch the Auth provider via the
AuthFactory.className = com.jivesoftware.base.ldap.LdapAuthFactory
4) Restart the server and it seemed to work... Until I tried to access it with a new user. Then something odd happened. The user was authenticated with ldap, an entry was made in the db but for some odd reason the user could not login (although his user name showed up in the Logged in status bar). It took a little while to figure it out but it looks like the login page is also checking against the password hash so LDAP auto-created users w/out a matching password in the db can't get in.
Any ideas of how to get around this last little hurdle?
thanks in advance.
I have the same situation. I deleted the GroupManager.className property to prevent the LDAP group manager from creating all the users in the directory.
About the login problem.
I saw the exact same thing when I tried 1.5. I changed the ldap.adminDN to just the username (sAMAccountName), not the fully qualified DN, and it worked. I have an open question about the same subject here:
What I was trying to figure was a repeatable way to create a new installation with the LDAP for auth only that didn't import in all of the users. Using the LDAP installer wizard was the only way to set all of the properties for the system but hitting ok to save the properties also pulled in all the ldap users into my clearspace.
I think I finally figured out a way to do this cleanly. I do all of the steps I mentioned in the original post but I had missed a second set of ldap properties that also needed to be set.
It looks like the different ldap managers use different configurations. I needed to configure the ldap.<properties> and the instance properties form each one of the spi provider classes. Luckily turning on the ldap trouble shooting helped out. I could see that my user was being authenticated in ldap, but then further down in the process I could see that ldap was being called again but this time with null properties for the ldap session:
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.ldap.InitialLdapContext.<init>(Unknown Source)
it printed out that some of these important params where null:
After looking a print out of my previous properties I noticed these had been inserted into the property tables:
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Administrator DN =
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Administrator Password = hidden
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Base DN =
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Connection Pooling Enabled = true
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Port = 389
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Search Filter =
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Search Sub Trees = true
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Search Wild Card Pattern = *
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Server Address =
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:SSL Enabled = false
__jive.spi.com.jivesoftware.spi.user.impl.ldap.AuthenticationProviderImpl:Username Field =
Same for the LdapUserProviderImpl class (property prefix below):
After tediously adding these manually to the property tables it worked as I had hoped.
BUG: It does look like 3 different ldap systems have to look up the users auth info (and each one uses a different property set for configuration). If a user mistypes their password our security policy (3 strikes you are out) causes our LDAP server to lock out accounts because of the multiple bad tries.
I hope this will help someone else out with a new install when they want auth only ldap.
Message was edited by: rmonge
Mine was working as just authorization until I switched to Clearspace 1.6, when 1500 users were added to my evaluation instance via Active Directory.
This filled up my evaluation licenses and now I can't use the system anymore.
How did you remove all of the users easily? You mention "drop the clearspace tables," what does this mean and how do you do it?
Unfortunately this means deleting all tables that clearspace made during the installation. There might be a another way to save some of your data but I wanted to make sure I started out cleanly so deleted the jive user and that drops all the tables created by that user in oracle:
DROP USER jive CASCADE;
Note: check on the jive username, I'm not in front of my notes.