[SSSD] Remote user use-case

Jeff Schroeder jeffschroed at gmail.com
Mon Nov 8 01:25:48 UTC 2010


Do you have users asking for this? The intention is fantastic, but the idea sound scary.

Sent from my iPhone

On Nov 7, 2010, at 8:36 AM, Simo Sorce <ssorce at redhat.com> wrote:

> 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
> _______________________________________________
> 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