OHDSI Home | Forums | Wiki | Github

Broadsea - Active Directory Integration

Implementers
#1

Hello everyone,

I’m trying to deploy Broadsea with Active Directory authentication but haven’t had any success so far. I’m using docker.io/ohdsi/webapi:2.14.0 and have set the following environment variables:

env | grep AD
SECURITY_AD_SYSTEM_USERNAME=user.name@europe.world…com
SECURITY_AD_SEARCHBASE=DC=EUROPE,DC=WORLD,DC=COM
SECURITY_AD_USERMAPPING_USERNAMEATTR=userPrincipalName
SECURITY_AUTH_AD_ENABLED=true
SECURITY_AD_SEARCHFILTER=(objectClass=person)(userPrincipalName=%s)
SECURITY_AD_USERMAPPING_DISPLAYNAMEATTR=displayName
SECURITY_AD_URL=ldap://192.168.2.2:389
SECURITY_AD_PRINCIPALSUFFIX=@europe.world…com
SECURITY_AD_SEARCHSTRING=(objectClass=person)(userPrincipalName=%s)

Attempts to log in from Atlas keep returning Bad credentials, and WebAPI logs show the following:

cat /tmp/atlas/audit/audit.log
<110>1 2024-11-13T16:04:37.379Z ohdsi-webapi-d55b44db9-cqt5g Atlas - - - User login failed: user.name, remote-host = 10.244.0.137
<110>1 2024-11-13T16:04:45.957Z ohdsi-webapi-d55b44db9-cqt5g Atlas - - - User login failed: user.name@europe.world…com, remote-host = 10.244.0.137

I’ve noticed there’s an application.properties file located at /var/lib/ohdsi/webapi/WEB-INF/classes/application.properties which doesn’t seem to be updated with the environment variables. Not sure if this is related.

When I start webapi:2.14.0 as root, I can successfully authenticate using ldapsearch and ldapwhoami commands. Here are my results:

Command 0: Returns AcceptSecurityContext error if prefix is missing or password is incorrect.
ldapwhoami -x -H ldap://192.168.2.2:389
-D “user.name”
-w ‘password’

Command 1: Returns account if credentials are correct.
ldapwhoami -x -H ldap://192.168.2.2:389
-D “user.name@europe.world…com”
-w ‘password’

Command 2: Searches by sAMAccountName with simple username (successful).
ldapsearch -x -H ldap://192.168.2.2:389
-D “user.name@europe.world…com”
-w ‘password’
-b “DC=EUROPE,DC=WORLD,DC=COM”
-s sub “(&(objectClass=person)(sAMAccountName=user.name))”
displayName givenname initials sn sAMAccountName

Command 3: Searches by sAMAccountName with full email address (returns 0 entries).
ldapsearch -x -H ldap://192.168.2.2:389
-D “user.name@europe.world…com”
-w ‘password’
-b “DC=EUROPE,DC=WORLD,DC=COM”
-s sub “(&(objectClass=person)(sAMAccountName=user.name@europe.world…com))”
displayName givenname initials sn sAMAccountName

Command 4: Searches by userPrincipalName with simple username (returns 0 entries).
ldapsearch -x -H ldap://192.168.2.2:389
-D “user.name@europe.world…com”
-w ‘password’
-b “DC=EUROPE,DC=WORLD,DC=COM”
-s sub “(&(objectClass=person)(userPrincipalName=user.name))”
displayName givenname initials sn sAMAccountName

Command 5: Searches by userPrincipalName with full email address (successful).
ldapsearch -x -H ldap://192.168.2.2:389
-D “user.name@europe.world…com”
-w ‘password’
-b “DC=EUROPE,DC=WORLD,DC=COM”
-s sub “(&(objectClass=person)(userPrincipalName=user.name@europe.world…com))”
displayName givenname initials sn sAMAccountName

I’m out of ideas at this point. Has anyone successfully integrated Broadsea with Active Directory? Are there any pre-configured Docker images available that work with AD, or does anyone see what might be going wrong?

Note: The form to create a new topic alerts me that new users can only put 2 links on a post.
…com is .com

Thanks in advance!

#2

Hi @Marco_Lima , we’re planning on configuring this as well, and were wondering if you had any further updates - as it would be great to have a fuller understanding of what approach to take.

Many thanks!

#3

Hi @Marco_Lima and @fassez1 - apologies for the delay.

I’ll review both configs against our setup and see if anything seems obvious to modify. But might need to chat with you more directly for troubleshooting. Can you send your email addresses to my Forums account via DM?

#4

Hi!
The AD filter was wrong, should be (&(objectClass=person)(userPrincipalName=%s)), not
(objectClass=person)(userPrincipalName=%s)

Nevertheless, I’m using a kubernetes configmap. (&(objectClass=person)(userPrincipalName=%s)) also fails.

apiVersion: v1
kind: ConfigMap
metadata:
name: ohdsi-webapi-config
data:
SECURITY_AD_SEARCHFILTER: “(&(objectClass=person)(userPrincipalName=%s))”

had to change it to:
SECURITY_AD_SEARCHFILTER: “”

It works that way but I’m still not able to add filters to restrict login to a AD group. Soon…

1 Like
#5

I think the best way to test is to use a tool like LDAP tool like Apache Directory Studio (Welcome to Apache Directory Studio — Apache Directory). That’s how I was able to get our config working correctly.

Here’s a redacted version of what we have working. I wonder about the SECURITY_AD_SEARCHFILTER, as we have it filtering based off of the sAMAccountName. We also have a blank SECURITY_AD_PRINCIPALSUFFIX.

# AD
SECURITY_AUTH_AD_ENABLED="true"
SECURITY_AD_URL="REDACTED"
SECURITY_AD_SEARCHBASE="DC=REDACTED,DC=com"
SECURITY_AD_PRINCIPALSUFFIX=
SECURITY_AD_SYSTEM_USERNAME="REDACTED"
SECURITY_AD_SYSTEM_PASSWORD_FILE="REDACTED"
SECURITY_AD_SEARCHFILTER="(&(sAMAccountName=*)(memberOf=REDACTED))"
SECURITY_AD_IGNORE_PARTIAL_RESULT_EXCEPTION="true"
SECURITY_AD_RESULT_COUNT_LIMIT="30000"
SECURITY_AD_DEFAULT_IMPORT_GROUP="public"
SECURITY_AD_SEARCHSTRING="(&(objectClass=user)(userPrincipalName=%s))"
SECURITY_AD_USERMAPPING_DISPLAYNAMEATTR="displayName"
SECURITY_AD_USERMAPPING_FIRSTNAMEATTR="givenname"
SECURITY_AD_USERMAPPING_MIDDLENAMEATTR="initials"
SECURITY_AD_USERMAPPING_LASTNAMEATTR="sn"
SECURITY_AD_USERMAPPING_USERNAMEATTR="sAMAccountName"
SECURITY_AD_USERIMPORT_LOGINATTR="sAMAccountName"
SECURITY_AD_USERIMPORT_USERNAMEATTR="cn"
t