[SSSD] should ad-gpo support additional logon rights?

Simo Sorce simo at redhat.com
Mon Jun 30 17:22:34 UTC 2014


On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
> 
> ----- Original Message -----
> > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
> > > 
> > > ----- Original Message -----
> > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
> > > > > Hi Simo,
> > > > > 
> > > > > I'd like to wrap up this discussion. I propose that we support only
> > > > > the InteractiveLogonRight (for the pam services you mentioned:
> > > > > "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the
> > > > > "ssh" pam service). We should not support the NetworkLogonRight since
> > > > > it is difficult to implement. Do you agree with this proposal?
> > > > 
> > > > Well I guess the answer depends on what do you plan to do for pam
> > > > services that are not listed ?
> > > > Do you always deny access ? Always permit ?
> > > 
> > > Since we would only support the InteractiveLogonRight and
> > > RemoteInteractiveLogonRight, we would always permit access for other pam
> > > services (because they would not be governed by gpo-based access control,
> > > and this would be clearly documented).
> > > 
> > > > 
> > > > I think a more reasonable workaround is to define a default type, and a
> > > > list of mappings.
> > > > 
> > > > If a PAM service is explicitly mapped you use that Right to decide,
> > > > otherwise the decision falls back to the "default" Right.
> > > > Actually the default right could well be actually NetworkLogonRight or
> > > > InteractiveLogonRight or something else. As long as you can change the
> > > > mappings locally through some configuration that would allow the admin
> > > > to add mappings according to their needs. Of course strong guidance
> > > > on which mappings should be used for specific type of services should be
> > > > provided.
> > > > 
> > > > Simo.
> > > > 
> > > 
> > > I would prefer an approach which is more predictable for the AD admin. If
> > > we limit ourselves to InteractiveLogonRight and
> > > RemoteInteractiveLogonRight, the semantics are very clear (console login
> > > and remote login), allowing the AD Admin to be confident that any existing
> > > or future policy files containing those rights would be applied correctly
> > > and consistently, regardless of whether the machine is running Linux or
> > > Windows.
> > > 
> > > Also, I suspect AD admins would not like per-machine service mappings to be
> > > enforced, since that would defeat the purpose of enforcing a centralized
> > > policy in a consistent manner. When an AD admin made a change to a
> > > LogonRight policy setting, he would have to keep in mind that Linux
> > > machines may use the policy settings in ways that were not intended by the
> > > AD admin. For example, it would be problematic if a local admin decided to
> > > map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to
> > > some LogonRight (but other local admins stayed with the default). This
> > > would result in inconsistent behavior between different Linux machines,
> > > and between Linux machines and Windows machines. Indeed, in the Windows
> > > world, the "local" per-machine GPO is given least priority in case of
> > > conflict (i.e. ou overrides domain, which overrides site, which overrides
> > > local). A solution to this problem of consistency would be to have a
> > > centralized GPO that maps pam services to LogonRights, but I don't think
> > > we need to implement that in the first release.
> > > 
> > > I think limiting ourselves to InteractiveLogonRight and
> > > RemoteInteractiveLogonRight would be less confusing and more predictable
> > > for AD admins (resulting in a greater likelihood of them deploying
> > > gpo-based access control). They would know that these two LogonRights
> > > would be enforced with the same semantics on Windows and Linux machines.
> > > They would also know that other LogonRights would not be enforced on Linux
> > > machines. Clean and crisp.
> > > 
> > > What do you think?
> > 
> > You make a good argument, but I am not entirely convinced you can avoid
> > a local mapping unless you provide a GPO mapping, because the admin must
> > be able to adjust mappings for new services installed on the box that
> > were not included in the upstream provided lists.
> > 
> > So if you already need to provide a way to augment mappings, you may as
> > well handle all rights with reasonable defaults, and let the admin
> > decide whether they need to change stuff around.
> > 
> > Simo.
> > 
> 
> Allowing local admins to change stuff from underneath the AD admin's
> directives seems to violate the GPO philosophy of centralized,
> consistent application of policy. I don't think AD admins will find
> the gpo-based access control feature compelling, if it does not fit
> with their mental model of how GPO is supposed to work.

Sorry but I do not buy this argument. The whole GPO policy can be turned
on or off in sssd, so if admins do not control the boxes' sssd.conf file
they already know their policies are, at best, advisory.

>  As you know, LogonRights are existing Windows policy settings (not
> Linux-specific settings), so we really do have to honor the intent of
> the settings and the GPO framework.

Indeed, and in order to do that you need to be able to appropriately map
arbitrary services.

>  Having said that, I don't think we necessarily need to have a
> comprehensive implementation in the first release, especially if we
> think the GPO mapping is the correct solution (and if we think that we
> may implement that in a subsequent release).

We do not need the support as a GPO deliverable policy, but you need a
local mapping for the feature to be usable/testable IMO.

> I think the centralized mapping offered by a future GPO mapping would
> certainly allay the concerns of AD admins, as the power would remain
> in their hands and it would be applied consistently. Implementing
> local mapping now, and then adding a centralized mapping later would
> delay deployment and would add too much complexity IMO. 

Why ? This is exactly the same as overlaying global policy on top of
local policy, I honestly do not see it as any more complex than needed.

> As for how to deal with new services (in the initial implementation),
> two ideas come to mind:
> 1) My preference would be that only services included in the upstream
> provided lists will be affected by gpo-based access control. Not very
> extensible, but that's OK if we intend on adding a GPO mapping in a
> future release. 

Upstream runs on multiple OSs and Linux distributions, within those
there is already, I bet, enough conflict to make a single upstream list
unfeasible, as pam service names are somewhat arbitrary and customized
in different way especially for very distro-specific services like login
and graphical session managers.

> 2) Alternatively, we could go with a completely different proposal
> that would affect all pam services. Specifically, since remote login
> seems to be an uncommon pam service (we could only come up with
> "ssh"), we could declare that "ssh" maps to
> RemoteInteractiveLogonRight, and that *all* other services (including
> new services, custom services, etc), map to InteractiveLogonRight.

That would be wrong. I suspect one of the services you really want to
control, as a windows admin, is samba file services, and those must be
mapped to NetworkLogonRight.
And NEtworkLogonRight seem to be generally the most sensible default
once you exclude the services you know are interactive login shells.

>  While certainly not ideal (and not my preference), I think AD admins
> would find this easier to grok than local mappings, as it would be
> predictable and would allow policy authority to remain centralized,
> without central directives being manipulated by local admins.

If the admin doesn't grok what services run on a Linux box, they are
already doomed I would think. You need at least a passing understanding
of the policies you are going to set. We can *definitely* provide a good
default set, admins should not be required to provide explicit mappings
if the default works for them, but an unchangeable list will severely
reduce the utility of the feature.

Simo.

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




More information about the sssd-devel mailing list