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

Yassir Elley yelley at redhat.com
Thu Jun 26 08:54:41 UTC 2014



----- Original Message -----
> 
> 
> ----- Original Message -----
> > On Thu, 2014-06-19 at 21:29 -0400, Yassir Elley wrote:
> > > 
> > > ----- Original Message -----
> > > > On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
> > > > > Simo, Gunther, others,
> > > > > 
> > > > > There has been a recent discussion on sssd-devel regarding whether
> > > > > sssd's
> > > > > AD-GPO effort should support additional logon rights (in addition to
> > > > > the
> > > > > InteractiveLogonRight that we are currently planning on supporting).
> > > > > As
> > > > > you may know, there are five windows logon types:
> > > > > * InteractiveLogonRight               Allows a user to log on locally
> > > > > at
> > > > > the computers keyboard.
> > > > > * RemoteInteractiveLogonRight         Allow logon through
> > > > > RDP/Terminal
> > > > > Services
> > > > > * NetworkLogonRight                   Determines which users are
> > > > > allowed to
> > > > > connect over the network to the computer.
> > > > > * BatchLogonRight                     Allows a user to log on by
> > > > > using
> > > > > a
> > > > > batch-queue facility.
> > > > > * ServiceLogonRight                   Allows a security principal to
> > > > > log on
> > > > > as a service. Services can be configured to run under the
> > > > > 
> > > > > There is some confusion about the NetworkLogonRight. My initial
> > > > > assumption was that the NetworkLogonRight referred to logging in to a
> > > > > windows computer over the network (e.g. by using ssh). With this
> > > > > assumption in mind,
> > > > 
> > > > wrong assumption :-)
> > > > NetworkLogonRight refers to things like SMB/CIFS, that is, the ability
> > > > to access "stuff" (with authentication) via the network.
> > > > 
> > > > >  I thought that it would be very useful to additionally support the
> > > > > SeNetworkLogonRight in order to distinguish between these common use
> > > > > cases (network logon vs local logon); this would require us to map
> > > > > the
> > > > > various pam service names into either the "network" bucket or the
> > > > > "local" bucket (probably by including an ad-gpo-specific option with
> > > > > reasonable defaults).
> > > > 
> > > > The problem is that you need to be able to edit this list. And you may
> > > > want to do it both centrally (if someone has homogeneous services) or
> > > > locally (or at least be able to specify different mappings for
> > > > different
> > > > classes of machines).
> > > > It seem this quickly lead to wanting a GPO to ship this info ...
> > > > 
> > > > > However, since windows users typically use RDP (and not ssh) to
> > > > > perform remote network logon, and since there is a separate
> > > > > RemoteInteractiveLogonRight to cover that case, it is unclear what
> > > > > the
> > > > > NetworkLogonRight actually refers to. Some web sites indicate that
> > > > > NetworkLogon refers to connecting to a shared folder on a windows
> > > > > computer from elsewhere on the network. If NetworkLogon refers to
> > > > > accessing SMB shares,
> > > > 
> > > > It does.
> > > > 
> > > > >  then I think the case for supporting NetworkLogonRight is less
> > > > > compelling.
> > > > 
> > > > Although it may make sense to restrict who can access to shares, it is
> > > > indeed less compelling, and also difficult to implement as a lot of
> > > > software does not have a centralized/able way to do it.
> > > > 
> > > > For example, I would consider scp/sftp a prime candidate for being
> > > > blocked by NetworkLogonRight (while ssh would use
> > > > RemoteInteractiveLogonRight), but I do not know how you would go and
> > > > enforce the difference.
> > > > 
> > > > >  In this case, perhaps we should stay with only supporting the
> > > > > InteractiveLogonRight policy.
> > > > > 
> > > > > Comments?
> > > > 
> > > > Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
> > > > 
> > > > Simo.
> > > > 
> > > 
> > > I think you are suggesting using RemoteInteractiveLogonRight for the
> > > "ssh" pam service name, and using InteractiveLogonRight for all other
> > > pam service names. Is that right?
> > 
> > Uhmm not exactly.
> > I am for using RemoteInteractiveLogonRight for the ssh pam service, yes.
> > 
> > But InteractiveLogonRight for most of the others is probably wrong.
> > Services like ftp, samba, imap, smtp, pop, etc.. clearly should be
> > mapped to NetworkLogonRight.
> > 
> > Really the only services that should have InteractiveLogonRight are gdm
> > (and all *dm) and login, perhaps also su/su-l/sudo/sudo-l ?
> > 
> > Simo.
> > 
> 
> You mentioned that the NetworkLogonRight case would be difficult to implement
> (e.g. ftp, samba, imap, smtp, pop, etc). Is that because those applications
> don't call pam_acct_mgmt?
> 
> If so, perhaps we should focus only on the InteractiveLogonRight (for the pam
> services you mention above: "login", etc) and RemoteInteractiveLogonRight
> (for the "ssh" pam service).
> 
> Regards,
> Yassir.

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?

Thanks,
Yassir.



More information about the sssd-devel mailing list