Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot log into Domain Account after most recent update #2086

Open
ccrpc-fjunge opened this issue Dec 31, 2024 · 6 comments
Open

Cannot log into Domain Account after most recent update #2086

ccrpc-fjunge opened this issue Dec 31, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@ccrpc-fjunge
Copy link

Describe the bug

After updating to the latest version (latest-41.20241231 (2024-12-31T05:07:04Z)) the domain account I used had disappeared. Clicking in "not listed" and entering the username and password there failed with "incorrect password".

I logged into a local account and ran rpm-ostree rollback. This reverted me to version latest-41.20241227 (2024-12-27T05:09:22Z). Here the domain account was still not listed in the list of available accounts, but clicking "not listed" and entering the username and password there worked. Logging out after logging in, the domain account is once again visible.

What did you expect to happen?

The update to not break the ability to log in with domain accounts.

Output of bootc status

This is the bootc on the working version:


apiVersion: org.containers.bootc/v1
kind: BootcHost
metadata:
  name: host
spec:
  image: null
  bootOrder: default
status:
  staged:
    image: null
    cachedUpdate: null
    incompatible: true
    pinned: false
    store: null
    ostree:
      checksum: 52f361300042b0daf871230ae0bb5d921e6942f239e0afcc8f74bc93b91da3dc
      deploySerial: 0
  booted:
    image: null
    cachedUpdate: null
    incompatible: true
    pinned: false
    store: null
    ostree:
      checksum: 7fa3a2016567dae99696cdf2ffab258df3f3d335d110b60ed7a12dc52e9f57e6
      deploySerial: 0
  rollback:
    image: null
    cachedUpdate: null
    incompatible: true
    pinned: false
    store: null
    ostree:
      checksum: 5316d0c2b8eeff806f87fadad1a701b08ff57f0f12e413bfb5bd2a53c9e620b3
      deploySerial: 0
  rollbackQueued: false
  type: null


This is the bootc of the version where I cannot log in:

apiVersion: org.containers.bootc/v1
kind: BootcHost
metadata:
  name: host
spec:
  image: null
  bootOrder: default
status:
  staged: null
  booted:
    image: null
    cachedUpdate: null
    incompatible: true
    pinned: false
    store: null
    ostree:
      checksum: 52f361300042b0daf871230ae0bb5d921e6942f239e0afcc8f74bc93b91da3dc
      deploySerial: 0
  rollback:
    image: null
    cachedUpdate: null
    incompatible: true
    pinned: false
    store: null
    ostree:
      checksum: 7fa3a2016567dae99696cdf2ffab258df3f3d335d110b60ed7a12dc52e9f57e6
      deploySerial: 0
  rollbackQueued: false
  type: null

Output of groups

This is the groups on version I am able to log in on:

domain [email protected] wheel docker [email protected] power [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] fldr_asdctdc1_d__zoning_rpc planning transfer [email protected] all users - [email protected] rpc - duo [email protected] [email protected] pwdeploy- [email protected] [email protected]


This is the groups of the version I am unable to log in on

root


Is it possible for the update to have reset the groups, or was this due to me being on a local account?

Extra information or context

This is the output of rpm-ostree status on the version I am able to log in on:

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest
                   Digest: sha256:d119ca7b6f8a05fd1cf645ef76c962abb83bbb601419ba68e445b7f3af46a881
                  Version: latest-41.20241227 (2024-12-27T05:09:22Z)
            LocalPackages: NetExtender-10.2.850-1.x86_64

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest
                   Digest: sha256:a2bf31c2fb3b94b8b2267d89aa8eaabe94e01187e5fe814e7eb2ab87f38ce729
                  Version: latest-41.20241231 (2024-12-31T05:07:04Z)
            LocalPackages: NetExtender-10.2.850-1.x86_64

@dosubot dosubot bot added the bug Something isn't working label Dec 31, 2024
@ccrpc-fjunge ccrpc-fjunge changed the title Cannog log into Domain Account Cannot log into Domain Account after most recent update Dec 31, 2024
@ccrpc-fjunge
Copy link
Author

ccrpc-fjunge commented Jan 3, 2025

Update:
There seems to be a permission problem with the sssd configuration in the version post latest-41.20241227.

Running the command sudo journalctl -u sssd shows that on the new versions:

-- Boot af468af2f994461ea2d04cee3df7d9bc --
Jan 03 08:59:21 bluefin systemd[1]: Starting sssd.service - System Security Services Daemon...
Jan 03 08:59:21 bluefin sssd[1676]: [sssd] [sss_ini_open] (0x0100): sss_ini_config_file_open() failed [13]: Permission denied
Jan 03 08:59:21 bluefin sssd[1676]: [sssd] [sss_ini_read_sssd_conf] (0x0020): sss_ini_open() on '/etc/sssd/sssd.conf' failed [13]: Permission denied
Jan 03 08:59:21 bluefin sssd[1676]: Can't read config: 'Failed to open main config file'
Jan 03 08:59:21 bluefin sssd[1676]: Failed to read configuration: 'Failed to open main config file'
Jan 03 08:59:21 bluefin sssd[1676]: Make sure configuration is readable by the user used to run service and doesn't have public rwx bits set.
Jan 03 08:59:21 bluefin systemd[1]: sssd.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
Jan 03 08:59:21 bluefin systemd[1]: sssd.service: Failed with result 'exit-code'.
Jan 03 08:59:21 bluefin systemd[1]: Failed to start sssd.service - System Security Services Daemon.

While on latest-41.20241227 it is

-- Boot 1b3d3612336e4746a0062c69ea0afe46 --
Jan 03 09:23:12 bluefin systemd[1]: Starting sssd.service - System Security Services Daemon...
Jan 03 09:23:13 bluefin sssd[1635]: Starting up
Jan 03 09:23:13 bluefin sssd_be[1691]: Starting up
Jan 03 09:23:13 bluefin sssd_pac[1702]: Starting up
Jan 03 09:23:13 bluefin sssd_nss[1700]: Starting up
Jan 03 09:23:13 bluefin sssd_pam[1701]: Starting up
Jan 03 09:23:13 bluefin systemd[1]: Started sssd.service - System Security Services Daemon.
Jan 03 09:23:14 bluefin sssd_be[1691]: Backend is offline
Jan 03 09:23:16 bluefin sssd_be[1691]: Backend is online

I will continue to investigate.

@m2Giles
Copy link
Member

m2Giles commented Jan 3, 2025

Can you stat the file to see if there is any obvious differences

@ccrpc-fjunge
Copy link
Author

So the /etc/sssd/sssd.conf file has not changed, but the /usr/lib/systemd/system/sssd.service file has. It now has the sssd files own by root rather than sssd, which unfortunately seems to fail.

Old /usr/lib/systemd/system/sssd.service file:

[Unit]
Description=System Security Services Daemon
# SSSD must be running before we permit user sessions
Before=systemd-user-sessions.service nss-user-lookup.target
Wants=nss-user-lookup.target
StartLimitIntervalSec=50s
StartLimitBurst=5
ConditionPathExists=|/etc/sssd/sssd.conf
ConditionDirectoryNotEmpty=|/etc/sssd/conf.d/

[Service]
Environment=DEBUG_LOGGER=--logger=files
EnvironmentFile=-/etc/sysconfig/sssd
ExecStartPre=+-/bin/chown -f sssd:sssd /etc/sssd
ExecStartPre=+-/bin/chown -f sssd:sssd /etc/sssd/sssd.conf
ExecStartPre=+-/bin/chown -f -R sssd:sssd /etc/sssd/conf.d
ExecStartPre=+-/bin/chown -f -R sssd:sssd /etc/sssd/pki
ExecStartPre=+-/bin/sh -c "/bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb"
ExecStartPre=+-/bin/sh -c "/bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/*"
ExecStartPre=+-/bin/sh -c "/bin/chown -f sssd:sssd /var/log/sssd/*.log"
ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER}
Type=notify
NotifyAccess=main
Restart=on-abnormal
CapabilityBoundingSet= CAP_CHOWN CAP_DAC_OVERRIDE CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH 
SecureBits=noroot noroot-locked
User=sssd
Group=sssd
# If service configured to be run under "root", uncomment "SupplementaryGroups"
#SupplementaryGroups=sssd

[Install]
WantedBy=multi-user.target

New /usr/lib/systemd/system/sssd.service file:

[Unit]
Description=System Security Services Daemon
# SSSD must be running before we permit user sessions
Before=systemd-user-sessions.service nss-user-lookup.target
Wants=nss-user-lookup.target
StartLimitIntervalSec=50s
StartLimitBurst=5
ConditionPathExists=|/etc/sssd/sssd.conf
ConditionDirectoryNotEmpty=|/etc/sssd/conf.d/

[Service]
Environment=DEBUG_LOGGER=--logger=files
EnvironmentFile=-/etc/sysconfig/sssd
ExecStartPre=+-/bin/chown -f -R root:sssd /etc/sssd
ExecStartPre=+-/bin/chmod -f -R g+r /etc/sssd
ExecStartPre=+-/bin/sh -c "/bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb"
ExecStartPre=+-/bin/chown -f -R sssd:sssd /var/lib/sss/gpo_cache
ExecStartPre=+-/bin/sh -c "/bin/chown -f sssd:sssd /var/log/sssd/*.log"
ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER}
Type=notify
NotifyAccess=main
Restart=on-abnormal
CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH 
SecureBits=noroot noroot-locked
User=sssd
Group=sssd
# If service configured to be run under "root", uncomment "SupplementaryGroups"
#SupplementaryGroups=sssd

[Install]
WantedBy=multi-user.target

systemctl status sssd.service for old sssd.service file:

sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf, 50-keep-warm.conf
     Active: active (running) since Fri 2025-01-03 10:03:45 CST; 1min 5s ago
Invocation: 6f59d1f3e83f4a318e79c34ffa4d9609
    Process: 1520 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd (code=exited, status=0/SUCCESS)
    Process: 1574 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd/sssd.conf (code=exited, status=0/SUCCESS)
    Process: 1584 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/conf.d (code=exited, status=0/SUCCESS)
    Process: 1588 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/pki (code=exited, status=0/SUCCESS)
    Process: 1591 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS)
    Process: 1593 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=0/SUCCESS)
    Process: 1599 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/log/sssd/*.log (code=exited, status=0/SUCCESS)
   Main PID: 1601 (sssd)
      Tasks: 5 (limit: 42900)
     Memory: 101.5M (peak: 102.1M)
        CPU: 789ms
     CGroup: /system.slice/sssd.service
             ├─1601 /usr/sbin/sssd -i --logger=files
             ├─1667 /usr/libexec/sssd/sssd_be --domain co.champaign.il.us --logger=files
             ├─1688 /usr/libexec/sssd/sssd_nss --logger=files
             ├─1689 /usr/libexec/sssd/sssd_pam --logger=files
             └─1690 /usr/libexec/sssd/sssd_pac --logger=files

Jan 03 10:03:44 bluefin systemd[1]: Starting sssd.service - System Security Services Daemon...
Jan 03 10:03:45 bluefin sssd[1601]: Starting up
Jan 03 10:03:45 bluefin sssd_be[1667]: Starting up
Jan 03 10:03:45 bluefin sssd_nss[1688]: Starting up
Jan 03 10:03:45 bluefin sssd_pac[1690]: Starting up

systemctl status sssd.service for new sssd.service file:

× sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf, 50-keep-warm.conf
     Active: failed (Result: exit-code) since Fri 2025-01-03 09:52:16 CST; 9s ago
Invocation: 592e7fd757164c1bad5e5644ac3e2e1f
    Process: 6932 ExecStartPre=/bin/chown -f -R root:sssd /etc/sssd (code=exited, status=0/SUCCESS)
    Process: 6934 ExecStartPre=/bin/chmod -f -R g+r /etc/sssd (code=exited, status=0/SUCCESS)
    Process: 6936 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS)
    Process: 6938 ExecStartPre=/bin/chown -f -R sssd:sssd /var/lib/sss/gpo_cache (code=exited, status=0/SUCCESS)
    Process: 6941 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/log/sssd/*.log (code=exited, status=0/SUCCESS)
    Process: 6944 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=3)
   Main PID: 6944 (code=exited, status=3)
   Mem peak: 1.5M
        CPU: 28ms

Jan 03 09:52:16 bluefin systemd[1]: Starting sssd.service - System Security Services Daemon...
Jan 03 09:52:16 bluefin sssd[6944]: [sssd] [sss_ini_open] (0x0100): sss_ini_config_file_open() failed [13]: Permission denied
Jan 03 09:52:16 bluefin sssd[6944]: [sssd] [sss_ini_read_sssd_conf] (0x0020): sss_ini_open() on '/etc/sssd/sssd.conf' failed [13]: Permission denied
Jan 03 09:52:16 bluefin sssd[6944]: Can't read config: 'Failed to open main config file'
Jan 03 09:52:16 bluefin sssd[6944]: Failed to read configuration: 'Failed to open main config file'
Jan 03 09:52:16 bluefin sssd[6944]: Make sure configuration is readable by the user used to run service and doesn't have public rwx bits set.
Jan 03 09:52:16 bluefin systemd[1]: sssd.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
Jan 03 09:52:16 bluefin systemd[1]: sssd.service: Failed with result 'exit-code'.
Jan 03 09:52:16 bluefin systemd[1]: Failed to start sssd.service - System Security Services Daemon.

This is interesting as one would think that giving group readability to the /etc/sssd/sssd.conf file would be enough, seeing as the service is running with Group=sssd, but that seems not to be the case.

@ccrpc-fjunge
Copy link
Author

ccrpc-fjunge commented Jan 3, 2025

The /usr/lib/systemd/system/sssd.service file seems to be part of the immutable file system which means I cannot change it to test if that is the only thing causing the domain log in to fail. That said the error

[sssd] [sss_ini_read_sssd_conf] (0x0020): sss_ini_open() on '/etc/sssd/sssd.conf' failed [13]: Permission denied

is certainly sufficient to break the log in on its own.

This is on BluefinDX if that changes anything.

@ccrpc-fjunge
Copy link
Author

ccrpc-fjunge commented Jan 3, 2025

This seems to have been a changed by upgrading to sssd version 2.10.1 from 2.10.0.

The 2.10.0 file has the user as sssd (https://github.com/SSSD/sssd/blob/2.10.0/src/sysv/systemd/sssd.service.in) while the 2.10.1 file has the user as root (https://github.com/SSSD/sssd/blob/2.10.1/src/sysv/systemd/sssd.service.in).

I will open an issue there as well to see if I can get some more sssd specific information.

Edit: Link to issue here - SSSD/sssd#7784

@ccrpc-fjunge
Copy link
Author

Update(s):

The issues with logging in seemed to stem from two different factors:

  1. Version 2.10.1 of sssd forgot to set g+x on some directories, causing a permission error.
  1. The sssd binaries have reduced capabilities as of SSSD/sssd@1614c5e.
    As of sssd 2.10.1, the sssd.service file only gives the service the capabilities it believes are needed for the new binaries (CapabilityBoundingSet=).
    Due to a bug in ostree-rs-ext (extended attributes discarded for layered changes ostreedev/ostree-rs-ext#654) the binaries still say they require the original capabilities (getcap /usr/libexec/sssd/* outputs the old set).
  • A workaround to this is is to use sudo systemctl edit sssd to add the following overide:
[Service]
CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH CAP_CHOWN CAP_DAC_OVERRIDE

So, as of right now, to get sssd 2.10.1 working on bluefin:

  1. Run sudo /bin/find /etc/sssd -type d -exec /bin/chmod g+x {} \;
  2. Use sudo systemctl edit sssd to add the capabilities back in.

Once sssd pushes SSSD/sssd#7783 one will no longer need to use sudo /bin/find /etc/sssd -type d -exec /bin/chmod g+x {} \;.

Once ostree 2024.10 (https://bodhi.fedoraproject.org/updates/FEDORA-2024-a84f4cae66) passes testing and is incorporated into bluefin one will no longer need to use sudo systemctl edit sssd (and will probably want to remove the override if you have created it).


For more information see also: https://universal-blue.discourse.group/t/bluefin-enterprise-woes/6157/7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants