Description of problem: SSSD supports a feature called "deferred kinit" when configured with the kerberos auth provider. This feature allows users to log in with their cached password while they're off the network, then automatically acquire a kerberos TGT when their Kerberos KDC becomes reachable (e.g. when they connect to a VPN). It would be handy to have authconfig be able to set this up (as a checkbox in the GUI and a flag on the command-line). All that is needed here is to set 'krb5_store_password_if_offline = True' in the [domain/default] section of sssd.conf. Version-Release number of selected component (if applicable): authconfig-6.2.1-1.fc17 Additional info: This option should not be the default because it DOES involve storing the user's password in plaintext (securely in the kernel keyring) until the deferred kinit occurs, at which time it is deleted. This produces a limited security vulnerability if the feature is enabled (it's possible for root to access the plaintext password through highly non-trivial means). For many users, the convenience will significantly outweigh the risks, especially on privately-controlled machines (such as a personal laptop).
How does this feature relate to the the cache_credentials option which authconfig sets on by default? Are these completely unrelated or does the cache_credentials imply this feature? I am not sure we want this option in the GUI as it should be kept as much simple as possible. Also as root is able to intercept the passwords when they are passed to the kinit during the login I do not see this feature as a security vulnerability anyway.
(In reply to comment #1) > How does this feature relate to the the cache_credentials option which > authconfig sets on by default? > > Are these completely unrelated or does the cache_credentials imply this > feature? > They layer atop each other. krb5_store_password_if_offline require 'cache_credentials = True' for it to to be available. When both are set, you get the additional functionality described above. > I am not sure we want this option in the GUI as it should be kept as much > simple as possible. Also as root is able to intercept the passwords when they > are passed to the kinit during the login I do not see this feature as a > security vulnerability anyway. Well, it's a matter of how big the window is. In the case of login, there's a very short window between when the password is entered, used and then cleared from memory. However, with the krb5_store_password_if_offline feature, until you've actually gone online (VPN, etc.), the password is theoretically possible to extract from the kernel keyring. This may be tens of minutes or longer. Upstream, we make the following recommendation with regard to this features: We recommend enabling it for systems that are primarily single-user (such as an employee's personal/corporate laptop). We recommend disabling it on multi-user systems such as servers. Given that the GUI is generally only used by single-user deployments, what if we took the following approach: Add a command-line option for supporting this feature: --sssddeferredkinit and enable this by default when running the GUI.
I've decided to key off the krb5_store_password_if_offline value from the cache_credentials value. I don't think the nuances of security implications from these two options are significant enough to require a separate command line option. As servers aren't generally used in offline mode the password won't be normally stored in the keyring anyway. For security sensitive environments the cache_credentials option can be switched off with --disablecachecreds.
authconfig-6.2.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/authconfig-6.2.4-1.fc18
(In reply to comment #3) > I've decided to key off the krb5_store_password_if_offline value from the > cache_credentials value. I don't think the nuances of security implications > from these two options are significant enough to require a separate command > line option. As servers aren't generally used in offline mode the password > won't be normally stored in the keyring anyway. For security sensitive > environments the cache_credentials option can be switched off with > --disablecachecreds. Is the cache_credentials option on by default? Is the --disablecachecreds option mentioned in the --help or the man page?
(In reply to comment #6) > Is the cache_credentials option on by default? Yes, it is on by default. > Is the --disablecachecreds option mentioned in the --help or the man page? It is mentioned in --help output.
Package authconfig-6.2.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing authconfig-6.2.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14836/authconfig-6.2.4-1.fc18 then log in and leave karma (feedback).
(In reply to comment #7) > (In reply to comment #6) > > Is the cache_credentials option on by default? > > Yes, it is on by default. > OK, that kind of surprises me mostly because it's not the default in the SSSD either. > > Is the --disablecachecreds option mentioned in the --help or the man page? > > It is mentioned in --help output. Then I think we're fine.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.