----- 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@domain) in order to determine
> a match. If it used that strategy, and RandomGroup@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@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.