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.