On Sun, 07 Nov 2010 07:00:04 -0500
Stephen Gallagher <sgallagh(a)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(a)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