You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am trying to get my LDAP/Crowd implementation to the point where as much of the relevant user information can be managed through the Crowd interface and not directly through LDAP.
Following the Ubuntu documentation for setting up OpenLDAP has led me to an example user that doesn't just have their objectClass as inetOrgPerson, but also posixAccount and shadowAccount.
It looks like changing the User Name Attribute from cn to uid and then, after a user account is created, manually adding the posixAccount objectClass to a user keeps Ubuntu LDAP "happy" and I can log in with the newly created user.
Is anyone else using Crowd with OpenLDAP and got any suggestions to share on how to get the process as automated/GUI-driven as possible?
Just to close off this question, I realised that I needed to have different objectClasses for different purposes. For example inetOrgPerson to hold the typical person information, the posix class for the Unix attributes and the SSH class for holding SSH keys.
Crowd only needs a subset of these attributes in order to do its thing so, ultimately, it wasn't going to be the best tool for managing the attributes. Instead, I've picked LDAP Account Manager to manage LDAP itself and that is the only underlying database I have, so that is all good. Crowd then does the SSO/OpenID thing.
Are you talking about the process of creating users within your OpenLDAP or on the Crowd side? Crowd using a connector to OpenLDAP that requires that all of the users pulled across be of a given object type. It looks like that may be the posixAccount in your case. Adding that class, and I assume doing a directory resync, would be the only time that Crowd is made aware of those users.
Just hoping to clarify a bit more. What part of the process for you want to be more automated and or GUI Driven?
I think I posted this question before I realised that Crowd could only write back the "core" attributes of a user, and that any other attributes (like uidNumber) would only be stored within Crowd itself and not LDAP.
I was trying to maximise the fact that Crowd has a web interface in order to open up the capabilities of managing users to other people like HR but I think I'll have to look at a web-based LDAP management system instead and rely on Crowd for the SSO piece and maybe end-user password resets.
Things are being made more complicated within my environment by virtue of the fact that user entities now need to use multiple objectClasses whereas Crowd only supports one.
I think I've mostly solved this one now by realising that I didn't need to use Crowd for absolutely everything.
Instead, I've decided to use LDAP Account Manager to provide the web interface for managing the underlying LDAP database. This comes with a self-service interface, which takes care of allowing users to modify their own details and the upcoming version 4.1 will have support for users adding and removing SSH keys (the current version allows administrators to do it).
So Crowd performs the SSO/OpenID piece but nothing else now for me, and that is fine.