----- 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@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.
>
> 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@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.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
We haven't had any activity on this thread for some time, so let me summarize the
discussion as I see it.
Issue: In the common case, the whitelists and blacklists in GptTmpl.inf are specified in
terms of sids. Using GPME, if the Windows admin "browses" to add a user to a
list, or if he manually enters a fully-domain-qualified name, then GPME converts those
into sids before writing them to the inf file. However, if the admin manually enters an
unqualified name, then that name string is written to the inf file.
Proposal 1: Simo suggested that we match the unqualified name against users/groups in
/etc/passwd|group.
Concern: 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?
Proposal 2: If local user/group support does not exist in sssd, I propose that we adopt a
policy of either always matching or never matching against such unqualified names
(although we may want to always match certain common group names, such as Users and
Guests).
Regards,
Yassir.