Starting SSSD without root
by Tero Saarni
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
1 week, 6 days
Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell
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.
9 months
How to do an ‘adcli join’ (or re-join) without creating an msDS-supportedEncryptionTypes LDAP attribute in the machine account?
by Spike White
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)
12 months