-----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 <sgall...@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 <sgall...@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----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel