----- Original Message -----
> On Sat, Jun 14, 2014 at 09:01:53PM -0400, Yassir Elley wrote:
> >
> >
> > ----- Original Message -----
> > > On Thu, Jun 12, 2014 at 04:37:25PM -0400, Yassir Elley wrote:
> > > >
> > > >
> > > >
>
> ...
>
> > > > >
> > > > > Second, you are only checking SeInteractiveLogonRight and
> > > > > SeDenyInteractiveLogonRight. What about
> > > > > Se[Deny][Network|Batch|Service|RemoteInteractive]LogonRight? Are you
> > > > > planning to integrate them as well and relate them to different PAM
> > > > > services?
> > > >
> > > > The plan for the initial deployment is to only support
> > > > SeInteractiveLogonRight and SeDenyInteractiveLogonRight.
> > >
> > > ok, but please keep in mind that it would be hard to add support for
> > > different login types, e.g. network vs. console, later on without
> > > breaking backward compatibility.
> >
> > We are initially supporting console login as a feature. If we later decide
> > to support network login as a feature (in a subsequent release), what is
> > the concern regarding backward compatibility?
>
> currently the patches add access control to all services not only
> console login. This means that currently SeInteractiveLogonRight
> SeDenyInteractiveLogonRight catches all services. If later on you want
> to add support for Se[Deny]NetworkLogonRight you either have to restrict
> the scope of Sei[Deny]InteractiveLogonRight which is not backward
> compatible. Or admins have to explicitly list all users and groups which
> should only be allowed to log in over the network in
> SeDenyInteractiveLogonRight which afaik is not needed for Windows
> clients.
>
> bye,
> Sumit
> >
> > >
Of the various logon rights supported by GPO, I think the InteractiveLogonRight
and NetworkLogonRight map well to the Linux world ("local" logon and "network"
logon), while the other logon rights (Batch, Service, RemoteInteractive) are
more Windows-specific. So I think we should focus on these two use cases
("local" vs "network").
You make a good point regarding backwards-compatibility. If we decide to later
add support for gpo processing of network logons, this could result in users
that were previously allowed logon access (using the presumably more liberal
local logon rules) to be denied access (using the presumably more restrictive
network logon rules). So I think it would be a good idea to support both
InteractiveLogonRight (aka local/console) and NetworkLogonRight from the very
beginning (and their Deny counterparts) to avoid such backward-compatibility
issues.
Having said that, this will introduce some complexity since it will require us
to specify which pam service names are considered "local" by sssd (and should
use InteractiveLogonRight policy) and which are considered "network" (and
should use NetworkLogonRight policy). We would also need to take into account
that pam allows custom service names to be used. A straightforward approach
would be to specify (in man page?) the pam services we consider to be "local"
(e.g. login, gdm, su) and then state that all other services (including custom
services, as well as services that wouldn't be expected to make pam_acct_mgmt
calls) are considered "network". A more sophisticated approach would
additionally provide an api that allows applications to specify whether a given
service name should be considered "local" or "network". What do you think?
Regards,
Yassir.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
