In order to be present IPA user and groups to windows servers each user and group must have a unique SID. There are different ways to solve this
- each user and group may have the corresponding samba objectclass and have a SID explicitly added to the object - the ipa_sam samba backend creates the SID on the fly based on the domain SID stored in the samba domain object in the IPA LDAP server and some data from the user or group object - maybe other methods
The following is a summary of a discussion between Simo, Alexander and Sumit.
Although it is quite elegant to generate the SID on the fly, there are other attributes which are needed to allow IPA user to access resources in a windows domain, which cannot be generated algorithmically on the fly. E.g. the home path and the home drive or the profile path. In the general case these attributes cannot be derived from other data and have to be set explicitly. Since we need to expand the LDAP schema to store these attributes we can add another one to store the SID.
It would be possible to either store the complete SID or only the RID and use the domain SID which is stored at some other place to generate the full SID. One argument which would favor to store only the RID is that it would be easy to change the domain SID. But this operation is in general not supported in a windows domain. We agreed that storing the full SID would be the more useful option here.
After it became clear that the SID should be stored in the LDAP directory the question arose if the sambaSamAccount objectclass shall be used or if an IPA specific objectclass should be created. Arguments in favor of an IPA specific objectclass are: - the new oc will not carry around unused or depricated attributes - the new oc will not contain attributes which must be kept in sync with other IPA attributes which the same semantic, like e.g. password related attributes in sambaSamAccount with the exception of sambaNTPassword or sambaAcctFlags which contains a flag if the user is enabled or disabled - existing IPA v1 or v2 installations which already added the sambaSamAccount oc manually to allow IPA to act as a samba LDAP backend can just migrated their individual changes without a conflict with IPA's internal use of the same oc
It was decided that we will create a new objectclass for IPA to store the needed data. This will be tracked by the follow-up ticket #1728.
Metadata Update from @sbose: - Issue assigned to simo - Issue set to the milestone: FreeIPA 3.0 Trust Effort - 2011/08
Login to comment on this ticket.