Having issues setting up LDAP/Active Directory auth

Get Help
1

Hello,

I am installing OOD on a CentOS 7 machine via RPM. Everything in the documentation has gone well so far, and I am at the point where I am attempting to add LDAP auth support. I have installed the httpd24-mod_ldap.x86_64 module via yum so I believe I should have the proper prerequisites/LDAP modules for Apache. As a next step we are attempting to set up AD auth for OOD and are running in to some issues. Not having much prior experience in web config I am sure I am missing something trivial in the setup.

Here is what I currently have in the ood_portal.yml in the ‘auth’ section:

auth:

  • ‘AuthType Basic’
  • ‘AuthBasicProvider ldap’
  • ‘AuthName " Enter your AD username and password."’
  • ‘AuthLDAPURL “ldap://ldap.domain.local:389/OU=Users,DC=domain,DC=local?sAMAccountName”’
  • ‘AuthLDAPBindDN “oodldap@domain.local”’
  • ‘AuthLDAPBindPassword oodldappassword’
  • ‘Require valid-user’

However when I run update_ood_portal after making the config changes to my ood_portal.yml, restart the web server and try to sign in it does not accept any AD username or password.

In error_log I am getting:

[Thu Jan 16 15:29:25.616999 2020] [auth_basic:error] [pid 32554] [client nnn.nnn.nnn.nnn:51086] AH01618: user test.user not found: /pun/sys/dashboard

I have verified that oodldap and password are correct and I am able to bind to our ldap server with those credentials. I also tested another user and am getting the same result. I have tried a few different iterations of the LDAP directives with the same result.

Would someone perhaps be willing to share their ood_portal.yml if you are running LDAP/AD? I am sure I have missed something there for a start, and am working my way back through the steps at the moment to see if I have forgotten anything else. Any other suggestions are greatly appreciated.

thank you!

2

Hi and welcome!

I think 2 things help in triaging ldap issues. First, you could turn log level up with the config file below. Briefly searching on this site, it looks like folks have misconfigured their ldap certificate. The logs may say as much.

# added in a new file /opt/rh/httpd24/root/etc/httpd/conf.d/ldap_debug.conf
Loglevel ldap_module:debug
Loglevel authnz_ldap_module:debug

Next is to step back and hack around on ldapsearch. Looks like you’ve been doing this to test auth, but you may need it to figure out the right ldap query. It could be as simple as ldapsearch cn=test.user.

I get an output like this, telling me I’d need to use /OU=People,DC=osc,DC=edu?uid instead of what you have /OU=Users,DC=domain,DC=local?sAMAccountName

dn: cn=johrstrom,ou=People,dc=osc,dc=edu
displayName: Jeff Ohrstrom
employeeType: REGULAR
gecos: Jeff Ohrstrom
cn: johrstrom
employeeStatus: ACTIVE
uid: johrstrom
loginShell: /bin/bash

Which is to say, confirm that your basedn and attribute are correct for what’s in your ldap.

Confirm that you only get one result for a given user. I’ve seen that before where 1 user can map to several ldap entries. You may need to dig into the ldap results and spice up your url with a filter like (myDomain=true) to choose one entry (the one with myDomain) over the other(s).

Lastly, I don’t think you’ve missed anything big. I’d guess it’s something simple. In sum, increase the log setting in apache and get familiar with LDAP in general and get strong at making ldap queries.

Hope that helps! We don’t run AD here, or I’d help you out with that config. Maybe if you post your ldap search result (redacting anything sensitive) I could confirm your basedn, attributes and filters.

3

For reference (my own as much as anyone else’s’), here’s the ldapsearch translation of that AuthLDAPURL.

“ldap://ldap.domain.local:389/OU=Users,DC=domain,DC=local?sAMAccountName”’

ldapsearch -W -h "ldap.domain.local" -b "OU=Users,DC=domain,DC=local" cn=test.user sAMAccountName

If I do something similar for myself, I can find myself in our LDAP.

[johrstrom@host ~]$ ldapsearch -x -h "host" -b "ou=People,dc=osc,dc=edu" cn=johrstrom uid
# extended LDIF
#
# LDAPv3
# base <ou=People,dc=osc,dc=edu> with scope subtree
# filter: cn=johrstrom
# requesting: uid 
#

# johrstrom, People, osc.edu
dn: cn=johrstrom,ou=People,dc=osc,dc=edu
uid: johrstrom

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
4

Jeff,

I really appreciate the reply. With your helpful suggestions I was able to get this up and running. It took a bit of trial and error but it was ridiculously simple: it did not like OU=Users under the LDAP search base, so I removed it and put in “DC=domain,DC=local” instead and that seems to have fixed it.

I was able to verify this with the following where ‘oodldap.domain.local’ was the bind account:

ldapsearch -H ldap://ldap.domain.local -x -W -D "oodldap.domain.local" -b "dc=domain,DC=local" "(sAMAccountName=test.user)"

This came back with:

dn: CN=Test\, User,OU=Users,OU=Research Computing,DC=domain,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Test, User
sn: Test
givenName: User
distinguishedName: CN=Test\, User,OU=Users,OU=Research Computing,DC=domain,DC=local
instanceType: 4
whenCreated: 20191030214811.0Z
whenChanged: 20200113212528.0Z
displayName: Test, User
uSNCreated: 6475624
memberOf: OU=Security Groups,OU=Research Computing,DC=domain,DC=local
memberOf: OU=Security Groups,OU=Research Computing,DC=domain,DC=local
uSNChanged: 17948823
name: Test, User
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 132241902578019028
lastLogon: 132242819389005116
pwdLastSet: 132169456921880942
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA6D7eMQhpIrNtgr1QR+MDAA==
accountExpires: 9223372036854775807
logonCount: 4
sAMAccountName: test.user
sAMAccountType: 805306368
userPrincipalName: test.user@domain.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=local
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 132234243136000434

Which did confirm ‘sAMAccountName’ was needed in our particular case vs. ‘?uid’ which was a good sanity check.

We have not added SSL yet but this at least got us up and running so we can move forward with the rest of the configuration.

This does lead me to another question, though AD auth seems to be working now, we are running into another problem in that the OOD dashboard sometimes takes upwards of 30 seconds to load, if at all. We’ve observed this on all users who have logged in so far. It also stalls on logout. Oddly, other times, it loads normally. Occasionally on timeout we get a Passenger error “We’re sorry, but something went wrong. We’ve been notified about this issue and we’ll take a look at it shortly”

I’m looking through the logs at /var/log/ondemand-nginx/$USER/error.log and on the affected accounts am getting the following:

[ E 2020-01-23 14:54:13.5538 2345/T1r age/Cor/App/Implementation.cpp:221 ]: Could not spawn process for application /var/www/ood/apps/sys/dashboard: A timeout occurred while spawning an application process.
  Error ID: 11b5b5d5
  Error details saved to: /tmp/passenger-error-udNlIj.html

App 3171 output: [2020-01-23 14:54:31 -0600 ]  INFO "method=GET path=/pun/sys/dashboard/ format=html controller=DashboardController action=index status=200 duration=21.16 view=5.56"
App 3171 output: [2020-01-23 14:54:43 -0600 ]  INFO "method=GET path=/pun/sys/dashboard/apps/show/activejobs format=html controller=AppsController action=show status=302 duration=2.84 view=0.00 location=http://nnn.nnn.nnn.nnn/pun/sys/activejobs"
App 3171 output: [2020-01-23 14:54:51 -0600 ]  INFO "method=GET path=/pun/sys/dashboard/apps/show/myjobs format=html controller=AppsController action=show status=302 duration=236.70 view=0.00 location=http://nnn.nnn.nnn.nnn/pun/sys/myjobs"
App 3556 output: Rails Error: Unable to access log file. Please ensure that /var/www/ood/apps/sys/activejobs/log/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /var/www/ood/apps/sys/activejobs/log/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
App 3556 output: [2020-01-23 14:55:55 -0600 ]  INFO "method=GET path=/pun/sys/activejobs/ format=html controller=JobsController action=index status=200 duration=22.26 view=21.74"

It seems like the “timeout occurred while spawning an application process” happens at random. I checked the /tmp/passenger-error-*.html but can’t make much sense of the output.

Perhaps this would be better if I started it as another topic?

I will keep digging into this issue, but was just curious if you folks had seen something like this before.

Thanks again Jeff!

1 Like
5

Awesome! Glad to hear you figured it out! I’ll bet order matters and if this is your structure, OU=Users,OU=Research Computing,DC=domain,DC=local it’s likely can’t skip the Research Computing OU.

To the bit about latency, yea feel free to open another topic and attache the /tmp/passenger-error-....html (redacting whatever you need). We’re aware of ~30 second boot times, but 230 is a real problem. If I had to guess off the top I’d put it to disk latencies?

Job composer doesn’t do much, but it does create and read a sqlite3 database in your home directory (~/ondemand/data/sys/myjobs). Dashboard does do a lot of file reading, but again, in your home directory mostly. And most sites have NFS storage so it ends up being network traffic. But I think the error messgae and the stack trace in the error.html specifically may shed some light on it.