Description of problem: When joining an IPA domain, `realm join` calls `ipa-client-install`, which configures sudo via authselect, and then calls authselect directly as a part of sssd-enable-login, where the sudo gets disabled. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. realm join MY.REALM 2. sudo -s Actual results: Error mesage "<username> is not in the sudoers file. This incident will be reported." Expected results: Running shell with appropriate permissions. Additional info: Previous discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1575538#c9
I debugged this a lot in bug 1582111 (which previously had the same net effect, but different root cause). I copy the detailled reproduction steps here, for the record: authselect-1.0-1.fc28.x86_64 freeipa-client-4.7.0-1.fc28.x86_64 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 realmd breaks ipa-client-install's nss rules.
Sumit, could you please add "with-sudo" to authselect call when joining to ipa domain? Thank you.
realmd-0.16.3-16.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d186fcd168
realmd-0.16.3-16.fc29 has been pushed to the Fedora 29 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-d186fcd168
realmd-0.16.3-16.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
I noticed this problem tonight. I just installed fc29 modular Linux 9b7811.localdomain 4.18.16-300.fc29.x86_64 #1 SMP Sat Oct 20 23:24:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux and checked the installer option for IPA server (not knowing what it was for. I can sudo if I am logging in from the local console, ( when I successfully did sudo dnf update) but not if I am logging in from the network. First I thought I forgot to check the "make user administrator" in the installer GUI, so I did the installation over again! I will follow this bug, so please let me know if I can do anything to help.