2

I'm attempting to set up LDAP authentication according to the instructions in Sander Van Vugt's RHCSA/RHCE book for RHEL7. In chapter 6 he explains that when using authconfig-tui the FORCELEGACY option is set to yes in /etc/sysconfig/authconfig. This is supposed to configure nslcd instead of sssd.

I do not see this happening. Perhaps it was that way in 7.0 or even 7.1, but in 7.3 the option is set to no after using authconfig-tui.

If I put aside the nslcd vs sssd confusion and attempt the complete the exercise which leads to running su - lara to authenticate via LDAP to said user, I merely get:

su: user lara does not exist

I've verified that the FreeIPA server is answering queries using ldapsearch and in doing so, confirmed that the user is in LDAP. It seems to me, though, that su is not authenticating against LDAP, but instead /etc/passwd.

My PAM system-auth configuration includes the sssd entries that seem to be necessary:

auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam.sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

My /etc/nsswitch.conf file contains:

passwd:    files sss
shadow:    files sss
group:     files sss

The sssd service is active.

There aren't any log entries in /var/log/* or /var/log/sssd/*. In fact, none of the sssd logs contains anything.

EDIT

After some reading I'm still no closer to a solution to this, however, I do have more information.

I am able to authenticate as user lara if I ssh into the LDAP server. So I know that LDAP is actually working.

I also looked at the PAM config for su. This is pulling in the system-auth file:

auth        substack        system-auth
account     include         system-auth
password    include         system-auth
session     include         system-auth

so it should be making use of the pam_sss.so module implicitly.

Still can't sort it out, though.

EDIT 2

Being able to log into the IPA server either locally or via SSH with user lara, I decided to compare the pam files on it with those on the client. The only difference I was able to determine is that the client contained broken_shadow with the pam_unix.so account entry. I removed it and even rebooted but it didn't fix anything.

How do I disable broken_shadow? I can't find anything about it.

  • Have a look at the contents of /etc/pam.d/login (which is clearly working) versus /etc/pam.d/su (which is likely wrong in some way) – steve Apr 28 '17 at 20:15
  • @steve /etc/pam.d/login contains the same includes and substack statements as /etc/pam.d/su. I've also attempted to log in directly as user lara on the client side. It didn't even attempt to check LDAP. It simply said Login incorrect because the local user doesn't exist. – theillien Apr 29 '17 at 7:52
  • Did you try to login ldap user thru phpldapadmin ? Before you used pam for ldap authentication. – supriady Jul 26 '18 at 14:02
0

This may be unrelated, but I'm following the same course (with a client Server of my creation) and managed to fix it by doing the following:

  1. Checking everything matched what I'd set in authconfig-tui in /etc/sssd/sssd.conf
  2. Setting the permissions on /etc/sssd/sssd.conf to 0600 (it worked immediately after that) - I'm unsure why this made a difference, given that it only grants user R/W, but I found it under an Oracle guide for RHEL7 SSSD Client configuration: https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-sssd-ldap.html

EDIT: Possible explanation: https://pagure.io/SSSD/sssd/issue/1413

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.