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

Jakub Hrozek jhrozek at redhat.com
Fri Aug 8 20:58:16 UTC 2014


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 interactive:
> > > > > gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin,
> > > > > 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 Ray argued 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 some
> > > > 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 the Gnome
> > > > 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 (no-password).
> > > 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 at 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 configuration).
> 
> 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
> 
> Regards,
> Yassir.

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
conversation.



More information about the sssd-devel mailing list