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

Yassir Elley yelley at redhat.com
Mon Aug 11 20:17:51 UTC 2014



----- Original Message -----
> On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
> > On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
> > > On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
> > > > On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley 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.
> > > > 
> > > > Except we do not have a logon right in windows that really matches what
> > > > sudo is/does ... besiodes given sudo does its own authorization checks,
> > > > what's the point of 2 ?
> > > 
> > > I assume by 'its own authorization checks', you mean /etc/sudoers,
> > > right?
> > 
> > Yes.
> > 
> > > Anyway, this is not something we can influence, can we? /etc/pam.d/sudo
> > > includes system-auth on Fedora, so account management is going to be
> > > called...
> > 
> > But we can map sudo and sudo-l targets in the gpo code as "always
> > allow".
> 
> Right, we just need to be very careful about documenting this (see the
> e-mail I just sent) to make sure users of any similar PAM services don't
> suffer.
> 
> Off-hand I can think of Quest -- don't they include a sudo version of
> their own that might be affected?

I think that adding an ad_gpo_map_permit option (see previous email) would address this, no?

Local admins can certainly add additional pam service names to any of the buckets. For example, they can choose to put quest-sudo in ad_gpo_map_permit or in ad_gpo_map_interactive or whatever. However, this does raise the question of whether we want to allow local admins to *remove* default pam service names from the buckets. In other words, do we want to allow an admin to move the "login" service name (which is in the interactive bucket, by default) to a different bucket (say Network or Batch)? Or do we only want them to be able to provide mappings for service names that have not already been specified as defaults in our code?

Regards,
Yassir.



More information about the sssd-devel mailing list