sssd-users March 2023

sssd-users@lists.fedorahosted.org

15 participants
11 discussions

SSSD.Service not starting
by Manjot Singh 12 Feb '25

12 Feb '25

● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-01-29 14:12:32 EST; 9s ago Process: 23217 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4) Main PID: 23217 (code=exited, status=4) Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Service RestartSec=100ms expired, scheduling restart. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Scheduled restart job, restart counter is at 5. Jan 29 14:12:32 pop-os systemd[1]: Stopped System Security Services Daemon. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Start request repeated too quickly. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Failed with result 'exit-code'. Jan 29 14:12:32 pop-os systemd[1]: Failed to start System Security Services Daemon.

4 3

Starting SSSD without root
by Tero Saarni 09 Apr '24

09 Apr '24

Hi, I'm trying to run SSSD inside docker container without root user. The container is executed in OpenShift cluster which does not allow running as root inside container. SSSD requires root and checks for this specifically. Is there any workaround for this? I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment. -- Tero

5 20

Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell 22 Jul '23

22 Jul '23

On my dual-stack network where some machines actually don't have IPv4 connectivity I am finding that whatever is writing IP addresses into /var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses and not the KDC's IPv6 addresses. The result is that such an IPv6 machine cannot reach a KDC until I remove that file. It ends up being recreated at some subsequent point again with only the KDC's IPv4 addresses. Is this a bug or a problem with my configuration? Cheers, b.

2 3

not getting cached ticket from PuTTY login
by Pieter Voet 29 Mar '23

29 Mar '23

Hi all, I have the same issue as was already reported here in 2016 : https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… however there was no reply given. Running sssd on RedHat linux 7 using 'ad' as the 'auth_provider' I succesfully get logged in using Putty from a Windows laptop. However, running 'klist' returns : klist: Credentials cache keyring 'persistent:808521:krb_ccache_x2hJGE1' not found I found articles like 'https://ubuntu.com/server/docs/service-sssd-ad' where it said to install 'krb5-user' if you want your AD users to also get a kerberos ticket upon logging in. But that is valid for Ubuntu, and there's no 'krb5-user' package for Redhat. Next I found the RH equivalent should be 'krb5-auth-dialog' , but that's not available for RedHat 7. Can anybody help me on getting a kerberos ticket if logged on by sssd ? Thanks !

5 17

Guidance on setting ideal enctypes?
by Kodiak Firesmith 29 Mar '23

29 Mar '23

Hi Folks, I'm nominally aware that the ability for adcli joins to honor custom enctypes became a thing around 2018, but I'm having a heck of a time finding guidance online for setting permitted enctypes so that keytabs don't create keys for DES and RC4. Our environment uses a mixture of SSSD 2.2.3, and 2.6.3, joining to MS Active Directory, which my Windows admins have said run MS Server 2019 with Active Directory 2016. I've been digging around on search engines and picking through various krb5 docs, and I think SSSD will refer to krb5.conf, and might be reading supported_enctypes or permitted_enctypes, but I'm not sure how to put it all together. Thanks very much! - Kodiak Firesmith Sent with [Proton Mail](https://proton.me/) secure email.

2 1

SSSD and TLS version
by Nicolas Martin 27 Mar '23

27 Mar '23

Hi, I use sssd together with 389 directory server to manage id and credentials. My Directory Server is configured to allow only TLSv1.3 (sslVersionMin == sslVersionMax == 1.3). However, whenever I start a ssh session to a machine using a directory user, I get the following message sequence between the sssd client and the directory server(exchange generated when the password is entered at prompt): client -> DS TLSv1.2 message DS-> client TLSv1.2 message client closes connections (RST) client establishes new connection TLS handshake Change Cipher Spec TLSv1.3 exchange (see detailed exchange below) I don't understand why there is this initial TLSv1.2 exchange. Is there a possibility to enforce TLSv1.3 on sssd side ? I tried to set: ldap_tls_cipher_suite = TLSv1.3!EXPORT:!NULL in /etc/sssd.conf, but the behavior is the same. 23 49.553616751 client → DS *TLSv1.2* 95 Application Data 24 49.553632077 client → DS *TLSv1.2* 90 Application Data 25 49.554509324 DS → client *TLSv1.2* 90 Application Data 26 49.554526401 client → DS TCP 54 44625 → 636 *[RST]* Seq=56 Win=0 Len=0 27 49.554534690 DS → client TCP 66 636 → 44625 *[RST, ACK]* Seq=25 Ack=56 Win=286 Len=0 TSval=1278977543 TSecr=3489465836 28 52.843158542 client → DS TCP 74 44627 → 636 *[SYN]* Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=3489469126 TSecr=0 WS=128 29 52.843547010 DS → Client TCP 74 636 → 44627 *[SYN, ACK]* Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1278980832 TSecr=3489469126 WS=128 30 52.843572758 client → DS TCP 66 44627 → 636 *[ACK]* Seq=1 Ack=1 Win=29312 Len=0 TSval=3489469126 TSecr=1278980832 31 52.84471237 client → DS TLSv1 355 *Client Hello* 32 52.845104921 DS → client TCP 66 636 → 44627 [ACK] Seq=1 Ack=290 Win=30080 Len=0 TSval=1278980833 TSecr=3489469127 33 52.866829425 DS → client TLSv1.3 4029 Server Hello, Change Cipher Spec, Application Data 34 52.866846844 client → DS TCP 66 44627 → 636 [ACK] Seq=290 Ack=3964 Win=37248 Len=0 TSval=3489469150 TSecr=1278980855 35 52.867532757 client → DS TLSv1.3 160 Change Cipher Spec, Application Data, Application Data 36 52.867591615 client → DS TLSv1.3 348 Application Data 37 52.868097985 DS → client TCP 66 636 → 44627 [ACK] Seq=3964 Ack=666 Win=31104 Len=0 TSval=1278980856 TSecr=3489469150 38 52.868929089 DS → client TLSv1.3 1471 Application Data 39 52.868942962 DS → client TLSv1.3 102 Application Data 40 52.869048855 client → DS TCP 66 44627 → 636 [ACK] Seq=666 Ack=5

1 0

authentication failure when one domain controller is down
by Craig Martin 22 Mar '23

22 Mar '23

Hi, I have a problem I have been unable to solve and I'm at a loss. We use sssd on Debian 11 clients with active directory backend. We have 4 domain controllers running Windows Server 2022 in our environment. If any one of those domain controllers goes offline we experience intermittent authentication failures on the linux clients running sssd. It happens on some (but not all) clients and even on an affected client it can be intermittent (meaning sometimes authentication will work, sometimes it will not). I have tried using the ad_server directive in sssd.conf to restrict the domain controllers the client will try to contact but it seems to have no effect. I have upped the verbosity level in the logs but I am bombarded with messages that I struggle to interpret. Is there someone here who can take a look and help me troubleshoot? I can provide any additional logs / config info upon request. Here is some preliminary info: Client OS: Debian 11 SSSD version: 2.4.1 sssd.conf [sssd] services = nss, pam config_file_version = 2 domains = AD.FINRCVGRP.COM [domain/AD.FINRCVGRP.COM] debug_level=6 ad_server = frgdc2.ad.finrcvgrp.com,frgdc3.ad.finrcvgrp.com id_provider = ad cache_credentials = true access_provider = ad #access_provider = simple #simple_allow_groups = sasdev, dbdev # Use this if users are being logged in at /. # This example specifies /home/DOMAIN-FQDN/user as $HOME. Use with pam_mkhomedir.so override_homedir = /home/%u override_shell = /bin/bash # Uncomment if the client machine hostname doesn't match the computer object on the DC. # ad_hostnamemymachine.myubuntu.example.com # Uncomment if DNS SRV resolution is not working # ad_server = dc.mydomain.example.com # Uncomment if the AD domain is named differently than the Samba domain # ad_domain = MYUBUNTU.EXAMPLE.COM # Enumeration is discouraged for performance reasons. # enumerate = true

2 5

sss allows extraneous @ characters prefixed to username?
by Paul B. Henson 21 Mar '23

21 Mar '23

We are running the latest RHEL 8.7 which includes sss version 2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore leading @ characters when looking up a username. For example: # getent passwd '@cpp.a' cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how many @ signs there are: # getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a' cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash This is a local account on the system, with the default sssd configuration, there is nothing explicitly set: # find /etc/sssd /etc/sssd /etc/sssd/conf.d /etc/sssd/pki If I update nsswitch.conf to remove sss from the passwd line this behavior goes away. The same behavior occurs on other systems that are integrated with our LDAP and kerberos systems. When logging in, not only is this invalid username successfully authenticated, it is passed to other pam modules: Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for '@@@@@@@henson' from 10.104.223.249: Allowing unknown user This is allowing a bypass of our security policies, in this case, a user who should have been forced to do MFA was able to login without it because the name passed to the other modules by the login stack was not the real username which ended up being logged in. Is this a bug? A configuration issue? I opened a support ticket with Red Hat but as have not as yet received a resolution. I wouldn't think this would be intended behavior out-of-the-box. Thanks…

4 12

SSSD 2.8 supported/working OS
by Roman Annenko 16 Mar '23

16 Mar '23

Hi, I couldn't find any information about which OSes can run sssd 2.x package. The only mention about "platform" I found in sssd-2.0.0 release notes: "Starting with SSSD 2.0, upstream no longer supports RHEL-6 and its derivatives". I have Oracle Linux 7 so I think this note implies that at least RHEL7 (and OL7) would be supported platform for sssd2.x But OL7 repository has only sssd-1.16.5 package included. So I tried to build sssd2.8 on my own from sources directly on OL7 machine, but compilation fails (after resolving all dependencies) because of missing struct members in declarations in krb5/clpreauth_plugin.h. Those declarations come from "krb5-devel" package on OL7 repo and appear to be incompatible with sssd2.x sources. Does this mean that sssd2 is incompatible with OL7 and there is no way to make it work on this platform?

3 6

SSSD conf - ldap_default_authtok and ldap_backup_uri
by Hristina Marosevic 13 Mar '23

13 Mar '23

Hello, Since I can not find relevant information on web about this I would like to ask you about my current issue. Im my SSSD configuration I have two LDAP URIs, one defines as value of ldap_uri and other defined as value of ldap_backup_uri. These LDAP instances have different password and same LDAP admin DN. LDAP password for binding to the first LDAP instance is defined as value of the SSSD conf attribute: ldap_default_authtok but I can not find attribute that will store LDAP password for the second LDAP instance. Are there options for defining LDAP bind password to connect to LDAP server defined as value of ldap_backup_uri in the SSSD configuration or I must change the password of the second instance to match the one defined and used on the first LDAP instance? Thank you in advance! BR, Hristina

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users March 2023