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

Yassir Elley yelley at redhat.com
Sun Aug 10 03:14:32 UTC 2014



----- Original Message -----
> 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 ?

Yes. The results of my testing indicate that unqualified names are only matched against the BUILTIN database. I tested this by performing the following steps:
* I created two users: BUILTIN\RandomUser and DOMAIN\RandomUser.
* I placed the unqualified name "RandomUser" on an Allow Logon Locally GPO (which I made sure would be processed). The semantics of this GPO are that no one is allowed to perform a console logon except for "RandomUser"
* When I tried to logon as DOMAIN\RandomUser, it failed with the message "You cannot log on because the logon method you are using is not allowed on this computer." This is the message displayed when a user is denied access b/c of GPO Logon Rights.

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

I think that whatever we decide to do for BUILTIN groups, we should also do for well-known SIDS. Currently, we never match well-known SIDs, which means that if the AD admin has specified that only the well-known SID for BUILTIN\Users should be allowed access, we never match against that SID (b/c it doesn't exist in our cache) and we deny access. Similarly, if the AD admin has specified that the well-known SID for BUILTIN\Users should be denied access, we never match against that SID and we allow access.

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

There seem to be a few issues here:
1) What should the gpo code do if it encounters a well-known SID or well-known unqualified name of a BUILTIN group?
2) What should the gpo code do if it encounters an unqualified name that is not well-known?
3) Should the behavior in 1 and 2 be different depending on whether the name is encountered in an Allow list or a Deny list?

Regards,
Yassir.





More information about the sssd-devel mailing list