Looking for advice re LDAP schemas and Crowd configuration

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?



2 answers

1 accepted

0 votes
Answer accepted

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.

Hello Philip,

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?

Best Regards,

Hi Daniel

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.



Suggest an answer

Log in or Sign up to answer
Community showcase
Published Thursday in Jira

Updates to jira.atlassian.com give you visibility into what's coming in Jira Server and Data Center

Hello, Community! My name is Gosia and I'm a Product Manager on Jira Server and Data Center here at Atlassian. Since 2002 when we launched our public issue tracker, jira.atlass...

465 views 1 14
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you