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.
--
Simo Sorce * Red Hat, Inc * New York