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

Yassir Elley yelley at redhat.com
Sun Aug 10 17:29:42 UTC 2014



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

Conceptually, I agree that non-qualified names should be matched against local posix users and groups (since this is exactly what Windows clients do). However, I don't think sssd currently manages local users and groups. I know this was discussed at some point, but I seem to recall it was not trivial, as it required coordination with some other packages. Has local user/group support already been added to sssd?

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

If support for local users/groups already exists in sssd, I agree. However, in the absence of that, as you suggested, we may still want to match against certain well-known SIDs or unqualified names (such as BUILTIN\Users and BUILTIN\Guests). Presumably, if the special groups appear in the Deny List, they should similarly always match (meaning we would always deny access if BUILTIN\Users was in the Deny List).

> 
> > 2) What should the gpo code do if it encounters an unqualified name
> > that is not well-known?
> 
> As above, match against local groups ?

Again, if support for local users/groups already exists in sssd, I agree. However, in the absence of that, we need to decide whether to always match such unqualified names (that are not well-known, such as RandomUser), or to never match them. Since an AD admin should know that placing RandomUser on a GPO Allow/Deny list is highly deprecated, and that there is no guarantee that all Windows clients in the domain will match it, I think we should take advantage of this fact, and never match RandomUser, which is fully compliant b/c Windows clients in a German locale would similarly never match them.

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

At the beginning of this thread, Jakub had suggested ignoring unqualified names if they appeared on the Allow list, but denying access if unqualified names appear on the Deny List. I guess this is somewhat equivalent to always matching unqualified names, although not exactly, b/c if RandomUser was the only entry on the Allow list, and we ignored it, then we would be denied access (whereas if we always matched it, we would be granted access).

Regards,
Yassir.



More information about the sssd-devel mailing list