[SSSD] Remote user use-case

Simo Sorce ssorce at redhat.com
Sun Nov 7 13:36:42 UTC 2010


On Sun, 07 Nov 2010 07:00:04 -0500
Stephen Gallagher <sgallagh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/05/2010 05:15 PM, Simo Sorce wrote:
> > On Fri, 05 Nov 2010 16:18:19 -0400
> > Stephen Gallagher <sgallagh at redhat.com> wrote:
> >> 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 fully agree that this is the correct long-term approach, but I think
> that the potential security concerns will need a lot of working-out,
> and so I suspect that this won't be available to us in the short or
> medium term.
> 
> ...
> > 
> > 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).
> 
> Well, my main thought here was that this option should not be the
> default (perhaps requiring an override flag to indicate that these
> potentially-error-prone values were being added on purpose). I was
> thinking that it would make sense from the perspective of a
> "manufacturing server", which is common at many companies.
> 
> The idea would be that a company might buy fifty or a hundred pieces
> of identical hardware, and write up a provisioning system that would
> provide a PXE setup system with kickstarts. Then they'd power these
> systems online and have them pick up their new configuration from the
> PXE server.
> 
> In many cases, these PXE systems may not in fact have access to the
> network that the target hardware is intended to be used on (which may
> include the LDAP server providing the user identity for that machine).
> 
> As a result, for this one-time provisioning step, we should allow a
> kickstart script to manually set the UID and primary GID etc.

And how would this server set the right UID/GID w/o being connected to
the LDAP server ?

I find it really unlikely that the lab where these machines are
configured is not connected to the network esp. if you expect to PXE
them, and even more so if the system is supposed to set a specific
username for each machine.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list