There is a generic issue when logging in to a system using a new password after it's been changed on the network.

The problem is that local tools like gnome-keyring or ecryptfs may need to be unlocked using the *old* password; the new password is useless to them.

They hook into the PAM 'password' stack to get notified of password changes and change their own encryption accordingly. But that obviously doesn't work if the password is changed externally, on the network.

My plan is to fix them to support a *secondary* decryption key, which can be obtained through other means. We can add a new item type PAM_RECOVERY_AUTHTOK to the PAM stack, and they find their secondary decryption key there.

For the simple case of stuff like NIS logins, the 'recovery authtok' can be the *old* password. We can handle that with a prompt from the pam_ccreds module.

But for AD logins there's a nicer solution: when logging in with pam_winbind and the password doesn't match the previously-cached one, also perform a BKRP recovery and provide its result in PAM_RECOVERY_AUTHTOK for ecryptfs/gkr to use.

And Lo! — we now have local encryption working properly without password-sync issues, even when the password gets changed externally.

tl;dr: Please start by implementing 'net rpc bkrp' to "backup" and restore keys from the command line or through library calls. We can worry about hooking it up to PAM later...

The BackupKey Remote Protocol:
http://msdn.microsoft.com/en-us/library/cc224123.aspx