Hi, I have recently setup a test freeipa server, and sssd on a client machine. Everything works as expected, but if the freeipa server is offline, I cannot get past the lock screen. I can not even type the password in. To get past this I have to click login as a different user, and than relogin with the original user.
I noticed these in the logs while trying to unlock in /var/log/messages: gdm: AccountsService: ActUserManager: user (null) has no username (object path: /org/freedesktop/Accounts/User0, uid: 0) in /var/log/secure: gkr-pam: no password is available for user
By editing /etc/pam.d/gdm-password I can get around this.
I edited the line: session required pam_namespace.so ignore_config_error to have the ignore_config_error parameter added to pam_namespace.so
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth substack password-auth auth optional pam_gnome_keyring.so auth include postlogin
account required pam_nologin.so account include password-auth
password substack password-auth -password optional pam_gnome_keyring.so use_authtok
session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so -session optional pam_ck_connector.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so ignore_config_error session include password-auth session optional pam_gnome_keyring.so auto_start session include postlogin
Is this an expected or normal behaviour? Is there any other way to get around this issue other than ignoring the error message? ~
On 06/15/2017 01:56 PM, falbee@cassens.com wrote:
Hi, I have recently setup a test freeipa server, and sssd on a client machine. Everything works as expected, but if the freeipa server is offline, I cannot get past the lock screen. I can not even type the password in. To get past this I have to click login as a different user, and than relogin with the original user.
I noticed these in the logs while trying to unlock in /var/log/messages: gdm: AccountsService: ActUserManager: user (null) has no username (object path: /org/freedesktop/Accounts/User0, uid: 0)
This looks like a bug in GDM. It's got a NULL value for the username and it's assuming UID 0 (which would be root). SSSD explicitly ignores requests for the root user (so that the system never gets completely locked out if SSSD was to fail).
What OS are you running? What version of GDM, accountsservice and SSSD?
in /var/log/secure: gkr-pam: no password is available for user
By editing /etc/pam.d/gdm-password I can get around this.
I edited the line: session required pam_namespace.so ignore_config_error to have the ignore_config_error parameter added to pam_namespace.so
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth substack password-auth auth optional pam_gnome_keyring.so auth include postlogin
account required pam_nologin.so account include password-auth
password substack password-auth -password optional pam_gnome_keyring.so use_authtok
session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so -session optional pam_ck_connector.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so ignore_config_error session include password-auth session optional pam_gnome_keyring.so auto_start session include postlogin
Is this an expected or normal behaviour? Is there any other way to get around this issue other than ignoring the error message? ~
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Running CentOS 7.3: gdm-3.14.2-20.el7_3.x86_64 accountsservice-0.6.35-14.el7_3.x86_64 sssd-1.14.0-43.el7_3.14.x86_64
sssd-users@lists.fedorahosted.org
-
Eric F -
falbee＠cassens.com -
Stephen Gallagher