Description of problem: I was testing a FreeIPA update (https://bodhi.fedoraproject.org/updates/FEDORA-2018-93dfeefc68) which pulls in a newer authselect (0.4-3). This breaks FreeIPA centrally managed sudo rules. Turns out this isn't the fault of freeipa, but just upgrading authselect from the previous version 0.4-1 to 0.4-3 already breaks it Version-Release number of selected component (if applicable): 0.4-3.fc28 How reproducible: Always Steps to Reproduce: 1. Enroll into a FreeIPA domain 2. Add a sudo rule for the "admin" user: ipa sudorule-add --hostcat=all --cmdcat=all All && ipa sudorule-add-user --groups=admins All 3. Log in as that user and try to run `sudo whoami` Actual results: $ sudo whoami [sudo] password for admin: admin is not in the sudoers file. This incident will be reported. Expected results: sudo succeeds (like it does with the previous authselect) Additional info: * This is broken for both qualified (admin) or unqualified (admin) user names. * This was detected by Cockpit's integration tests when trying to refresh the Fedora 28 image (https://github.com/cockpit-project/cockpit/pull/9224)
This is due to https://github.com/pbrezina/authselect/commit/4b1981a67216f56e67cff3887fe38ee8063ee0b2. Unfortunately, FreeIPA wasn't consulted and updated to add 'with-sudo' option, thus it broke. I'm moving this to freeipa for handling.
ab | pitti: until authselect use is fixed in freeipa, you can get sudo rules back with 'authselect enable-feature with-sudo'
Upstream ticket: https://pagure.io/freeipa/issue/7562
Created attachment 1441043 [details] log with authselect 0.4-3 and freeipa pre1 As requested by Alexander, I'm collecting config/log files from various scenarios. This is authselect 0.4-3 (the "broken" one) with the current freeipa-client-4.6.90.pre1-6.1.fc28 ; the minimal change to the previously working scenario with authselect 0.4-1 and the same freeipa
great, thanks. With freeipa pre1/authselect 0.4-3: ------------------------ 2018-05-24T12:27:49Z DEBUG Starting external process 2018-05-24T12:27:49Z DEBUG args=['/usr/sbin/authconfig', '--enablesssd', '--enablesssdauth', '--enablemkhomedir', '--update'] 2018-05-24T12:27:49Z DEBUG Process finished, return code=0 2018-05-24T12:27:49Z DEBUG stdout=Running authconfig compatibility tool. IMPORTANT: authconfig is replaced by authselect, please update your scripts. See Fedora 28 Change Page: https://fedoraproject.org/wiki/Changes/AuthselectAsDefault See man authselect-migration(7) to help you with migration to authselect Executing: /usr/bin/authselect select sssd --force with-mkhomedir -------------------------- So my theory is right: authselect is called via authconfig compatibility layer and sets the default configuration without sudo support.
Created attachment 1441044 [details] logs with authselect 0.4-3 and freeipa pre2 This is now an image with the newer authselect (0.4-3) and freeipa 4.6.90.pre2-3.fc28 (from https://bodhi.fedoraproject.org/updates/FEDORA-2018-93dfeefc68). Again, this is "clean install, then upgrade packages, *then* enroll into the domain". Same sudo issue.
Created attachment 1441045 [details] logs with authselect 0.4-3 and freeipa pre2 and enable-feature with-sudo Same as before, but now I ran "authselect enable-feature with-sudo", which added the appropriate authselect files. Et voilà: [root@x0 ~]# authselect enable-feature with-sudo [root@x0 ~]# su - admin Last login: Do Mai 24 08:48:51 EDT 2018 [admin@x0 ~]$ sudo whoami [sudo] password for admin: root Attaching the logs again for completeness.
And with pre2/authselect 0.4-3 we seem to run authselect directly: ----------------------- 2018-05-24T12:40:21Z DEBUG Starting external process 2018-05-24T12:40:22Z DEBUG args=['/usr/bin/authselect', 'current', '--raw'] 2018-05-24T12:40:22Z DEBUG Process finished, return code=2 2018-05-24T12:40:22Z DEBUG stdout=No existing configuration detected. 2018-05-24T12:40:22Z DEBUG stderr= 2018-05-24T12:40:22Z DEBUG Current configuration not managed by authselect 2018-05-24T12:40:22Z WARNING WARNING: The configuration pre-client installation is not managed by authselect and cannot be backed up. Uninstallation may not be able to revert to the original state. 2018-05-24T12:40:22Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' 2018-05-24T12:40:22Z DEBUG Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' 2018-05-24T12:40:22Z DEBUG Starting external process 2018-05-24T12:40:22Z DEBUG args=['/usr/bin/authselect', 'select', 'sssd', 'with-mkhomedir', '--force'] 2018-05-24T12:40:22Z DEBUG Process finished, return code=0 2018-05-24T12:40:22Z DEBUG stdout= 2018-05-24T12:40:22Z DEBUG stderr= 2018-05-24T12:40:22Z INFO SSSD enabled ----------------------- So we definitely need to add with-sudo here.
Created attachment 1441054 [details] logs from upgrading authselect and ipa Upgrade scenario: Starting from IPA pre1 and authselect 0.4-1, then enrolling into a domain (sudo works), and *then* upgrading packages: Upgrading: authselect x86_64 0.4-3.fc28 updates 24 k authselect-compat x86_64 0.4-3.fc28 updates 30 k authselect-libs x86_64 0.4-3.fc28 updates 49 k freeipa-client x86_64 4.6.90.pre2-3.fc28 @commandline 157 k freeipa-client-common noarch 4.6.90.pre2-3.fc28 @commandline 65 k freeipa-common noarch 4.6.90.pre2-3.fc28 @commandline 604 k nss x86_64 3.36.1-1.1.fc28 updates 646 k nss-softokn x86_64 3.36.1-1.1.fc28 updates 383 k nss-softokn-freebl x86_64 3.36.1-1.1.fc28 updates 227 k nss-sysinit x86_64 3.36.1-1.1.fc28 updates 64 k nss-tools x86_64 3.36.1-1.1.fc28 updates 480 k nss-util x86_64 3.36.1-1.0.fc28 updates 90 k python3-ipaclient noarch 4.6.90.pre2-3.fc28 @commandline 556 k python3-ipalib noarch 4.6.90.pre2-3.fc28 @commandline 558 k Installing dependencies: libsss_simpleifp x86_64 1.16.1-2.fc28 fedora 76 k python3-sss x86_64 1.16.1-2.fc28 fedora 92 k sssd-dbus x86_64 1.16.1-2.fc28 fedora 187 k sssd-tools x86_64 1.16.1-2.fc28 fedora 349 k This created a 0-byte (!) file /var/log/ipaupgrade.log. Then I rebooted. This now also broke sudo: # grep -r sudo /etc/authselect/ /etc/authselect/nsswitch.conf:sudoers: files after reboot, /var/log/ipaupgrade.log is still empty, so that doesn't help much. However, attaching all the files as before.
Ok, so upgrade case is equal to the first one: authconfig-compat creates default profile 'sssd', then authselect upgrade removes sudo because it is not part of the default profile anymore.
Moving the BZ to authselect component as authselect should handle upgrade from authconfig to authselect when sudo support is enabled.
I provided a scratch build to the other bug [1] and I'm waiting for some feedback before I push the build to Fedora. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1577615#c7
I installed the authselect{,-libs}-0.4-3.1.fc28.x86_64 scratch build, joined a domain, and nsswitch.conf still only says "sudoers: files", and sudo is not working. The fix above only seems to apply to upgrades, not to fresh installs and realm joins?
Hi Martin, you are right, the fix only applies to upgrades. We also need to make a fix on ipa side for fresh installs (in the installer, configure authselect select sssd *with-sudo*). This is why we kept 2 different BZs (this one against authselect, and 1577615 against freeipa).
authselect-0.4-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9622a5cc95
authselect-0.4-4.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-9622a5cc95
I pushed Florence's fix to FreeIPA upstream, https://pagure.io/freeipa/c/eda831dba1e09e7f4660c64756343538042b48e0
Thank you.
Upgrade to authselect-0.4.4.fc28 manually tested, correctly adds the with-sudo feature.
authselect-0.4-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
Maybe upgrades are fixed, but fresh installs are not. A fresh install of Fedora 28 with updates, and authselect-0.4-4.fc28.x86_64 still has sudoers: files in nsswitch.conf by default, so that sudo does not work out of the box with FreeIPA.
This is with freeipa-client-4.6.90.pre2-3.fc28.x86_64
Could you try again with latest FreeIPA? 4.7.0 is GA.
Whoops, that was an older image indeed, sorry about that (refreshes are stuck on getting a new Fedora Atomic out, but that's a different story). Re-tested with authselect 1.0-1.fc28 and freeipa-client 4.7.0-1.fc28, and it still fails. In fact now "sudo" doesn't appear in /etc/nsswitch.conf at all any more. I attach that and the current ipa client install log.
Created attachment 1479057 [details] nsswitch.conf with authselect 1.0-1 and freeipa 4.7.0
Created attachment 1479058 [details] ipaclient-install.log with authselect 1.0-1 and freeipa 4.7.0
From ipaclient-install.log it seems that authselect indeed initially enables sudo: sudoers: files sss 2018-08-27T20:00:27Z INFO Configured sudoers in /etc/nsswitch.conf [...] 2018-08-27T20:00:36Z DEBUG args=['/usr/bin/authselect', 'select', 'sssd', 'with-mkhomedir', 'with-sudo', '--force'] 2018-08-27T20:00:37Z DEBUG Process finished, return code=0 but later on, sssd seems to revert it? 2018-08-27T20:00:36Z DEBUG args=['/usr/bin/authselect', 'select', 'sssd', 'with-mkhomedir', 'with-sudo', '--force'] 2018-08-27T20:00:37Z DEBUG Process finished, return code=0 2018-08-27T20:00:37Z DEBUG stdout=Backup stored at /var/lib/authselect/backups/2018-08-27-20-00-37.trqwy2 Profile "sssd" was selected. The following nsswitch maps are overwritten by the profile: - passwd - group - netgroup - automount - services - sudoers
Can you please also pass the content of /etc/authselect/user-nsswitch.conf please?
Also is /etc/nsswitch.conf symbolik link to /etc/authselect/nsswitch.conf? And what is the output of `authselect check`?
Created attachment 1479170 [details] /etc/authselect/user-nsswitch.conf with authselect 1.0-1 and freeipa 4.7.0 Attached /etc/authselect/user-nsswitch.conf . There is also no sudo rule there.
It is a symbolic link: /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf # authselect check Current configuration is valid.
OK. Thank you. And what is the output of 'authselect current'?
# authselect current Profile ID: sssd Enabled features: - with-mkhomedir
Apparently, the current authselect configuration is really valid. What I can see from given information is that the nsswitch.conf was generated at 4PM but ipa-client-install runs authselect at 8PM the same day. Can you check if other files under /etc/authselect were generated at the same time? I know IPA creates backup of pre-installation state. Is it possible that the system was restored to this state?
Timestamps: [root@x0 ~]# ls -l /etc/nsswitch.conf /etc/authselect/ /var/log/ipaclient-install.log lrwxrwxrwx. 1 root root 29 28. Aug 04:20 /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf -rw-------. 1 root root 116745 28. Aug 04:20 /var/log/ipaclient-install.log /etc/authselect/: total 40 -rw-r--r--. 1 root root 20 28. Aug 04:20 authselect.conf drwxr-xr-x. 2 root root 6 14. Aug 06:32 custom -rw-r--r--. 1 root root 195 28. Aug 04:20 dconf-db -rw-r--r--. 1 root root 205 28. Aug 04:20 dconf-locks -rw-r--r--. 1 root root 91 28. Aug 04:20 fingerprint-auth -rw-r--r--. 1 root root 2574 28. Aug 04:20 nsswitch.conf -rw-r--r--. 1 root root 2062 28. Aug 04:20 password-auth -rw-r--r--. 1 root root 399 28. Aug 04:20 postlogin -rw-r--r--. 1 root root 91 28. Aug 04:20 smartcard-auth -rw-r--r--. 1 root root 2062 28. Aug 04:20 system-auth -rw-r--r--. 1 root root 1731 27. Aug 15:56 user-nsswitch.conf > Is it possible that the system was restored to this state? What would do this? I didn't manually un-enroll this system or anything. E. g. I can log into it as a FreeIPA user: # ssh -l admin localhost [...] [admin@x0 ~]$ id uid=573400000(admin) gid=573400000(admins) groups=573400000(admins) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 It's just sudo that is broken: $ sudo whoami [sudo] password for admin: admin is not in the sudoers file. This incident will be reported. Is that not reproducible on a standard Fedora 28 VM on your side? There's nothing magic in my VM that I'm aware of..
Timestamps do not match. - Attached nsswitch.conf was generated at Mon Aug 27 16:00:48 2018 as we can see in the file header. - ipa-client-install was called at 2018-08-27T20:00:03Z as we can see from the log. - And output of your ls commands says that files were generated a day later at 28. Aug 04:20 IPA server and client installation works for me well with following packages: [root@client vagrant]# rpm -qa authselect authselect-1.0-1.fc28.x86_64 [root@client vagrant]# rpm -qa | grep freeipa freeipa-common-4.7.0-1.fc28.noarch freeipa-client-common-4.7.0-1.fc28.noarch freeipa-client-4.7.0-1.fc28.x86_64
The day before (on Aug 27) I updated the VM to the latest freeipa + authselect packages, then on Aug 28 I ran the test again and collected the logs and packages. So it seems like user-nsswitch.conf actually gets created at package install/upgrade time (Aug 27), not on realm enrollment time (Aug 28)? I. e. maybe this only affects upgrades, not fresh installs?
Upgrade case works for me as well. 1. install authselect-0.4-3, freeipa-client 4.6.90.pre1-6.1.fc28 2. ipa-client-install 3. dnf update authselect freeipa-client 4. authselect current Profile ID: sssd Enabled features: - with-sudo Frankly, I am now lost in all those comments. Can you please describe exactly your steps that you have taken?
I now tried this again with a very recent Fedora 28, without any package upgrades (this is a clean virt-install), with authselect-1.0-1.fc28.x86_64 freeipa-client-4.7.0-1.fc28.x86_64 The reproduction steps from the description are still valid. But I repeat them here, with more detail, for absolute clarity: 1. Have a FreeIPA server nearby. I use a VM which serves the "COCKPIT.LAN" domain. There's nothing particularly magic or non-standard about our's, you can see how it it set up here: https://github.com/cockpit-project/cockpit/blob/master/bots/images/scripts/ipa.setup . This is called "f0.cockpit.lan". 2. Configure the IPA server to make sudo work out of the box (see https://pagure.io/freeipa/issue/7538) # kinit -f admin # ipa sudorule-add --hostcat=all --cmdcat=all All && ipa sudorule-add-user --groups=admins All (This can also be done on the enrolled client, but let's do as little as possible there) 3. Boot a current Fedora 28 machine. No custom configuration, no local "admin" user, just the stock freeipa-client and authselect packages. # id admin id: ‘admin’: no such user 4. Make sure it's in the same DNS domain: # hostnamectl set-hostname x0.cockpit.lan 5. Enroll into domain: # printf '[cockpit.lan]\nfully-qualified-names = no\n' >> /etc/realmd.conf (Workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1575538) # realm join -vU admin cockpit.lan (Type admin password, everything else should be automatic) 6. Wait until everything actually works (after the above command it won't, there's still stuff happening in the background). These should succeed: # while ! id admin; do sleep 5; done # this might take a minute or two # ssh -l admin localhost # this might also not succeed at the first time Now you are logged in as "admin" FreeIPA user. 7. Check nsswitch: [admin@x0 /]$ grep sudo /etc/nsswitch.conf (No hits) 8. Try to sudo: [admin@x0 /]$ sudo whoami [sudo] password for admin: admin is not in the sudoers file. This incident will be reported. You can do the same without the "fully-qualified-names = no" change from above, and then use "admin@localhost" as user name. Same result. This can be fixed with running "authselect enable-feature with-sudo" after joining, which will set up nsswitch correctly. I now modified step 5 to not use "realm join", but # ipa-client-install (Confirm defaults, user "admin", type your password, everything else should be automatic) And indeed it works now. So it seems this is a bug in conjunction with realmd. I'll file a new bug there instead.
See bug 1620097. Thanks!