Debugging SSSD Access in Fedora 34
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.