[SSSD] [PATCH] AD: Add initial gpo-smb implementation.

Yassir Elley yelley at redhat.com
Thu Jun 19 10:49:09 UTC 2014



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



More information about the sssd-devel mailing list