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

Simo Sorce simo at redhat.com
Sun Aug 10 15:53:39 UTC 2014


On Sat, 2014-08-09 at 23:14 -0400, Yassir Elley wrote:
> 
> ----- 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.

Ok, so this is just to match BUILTIN's which makes sense as you could
have a LocalUser on each machine and on each one it would have
potentially a different local sid.

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

We should probably treat local posix users as BUILTIN.

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

I think we should match them against user/groups in /etc/passwd|group

We may also want to map well known BUILTIN groups to well known local
posix groups anyway at some point.

> 2) What should the gpo code do if it encounters an unqualified name
> that is not well-known?

As above, match against local groups ?

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

Different how ?

Simo.

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




More information about the sssd-devel mailing list