LDAP usage in Crowd 3.1.3

[Jean Bausch]

Hi,

we want to use Crowd for the user management of several Jira and confluence servers with different users and groups. We also want to use our company wide Active Directory (where we don't have writing rights) as user base and authentication server. How do we get on for that?

I have installed the trial version of Crowd on a server and configured our Active Directory as Crowd Delegated Authentication directory. The test was successful, but even an empty user search does not give any result.

I followed the instructions on https://confluence.atlassian.com/crowd/getting-started-with-crowd-197298051.html

Now I am in doubt whether I should have chosen the first LDAP variant instead of the "delegated authentication"? I thought this couldn't be it as we can't store our Jira and confluence groups in the company Active Directory.

[Bruno Vincent · Accepted solution]

Hi @Jean Bausch

That's right, you should have chosen an LDAP directory connector instead of a delegated authentication one: https://confluence.atlassian.com/crowd/configuring-an-ldap-directory-connector-18579550.html

With delegated authentication, users are only retrieved in Crowd after they successfully authenticate.

You don't need to have any write privilege on AD for standard LDAP directory connector. The connector will synchronize users and groups from AD into Crowd and won't do any write operations on AD, at least if you don't want to. You should configure the connector with an AD user that does not have any write privileges on AD.

[Jean Bausch]

Merci beaucoup!

[Bruno Vincent]

You're welcome @Jean Bausch!

I've edited and completed my answer as some community readers might want to use Crowd to do write operations on AD, which is also feasible. If you do not want Crowd to write anything on AD:

• Configure the connector with an AD read-only user
• Make sure to uncheck all Add/Modify/Remove boxes in the permissions tab of your directory in Crowd's console