scoold: para LDAP config is not picked up correctly

I’m setting up server like this:

scoold server
  - application.conf
    - para.security.ldap.server_url = "ldap://test.com"
    - (...other)
para server
  - application.conf

at first try, everything is working but after adjust some of the configuration. I am not sure what is the root cause. now suddenly there is an error cannot authenticate with LDAP server localhost:8389 (which is the default)

my workaround is:

I have to also put the config inside the para (application.conf) too and now it is working again.

scoold server
  - application.conf
    - para.security.ldap.server_url = "ldap://test.com"
    - (...other)
para server
  - application.conf
    - para.security.ldap.server_url = "ldap://test.com"
    - (...other)

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 31 (20 by maintainers)

Commits related to this issue

fixed certain LDAP login issues with Active Directory servers where logins would fail if the UPN suffix is different than the given domain, related to Erudika/scoold#67 — committed to Erudika/para by albogdano 4 years ago

Most upvoted comments

I’m having a hard time configuring scoold for AD auth using the UPN. This one works for me:

para.security.ldap.user_search_filter = "(&(objectClass=user)(sAMAccountName={1}))"

As you probably guessed, this lets you in with user.name. But I want to log in with the full email address. So I tried with

para.security.ldap.user_search_filter = "(&(objectClass=user)(userPrincipalName={0}))"
para.security.ldap.user_search_filter = "(&(objectClass=user)(userPrincipalName={1}))"
para.security.ldap.user_search_filter = "(&(objectClass=user)(mail={0}))"
para.security.ldap.user_search_filter = "(&(objectClass=user)(mail={1}))"

None of them works. I’m afraid the @ might not be escaped correctly somehwere. Any ideas?

For the record, here’s everything LDAP-related:

para.security.ldap.server_url = "ldap://dc2.ad.foobar.com:389/"
para.security.ldap.base_dn = "DC=ad,DC=foobar,DC=com"
para.security.ldap.bind_dn = "CN=ldap,OU=Helpers,OU=Foobar,DC=ad,DC=foobar,DC=com"
para.security.ldap.bind_pass = "***"
para.security.ldap.user_search_base = "OU=Users,OU=Foobar,DC=ad,DC=foobar,DC=com"
# WORKS para.security.ldap.user_search_filter = "(&(objectClass=user)(sAMAccountName={1}))"
para.security.ldap.user_search_filter = "(&(objectClass=user)(userPrincipalName={0}))"
#para.security.ldap.user_dn_pattern = "uid={0},ou=people"
#para.security.ldap.password_attribute = "userPassword"
# set this only if you are connecting to Active Directory
para.security.ldap.active_directory_domain = "ad.foobar.com"

bviktor on Feb 13, 2019

@albogdano I apologize for being MIA for a couple days. I have tried that. That is when I start getting <ROOT> showing up in the network trace. I’m going to dig more into that as well as other ways to BIND (eg. full DN).

tongueisthirsty on Jan 31, 2019

I spent basically the whole day trying to make this work, because I didn’t think to be watching the LDAP logs, but here’s the config that works for me:

para.security.ldap.server_url = "ldap://ldaphost:389/"
para.security.ldap.base_dn = "DC=mycompany,DC=com"
para.security.ldap.bind_dn = "CN=admin,DC=mycompany,DC=com"
para.security.ldap.bind_pass = "1234"
para.security.ldap.user_search_base = "OU=people"
para.security.ldap.user_search_filter = "cn={0}"
para.security.ldap.user_dn_pattern = "CN={0},OU=people"

weisjohn on Jun 22, 2018

Edit scoold.env and set BOOT_SLEEP=10 for the Scoold container. This will tell Scoold to wait a bit longer for Para to start.

albogdano on Jun 6, 2018

By creating a new app I meant calling para-cli new-app "scoold" --name "Scoold" with the keys for the root app. It’s recommended to have a separate app namespace for Scoold.

albogdano on Jun 5, 2018