[SSSD] [PATCH] AD: Cache gpo version; only download policy files if version changes

Simo Sorce simo at redhat.com
Thu Aug 7 04:12:00 UTC 2014


On Wed, 2014-08-06 at 23:59 -0400, Yassir Elley wrote:
> I think a non-qualified name can be thought of as either a built-in
> group (such as "Administrators") or as a local group (such as
> "RandomGroup") which happens to have the same name on multiple clients
> (a la windows workgroups). Since sssd supports neither built-in groups
> nor local groups, we aren't going to be able to do exactly what a
> windows client would do. We should do whatever makes sense in an sssd
> context.

Yes but we also need to match Windows administrators expectations and
GPO general behavior.
If "Administrator" matches both BUILTIN\Administrator as welll as
DOMAIN\Administrator for example, we better match the latter as well.

Can you test what windows does if multiple users with the same
unqualified name exist from different domains ?

> For example, if a Windows client encounters a non-qualified name (such
> as RandomGroup) in the GPO policy settings, the client doesn't qualify
> it with the client's domain (RandomGroup at domain) in order to determine
> a match. If it used that strategy, and RandomGroup at domain didn't
> appear among the user's memberships, it would simply ignore that group
> and process the other users/groups in the policy settings. However,
> that's not what a Windows client does. Rather, the Windows client
> consults its SAM database for a match against RandomGroup. If it
> doesn't find a match, it denies access and logs an error (and stops
> processing any other users/groups). So, the actions are quite
> different depending on the strategy used (ignore group vs. deny
> access).

So you tested that unqualified names are only matched against the
BUILTIN database ?

> For sssd, if we think it makes sense to match against
> RandomGroup at domain when we encounter RandomGroup in policy settings,
> we can certainly do that. If we think we should always deny access
> when we encounter non-qualified names, we can also do that. However, I
> think we should apply whatever strategy we decide upon consistently,
> regardless of whether the non-qualified name is on an allow list or a
> deny list. 

I fear we'll have to at least whitelist things like BUILTIN\Users or
BUILTIN\Guests or we may get denials when policies that reference those
special groups are encountered and that should not happen.
However I would like to see some testing that confirm what a Windows
client actually do, so we know for certain and can decide based on the
actual behavior.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list