Debugging SSSD Access in Fedora 34

May 13, 2021 - 4 minutes read - 656 words

A big part of my crazy plan to have SSO for every computer in my house is making sure that my wife’s account works everywhere including my Surface laptop. It is running Fedora 34 and is connected to my home FreeIPA cluster using the Fedora “Enerprise Login”. For me, it works great, but when I tried to login with the wife’s account I got a permission denied. Assuming I had gotten the password wrong I hopped into FreeIPA and reset it before making sure I could get into the FreeIPA web UI with her credentials.

The first thing I checked was FreeIPA’s Host Based Access Controls because I’ve been bitten by those before.

> ipa hbactest --user=user --host=host.example.com --service=gdm
--------------------
Access granted: True
--------------------
  Matched rules: allow_desktop
  Not matched rules: allow_admins_all

Unfortunately, everything seemed happy and she had permission to login through GDM. Next thing was to check SSSD and make sure it was reporting the correct info. I started by expiring the SSSD cache so it would pull the new password I had just set.

> sudo sssctl cache-expire -E

Running id to check that it was pulling the right user and group info also returned the correct thing.

> id user
uid=100001(user) gid=100001(user) groups=100001(user),100010(desktop-users)

Since everything looked correct there I tried logging in again while tailing journalctl in another window getting the error message shown below.

> sudo journalctl -f
May 13 07:56:50 host.example.com gdm-password][27965]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=user
May 13 07:56:50 host.example.com audit[27965]: USER_AUTH pid=27965 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_usertype,pam_usertype,pam_sss,pam_gnome_keyring acct="user" exe="/usr/libexec/gdm-session-worker" hostname=host.example.com addr=? terminal=/dev/tty1 res=success'
May 13 07:56:50 host.example.com gdm-password][27965]: gkr-pam: unable to locate daemon control file
May 13 07:56:50 host.example.com gdm-password][27965]: gkr-pam: stashed password to try later in open session
May 13 07:56:50 host.example.com gdm-password][27965]: pam_sss(gdm-password:account): Access denied for user user: 6 (Permission denied)

That combination of error messages where authentication was successful and there still was a “Permission Denied” lead me to check that SSSD was interacting with the user account correctly.

> sudo sssctl user-checks user
user: user
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: user
 - user id: 100001
 - group id: 100001
 - gecos: Example User
 - home directory: /home/user
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: user
 - uidNumber: 100001
 - gidNumber: 100001
 - gecos: Example User
 - homeDirectory: /home/user
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Permission denied

PAM Environment:
 - no env -

Looking at that error lead me to this link which describes configuring SSSD on RHEL hosts. From there I went into /etc/sssd/sssd.conf and noticed the following line listing the user that I originally set the laptop up with.

[domain/example.com]
simple_allow_users = $, oldUser

According to the previous link this limits access to the machine to just oldUser regardless of what FreeIPA or HBAC says about the subject. I believe that the rules specified here are applied after FreeIPA’s rules are run and either approve or deny the attempt. The short term solution ended up being very simple, just add my wife’s user account to the list of allowed users and reboot sssd.

[domain/example.com]
simple_allow_users = $, oldUser, user

Now when I ran the same test as before I got a better response checking the account.

sudo sssctl user-checks user
user: user
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: user
 - user id: 100001
 - group id: 100001
 - gecos: Example User
 - home directory: /home/user
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: user
 - uidNumber: 100001
 - gidNumber: 100001
 - gecos: Example User
 - homeDirectory: /home/user
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -

With that I tried logging in again via GDM and it loaded up fine! Next step is figuring out how to get FreeIPA to be the authoritative source for this kind of data, but that’s a fight for another day.