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, w...@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@suacri10103 ~]# getent group domain\ us...@ad.example.org
>>>domain us...@example.org:*:1012600513:someu...@ad.example.org
>>>[root@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@ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist
>>> 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 someu...@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 us...@ad.test' would make it impossible to assign anything to
'Domain us...@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...

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
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

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to