When the domain password is changed externally, SSSD requires that the user log in with their new domain password. This is problematic because things like gnome-keyring and ecryptfs hook into the PAM 'password' stack and expect to be told of changes, so that they can change their master encryption key accordingly. The problem manifests itself with gnome-keyring asking for my old password after I've logged in. And I've no idea what the failure mode for ecryptfs will be; I didn't expect this to work so I deliberately haven't enabled ecryptfs yet. The Windows model is that users always log in with their *old* password, and are then prompted to update/resync. This allows them to automatically unlock any local resources which are encrypted with the old password. I see two potential fixes for this. The best, if we can manage it, is some kind of 'key escrow'. If there is *some* secret in AD which can only be accessed with a currently valid password, then things like ecryptfs could store a second copy of the master disk encryption key, encrypted with that secret. It would *also* store the disk encryption key encrypted with the locally-known password, as usual. And when a login happens with a remotely-changed password, the disk encryption key could be recovered using the 'escrow secret' and another copy written out, encrypted with the *new* password. An alternative is to use the Windows model where we *always* log in using the old password. It could work something like this: - Prompt for the password. - Check it against the network. - If it works, but it *doesn't* match the user's cached password, then ask for the old password too. Run the PAM stack to let gnome-keyring/ecryptfs/etc know about the change. - If it doesn't work against the network (but the network is online and it really is a wrong password, rather than some other error), but it *does* match the user's cached password, then ask then for the *new* password too. And run the PAM stack for the change. If we really are offline and the password has changed on the network, we'll *eventually* notice, because we'll try to obtain a TGT (we do keep trying that in the background, right?) and we'll realise the password is wrong. At that point, we need a small tool in the user's session which communicates with SSSD somehow and does the prompting.
The workflow you describe seem to assume you are going to ask for the old password, so I think this is something gnome-keyring should do rather then trying to make gnome-keyring shortcomings complicate sssd's perfectly working workflow. Given they seem to obviously also hook the authentication stack they should try the new password if the underlying pam stack says it performed successful authentication. If it does and the password is not good, then gnome-keyrign should prompt for the old password and then perform an internal rekey with the new password it grabbed from the pam stack. I suggest re-assigning this bug to gnome-keyring instead. They can solve this in a much easier way than sssd could anyway, and by doing it in gnome-keyring you fix *all* remote authentication cases (sssd, pam_ldap, pam_krb5, nis, hesiod and whatnot) in a single change.
I agree with Simo. Reassigning.
I'm not really wedded to any workflow, as long as it works. I'm just trying to improve integration of Fedora in our corporate environment to the point where I can give it to long-time Windows users and *not* have them hunt me down and promote an attitude of violence towards me. I actually prefer the key-escrow option that doesn't require asking for the old password at all. If we can find a suitable 'secret' in AD, that would be great. We can stick that into a separate PAM environment variable and things like pam_ecryptfs/pam_gnome_keyring can use it as a fallback if the password doesn't work. If we do have to stick with asking for the old password somehow, then one of the simplest options is to do what Windows does and *always* log in with the old password, regardless of whether we're online or not. We're going to need a process running in the user's session to notice password changes on the network *anyway*. It can prompt for the new password then, and change the local password to match. Perhaps this is something that gnome-keyring should be involved with (cf. bug 975464). Another option which could also fix things for pam_ldap/pam_krb5/nis etc. would perhaps be a *separate* pam_pwcache module. It sits in the PAM login stack after the normal login modules, and if the password used to log in does *not* match the cached one, then it would prompt immediately for the old password. That old password could be set in a PAM variable for things like pam_ecryptfs/pam_gnome_keyring/etc. to use if the main password didn't work. Fairly much the same as the key escrow option, except that we have to ask the user for it. I have an open mind about how we solve this problem, but I really do think it needs to be solved *somehow* to give a viable usability experience for users who come from the Windows world and expect this stuff to Just Work™
(In reply to David Woodhouse from comment #3) > I'm not really wedded to any workflow, as long as it works. I'm just trying > to improve integration of Fedora in our corporate environment to the point > where I can give it to long-time Windows users and *not* have them hunt me > down and promote an attitude of violence towards me. > > I actually prefer the key-escrow option that doesn't require asking for the > old password at all. If we can find a suitable 'secret' in AD, that would be > great. We can stick that into a separate PAM environment variable and things > like pam_ecryptfs/pam_gnome_keyring can use it as a fallback if the password > doesn't work. If you are using AD I think you should look at this: http://msdn.microsoft.com/en-us/library/cc224123.aspx > If we do have to stick with asking for the old password somehow, then one of > the simplest options is to do what Windows does and *always* log in with the > old password, regardless of whether we're online or not. A) AFAIK Windows does not do that unless you are offline (but AD does allow you to use the old password for a limited amount of time (a few hours or so) when using kerberos after a password change so it may seem that way if you test immediately after a password change). B) It would clearly be a security issue that would get an immediate CVE to stop doing that. One of the reasons to change a password is that it has been stolen/compromised, you cannot allow login with an old password except in the offline case where you have no way to know the password actually has changed. But when online you definitely refuse old passwords. If you are going to detect whether the password is new or old at login time then you will cause less confusion allowing the user to use the *current* password to log in and then clearly state you need the *old password* only if/when you really need it. > We're going to need a process running in the user's session to notice > password changes on the network *anyway*. It can prompt for the new password > then, and change the local password to match. Perhaps this is something that > gnome-keyring should be involved with (cf. bug 975464). Right. What you can do is that you can store a salted hash of the old password and, at login, find out if the new password does not match that hash, in that case you prompt for the old password. If it matches then you update from old to new. This will happen rarely on the main user machine as the user will change his password on that machine and you can still also intercept the pam passwd target for the common case. So in most cases will be transparent and will ask the old password only in rare cases. > Another option which could also fix things for pam_ldap/pam_krb5/nis etc. > would perhaps be a *separate* pam_pwcache module. It sits in the PAM login > stack after the normal login modules, and if the password used to log in > does *not* match the cached one, then it would prompt immediately for the > old password. I do not think it matters 'where' you intercept/use it. Of course what is important is that you keep around any password in the plain the least amount of time possible. > That old password could be set in a PAM variable for things like > pam_ecryptfs/pam_gnome_keyring/etc. to use if the main password didn't work. That would mean storing the password in clear text ? Not a good idea, at all, please do not make gnome components ever do that. It would be against many company policies and industry regulations anyway. > Fairly much the same as the key escrow option, except that we have to ask > the user for it. > > I have an open mind about how we solve this problem, but I really do think > it needs to be solved *somehow* to give a viable usability experience for > users who come from the Windows world and expect this stuff to Just Work™ I think the simplest path is to make gnome-keyring (or whatever process even a pam module) ask for the old password in those rare cases when the user changes the password on another machine and then logs into their machine with the new password. Password changes are rare, and changes done on another machine also rarer, so asking for the old password when that happens is not bad. of course if it is a machine on which you very rarely log in and/or the ols password was simply forgotten and administratively reset you are screwed. But that screwedness is inherent in the bad idea of gnome-keyring of trying to snatch the password and re-use it. It is bound to fail in edge cases and there is nothing you can do about it (except using an escrow service on a remote server).
The BackupKey Remote Protocol looks like the perfect solution for AD; thanks. All we need is for ecryptfs/gkr/whatever to be able to unlock themselves using *either* the raw password, *or* the secret obtained by this protocol. Let's call it the "recovery secret". And of course, the 'recovery secret' concept doesn't have to be limited to AD. It could even be the old password. Or a "master" password set by the user when the machine is deployed, or a hash of the answers to a set of biographical questions, or a secret obtained by a simple authenticated HTTPS fetch request. In non-AD systems we could use a 'pam_recovery' module which would compare the login password with a stored hash and notice that it's different, then trigger an extra PAM prompt for the (old/master/bio) secret. Or one which could do the HTTP thing. However it's obtained, we just put the recovery secret into a new variable in the PAM stack alongside the login password (clear text, yes. But *within* the PAM stack, and if the PAM stack is compromised you're buggered anyway. See the hoops that pam_ecryptfs and pam_gnome_keyring have to jump through to actually extract it and do something useful with it). And then pam_ecryptfs/pam_gnome_keyring/etc can obtain the recovery secret from there at the same time they're nabbing the login password. I'm not sure how best to handle BKRP. One option is to have a completely separate PAM module which does it, and which has to find the AD server for itself and reimplement a bunch of what already exists in SSSD. (Can SSSD be used as a 'locator' to eliminate some of that?). The other concern with a separate module is that it would make the online/offline determination non-atomic. Instead of "we are online if we can authenticate and obtain the backup key from the BKRP", we end up with a failure mode where authentication *worked* but BKRP fails. The other option is to have pam_sss do it, and just populate the PAM 'recovery secret' variable for itself. A third option remains to push it out to gkr and ecryptfs, and force *each* of them (and anything else with the same requirements) to do the recovery for themselves. But I think putting the recovery secret into a standard location in the PAM stack and configuring it *once* makes a lot more sense.
Integrating this functionality in SSSD makes a lot of sense long term, as SSSD is a privileged process and already has all the information and smarts needed.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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 this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.