Bug 1575297
Summary: | No login possible for NIS users on fedora 28 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom Horsley <horsley1953> |
Component: | authselect | Assignee: | Pavel Březina <pbrezina> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | bryan, dave.close, edgar.hoch, ed.greshko, igeorgex, jerrylu2008, jhrozek, john.kissane, jszinger, mjc, mmuzila, nigel.arnot, pawel_sikora, pbrezina, rkudyba, rstonehouse, sampos, shooman, zing |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | authselect-1.0-1.fc28 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-08-22 01:26:41 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tom Horsley
2018-05-05 19:28:23 UTC
Same problem. Console login to NIS user fails. Remote ssh login to NIS user succeeds but with very long delay. Please advise on information to collect from the remote session to help with the investigation. Thanks. FWIW, the problem seems to be on the client side. I created 2 VM's (a client and a server) both running F28. I then verified the problem. I also used wireshark to trace the communication between them and it looked OK. The server returned the pw to the client. I then created a 3rd VM as a client running F27. From F27 I am able to login as the NIS user. So, something appears amiss on the F28 client side. Correction to original report: I don't see the user names show up in "ls", I just see the uid. Not sure if they once appeared, or if I was looking at the wrong things when I made that observation. (I do get valid ypcat passwd output though). (In reply to Tom Horsley from comment #3) > Correction to original report: I don't see the user names show up in "ls", I > just see the uid. Not sure if they once appeared, or if I was looking at the > wrong things when I made that observation. (I do get valid ypcat passwd > output though). I do see the user name. The host f28xfce is the client system.... [egreshko@meimei ~]$ ssh 192.168.1.81 egreshko.1.81's password: Last login: Mon May 7 22:56:46 2018 from 192.168.1.18 [egreshko@f28xfce ~]$ su - maria Password: su: Authentication failure [egreshko@f28xfce ~]$ su - Password: Last login: Mon May 7 22:33:08 CST 2018 on pts/2 [root@f28xfce ~]# su - maria Last login: Mon May 7 21:47:40 CST 2018 on pts/2 Last failed login: Tue May 8 07:37:36 CST 2018 on pts/2 There were 9 failed login attempts since the last successful login. [maria@f28xfce ~]$ whoami maria [maria@f28xfce ~]$ ll total 0 [maria@f28xfce ~]$ touch test [maria@f28xfce ~]$ ll total 0 -rw-rw-r--. 1 maria maria 0 May 8 07:38 test OK, so maybe I did see them at first, but they are gone now (after various experiments which may have busted something more thoroughly :-). (In reply to Tom Horsley from comment #5) > OK, so maybe I did see them at first, but they are gone now (after various > experiments which may have busted something more thoroughly :-). Yep, it was my experimenting. There was some bits of sssd still enabled, I disabled them, and the names started showing up in ls output again. If I really need to run as an NIS user now, I can login as root then "su -l nisuser" and that seems to work. Possible duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1574959 "Set IPAddressDeny= in systemd-logind service file". At least the symptoms sound similar. Does the workaround in https://github.com/systemd/systemd/issues/7074 "systemd-logind's IP sandbox breaks nss-nis and suchlike" help? I changed the systemd-logind service file as described and even rebooted to make sure absolutely everything got re-initialized, I still get this from an ssh attempt: May 8 11:33:43 tomh sshd[2774]: fatal: Access denied for user tom by PAM account configuration [preauth] Was there some change to pam to remove NIS support? (In reply to Tom Horsley from comment #8) > May 8 11:33:43 tomh sshd[2774]: fatal: Access denied for user tom by PAM > account configuration [preauth] > > Was there some change to pam to remove NIS support? I too made the changes suggested in comment #7. It did not fix the problem for me either. One thing though. My error message in the logs is different. I get, May 09 06:43:52 f28xfce.greshko.com sshd[11836]: Failed password for maria from 192.168.1.18 port 55602 ssh2 In my attempts to solve the problem, I did create a sssd.conf file on the client containing. [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam debug_level = 2 [nss] filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_nowait_percentage = 75 No help, of course. :-( Have a try to edit the following file. /etc/pam.d/password-auth Then comment the following line. #auth [default=1 ignore=ignore success=ok] pam_localuser.so Also edit /etc/pam.d/system-auth then comment the following line. #auth [default=1 ignore=ignore success=ok] pam_localuser.so #account sufficient pam_localuser.so Just tried commenting out the above localuser lines in the two files. No change, still getting the same error: May 9 09:31:34 tomh sshd[9158]: fatal: Access denied for user tom by PAM account configuration [preauth] I didn't reboot or anything, is something additional required to make pam config files take effect? I have made those changes to the client side and it is now working for me. [egreshko@meimei ~]$ ssh maria.1.81 maria.1.81's password: Last login: Wed May 9 21:34:22 2018 from 192.168.1.18 [maria@f28xfce ~]$ grep maria /etc/passwd [maria@f28xfce ~]$ This brings up a few questions such as.... Why were these lines added? Will commenting them have a downside? Since those files are generated by authselect won't the changes be reverted at some point? And does this mean NIS will only work if I also enable sssd and install the config file described above? Because just changing the pam.d files didn't work for me. (In reply to Tom Horsley from comment #14) > And does this mean NIS will only work if I also enable sssd and install the > config file described above? Because just changing the pam.d files didn't > work for me. Just for completeness, this is my nsswitch.conf # Generated by authselect on Wed Apr 4 20:58:48 2018 # Do not modify this file manually. passwd: sss files nis group: sss files nis netgroup: sss files automount: sss files services: sss files sudoers: files sss shadow: files ethers: files netmasks: files networks: files protocols: files rpc: files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname aliases: files nisplus bootparams: nisplus [NOTFOUND=return] files publickey: nisplus And my sssd.conf I've alaready posted.... And.... I just found the answer to one of my questions. There is a downside to making those changes. [egreshko@meimei ~]$ ssh maria.1.81 maria.1.81's password: Last login: Wed May 9 22:32:02 2018 from 192.168.1.18 [maria@f28xfce ~]$ su - su: Authentication failure I can no longer su to root! Not so good... sudo still works. Let me summarize what I did. 1. # yum install libnsl nss_nis ypbind autofs 2. Disable selinux on /etc/selinux/config 3. # yum remove firewalld (optional) 4. # systemctl enable ypbind 5. # systemctl enable autofs 6. # vi /etc/nsswitch.conf passwd: files nis group: files nis netgroup: files nis automount: files nis services: files sudoers: files shadow: files nis ethers: files netmasks: files networks: files protocols: files rpc: files hosts: files dns aliases: files nisplus bootparams: nisplus files publickey: nisplus 7. vi /lib/systemd/system/systemd-udevd.service (Comment #IPAddressDeny=any) 8. vi /lib/systemd/system/systemd-logind.service (Comment #IPAddressDeny=any) 9. vi /etc/pam.d/password-auth auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet #auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success #auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_unix.so #account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet #account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok #password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so #session optional pam_sss.so 10. vi /etc/pam.d/system-auth auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet #auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success #auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_unix.so #account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet #account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok #password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so #session optional pam_sss.so 11. # yum remove sssd 12. # yum remove authselect 13. # yum install libnsl nss_nis 14. # reboot (In reply to Ed Greshko from comment #15) > (In reply to Tom Horsley from comment #14) > > And does this mean NIS will only work if I also enable sssd and install the > > config file described above? Because just changing the pam.d files didn't > > work for me. > > Just for completeness, this is my nsswitch.conf > > # Generated by authselect on Wed Apr 4 20:58:48 2018 > # Do not modify this file manually. > > passwd: sss files nis > group: sss files nis > netgroup: sss files > automount: sss files > services: sss files > sudoers: files sss > > shadow: files > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname > > aliases: files nisplus > bootparams: nisplus [NOTFOUND=return] files > publickey: nisplus > > And my sssd.conf I've alaready posted.... > > > And.... I just found the answer to one of my questions. There is a > downside to making those changes. > > [egreshko@meimei ~]$ ssh maria.1.81 > maria.1.81's password: > Last login: Wed May 9 22:32:02 2018 from 192.168.1.18 > [maria@f28xfce ~]$ su - > su: Authentication failure > > I can no longer su to root! Not so good... > > sudo still works. Comment the following line from /etc/pam.d/system-auth & /etc/pam.d/password-auth #auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet (In reply to jerrylu2008 from comment #17) > Comment the following line from /etc/pam.d/system-auth & > /etc/pam.d/password-auth > > #auth [default=1 ignore=ignore success=ok] pam_succeed_if.so > uid >= 1000 quiet OK, this fixes (works-around) the problem of not being able to "su -". So, it seems, all the "fixes" I needed to get this working was changes to pam. This would seem to indicate a BZ is needed with pam as the package needing fixes? I just got NIS working in a somewhat similar way to comment #16 in /lib/systemd/system/systemd-udevd.service and /lib/systemd/system/systemd-logind.service, I commented out the line #IPAddressDeny=any Then I copied my fedora 27 versions of password-auth and system-auth into my fedora 28 /etc/pam.d directory (saving the f28 versions in case I needed to put them back). I had already point passwd, group and shadow at "files nis" in /etc/nsswitch.conf and installed and enabled ypbind. I didn't remove sssd, I just made sure it was disabled. Then I rebooted and everything is working again. I can use "su", I can login as an NIS user, I can login as a local user. It is all back to normal. Maybe an "nis" config for authselect is what is needed? Adding to the above comments, I was able to get mine to work by adding nis to the /etc/authselect/nsswitch.conf file. Re-running authselect breaks this. Confounding the issue is that authselect does not understand mdns4 (i.e. it would remove the mdns4_minimal line from nsswitch.conf), so my configuration would not work until I had both name resolution and nis lookup working. mdns issue is documented here: https://bugzilla.redhat.com/show_bug.cgi?id=1577243 Hi, there was a missing dependency in ypbind-2.4-7.fc28.x86_64 to nss_nis. This was fixed in ypbind-2.4-8.fc28.x86_64. Although there are problems with login, the ypbind itself seems to work well. I'm moving the bug to authselect. Any idea if there will be a 32 bit RPM pushed for Fedora 28? To summarize, removing lines 5 and 6 from [1] fix this issue? In general, authselect do not provide any native support for NIS anymore as authconfig did so manual changes are needed or a custom profile for authselect needs to be created. Given how many users are involved in this BZ, we will consider providing some level of support in upstream. [1] https://github.com/pbrezina/authselect/blob/master/profiles/sssd/system-auth#L5 I created a BZ at https://bugzilla.redhat.com/show_bug.cgi?id=1576558 and when I reboot a 64-bit Fedora 28 server with nis in the /etc/nsswitch.conf file, systemd-login just keeps coredumping and I can never get to a login prompt. Once I remove the nis entries in the /etc/nsswitch.conf I can get to the desktop login manager (or ssh) and login as a local (non-NIS) user. I can then enable NIS logins by adding the nis entries back into the /etc/nsswitch.conf file and NIS users can then log in. Why would systemd-logind continue to crash even after I commented out, i.e., #IPAddressDeny=any, in /lib/systemd/system/systemd-udevd.service and /lib/systemd/system/systemd-logind.service? We decided to create an authselect profil for NIS to setup nsswitch.conf and PAM. Upstream ticket: https://github.com/pbrezina/authselect/issues/61 So does this mean NIS still won't work when I install fedora 29 until I manually run authselect to change to the NIS profile? (In reply to Tom Horsley from comment #26) > So does this mean NIS still won't work when I install fedora 29 until I > manually run authselect to change to the NIS profile? Yes authselect-1.0-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2dd06e12ff authselect-1.0-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2dd06e12ff I ran into this problem also while testing a kickstart install of Fedora 28. Previous script for F27 used authconfig to configure NIS. The test version of authselect allowed me to select NIS successfully. Do you need to add the entry to the yp.conf file manually now as authconfig took the domain & servers a parameter & updated the file eg: authconfig --enableshadow --enablemd5 --enablenis --nisdomain=DOMAIN --nisserver=SERVER --enablecach Thank you for testing. The test version of authselect also provides updated authconfig compatibility tool which supports --enablenis, --nisdomain and --nisserver so if you install F28 with updated packages the kickstart with authconfig script should configure system correctly. (In reply to Pavel Březina from comment #31) > Thank you for testing. The test version of authselect also provides updated > authconfig compatibility tool which supports --enablenis, --nisdomain and > --nisserver so if you install F28 with updated packages the kickstart with > authconfig script should configure system correctly. Thank you, that worked perfectly! authconfig --enablenis --nisdomain=DOMAIN --nisserver=server --updateall If it works for you, can you give karma and provide feedback at [1] please? [1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-2dd06e12ff (In reply to Pavel Březina from comment #33) > If it works for you, can you give karma and provide feedback at [1] please? > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-2dd06e12ff I already did but it shows me as anonymous. authselect-1.0-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. Hi there, There seems to be a related problem with kickstart deployments of Fedora 28. Booting off Fedora-Server-netinst-x86_64-28-1.1.iso (2018-04-25), the install fails with Problem: conflicting requests - nothing provides authselect (x86-64) = 0.4-1.fc28 needed by authselect-compat-0.4-1.fc28.x86_64 - nothing provides authselect (x86-64) = 1.0-1.fc28 needed by authselect-compat-1.0-1.fc28.x86_64 The kickstart file contains these relevant lines: repo --name=updates --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f28&arch=x86_64 authconfig --enableshadow --passalgo=sha512 --enablenis --nisdomain=REDACTED --nisserver=192.168.99.99 --disablesssd --disablesssdauth Is there a need to provide updated .iso images? Is there any other work-around? I can confirm that dnf system-upgrade of a working Fedora 27 system using NIS for logins, now results in a working Fedora-28 system still using NIS. For now I can kickstart-install Fedora 27 and then immediately upgrade to Fedora 28, but this will become a problem some time after Fedora 29 ships and Fedora 27 goes EOL. Ignore my previous comment (#36) as far as kickstart installation is concerned. It works, with the repo and authconfig lines as specified. Fedora 28 is go. (I'd corrupted the packages list in my fedora 28 development KS file). |