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@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...
917 } 918 919 if (group_sid != NULL) { 920 ret = retain_extern_members(memctx, dom, group_name, group_sid, 921 &userdns, &nuserdns);
Which means we don't call retain_extern_members at all.
922 if (ret != EOK) { 923 DEBUG(SSSDBG_TRACE_INTERNAL, 924 "retain_extern_members failed: %d:[%s].\n", 925 ret, sss_strerror(ret)); 926 } 927 } 928 }
But since the whole block of code was added in the same commit, I guess it must have some purpose..so is going on without a SID the right thing to do? What was the use-case of the original code?
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@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 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.
bye, Sumit
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@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@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Fri, Dec 04, 2015 at 04:39:36PM +0100, Jakub Hrozek wrote:
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@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
This is expected because this is "just" said that the plugin is configured. At the end you should see a "adding SIDs to existing users and groups" message as well indicating that ipa-adtrust-install tried to run the plugin as well.
guess my test IPA install is not in the best shape, maybe I should just refresh it..
Maybe, but it would be good to know why the plugin failed to add a SID to this group. Do you have a change ru run the plugin with plugin debugging enabled for DS?
Does the group by chance has a GID which does not come from the IPA id-range, because it was "migrated" from a different source? In this case adding a local id-range for the "migrated" IDs might help.
bye, Sumit
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@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Mon, Dec 07, 2015 at 10:56:09AM +0100, Sumit Bose wrote:
Maybe, but it would be good to know why the plugin failed to add a SID to this group. Do you have a change ru run the plugin with plugin debugging enabled for DS?
I'm sorry but I no longer have access to that environment, I recycled it so I can continue debugging the original problem..
The environment was around for a long time, since we started working on the one-way-trust feature and had several git shapshots over the time, so I wouldn't be surprised there was something wrong..
sssd-devel@lists.fedorahosted.org