# LDAP authentication failure

**URL:** <https://discourse.openondemand.org/t/ldap-authentication-failure/31>\
**Category:** Get Help\
**Created:** [August 21, 2018, 7:50pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31 "2018-08-21T19:50:19Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![azhu](https://avatars.discourse-cdn.com/v4/letter/a/edb3f5/32.png) [@azhu](https://discourse.openondemand.org/u/azhu)\
**Post date:** [August 21, 2018, 7:50pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/1 "2018-08-21T19:50:19Z")

</div>

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:

```auto
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](https://listsprd.osu.edu/pipermail/ood-users/2018-August/000201.html)._

---

<div class="post-metadata">

**Author:** ![azhu](https://avatars.discourse-cdn.com/v4/letter/a/edb3f5/32.png) [@azhu](https://discourse.openondemand.org/u/azhu)\
**Post date:** [August 23, 2018, 6:52pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/2 "2018-08-23T18:52:10Z")

</div>

The logs will be in `/var/log/httpd24`. If there is nothing useful you can try [increasing the logging from mod\_ldap](https://httpd.apache.org/docs/2.4/mod/mod_ldap.html#ldaplibrarydebug). 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.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [July 5, 2019, 2:50pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/3 "2019-07-05T14:50:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [July 5, 2019, 2:50pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/4 "2019-07-05T14:50:41Z")

</div>



---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [July 8, 2019, 8:28pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/5 "2019-07-08T20:28:51Z")

</div>



---

<div class="post-metadata">

**Author:** ![at8036](https://avatars.discourse-cdn.com/v4/letter/a/e9c0ed/32.png) [@at8036](https://discourse.openondemand.org/u/at8036)\
**Post date:** [July 31, 2019, 9:57pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/6 "2019-07-31T21:57:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 1, 2019, 1:40pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/7 "2019-08-01T13:40:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![efranz](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/efranz/32/27_2.png) [@efranz](https://discourse.openondemand.org/u/efranz)\
**Post date:** [August 2, 2019, 12:56pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/8 "2019-08-02T12:56:42Z")

</div>

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

```auto
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.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 7, 2019, 1:33pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/9 "2019-08-07T13:33:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![at8036](https://avatars.discourse-cdn.com/v4/letter/a/e9c0ed/32.png) [@at8036](https://discourse.openondemand.org/u/at8036)\
**Post date:** [August 9, 2019, 9:06pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/10 "2019-08-09T21:06:03Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 12, 2019, 5:50pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/11 "2019-08-12T17:50:01Z")

</div>

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`

---

<div class="post-metadata">

**Author:** ![at8036](https://avatars.discourse-cdn.com/v4/letter/a/e9c0ed/32.png) [@at8036](https://discourse.openondemand.org/u/at8036)\
**Post date:** [August 26, 2019, 8:43pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/12 "2019-08-26T20:43:49Z")

</div>

Hello,  
I’ve tried raising the log levels but I’m not seeing anything pertaining to whether ldap is trying to authenticate or not, what I do see though is a GET request and an error:

141.217.136.24 - at8036 [26/Aug/2019:16:26:32 -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”

[Mon Aug 26 16:26:32.553325 2019] [auth\_basic:error] [pid 78804] [client 141.217.136.24:41544] AH01618: user at8036 not found: /pun/sys/dashboard

I can reach ldap and have no problems with ldapsearch. Also, I don’t see any sign of an LDAP query when capturing all traffic in and out of the server with tcpdump. Any other thoughts? As far as I can tell I type in credentials, it checks to see if the account exists and when failing that just pops up a new window asking for credentials again.

I appreciate any suggestions!!!  
Thanks,  
Aragorn.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 26, 2019, 9:20pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/13 "2019-08-26T21:20:16Z")

</div>

> [@at8036](#):
>
> I don’t see any sign of an LDAP query when capturing all traffic in and out of the server with tcpdump.

That’s worrisome, but perhaps a clue to this issue.

what happens when you just run `ldapsearch uid=at8036`. For me, on our systems, I can’t even run ldapsearch using myself (I mean my authenticated ldapuser `johrstrom`), I need a bind user and password from my administrators. I guess my question is, can you run ldapsearch anonymously?

Otherwise you’ll have to specify a username/password with these directives.  
[https://httpd.apache.org/docs/2.4/mod/mod\_authnz\_ldap.html#authldapbinddn](https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html#authldapbinddn)

---

<div class="post-metadata">

**Author:** ![at8036](https://avatars.discourse-cdn.com/v4/letter/a/e9c0ed/32.png) [@at8036](https://discourse.openondemand.org/u/at8036)\
**Post date:** [August 27, 2019, 1:52pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/14 "2019-08-27T13:52:15Z")

</div>

Hello,

This is what I get when running your simple command:  
[root@ondemand ~]# ldapsearch uid=at8036  
SASL/EXTERNAL authentication started  
ldap\_sasl\_interactive\_bind\_s: Unknown authentication method (-6)  
additional info: SASL(-4): no mechanism available:

That fails, however this passes with no problem:  
[root@ondemand ~]# ldapsearch -x -h ldap.wayne.edu -b “ou=people,dc=wayne,dc=edu” uid=at8036  
# extended LDIF  
#  
# LDAPv3  
# base \<ou=people,dc=wayne,dc=edu\> with scope subtree  
# filter: uid=at8036  
# requesting: ALL  
#  
…

It is possible to query LDAP anonymously. It isn’t possible to modify LDAP records without a password. The results are the same for my user btw/:

[at8036@ondemand ~] ldapsearch uid=at8036 SASL/EXTERNAL authentication started ldap\_sasl\_interactive\_bind\_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: [at8036@ondemand ~] ldapsearch -x -h ldap.wayne.edu -b “ou=people,dc=wayne,dc=edu” uid=at8036  
# extended LDIF  
#  
# LDAPv3  
# base \<ou=people,dc=wayne,dc=edu\> with scope subtree  
# filter: uid=at8036  
# requesting: ALL  
#  
…

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 28, 2019, 7:08pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/16 "2019-08-28T19:08:34Z")

</div>

OK, your config seems correct, maybe it’s not being added to the actual httpd config? You say you’re not generating _any_ outbound ldap traffic and that may be our only clue.

Look in `/opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf` to see what’s configured there. Does what you configure in `/etc/ood/config/ood_portal.yml` get correctly populated (after you run `/opt/ood/ood-portal-generator/sbin/update_ood_portal`)?

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [September 10, 2019, 5:27pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/17 "2019-09-10T17:27:15Z")

</div>

Any news @at8036? You may need to try upping the log level of that particular module with something like `LogLevel info mod_authnz_ldap:trace5`.

---

<div class="post-metadata">

**Author:** ![efranz](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/efranz/32/27_2.png) [@efranz](https://discourse.openondemand.org/u/efranz)\
**Post date:** [September 10, 2019, 7:10pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/18 "2019-09-10T19:10:36Z")

</div>

Sanity check: what browser are you using?

---

<div class="post-metadata">

**Author:** ![rodgers.355](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rodgers.355/32/193_2.png) [@rodgers.355](https://discourse.openondemand.org/u/rodgers.355)\
**Post date:** [September 10, 2019, 8:07pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/19 "2019-09-10T20:07:27Z")

</div>

@efranz from the Apache access log it looks like FireFox v60 for 64bit Linux:

```nohighlight
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

```

---

<div class="post-metadata">

**Author:** ![at8036](https://avatars.discourse-cdn.com/v4/letter/a/e9c0ed/32.png) [@at8036](https://discourse.openondemand.org/u/at8036)\
**Post date:** [September 16, 2019, 8:47pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/20 "2019-09-16T20:47:51Z")

</div>

Ok, mystery has been resolved. It looks like the main problem was that the yum install adds a file, “ood”, to the sudoers.d directory to give apache sudo for the nginx setup script. I’m using a vm that did not check that directory, hence, nginx wasn’t creating the pun directories. 🙂 I had a number of other problems here and there but that is the primary one to resolve this problem.

Thanks for everyone’s assistance!!!

Thanks,  
Aragorn.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [September 17, 2019, 1:41pm UTC](https://discourse.openondemand.org/t/ldap-authentication-failure/31/21 "2019-09-17T13:41:17Z")

</div>

That’s awesome that you got it fixed! I’m surprised to hear it wasn’t apache directly but some secondary issue.

To be clear, this line wasn’t configured in your /etc/sudoers file?

```auto
# /etc/sudoers
# ...
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

```

[Next page](https://discourse.openondemand.org/t/ldap-authentication-failure/31.md?page=2)
