sssd-users April 2023

sssd-users@lists.fedorahosted.org

1 participants
3 discussions

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

How to do an ‘adcli join’ (or re-join) without creating an msDS-supportedEncryptionTypes LDAP attribute in the machine account?
by Spike White 28 Apr '23

28 Apr '23

Sssd experts, Our AD team is in the process of eradicating deprecated arcfour-hmac encryption type from AD. (It’s a long road). Our strong preference on the machine accounts is to not even have an msDS-supportedEncryptionTypes LDAP attribute associated with it. In that way, the machine account takes on the AD domain’s default. Windows servers do this when they AD join. Their machine accounts don’t have an explicit msDS-supportedEncryptionTypes LDAP attribute. Only our Linux machine accounts have an explicit msDS-supportedEncryptionTypes LDAP attribute. (Our Linux machines AD integrate via sssd, using adcli join to join the domain). Right now, the AD domain default is aes256/aes128/rc4, but when all rc4 traffic is eradicated they’ll change the domain default to aes256/aes128 only. We would prefer to not have to circle around and clean up all the explicit msDS-supportedEncryptionTypes LDAP attributes associated with all the Linux machine accounts. To that end, weeks ago one of the AD engineers removed all msDS-supportedEncryptionTypes LDAP attributes from all our Linux machine accounts. But just today, we noticed that some have come back. And we can’t even figure out a pattern. Some have aes256/aes128/rc4 and some have aes256/aes128 only. It appears that new builds are setting an explicit msDS-supportedEncryptionTypes LDAP attribute. If we re-join (via adcli join), is it then setting an explicit msDS-supportedEncryptionTypes LDAP attribute? (When sssd drops off the domain, our Linux support engineers often just re-join the server to the domain via a script that does ‘adcli join’.) I looked at the adcli man page. It has flags for setting random LDAP attributes, but doesn’t take explicitly about msDS-supportedEncryptionTypes LDAP attribute. Seeking enlightenment, Spike White (Happy sssd customer)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users April 2023