Open sssd-bot opened 4 years ago
@jhrozek @thalman Is there anyway to provide an update on the RFE here? I dont believe redhat bug ID #1529445 is viewable to the public
@jhrozek @thalman Is there anyway to provide an update on the RFE here? I dont believe redhat bug ID #1529445 is viewable to the public
Mentioned RHBZ was closed as WONTFIX due to capacity reasons.
Patches are welcome upstream.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3612
This is a sanitized version of a useful comment Sumit Bose wrote in the downstream bugzilla.
In contrast to Windows clients a RHEL/Linux client with SSSD cannot ask a DC of the joined domain for the information about users from trusted domains but has to connect to the DCs of the trusted domain to get this information. One reason is that the Windows specific protocols used by Windows clients to get this data from the local DCs are not supported by SSSD. Another reason is that SSSD might need additional information about the user or group, e.g. POSIX attributes, which cannot be retrieved from the local DC.
Since AD does not allow anonymous LDAP binds SSSD uses the machine account and the host keys stored in /etc/krb5.keytab to get a Kerberos ticket and then do a authenticated SASL bind to the LDAP (or Global Catalog) port of the domain controller. If the RHEL client is joined to FOO the Kerberos TGT will be issued for HOSTNAME$@FOO. To access a service from a trusted domain BAR a cross realm ticket is needed, in this case krbtgt/BAR@FOO But due to the one-way trust this principal does not exist because BAR does not trust principals from FOO, only the other way round.
If it is possible to have a generic account in BAR which can be used to lookup the user and group information you can setup a second domain (not a trusted domain) in sssd.conf for BAR with ldap_default_bind_dn and ldap_default_authtok (it would be possible to use Kerberos as well). Unfortunately those options are currently not available for the trusted domain configuration domain/foo/bar which will cause some restrictions to cross-domain group memberships.
This RFE is about enabling cases like this by providing a way for the trusted domains to authenticate.
Comments
Comment from jhrozek at 2018-01-11 10:35:57
Metadata Update from @jhrozek:
Comment from jhrozek at 2018-01-17 17:36:29
Metadata Update from @jhrozek:
Comment from thalman at 2020-03-11 14:13:09
Metadata Update from @thalman: