Rafal Pietrak <ra...@ztk-rp.eu> writes: > I did attempt that, but without success.
> When I swapped krb5 entry with unix entry in common-password, nothing > changes. When I did that in common-auth I've go "bad password" response > from sudo command. You want common-auth, not common-password. Are you sure that you're using the password in the local system /etc/shadow and that you've set the pam_unix module as sufficient so that pam_krb5 doesn't run if it succeeds? You want something like: auth sufficient pam_unix.so auth required pam_krb5.so try_first_pass minimum_uid=1000 You may also have to change the account stack -- I don't recall off-hand. > 1. provided, full fix is impossible due to its complexity, and a "hinted > solution" does not work on first go ... may be an additional README > coming with binary package would be doable. It would be great to have tested documentation for how to do this, but I'm not sure it's in the scope for a specific PAM module. It's more of a general PAM configuration question of how to stack multiple authentication modules. (I'm also extremely short on resources to even maintain the basic module functionality, so can't promise much contribution on the more general PAM configuration front.) > 2. then again... may be it would be good to make the order that actually > dos work and does not make those problems should be the default debian > installation - may be this could be changed? Most people using a Kerberos PAM module expect Kerberos to be tried first since authentication that doesn't give them Kerberos tickets may not be normally usable, and are using pam_unix only for root passwords and similar local fallbacks. So things are currently set up for the typical use case. > I'm pushing this a little, because it may be mo more common problem that > currently perceived. Pls consider todays everyday situation of laptops > and other portables getting to sleep mode and awakening somewhere else > where (time consuming) network reconnect is due. So at leas some > unnecesary delay will happen when the new connectivity is only partially > set up. Unless carefully configured to not be the default authentication option, and honestly even then, a Kerberos PAM module is not a good configuration for systems that have spotty network connectivity. Have you considered removing the PAM module entirely, using local system authentication, and running kinit when you want Kerberos tickets? That's what I do. Even if you don't want to do that for general system login, you can definitely do that for sudo. Another possible approach would be to use sssd, which is a more complex system that does local caching of the Kerberos authentication credentials and is designed specifically to handle this use case. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
