JIRA and Confluence can do authentication against LDAP (e.g. Active Directory), using the standard Java JNDI library. When you're having LDAP connectivity problems, the ldapsearch
command can sometimes be useful as a means of verifying your LDAP parameters.
Getting and configuring ldapsearch
On Ubuntu/Debian:
apt-get install ldap-utils
On CentOS/RHEL:
yum install openldap-clients
Furthermore on CentOS/RHEL (6.4 at least), if you want SSL/TLS to work, you'll need to edit /etc/openldap/ldap.conf
and add the lines:
## http://serverfault.com/questions/437546/centos-openldap-cert-trust-issues TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt
See the mentioned URL for why.
Sample query
If the Use SSL
box is checked (typically port 636):
ldapsearch \ -H ldaps://tx-dc2.corp.example.com:636 \ -D 'CN=svcLDAPquery,CN=Managed Service Accounts,DC=corp,DC=example,DC=com' \ -w s3cret \ -b 'DC=corp,DC=example,DC=com' \ sub 'OU=Internal,DC=corp,DC=example,DC=com' \ -x -z5 \ sAMAccountName
This query does a subtree ( sub
) search for all nodes below OU=Internal,DC=corp,DC=example,DC=com
, returning the sAMAccountName
(i.e. username) attribute for each. It is limited to 5 results ( -z5
).
LDAP's startTLS
extension also allows a connection on port 389 to be upgraded to TLS ( ldapsearch -ZZ
) but I can find no evidence that JIRA/Confluence support this.
If you can see the existing JIRA/Confluence User Directory, the properties map to ldapsearch
parameters as follows: