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, 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).
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, then I think the case for
supporting NetworkLogonRight is less compelling. In this case, perhaps we should stay with
only supporting the InteractiveLogonRight policy.
Comments?
Thanks,
Yassir.