We will not use remote groups directly but map them to empty local groups.
I can see two possible ways to handle this in the ds tree. In both cases a new objectclass is needed. I the first case this class only contains a mandatory attribute which holds the remote unique ID of the group (e.g. the SID) in the second case there will be a second mandatory group id attribute for the local gid.
I the first case the new objectclass is used together with the posixGroup objectclass while in the second case it is used instead of the posixGroup and groupOfNames object classes.
I think the second one is safer since it won't allow to add direct member to this object, but I would expect that more changes are needed (even on the sssd side) with this approach.
Simo, which would you prefer?
A new group type will be used to map external groups to local groups. Besides the typical group objectclasses, e.g. posixGroup to allow the groups to be used on the clients, these groups will have the objectclasses ipaExternalGroup. This objectclasses has the optional attribute ipaExternalMember which can store the identifiers for external groups. In the AD case this would typically be the SID of the group. The new group type will have the following objectclasses: - objectclass: top - objectclass: ipaobject - objectclass: posixgroup - objectclass: ipaExternalGroup
For the CLI I would suggest to add an option --external to ipa group-add to create a group for external members. To manage external members new sub-commands like 'ipa group-add-external-member' and 'ipa group-remove-external-member' can be used.
When the KDC receives a TGS request with a PAC it will read all groups SIDs from the PAC and - delete all SIDs from the local IPA domain to avoid attacks from trusted domains - looks for local ipaExternalGroup-s which have one of the remote SIDs in ipaExternalMember and add a local SID made of the domain SID of the local IPA domain and the GID of the group object as a RID to the PAC
The sssd pac responder will look for SIDs from the local IPA domain and will use the RIDs as secondary GIDs for the user. If the user does not exist in the cache it will be added and the groups memberships will be added as well. We have to make sure that group lookups will not delete the remote users from the external groups because they are empty on the server side.
Moved to June
Some corrections, an external group object would look like
dn: cn=ext_group,cn=external_groups,cn=accounts,dc=ipa,dc=domain objectclass: top objectclass: ipaobject objectclass: ipaExternalGroup cn: ext_group ipaExternalMember: S-1-15-4234234-432423-4324234-1234 <--- external SID ipaExternalMember: S-1-15-4234234-432423-4324234-5678 <--- external SID memberOf: cn=ipa_group1,cn=groups,cn=accounts,dc=ipa,dc=domain memberOf: cn=ipa_group2,cn=groups,cn=accounts,dc=ipa,dc=domain
Taking the ticket to help Sumit.
master: a6ff85f
Metadata Update from @sbose: - Issue assigned to abbra - Issue set to the milestone: FreeIPA 3.0 Trust Effort - 2012/06
Login to comment on this ticket.