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

Yassir Elley yelley at redhat.com
Tue Aug 26 19:00:27 UTC 2014



----- Original Message -----
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > On Mon, Aug 11, 2014 at 04:17:51PM -0400, Yassir Elley wrote:
> > > > 
> > > > 
> > > > ----- 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?
> > > 
> > > I think overrides would be handy. We can even do something similar as we
> > > do with infopipe's attribute list:
> > > 
> > > Let's consider the ad_gpo_map_permit was set to 'dflsvc' by default.
> > > Then:
> > > 
> > > ad_gpo_map_permit = svc1, svc2 # permit list is explicitly set to svc1,
> > > svc2
> > > ad_gpo_map_permit = +svc1 # svc1 is added to the permit list, making the
> > > whole list 'dflsvc, svc1'
> > > ad_gpo_map_permit = -dflsvc # dflsvc is removed from the permit list,
> > > making
> > > the list effectivelly empty
> > > 
> > > See the description of 'user_attributes' in man sssd-ifp for more
> > > details.
> > > 
> > 
> > This is cool!
> > 
> > On a separate topic, what should we do if we encounter the same service on
> > multiple maps? For example, if an admin maps a custom service to both
> > 'interactive' as well as 'network', should we consider that to be a
> > misconfiguration. I don't think Microsoft allows this, but I wonder if it
> > makes sense in some linux scenarios. For example, maybe there is a custom
> > pam service and the local admin wants GPO-based access control to be
> > evaluated against both the InteractiveLogonRight and the NetworkLogonRight.
> > But then would we use AND semantics or OR semantics? If he also mapped it
> > to
> > 'permit', would permit override everything else? Same with deny. Yikes.
> > This
> > might get arbitrarily hairy. I propose we just throw a misconfiguration
> > error if we detect a duplicate mapping.
> > 
> > Regards,
> > Yassir.
> > 
> > 
> > 
> 
> For pam service names in the gpo_map_permit [or gpo_map_deny] bucket,
> considering that we currently only support the Logon Rights GPO, am I
> correct in assuming that the gpo code should immediately return EOK [or
> EACCES] before making any LDAP/SMB calls (but after receiving the service
> name, of course)?
> 
> Regards,
> Yassir.
> 
> 
> hould we just treat the gpo check as a no-op (similar to when it is
> disabled), or should we go through the

Oops. Pls ignore the sentence fragment immediately above.

Let me also clarify the question.

The following is my proposed table for various combinations of gpo_mode and the category (or bucket) which the service maps to. I am only looking at the permit and deny categories here (not interactive, network, etc)

gpo_mode        service_category        return_value
====================================================
disabled         permit                 EOK immediately (i.e. before any LDAP/SMB calls)
disabled         deny                   EOK immediately ...

enforcing        permit                 EOK immediately ...
enforcing        deny                   EACCES immediately ...

permissive       permit                 EOK immediately ...
permissive       deny                   EOK immediately ...

Do you agree with the above table?

Regards,
Yassir.



More information about the sssd-devel mailing list