On Fri, Aug 23, 2024 at 11:55 AM Bob Green <wood.green.rob...@gmail.com> wrote: > > A version of this question has been asked on the users mailing list, > thought I'd ask here as well. > > Can sssd support a Microsoft AD to AD "Cross Forest One Way Selective > Auth Trust"? I suspect no, considering the response by Sumit Bose to > github issue #7280 "Multi domain configuration - can't get all gids > for all groups where the user is member of": > > "you currently cannot mix group-memberships from different domains > configured in sssd.conf by design. But as long as those two domains > belong to the same forest i.e. the two domains (not forests)..." - > Sumit. > > Unfortunately for me I'm dealing with 2 forests. User accounts reside > in TRUSTED.corp.com, computer objects groups, service accounts reside > in TRUSTING.corp.com. The TRUSTED.corp.com user accounts have > foreignSecurityPrincipals in TRUSTING.corp.com which resemble: > > dn: > CN=S-1-5-21-1234567890-1234567890-1234567890-1234567,CN=ForeignSecurityPrincipals,dc=trusting,dc=corp,dc=com > objectClass: top > objectClass: foreignSecurityPrincipal > cn: S-1-5-21-1234567890-1234567890-1234567890-1234567 > objectSid:: S-1-5-21-0987654321-0987654321-0987654321-0000011 > > where cn: <objectSid> would map to a user account in TRUSTED via it's > <objectSid>. > > groups in TRUSTED.corp.com have members DNs of > cn=<objectSid>,cn=ForeignSecurityPrincipals,dc=trusting,dc=corp,dc=com, > such as:
Re-reading my post I realized that the above should read "groups in TRUSTING.corp.com have member DNs of cn=<objectSid>,cn=ForeignSecurityPrincipals,dc=trusting,dc=corp,dc=com, ,,, > dn: CN=group1,ou=groups,dc=trusting,dc=corp,dc=com > member: > CN=S-1-5-21-1234567890-1234567890-1234567890-1234567,CN=ForeignSecurityPrincipals,DC=trusting,DC=com > member: > CN=S-1-5-21-1234567890-1234567890-1234567890-1234568,CN=ForeignSecurityPrincipals,DC=trusting,DC=com > > In order for sssd to understand that us...@trusted.corp.com is a > member of gro...@trusting.corp.com, sssd would need to maintain a map > of user1's objectSID to the foreignSecurityPrincipal located in the > trusting forest. > > I'm hoping someone on this list might be able to confirm that sssd is > not currently an authentication client solution for the current > backend architecture I've described here, or better yet tell me, yes > this architecture is supported by sssd. > > Thank you for your development of sssd, > > Bob -- _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
