In Fedora 26 FreeIPA testing we can now get as far as deploying the server and enrolling a client. However, one of the early post-enrolment client tests fails. One of the first things the client tests after enrolment is to run this: getent passwd admin@DOMAIN (where DOMAIN is the correct name of the domain). In testing of current Fedora 26 plus 389-ds-base-1.3.6.2-2.fc26 , this consistently returns nothing (rather than details of the admin user account, as it should). I don't have a lot of debugging info yet, will update this report as I manage to get it. This is probably a violation of Alpha criterion "The core functional requirements for all Featured Server Roles must be met, but it is acceptable if moderate workarounds are necessary to achieve this", core requirement "Client systems must be able to authenticate users with Kerberos" - https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria#Role_functional_requirements , https://fedoraproject.org/wiki/Domain_controller_role_requirements .
Right, logs are needed (this works for me with sssd built from master which is quite similar to what is in 26)
Looks like logging in as a domain user doesn't work either, per the cockpit enrolment / webui test: https://openqa.stg.fedoraproject.org/tests/80457 that one tries logging in as a domain user (created via the webui) before it tries the 'getent passwd' test, and the login is refused...
So I adapted the test to upload /etc/nsswitch.conf , and that looks wrong: https://openqa.stg.fedoraproject.org/tests/80574/file/freeipa_client-nsswitch.conf Note these lines: passwd: shadow: group: it seems like client enrolment somehow didn't modify nsswitch.conf correctly. I guess I'll tweak the test again to upload it once *before* enrolment and once *after* and we can diff the result.
It would be also good to see content of /etc/nsswitch, /etc/pam.d/system-auth, /etc/pam.d/password-auth. + related part of journald (equivalent to /var/log/secure) for failed authentication
It looks like the 'authconfig' command realmd ran was: /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart The authconfig in Fedora 26 currently is authconfig-7.0.0-1.fc26 .
(In reply to Adam Williamson from comment #3) > So I adapted the test to upload /etc/nsswitch.conf , and that looks wrong: > > https://openqa.stg.fedoraproject.org/tests/80574/file/freeipa_client- > nsswitch.conf > > Note these lines: > > passwd: > shadow: > group: > > it seems like client enrolment somehow didn't modify nsswitch.conf > correctly. I guess I'll tweak the test again to upload it once *before* > enrolment and once *after* and we can diff the result. I would expect some issue with authconfig; which is called from ipa-client-install. Because IIRC ipa-client-install does not touch this file directly. It might be related to glibc change in order Current default on f26+ is passwd: sss files systemd shadow: files sss group: sss files systemd
(In reply to Adam Williamson from comment #5) > It looks like the 'authconfig' command realmd ran was: > > /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth > --enablemkhomedir --nostart > > The authconfig in Fedora 26 currently is authconfig-7.0.0-1.fc26 . BTW does "authconfig --updateall" help?
Well, this is my fault for assuming that if sss is already in nsswitch.conf, then running authconfig --enablesssd wouldn't touch nsswitch.conf because...sss is already there. But this must be fixed on the authconfig side, the nsswitch.conf file is definitely wrong.
So it looks like this is a bug in authconfig 7.0.0. Luckily you don't actually need to go through a whole FreeIPA deployment to test this: you can easily do it with just a stock Fedora 26 install. Do a stock F26 install, then do: cp /etc/nsswitch.conf /etc/nsswitch.conf.bak authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart Inspect /etc/nsswitch.conf and note the passwd, shadow and group lines are all blank. If you restore the original nsswitch.conf, downgrade authconfig to the previous build - authconfig-6.2.10-16.fc26 - and try again, the lines are not blank. So clearly this broke in authconfig 7.0.0.
Actually, this behaves rather oddly. The *first* time you run the authconfig command, it messes up nsswitch.conf . You can then re-run it as many times as you like, and it'll leave it messed up. But if you then copy the backup file back into place and run authconfig *again*, it'll produce a correct-looking nsswitch.conf! I have no idea why that happens. From that point on, I can't get it to break again: I have to revert to a snapshot of the clean post-install state to recreate the bug again. But it seems like the first run always breaks the file.
It's still a bug in 7.0.0, though, it seems: 6.2.10 doesn't do the same. If I downgrade to authconfig 6.2.10 before the first authconfig attempt, the first one works OK. Only 7.0.0 seems to have this weird "first attempt fails" bug.
OK, the bug here is actually pretty obvious: the `writeNSS` function in authinfo.py (in authconfig) initializes a variable called `users` as the empty string, then never updates it from that value, then uses it as the value for the passwd, shadow and group lines. It does a lot of work to populate a *different* variable called `normal`, and I suspect what's missing is a simple: users = normal at some point. I'm going to send a PR for authconfig and do a package build with it included.
https://pagure.io/authconfig/pull-request/7 should fix this. I will do a package build with the patch applied and test it.
Note on the 'only happens on first run' thing: that's just because of the `--update` arg. That tells authconfig to only update things it expects to change compared to the previous authconfig configuration, so if you run the same authconfig command with `--update` multiple times, it won't change anything. You can pass `--updateall` to force it to rewrite everything.
authconfig-7.0.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-eab00916f2
+1 blocker here. There's probibly several critera that could work: * Client systems must be able to authenticate users with Kerberos * A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. etc...
I think the most relevant is "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain." The "Kerberos" thing is part of the FreeIPA server end requirements, and the *server* actually is set up such as to allow this, the error is on the *client* end. A 'normal' install doesn't hit this, because while authconfig is run during install, unless you join the system to a domain via kickstart or in some other way cause non-'standard' authconfig args to be set, the authconfig run decides not to edit nsswitch.conf. So the most clear case here is the criterion cited, I think. The system clearly does not "respect the identity, authentication and access control configuration provided by the domain" when nsswitch.conf is messed up like this.
+1 to blocker here as well
That's +3 (me, Kevin, Dennis), setting accepted.
authconfig-7.0.0-2.fc26 has been pushed to the Fedora 26 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-2017-eab00916f2
+1 blocker
authconfig-7.0.0-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.