Description of problem: A joined machine supposed to be persistently joined to idm after restart too. This is the case when join is done via command line realm, but whe joining via the gnome-control-center after restart the machine seems to be still joined, but users cannot log in. Version-Release number of selected component (if applicable): realmd-0.13.3-2.fc19 control-center-3.8.0-3.fc19 How reproducible: always Steps to Reproduce: 1. start gnome-control-center > Users and add an enterprise user 2. log in via that user 3. log out and restart 4. after restart: [test@client ~]$ id aaa uid=856200004(aaa) gid=856200004(aaa) groups=856200004(aaa) [test@client ~]$ [test@client ~]$ su - aaa su: user aaa does not exist [test@client ~]$ id aaa [test@client ~]$ realm -v list skynet.com type: kerberos realm-name: SKYNET.COM domain-name: skynet.com configured: kerberos-member server-software: freeipa client-software: sssd required-package: freeipa-client required-package: sssd-tools required-package: sssd login-formats: %U login-policy: allow-realm-logins and after a while (a few minutes): [test@client ~]$ id aaa id: aaa: no such user but still: [test@client ~]$ realm -v list skynet.com type: kerberos realm-name: SKYNET.COM domain-name: skynet.com configured: kerberos-member server-software: freeipa client-software: sssd required-package: freeipa-client required-package: sssd-tools required-package: sssd login-formats: %U login-policy: allow-realm-logins Actual results: Expected results: Additional info:
Can you log in pre-reboot?
(In reply to comment #1) > Can you log in pre-reboot? yes, indeed
I see this bug again with AD too.
This is an sssd bug. realmd isn't involved in logging the user in (with the exception of gdm using it to look up a login hint to display). Ideally we could troubleshoot this with Jakub.
Ok, that would be nice because I see this also if join via cmd line gdm. I'll ask jhrozek to check it. [root@pkisf19 ~]# realm -v join --user Bender-admin ad.baseos.qe * Resolving: _ldap._tcp.dc._msdcs.ad.baseos.qe * Sending MS-CLDAP ping to: 10.34.25.20 * Successfully discovered: ad.baseos.qe Password for Bender-admin: * Required files: /usr/sbin/sss_cache, /usr/sbin/sssd, /usr/bin/net * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.NVTHWW -U Bender-admin ads join ad.baseos.qe Enter Bender-admin's password: DNS update failed: NT_STATUS_INVALID_PARAMETER Using short domain name -- AD Joined 'PKISF19' to dns domain 'ad.baseos.qe' No DNS domain configured for pkisf19. Unable to perform DNS Update. * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.NVTHWW -U Bender-admin ads keytab create Enter Bender-admin's password: * /usr/bin/systemctl enable sssd.service ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service' * /usr/bin/systemctl restart sssd.service * /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart * Successfully enrolled machine in realm [root@pkisf19 ~]# id 'AD\Bender' uid=1197601112(AD\bender) gid=1197600513(AD\domain users) groups=1197600513(AD\domain users),1197601109(AD\planet express),1197601110(AD\test users) [root@pkisf19 ~]# [root@pkisf19 ~]# reboot Connection to 192.168.100.19 closed by remote host. Connection to 192.168.100.19 closed. ... $ ssh root.100.19 Last failed login: Sat May 11 15:13:34 CEST 2013 from 192.168.100.41 on ssh:notty There was 1 failed login attempt since the last successful login. Last login: Thu May 9 17:52:00 2013 from 192.168.100.1 [root@pkisf19 ~]# [root@pkisf19 ~]# [root@pkisf19 ~]# realm list ad.baseos.qe type: kerberos realm-name: AD.BASEOS.QE domain-name: ad.baseos.qe configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: adcli required-package: samba-common login-formats: AD\%U login-policy: allow-realm-logins [root@pkisf19 ~]# [root@pkisf19 ~]# id 'AD\Bender' id: AD\Bender: no such user [root@pkisf19 ~]# [root@pkisf19 ~]# [root@pkisf19 ~]# cat /etc/sssd/sssd.conf [sssd] domains = AD config_file_version = 2 services = nss, pam [nss] default_shell = /bin/bash [domain/AD] ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad full_name_format = %2$s\%1$s krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad [root@pkisf19 ~]# [root@pkisf19 ~]# [root@pkisf19 ~]# rpm -q realmd realmd-0.14.0-1.fc19.x86_64 [root@pkisf19 ~]# rpm -q sssd sssd-1.10.0-4.fc19.beta1.x86_64 [root@pkisf19 ~]#
workaround: systemctl restart sssd
It is a realmd bug; realmd does not enable sssd service while joining. [root@pkisf19 ~]# systemctl list-unit-files |grep sssd sssd.service disabled
(In reply to comment #5) > * /usr/bin/systemctl enable sssd.service > ln -s '/usr/lib/systemd/system/sssd.service' Very strange, you can see it being enabled here in your output.
(In reply to comment #8) > (In reply to comment #5) > > * /usr/bin/systemctl enable sssd.service > > ln -s '/usr/lib/systemd/system/sssd.service' > > Very strange, you can see it being enabled here in your output. Manually running [root@pkisf19 ~]# /usr/bin/systemctl enable sssd.service ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service' enables it, but when realmd runs it it does not create the symlink. Then, after realm leave the service is disabled again, so systemctl disable is working from realmd but not enable. The same in permissive mode.
Interesting. This is an authconfig bug. What I really want is a way to just tell authconfig to modify the PAM stack and nsswitch.conf file (which it owns) and not do anything, absolutely anything, else. You can see here that running authconfig with --nostart disables sssd, despite what the manual says: If --nostart is specified (which is what the install program does), ypbind or other daemons will not be started or stopped immediately fol‐ lowing program execution, but only enabled to start or stop at boot time. [stef@stef realmd]$ systemctl status sssd sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) ... snip ... [stef@stef realmd]$ sudo /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart [stef@stef realmd]$ systemctl status sssd sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled) ... snip ...
Added work-around to realmd: http://cgit.freedesktop.org/realmd/realmd/commit/?id=2f2049c4fc54356c130a348618cd547c9d5aa240
authconfig-6.2.6-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/authconfig-6.2.6-3.fc19
Confirming that this fixes the problem.
Package authconfig-6.2.6-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing authconfig-6.2.6-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8115/authconfig-6.2.6-3.fc19 then log in and leave karma (feedback).
authconfig-6.2.6-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.