Crowd LDAP configuration with Microsoft Active Directory

2
votes

I hava an issue with the configuration of LDAP in Crowd.

Background A remote CentOS server running Atlassian Crowd needs to integrate with the in-house Microsoft Active Directory.

We configured Crowd with the following obfuscated details:

  • URL: ldap://ldaps.xyzgroup.com.uk:389
  • Base DN: OU=Users, DC=xyz, DC=local
  • User account: xyz\parkbasead
  • Password: <somepass>

Problem Crowd is correctly validating the server but throws an exception when the user logs in:

AcceptSecurityContext error, data 52e, v1db1]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e, v1db1]

Given the details above, what constitutes a base DN and should we be using an UPN (fully qualified username) to log in from the remote server? In the base DN can someone share thoughts if DC=local should be replaced with a meaningful domain controller name?

1
active-directoryldapatlassian-crowd
In my case the account was right, the password was right and the account was not locked. Probably started suddenly for no known reason. I resolved by using the full UPN ([email protected]) to get authenticated and avoid this error. Another application was using the same account and did not require the UPN. – Ryan D

1 Answers

2
votes

Addressing each question here, but in the future you should really avoid multiple questions inside one question. People are less likely to help when there are multiple questions inside one question.

  1. In Active Directory, Users is a container not an OU. Therefore the Base DN, which is an LDAP path, in your case would actually be: CN=Users,DC=xyz,DC=local. Note there are no spaces after the comma. The Base DN could also simply be DC=xyz,DC=local. The Base DN specifies the root for searches in the Active Directory. In my experience, specifying the Base DN as the root of the Directory does incur a slightly higher cost on CPU time if you are a every large organization because there are more levels in Active Directory to look in to find the user, so I would try to use CN=Users,DC=xyz,DC=local first as the Base DN if that's where all your users are. If not then try DC=xyz,DC=local, which is similar to the example below, where the Base DN is ISL.local.

Active Directory Users and Computers

LDAP / AD Integration screen

  1. The UPN would look like [email protected]. In my experience that may or may not work coming in from a remote server depending on the authentication libraries installed so also try parkbasead all by itself. The xyz.local is assumed when the domain membership of the client and the server is xyz.local.

  2. Note that the domain controller name is never a part of the Base DN, as the Base Dn is nothing more than an LDAP path.

Here's a nice external reference on the subject where I found the examples and screenshots: How to find the correct Base DN setting

EDIT: In my experience, the best way to troubleshoot a problem with an account that you suspect may have sent a bad password to or is locked out in Active Directory is to use the Microsoft Account Lockout Status tool. It will tell you the source of any account lockouts and then you can quickly inform the AD administrator to unlock the account. Be careful against relying on just codes, LDAP codes can be cryptic and the true source of the problem may or may not be directly implicated in the code. Example of the Microsoft Account Lockout Status Tool:

Account Lockout Status Tool