----- Original Message -----
Essentially I wanted to address the integration of rights assignments to sudo
and potentially other components. Sudo is a two factor item - first the
authentication, then the filter of rules based on users or groups that
determine whether the calling user actually has rights.
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.
The GPO Logon Rights relate to step (2) of this procedure.
Integrating that into InteractiveLogonRight seems perfectly fine in a desktop
environment, but one of the common themes in windows server hardening is
locking down the InteractiveLogonRight and removing all but Domain and Local
Administrators, or adding a DenyInteractiveLogonRight entry for the user
groups, and granting only RemoteInteractiveLogonRight.
Our discussion involved a few theoreticals and some testing.
For example, let's say a user is a member of a group that has
RemoteInteractiveLogonRight but Deny Local Logon. In this case, an
administrator would expect that the user can log in and utilize sudo to
access authorized privileged commands, similar to how in Windows, a user can
log in using only this right and access other services, batch jobs, or
privileged operations (assuming they're authorized) using RunAs and UAC. In
this Scenario, however, sudo would not authenticate the user, since they are
in Deny Local Logon.
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
This is a very common setup for servers - and Deny's always take precedence
over their associated Allow in the context of the Local or Remote
Yes. In fact, Deny's take precedence for all LogonRights, including
(Local)InteractiveLogonRight, RemoteInteractiveLogonRight, NetworkLogonRight,
ServiceLogonRight, and BatchLogonRight.
The discussion concluded with a concern on whether sudo and sudo-i should
even be included in the rights policies given its two-factor nature. Would a
security concern be raised by allowing sudo to authenticate a user
regardless of these memberships? As far as I'm aware, sudo is called from an
existing logon, cron, or other session.
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?
Hope that sums everything we talked about up!
Thanks for your input. It is an interesting discussion!
On Fri, Aug 8, 2014 at 1:58 PM, Jakub Hrozek < jhrozek(a)redhat.com > wrote:
On Tue, Aug 05, 2014 at 05:14:17PM -0400, Yassir Elley wrote:
> ----- Original Message -----
> > On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
> > > ----- Original Message -----
> > > > On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > 4. Should we add the various gdm-* service names as
> > > > > gdm-autologin, gdm-fingerprint, gdm-launch-environment,
> > > > > gdm-smartcard
> > > > >
> > > > > 5. Should we add the screen savers as interactive:
> > > > > gnome-screensaver,
> > > > > kscreensaver
> > > >
> > > > I think we should check with Ray Strode (halfline on
> > > > IRC) about the and screensaver semantics. For instance in
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16
> > > > that
> > > > screensaver only 're-authenticates'.
> > > >
> > > > I tend to agree about the gdm-* services, but again, checking with
> > > > Ray
> > > > might be a good idea. I think at least in the past, gdm would do
> > > > funky stuff with non-password authentication, like sending the
> > > > authtoks
> > > > to several different pam services and checking which ones would let
> > > > the
> > > > user through..I'm not sure if it's still the case now after
> > > > 3.x rewrite.
> > > >
> > > > What does gdm-launch-environment do?
> > > >
> > >
> > > I chatted with Ray Strode, who said we should provide defaults (of
> > > interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The
> > > pam
> > > gnome-screensaver service has apparently been replaced with a
> > > gnome-shell
> > > lock screen (starting with RHEL 7). Even on RHEL 6, while the
> > > pam_acct_mgmt call is made when unlocking the gnome-screensaver, the
> > > results are apparently ignored (b/c the user already has a running
> > > session; the lock simply hides the gnome-shell display).
> > Right, I found this out as well, it was a bit suprising to me, but meh,
> > the user's TGT would expire anyway..
> > > He didn't think default values were needed for any of the other gdm
> > > related
> > > services, such as:
> > > * gdm-pin (no longer supported)
> > > * gdm-autologin (password-less login)
> > > * gdm-launch-environment (used to launch system session for gdm user to
> > > run
> > > login process)
> > > Note that there is no pam service simply named "gdm".
> > >
> > > On the other side, there seem to be four pam services related to kdm:
> > > kdm,
> > > kdm-np, kcheckpass, and kscreensaver. We should definitely include a
> > > default for kdm, but we probably don't care about kdm-np
> > > Does anyone know how kscreensaver differs from kcheckpass (both have
> > > identical pam files, which essentially include system-auth for all
> > > calls
> > > (auth, account, session, password). Perhaps we should add defaults for
> > > both kcheckpass and kscreensaver.
> > I'm sorry, I have no idea about KDE at all...I know that ltinkl(a)r.c does
> > a
> > bit of KDE development, maybe he would get an idea.
> Couldn't get in touch with ltinkl, but halfline pointed me to dvratil, who
> I chatted with instead. When a user tries to unlock the screen,
> kscreenlocker_greet calls kcheckpass, which calls pam_authenticate (but
> not pam_acct_mgmt). Also, kscreensaver is apparently legacy. So, among the
> KDE pam services, I think we should only provide a default for "kdm".
> Here is a summary of the pam service names for which I am planning on
> providing default logon rights (which can, of course, be overridden by
> Default = InteractiveLogonRight
> * login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint,
> gdm-smartcard, kdm
> Default = RemoteInteractiveLogonRight
> * sshd
> Default = NetworkLogonRight
> * ftp, samba
> Default = BatchLogonRight
> * crond
We had a long and useful conversation about this topic on #sssd with
one of our users -- I'm adding him to the CC list so we can continue the
sssd-devel mailing list