[SSSD] Remote user use-case

Sumit Bose sbose at redhat.com
Sun Nov 7 11:28:36 UTC 2010


On Fri, Nov 05, 2010 at 05:15:08PM -0400, Simo Sorce wrote:
> On Fri, 05 Nov 2010 16:18:19 -0400
> Stephen Gallagher <sgallagh at redhat.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > One of SSSD's intended primary use-cases is that of the laptop user.
> > We support cached, offline authentications to the local machine so
> > that when a laptop user picks their machine up from their desk and
> > goes home with it, they can still log in.
> > 
> > So what about the use-case of a user that never goes into the office?
> > How can SSSD solve the problem of mailing a laptop to a new employee
> > working out of a home-office? Specifically, how do we provide this
> > user (probably a non-technical user) access to their account for the
> > first time, if they don't have direct physical access to the network
> > to perform that first authentication?
> > 
> > One approach would be for GDM to provide an interface for a user who
> > was not authenticated on the local machine to connect to a
> > NetworkManager-controlled VPN like IPSEC or vpnc. This would require a
> > lot of coordinating work done in the desktop environment (not to
> > mention the security concerns of allowing an unauthenticated user
> > access to VPN settings).
> 
> This is not a bad idea in any case. It would allow a user to log in
> after he forgot the password and called helpdesk to reset it on his
> corporate account. for obvious reasons helpdesk can't reset his cached
> one if he is not connected to the corp. network.

I like the idea of an 'emergency' VPN connection, because as Simo
mentioned it has a much broader use case then just the setting of the
initial password. But for this I'm thinking of a perhaps simpler
solution than a desktop/gdm integration. What about a special run-level
start script which is only executed when a certain command line option
is set during the system startup (the user does not have to set this
manually but just need to choose something like 'Helpdesk assisted
startup' instead of 'Normal startup' at the grub boot screen. This start
script than ask the user to call helpdesk and helpdesk can give a
one-time username/password to the user which is used by the script to
set up a VPN connection. Then the system continues to boot.

bye,
Sumit

> 
> > Another approach might be setting up SSSD with a utility to allow us
> > to set a temporary offline cached password. Essentially, an
> > administrator could provision the machine ahead of time with one
> > remote user (pre-caching their identity data, but not their real
> > password). The machine could then be shipped to the user, and the
> > temporary offline password would be overridden the first time that
> > the user provides a valid online password.
> > 
> > Is this something we should consider exploring in SSSD 1.5.0? I think
> > the implementation of this would be fairly straightforward. All we'd
> > need to do is write a new tool similar to sss_useradd that would
> > pre-cache a user from the default domain. If the machine is online, it
> > should be capable of pulling the standard user identity data from the
> > identity provider, but if the machine is offline it should be possible
> > to manually provide this information as well. Then the utility would
> > hash the temporary password in the sysdb and the machine would be
> > ready to ship off.
> 
> I do not agree on manually providing user data like uid or gid, it is
> quite prone to error. But it make sense to be able to set an
> arbitrary password as a provisioning step. As for priming the user data
> running 'id username' while online should already do all is needed
> (except the password).
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list