OHDSI Home | Forums | Wiki | Github

Broadsea ldap issues

We are trying to get ldap working with the Broadsea implementation of the OHDSI. https://github.com/OHDSI/Broadsea

The following is one of many configurations we have tried as an example. Based on what we have read we believe this should work, but are apparently missing something.

 - JAVA_OPTS=-Xmx64g -Djavax.net.ssl.trustStore=/etc/certs/cacerts -Djavax.net.ssl.trustStorePassword=<password>
 - TLS_REQCERT=allowed

- security.ldap.dn=cn={0},ou=UF,dc=ad,dc=ufl,dc=edu
- security.ldap.url=ldap://hsc-site-ufdc.ad.ufl.edu:389
- security.ldap.baseDn=ou=UF,dc=ad,dc=ufl,dc=edu
- security.ldap.system.username=ITC-LDAPBind
- security.ldap.system.password=
- security.ldap.searchString=(&sAMAccountName={0})
- security.ldap.searchBase=ou=People,ou=UF,dc=ad,dc=ufl,dc=edu

Some notes:

LDAP auth attempts result in an AcceptSecurityContext error.

/etc/certs/cacerts is a truststore containing all of the CA certs including that of the AD/LDAP server’s root certificate.

ITC-LDAPBind is the auth bind user. Other users reside in OU=People, but service accounts such as it do not. As the system username we’ve tried ITC-LDAPBind, UFAD\ITC-LDAPBind, ITC-LDAPBind@ad.ufl.edu, and its full DN of CN=ITC-LDAPBind,OU=LDAP Accounts,OU=Service Accounts,OU=ITCENTER,OU=HSC,OU=Departments,OU=UF,DC=ad,DC=ufl,DC=edu

Have attempted both LDAP (389) and LDAPS (port 636).

Within the WebAPI container, we can successfully authenticate and query the LDAP server with the following:

ldapsearch -x -H ldaps://hsc-site-ufdc.ad.ufl.edu -D ITC-LDAPBind -w -b ou=UF,dc=ad,dc=ufl,dc=edu -s sub “(sAMAccountName=)”

Does anyone see anything obvious we are missing? Thanks for any assistance.