On Fri, Dec 04, 2015 at 04:05:52PM +0100, Sumit Bose wrote:
On Fri, Dec 04, 2015 at 02:47:17PM +0100, Jakub Hrozek wrote:
> Hi,
>
> it seems like
https://fedorahosted.org/sssd/ticket/2492 was not fixed
> completely. Attached are two patches that do the trick for me -- they
> are not polished (at the very least, the first one needs a test..) but I
> would like to get another opinion if they at least aim in the right
> direction.
>
> So my groups on IPA server are set like this:
>
> [jhrozek@unidirect] sssd $ [(ext_mem)] ipa group-show topgr --all --raw
> dn: cn=topgr,cn=groups,cn=accounts,dc=ipa,dc=test
> cn: topgr
> gidnumber: 240000024
> member: cn=ext_ipa_gr,cn=groups,cn=accounts,dc=ipa,dc=test
> ipaUniqueID: 193b7c04-91e9-11e5-bc59-5254005f7b59
> objectClass: ipaobject
> objectClass: top
> objectClass: ipausergroup
> objectClass: posixgroup
> objectClass: groupofnames
> objectClass: nestedgroup
> [jhrozek@unidirect] sssd $ [(ext_mem)] ipa group-show ext_ipa_gr --all --raw
> dn: cn=ext_ipa_gr,cn=groups,cn=accounts,dc=ipa,dc=test
> cn: ext_ipa_gr
> ipaexternalmember: S-1-5-21-1897531548-1940899517-361317264-500
> ipaUniqueID: ad2bd978-91e8-11e5-9d52-5254005f7b59
> memberof: cn=topgr,cn=groups,cn=accounts,dc=ipa,dc=test
> objectClass: ipaobject
> objectClass: top
> objectClass: nestedgroup
> objectClass: ipausergroup
> objectClass: groupofnames
> objectClass: ipaexternalgroup
>
> The SID S-1-5-21-1897531548-1940899517-361317264-500 is an AD user
> (administrator)
>
> Now when I do:
> sudo sss_cache -E
> $ id -G administrator(a)win.trust.test
> $ sudo sss_cache -G
> $ getent group 240000024
>
> Then the "topgr" group gets resolved and the code gets into
sdap_save_grpmem:
> 908 /* This is a temporal solution until the IPA provider is able to
> 909 * resolve external group membership.
> 910 *
https://fedorahosted.org/sssd/ticket/2522
> 911 */
> 912 if (opts->schema_type == SDAP_SCHEMA_IPA_V1) {
> 913 ret = sysdb_attrs_get_string(attrs, SYSDB_SID_STR, &group_sid);
> 914 if (ret != EOK) {
> 915 DEBUG(SSSDBG_TRACE_FUNC, "Failed to get group sid\n");
> 916 group_sid = NULL;
>
> Here we set the group_sid variable to NULL, because topgr, being an IPA
> group, doesn't have a SID...
why does it not have a SID.
I don't know, even re-running:
# ipa-adtrust-install --add-sids
Tells me that "Sidgen task plugin already configured, nothing to do". I
guess my test IPA install is not in the best shape, maybe I should just
refresh it..
I guess it has a GID since we got this far.
IPA with trust enabled should automatically add SIDs to new POSIX groups
and groups created before trust setup should get them from running the
sidgen task. It is important that the groups have a SID because
otherwise they cannot be added to the PAC causing different views of the
groups membership see by the PAC responder and the ID provider.
Makes sense.
>
> bye,
> Sumit
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org