I am wondering if sssd can be configured to pull user accounts from 1 AD domain (trusted) and correlate those user accounts to groups stored in the trusting AD domain? The "trusting" AD domain will have groups whose members are identified via user objectSids in the format of CN=ForeignSecurityPrincipals,DC=trusting,DC=com ; e.g.:
dn: CN=group,OU=groups,DC=trusting,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
The user accounts which are members of dn: CN=group,OU=groups,DC=trusting,DC=com would be located in the "trusted" domain. e.g.
dn: cn=user1,ou=accounts,dc=trusted,dc=com samaccountname=user1 cn=user1 objectsid=S-1-5-21-1234567890-1234567890-1234567890-1234567
dn: cn=user2,ou=accounts,dc=trusted,dc=com samaccountname=user2 cn=user2 objectsid=S-1-5-21-1234567890-1234567890-1234567890-1234568
The sssd client will be joined to the trusting domain, and configured with 2 "bind" accounts. The join host /etc/krb5.keytab will allow reading of objects in "trusting" domain such as the group information, and a second "bind" account perhaps in the form of a shared keytab and principal will allow reading the user objects in the "trusted" domain. I can configure sssd.conf to use 2 separate "bind" accounts, but what I am unsure of is whether sssd will recognize that user1@TRUSTED is a member of group@TRUSTING via the CN=ForeignSecurityPrincipals mapping shown in the AD group object above. At this point my sssd.conf configuration allows me to: % getent passwd <user_from_trusted) and % getent group <group_from_trusting>
but when i run something like "id/groups <user_from_trusted>" the groups defined in trusting are not shown.
Can I expect sssd to support this type of AD to AD 1 way trust, where groups defined in the trusting domain have members identified via objectSid?
Thank you for your time and assistance, Bob
To add a little more detail, I'm trying to determine if sssd can support a Microsoft AD to AD "Cross Forest One Way Selective Auth Trust". User accounts reside in the "trusted" forest, and are represented in the "trusting" forest via MS foreignSecurityPrincipals [1]. A foreignSecurityPrincipal has a DN composed of the objectSid of the account it maps to in the trusted forest. An example might look like:
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 user1@TRUSTED <objectSid>.
In order for sssd to understand that user1@TRUSTED is a member of group@TRUSTING, sssd would need to maintain a map of user1's objectSID to the foreignSecurityPrincipal located in trusting forest. I suspect this is not currently possible for sssd given the comment by Sumit Bose for sssd github issue #7280 "Multi domain configuration - can't get all gids for all groups where the user is member of" where Sumit states:
"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)..." - Unfortunately for me I'm dealing with 2 forests.
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 describe which is an AD ""Cross Forest One Way Selective Auth trust"
Thank you for your time and for developing this authentication client.
Sincerely, Bob
[1]: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adsc/65f7d0...
sssd-users@lists.fedorahosted.org
-
Robert Green