[SSSD] Remote user use-case

Stephen Gallagher sgallagh at redhat.com
Mon Nov 8 11:59:53 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/07/2010 08:36 AM, Simo Sorce 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.


Agreed. I think that if we implement this, we should probably just
assume we have a live connection for now.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzX5jMACgkQeiVVYja6o6M+XwCfVNAHF/3tBmcxCzHaDiVEzvwN
DxgAn1FtEvtVDJkZoTrbnuS+9gV7a7Ez
=hsEj
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list