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

Yassir Elley yelley at redhat.com
Sat Jun 28 05:20:32 UTC 2014



----- Original Message -----
> On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
> > 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?
> 
> Well I guess the answer depends on what do you plan to do for pam
> services that are not listed ?
> Do you always deny access ? Always permit ?

Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).

> 
> I think a more reasonable workaround is to define a default type, and a
> list of mappings.
> 
> If a PAM service is explicitly mapped you use that Right to decide,
> otherwise the decision falls back to the "default" Right.
> Actually the default right could well be actually NetworkLogonRight or
> InteractiveLogonRight or something else. As long as you can change the
> mappings locally through some configuration that would allow the admin
> to add mappings according to their needs. Of course strong guidance
> on which mappings should be used for specific type of services should be
> provided.
> 
> Simo.
> 

I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.

Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.

I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.

What do you think?

Regards,
Yassir.



More information about the sssd-devel mailing list