LDAP authentication failure

How can I effectively test so as to correct the ldap configuration? I’m accustomed to using ldapsearch within the cluster, and am learning some things about ldap through the local configuration in the cpu.conf and the sssd.conf.

I have followed the prescription to configure, as below:

auth:
  - 'AuthType Basic'
  - 'AuthName "Case SSO"'
  - 'AuthBasicProvider ldap'
  - 'AuthLDAPURL
"ldap://<internal-ip>:389/ou=People,dc=cwru,dc=cloh,dc=osc,dc=edu?uid"'
  - 'AuthLDAPGroupAttribute memberUid'
  - 'AuthLDAPGroupAttributeIsDN off'
  - 'RequestHeader unset Authorization'
  - 'Require valid-user'

When prompted to authenticate, I enter my ldap credentials, which is rejected, and the login prompt window appears again. I’m not finding local logging of how the authentication is failing. The ‘dc’ values are taken from my standard usage of ldapsearch, to look up info about our cluster user accounts.

Is the structure of the ldap call to the server adequate? How do I know what value needs to be returned, and whether the necessary value is satisfied? For example, my ldapsearch will not return a field ‘memberUid’, so is the ‘AuthLDAPGroupAttribute memberUid’ inappropriate in this case?

Source: Originally posted by E.M. Dragowsky in the ood-users mailing list.

The logs will be in /var/log/httpd24. If there is nothing useful you can try increasing the logging from mod_ldap. If there is nothing sensitive in your sssd.conf, could you share that or maybe an example command you use with ldapsearch? The examples in our documentation and your auth lines assume plain text LDAP over port 389 that is doing unauthenticated binds.

It’s unclear how this got solved, you can see in the mailing list that was the last message in the thread. I guess next time it comes up we’ll have to specify was the problem/solution was a little better.

Hello!
I am trying to get an instance of ood up and running and am running into what I believe are a number of problems. One in particular matches the behavior mentioned here. I have not been able to login to this instance using either the apache passwd file or ldap. I’m not sure if the problem is the actual authentication process, or if the problem is a lack of pun/sys directories. I am installing to CentOS 7 with yum. I have the errors from the /var/log/httpd24 directory:

[root@ondemand httpd24]# tail -n 50 ondemand.grid.wayne.edu_*
==> ondemand.grid.wayne.edu_access_ssl.log <==
141.217.136.24 - - [31/Jul/2019:16:28:50 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:28:50 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - at8036 [31/Jul/2019:16:29:10 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - at8036 [31/Jul/2019:16:29:35 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:29:44 -0400] “GET /favicon.ico HTTP/1.1” 404 209 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:46:26 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:46:26 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - zz9992 [31/Jul/2019:16:46:38 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - zz9992 [31/Jul/2019:16:47:10 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:47:16 -0400] “GET /favicon.ico HTTP/1.1” 404 209 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:47:45 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:16:47:45 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - zz9992 [31/Jul/2019:16:48:39 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - zz9991 [31/Jul/2019:16:48:46 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
192.170.254.110 - - [31/Jul/2019:17:01:53 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:01:53 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:02:57 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:02:57 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:04:17 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:04:17 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:16:47 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:16:47 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:16:52 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:16:52 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:17:01 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:17:01 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36”
192.170.254.110 - - [31/Jul/2019:17:17:21 -0400] “-” 408 - “-” “-”
141.217.136.24 - - [31/Jul/2019:17:17:36 -0400] “GET / HTTP/1.1” 302 233 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:17:17:36 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - zz9992 [31/Jul/2019:17:18:07 -0400] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
141.217.136.24 - - [31/Jul/2019:17:18:14 -0400] “GET /favicon.ico HTTP/1.1” 404 209 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”

==> ondemand.grid.wayne.edu_error_ssl.log <==
[Wed Jul 31 16:29:35.427290 2019] [auth_basic:error] [pid 39790] [client 141.217.136.24:42192] AH01618: user at8036 not found: /pun/sys/dashboard
[Wed Jul 31 16:48:46.858503 2019] [auth_basic:error] [pid 38765] [client 141.217.136.24:42366] AH01618: user zz9991 not found: /pun/sys/dashboard
[Wed Jul 31 17:18:07.693195 2019] [auth_basic:error] [pid 51394] [client 141.217.136.24:42586] AH01618: user zz9992 not found: /pun/sys/dashboard

The yaml for ldap looks like:
auth:

  • ‘AuthType Basic’
  • ‘AuthName “private”’
  • ‘AuthBasicProvider ldap’
  • ‘AuthLDAPURL “ldaps://ldap.wayne.edu:636/ou=People,dc=wayne,dc=edu?uid”’
  • ‘AuthLDAPGroupAttribute memberUid’
  • ‘AuthLDAPGroupAttributeIsDN off’
  • ‘RequestHeader unset Authorization’
  • ‘Require valid-user’

I’ve been poking at things for a while and am a bit stuck at the moment. Currently I can only attempt to login when accessing via localhost, and then when I try from localhost I just get prompted for credentials again.

I appreciate any suggestions!!! Thanks!
Aragorn.

I don’t know much about LDAPs, but here we go.

I would first enhance the log level of the ldap module that may give you more insight into what’s going wrong.

Here are some other questions I would try to answer.

  1. Do you need a username/password to search your ldap? I.e., do you need to be an authenticated user to even search the LDAP? That configuration does it anonymously, which means anyone could.
  2. Is that search query correct. I mean, do you actually have an ou named ‘People’ and a ‘dc’ named wayne, etc. I would confirm through the command ldapsearch that these are the actual OUs and DCs.

My guess (out of thin air) is that you need to be an authenticated user to search your ldap.

FWIW here are relevant portions of our /etc/ood/config/ood_portal.yml:

auth:
- AuthType basic
- AuthName "Private"
- AuthBasicProvider ldap
- AuthLDAPURL "ldaps://ldap1.****.edu:636 ldap2.****.edu:636 ldap3.****.edu:636/ou=People,dc=osc,dc=edu?uid"
  SSL
- AuthLDAPGroupAttribute member
- AuthLDAPGroupAttributeIsDN on
- Require valid-user
- RequestHeader unset Authorization

Of course if you change the yaml file you have to regenerate the corresponding ood-portal.conf file as a result.

@at8036 were you able to find out anything more through debug logs?

Sorry, been pretty busy since getting back from PEARC! I will look into it. I am not so certain it is an LDAP issue though since the problem is the same even when trying to use the Apache password file. Quick question beforehand, the nginx config file I noticed is completely commented out. Am I supposed to do something to set that up?

Cool, just let us know.

About the nginx config, no you don’t need to modify that because you get a Per User Nginx instance that ondemand sets up and configures for you when you login. Like mine below was configured for specifically for me.

/var/lib/ondemand-nginx/config/puns/johrstrom.conf