[SSSD] [PATCH] IPA: verify group memberships of trusted domain users

Sumit Bose sbose at redhat.com
Wed Dec 17 18:52:06 UTC 2014


On Wed, Dec 17, 2014 at 04:40:53PM +0100, Sumit Bose wrote:
> On Wed, Dec 17, 2014 at 04:07:42PM +0100, Lukas Slebodnik wrote:
> > On (16/12/14 10:47), Sumit Bose wrote:
> > >On Mon, Dec 15, 2014 at 10:41:25AM +0100, Lukas Slebodnik wrote:
> > >> On (12/12/14 11:04), Sumit Bose wrote:
> > >> >Hi,
> > >> >
> > >> >This patch tries to assure on IPA clients that users from trusted
> > >> >domains are really belong ot all groups they are member of and should
> > >> >fix https://fedorahosted.org/sssd/ticket/2529 .
> > >> >
> > >> >bye,
> > >> >Sumit
> > >> 
> > >> >From 57f82b2f316d78b1971d6d045c6662a54fe8a6a6 Mon Sep 17 00:00:00 2001
> > >> >From: Sumit Bose <sbose at redhat.com>
> > >> >Date: Thu, 11 Dec 2014 10:49:39 +0100
> > >> >Subject: [PATCH] IPA: verify group memberships of trusted domain users
> > >> >
> > >> >Depending on the state of the cache group object a freshly created or
> > >> >updates user entry for a trusted domain user might already be a member
> > >> >of the group or not. This cache makes sure the requested user is a
> > >> >member of all groups returned from the extdom request.
> > >> >
> > >> >Resolves https://fedorahosted.org/sssd/ticket/2529
> > >> >---
> > >> Your patch fixes problem just partially. There is still problem with external
> > >> group. I had similar problem with RESP_GROUP_MEMBERS in ticket #2524.
> > >> The main problem is that domain for storing result in sysdb needn't be the
> > >> same. In my case, external groups were stored to ad.domain instead of
> > >> ipa.domain. I fixed it with using right domain (attached patch)
> > >> 
> > >> There is still problem if two AD users are members of the same groups
> > >>  (especially external IPA group).
> > >> For the first user, groups are resolved due to RESP_GROUP_MEMBERS.
> > >> Membership for the second user is partially fixed by your patch for
> > >> RESP_USER_GROUPLIST, but external group is not fixed.
> > >> 
> > >> Let me show small example.
> > >> 
> > >> We have users aduser1 at ipaad2012.test and aduser2 at ipaad2012r2.test.
> > >> aduser1 connects with ssh to machine. group membership is resolved due to
> > >> RESP_GROUP_MEMBERS. The second user aduser2 connects to the same machine and
> > >> is member of the same groups. It will receive list of groups
> > >> (RESP_USER_GROUPLIST)
> > >>     list = { "aduser2 at ipaad2012.test", "domain users at ipaad2012.test",
> > >>              "adgroup1 at ipaad2012.test", "tgroup5" }
> > >> "tgroup5" is ipa group.
> > >> 
> > >> There are errors in log file::
> > >> [sysdb_update_members_ex] (0x0020): Could not add
> > >>     member [aduser2 at ipaad2012r2.test] to group [tgroup5]. Skipping.
> > >> [sysdb_update_members_ex] (0x0020): Could not add
> > >>     member [aduser2 at ipaad2012r2.test] to group [aduser2 at ipaad2012r2.test]. Skipping.
> > >> 
> > >> The reason why it failed is that sssd tried to update membership
> > >> in the group tgroup5 at ipaad2012.test, which does not exists.
> > >> 
> > >> I'm not sure what is right solution. In my opinion IPA server mode should
> > >> enable fully quallified names. So we sould be extract domain from group name
> > >> "tgroup5 at ipa.test", but it would not fix the bug in RESP_USER_GROUPLIST
> > >> it would need to be speacial cased. Another solution can be to change default
> > >> domain to ipa domain and search for subdomain where it is necessary.
> > >
> > >Thank you for the rigid testing. I've attached a new over of the patch
> > >which used the DNs of the groups to make sure they will be added to the
> > >cache in the right place.
> > >
> > >I've added a commit message to your patch and added it here as well.
> > >
> > >> 
> > >> BTW: the function ipa_s2n_save_objects is big enough. So it would be good to
> > >> extract your patch to static function. The another season for separate function
> > >> is ldb transaction.
> > >
> > >I agree, but I prefer to complete refactor ipa_s2n_save_objects() when
> > >all open issues related to group lookups on IPA clients are solved.
> > Fair enough
> > 
> > >Maybe it would be even better to schedule this for 1.13 for make fixing
> > >and backporting patches for upcoming issues in this area more easy. If
> > >you agree I'll open a ticket about it so it won't get lost.
> > OK
> > 
> > >From 58e0e132d291234f0bf6305e5410a68481fe50be Mon Sep 17 00:00:00 2001
> > >From: Sumit Bose <sbose at redhat.com>
> > >Date: Thu, 11 Dec 2014 10:49:39 +0100
> > >Subject: [PATCH 1/2] IPA: verify group memberships of trusted domain users
> > >
> > >Depending on the state of the cache group object a freshly created or
> > >updates user entry for a trusted domain user might already be a member
> > >of the group or not. This cache makes sure the requested user is a
> > >member of all groups returned from the extdom request. Special care has
> > >to be taken to cover cross-domain group-memberships properly.
> > >
> > >Resolves https://fedorahosted.org/sssd/ticket/2529
> > >---
> > Problem with two users which are in the same external group is fixed.
> > ACK
> > 
> > >From 37193dc35297bf9d552c67be2c5f2d80bc9c9e5a Mon Sep 17 00:00:00 2001
> > >From: Lukas Slebodnik <lslebodn at redhat.com>
> > >Date: Fri, 12 Dec 2014 13:07:55 -0500
> > >Subject: [PATCH 2/2] IPA: properly handle groups from different domains
> > >
> > >When groups are resolved on IPA clients as part of a user lookup not all
> > >groups have to be from the same domain as the used. This has to be
> > >checked to store the group object properly in the cache.
> > >
> > >Related to https://fedorahosted.org/sssd/ticket/2529
> > You can add ticket https://fedorahosted.org/sssd/ticket/2524 as well, but it is
> > not important.
> > 
> > I will not ACK my own patch :-)
> 
> ACK :-) 

Pushed to master:
    ad463501d3bdea4c24c17d792efc1c3e65c08c19
    8f9d7684a47cd4715dce22c8254ddde205db9afe

bye,
Sumit

> 
> bye,
> Sumit
> > 
> > LS
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list