[Freeipa-users] Active Directory Trust = filter users

[Sumit Bose]

On Mon, Feb 15, 2016 at 11:10:41AM +0200, Alexander Bokovoy wrote:
> On Mon, 15 Feb 2016, Sumit Bose wrote:
> >On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote:
> >>On Fri, 12 Feb 2016, Jakub Hrozek wrote:
> >>>On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote:
> >>>>On Fri, 12 Feb 2016, wdh at dds.nl wrote:
> >>>>>Hi all,
> >>>>>
> >>>>>Yes, you can filter out certain SIDs--> I tried, but cannot get it to
> >>>>>work. For example, I don't need "Domain Users":
> >>>>>
> >>>>>Found out the SID by:
> >>>>>
> >>>>>[root at suacri10103 ~]# getent group domain\ users at ad.example.org
> >>>>>domain users at example.org:*:1012600513:someuser at ad.example.org
> >>>>>[root at suacri10103 ~]# ldbsearch -H
> >>>>>/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb  gidNumber=1012600513 |
> >>>>>grep objectSIDString
> >>>>>asq: Unable to register control with rootdse!
> >>>>>objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513
> >>>>>
> >>>>>and put the SID in the blacklist; yes it is blacklisted:
> >>>>>
> >>>>>admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist
> >>>>>incoming"
> >>>>> SID blacklist incoming: S-1-5-20,
> >>>>>S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1,
> >>>>>S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,
> >>>>>S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2,
> >>>>>S-1-1, S-1-0, S-1-5-19, S-1-5-18
> >>>>>
> >>>>>However, the group is still there if I do a n "id someuser at ad.example.com"
> >>>>>(yep, whiped cache, restarted ipa etc.)
> >>>>>
> >>>>>Shouldn't the group be disappeared since the SID is blacklisted...?
> >>>>Only from Kerberos tickets. I don't think SSSD in ipa_server_mode
> >>>>consults this list. Instead, when AD users logins with Kerberos ticket,
> >>>>the resulting ticket already has blacklisted SIDs filtered out by IPA
> >>>>KDC and SSSD will see that these tickets' MS-PAC doesn't have additional
> >>>>groups in it.
> >>>
> >>>Alexander, do you think this would make a reasonable RFE?
> >>For non-logged-in case? Yes, it certainly makes sense as it would be
> >>consistent with KDC then. The only potential issue is that we'd lose
> >>'true' group membership for IPA CLI/Web UI operations as removing
> >>'Domain users at AD.TEST' would make it impossible to assign anything to
> >>'Domain users at AD.TEST' in ID overrides and external group members, but
> >>given it is actually filtered out at the level of a trust boundary, may
> >>be this is exactly what a person would like to achieve?
> >
> >yes, I think we have to add support in SSSD for this to be consistent
> >with the group memberships we get from the PAC. But since we in general
> >cannot ignore the groups completely it might be sufficient to just label
> >the filtered groups as non-POSIX groups in the cache (maybe we need an
> >additional flag to indicate that the group is really filtered out to
> >make sure that future lookup schemes which might include non-POSIX
> >groups will ignore the filtered groups as well).
> Marking it non-POSIX wouldn't prevent nested group membership, though.
> This obviously needs more thought...

yes, but I think this would be in agreement to the filtering in the PAC
because here we filter only the SID from this blacklist and not the SIDs
of groups nested in the related group.

bye,
Sumit

> 
> >Btw, the 'Domain Users' group is a bad example here, because it is in
> >general the primary group of the AD users in AD and hence listed in the
> >PAC as primary group. If you filter 'Domain Users' we have to reject all
> >Kerberos request because the resulting PAC will not have a primary
> >group.
> Yep. Though I've seen some environments where people did actually change
> the primary group for AD users to something else. AD environments can be
> broken in a multitude of interesting ways. ;)
> 
> -- 
> / Alexander Bokovoy