----- 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
> > > "local" bucket (probably by including an ad-gpo-specific option
> > > 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 ?
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
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).