-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
One of SSSD's intended primary use-cases is that of the laptop user. We support cached, offline authentications to the local machine so that when a laptop user picks their machine up from their desk and goes home with it, they can still log in.
So what about the use-case of a user that never goes into the office? How can SSSD solve the problem of mailing a laptop to a new employee working out of a home-office? Specifically, how do we provide this user (probably a non-technical user) access to their account for the first time, if they don't have direct physical access to the network to perform that first authentication?
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).
Another approach might be setting up SSSD with a utility to allow us to set a temporary offline cached password. Essentially, an administrator could provision the machine ahead of time with one remote user (pre-caching their identity data, but not their real password). The machine could then be shipped to the user, and the temporary offline password would be overridden the first time that the user provides a valid online password.
Is this something we should consider exploring in SSSD 1.5.0? I think the implementation of this would be fairly straightforward. All we'd need to do is write a new tool similar to sss_useradd that would pre-cache a user from the default domain. If the machine is online, it should be capable of pulling the standard user identity data from the identity provider, but if the machine is offline it should be possible to manually provide this information as well. Then the utility would hash the temporary password in the sysdb and the machine would be ready to ship off.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Fri, 05 Nov 2010 16:18:19 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
One of SSSD's intended primary use-cases is that of the laptop user. We support cached, offline authentications to the local machine so that when a laptop user picks their machine up from their desk and goes home with it, they can still log in.
So what about the use-case of a user that never goes into the office? How can SSSD solve the problem of mailing a laptop to a new employee working out of a home-office? Specifically, how do we provide this user (probably a non-technical user) access to their account for the first time, if they don't have direct physical access to the network to perform that first authentication?
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.
Another approach might be setting up SSSD with a utility to allow us to set a temporary offline cached password. Essentially, an administrator could provision the machine ahead of time with one remote user (pre-caching their identity data, but not their real password). The machine could then be shipped to the user, and the temporary offline password would be overridden the first time that the user provides a valid online password.
Is this something we should consider exploring in SSSD 1.5.0? I think the implementation of this would be fairly straightforward. All we'd need to do is write a new tool similar to sss_useradd that would pre-cache a user from the default domain. If the machine is online, it should be capable of pulling the standard user identity data from the identity provider, but if the machine is offline it should be possible to manually provide this information as well. Then the utility would hash the temporary password in the sysdb and the machine would be ready to ship off.
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).
Simo.
On Fri, Nov 05, 2010 at 05:15:08PM -0400, Simo Sorce wrote:
On Fri, 05 Nov 2010 16:18:19 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
One of SSSD's intended primary use-cases is that of the laptop user. We support cached, offline authentications to the local machine so that when a laptop user picks their machine up from their desk and goes home with it, they can still log in.
So what about the use-case of a user that never goes into the office? How can SSSD solve the problem of mailing a laptop to a new employee working out of a home-office? Specifically, how do we provide this user (probably a non-technical user) access to their account for the first time, if they don't have direct physical access to the network to perform that first authentication?
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 like the idea of an 'emergency' VPN connection, because as Simo mentioned it has a much broader use case then just the setting of the initial password. But for this I'm thinking of a perhaps simpler solution than a desktop/gdm integration. What about a special run-level start script which is only executed when a certain command line option is set during the system startup (the user does not have to set this manually but just need to choose something like 'Helpdesk assisted startup' instead of 'Normal startup' at the grub boot screen. This start script than ask the user to call helpdesk and helpdesk can give a one-time username/password to the user which is used by the script to set up a VPN connection. Then the system continues to boot.
bye, Sumit
Another approach might be setting up SSSD with a utility to allow us to set a temporary offline cached password. Essentially, an administrator could provision the machine ahead of time with one remote user (pre-caching their identity data, but not their real password). The machine could then be shipped to the user, and the temporary offline password would be overridden the first time that the user provides a valid online password.
Is this something we should consider exploring in SSSD 1.5.0? I think the implementation of this would be fairly straightforward. All we'd need to do is write a new tool similar to sss_useradd that would pre-cache a user from the default domain. If the machine is online, it should be capable of pulling the standard user identity data from the identity provider, but if the machine is offline it should be possible to manually provide this information as well. Then the utility would hash the temporary password in the sysdb and the machine would be ready to ship off.
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).
Simo.
-- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/07/2010 06:28 AM, Sumit Bose wrote:
I like the idea of an 'emergency' VPN connection, because as Simo mentioned it has a much broader use case then just the setting of the initial password. But for this I'm thinking of a perhaps simpler solution than a desktop/gdm integration. What about a special run-level start script which is only executed when a certain command line option is set during the system startup (the user does not have to set this manually but just need to choose something like 'Helpdesk assisted startup' instead of 'Normal startup' at the grub boot screen. This start script than ask the user to call helpdesk and helpdesk can give a one-time username/password to the user which is used by the script to set up a VPN connection. Then the system continues to boot.
This approach would still likely require plymouth integration at the least, since a user would need to be able to specify this at boot time before the transition over to the real X-server.
I'm also wary of ever allowing an unauthenticated user access to a VPN shared secret, but if it was contacting a special VPN concentrator created for this purpose that only allowed authentication with one-time-passwords and only provided access to the LDAP server and authentication server, then I suppose I can live with that. But that's putting an awful lot of additional responsibility on the IT staff to make sure that connection is secure. As well as additional hardware.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Sun, 07 Nov 2010 07:16:24 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
I'm also wary of ever allowing an unauthenticated user access to a VPN shared secret, but if it was contacting a special VPN concentrator created for this purpose that only allowed authentication with one-time-passwords and only provided access to the LDAP server and authentication server, then I suppose I can live with that. But that's putting an awful lot of additional responsibility on the IT staff to make sure that connection is secure. As well as additional hardware.
Why do you say you are going to give an unauthenticated user access to a shared secret ?
The best course of action would be for helpdesk to give a short lived set of credentials to the user via telephone. This set of credentials would be usable only to set up the VPN. Nothing shared, and they would be expired as soon as helpdesk confirms you got access with your normal credentials.
The only thing it requires is a way to call the VPN software from GDM. But the only stuff you'd be allowed to set are your temporary VPN username and password or OTP token, or ...
Once the VPN connection is established, you will try to login with your username and the new password set by helpdesk (this will hopefully force a password change too, but that's up to how helpdesk setup their password change procedures). Once you are in, the helpdesk VPN can be terminated.
Simo.
-----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@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.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Sun, 07 Nov 2010 07:00:04 -0500 Stephen Gallagher sgallagh@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@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.
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@redhat.com wrote:
On Sun, 07 Nov 2010 07:00:04 -0500 Stephen Gallagher sgallagh@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@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/07/2010 08:25 PM, Jeff Schroeder wrote:
Do you have users asking for this? The intention is fantastic, but the idea sound scary.
Which part sounds scary?
Also, yes. There are some deployments I'm aware of that would very much like to see this feature (at least with the first-time cached password).
- -- 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 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@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@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/
sssd-devel@lists.fedorahosted.org
-
Jeff Schroeder -
Simo Sorce -
Stephen Gallagher -
Sumit Bose