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:
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?
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:
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 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.
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.
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.
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?
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.
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:
[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.
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?
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
#
…
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)?
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.
I had a number of other problems here and there but that is the primary one to resolve this problem.