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

Jakub Hrozek jhrozek at redhat.com
Mon Aug 11 19:14:03 UTC 2014


On Mon, Aug 11, 2014 at 09:54:30AM -0700, Michichael Folfsunè wrote:
> > In our case, when a user calls "sudo ls", I think it is a three-step
> > procedure:
> > 1) sudo calls pam_authenticate to authenticate the user
> > 2) sudo calls pam_acct_mgmt to make sure that the account is not
> > locked, that the ldap/gpo policies permit the user to run sudo, etc
> > 3) sudo refers to /etc/sudoers to determine if it can perform the sudo
> > action (i.e. "ls").
> >
> > The GPO Logon Rights relate to step (2) of this procedure.
> 
> Forgive me if I'm misunderstanding, but wouldn't the pam_authenticate
> attempt an authentication against AD if AD was available, and at that phase
> determine whether it's locked out or not? In testing, a locked account
> cannot use sudoers, even if it has a session. If AD isn't available, it'd
> use the cached password (if enabled), but it wouldn't detect a lockout
> regardless. Step 2 seems moot outside of that permission check.
> 
> >You assert that Windows would allow a user to perform remote login
> >(and then access other services, batch jobs, privileged operations)
> >using only the RemoteInteractiveLogonRight. Is your assertion based
> >on actual testing on a Windows client?  I ask because this is not
> >my understanding. I would expect that the RemoteInteractiveLogonRight
> >would be consulted when the user used RemoteDesktop on a
> >Windows client to login to the remote Windows server, and that the
> >InteractiveLogonRight (Allow/Deny Local Logon) would be consulted
> >when the user attempted to perform a privileged operation (using
> >RunAs or UAC). However, I haven't actually tested this yet, so it would
> >be useful to know if you have already tested this.
> 
> Correct, though Windows makes this is a bit muddy. If a user has rights
> granted for RemoteInteractive, but rights explicitly denied for Local
> Interactive (I'm going to refer to it as this just to keep the references
> clear, I think we all understand that it's InteractiveLogonRight), they can
> remote desktop into a server and perform all manner of activities and
> privileged operations. However, with deny Local Interactive in place, if
> their account is used as the target of a RunAs, the SecondaryLogon service
> ONLY checks Local Interactive, and they would be denied. They can still
> make changes to registry, run programs or installers under their
> privileges, etc; but they can't drop into the "console" session or start a
> Local Interactive session. UAC runs perfectly fine for the user to elevate
> their rights (if authorized) using these rights; that's what my personal
> testing has found. I had to use the explicit denies because of how Windows
> nests its privileges, the explicit deny supersedes an approval, but only
> for its respective permission (Local Interactive/Deny Local Interactive).
> 
> > Are you suggesting that sudo skip all of the pam_acct_mgmt checks
> > (checking for locked accounts, ldap filter policies), or that it skip
> > only the gpo policy check?
> 
> Our discussion concluded with the recommendation that it skips the gpo
> policy check, the authentication handles the lockout check if AD is
> available.

This is all fine for the AD use-case, but sudo (or any other PAM-aware
application for that matter) has no idea what is on the server side,
whether it's AD or some home-grown LDAP server. And with LDAP, you
typically don't detect the account lockout until the pam_account phase
as the authentication only binds as the user DN..

Anyway, this discussion started as a thread about mapping sudo to either
InteractiveLogonRight or RemoteLogonRight. It sounds to me that
Michichael and Simo are for moving sudo to the Remote bucked. Is that
right?



More information about the sssd-devel mailing list