I have a working Kerberos authentication tested with kinit on Debian Buster. Now I try to use it with PAM for login with Kerberos and installed libpam-krb5 and configured it with pam-auth-update. But the documentation in /usr/share/doc/libpam-krb5/README.Debian.gz noted:

This configuration will still require that users be listed in /etc/shadow, since otherwise the pam_unix account module will fail. Normally, accounts that should only use Kerberos authentication should be created with adduser --disabled-password. If you don't want the accounts to be listed in /etc/shadow at all (if, for example, you're using some other source than files for your nsswitch configuration), you can mark the pam_krb5 account module as sufficient rather than required so that pam_unix isn't run. This will mean that you won't be able to disable accounts locally.

I don't want the accounts to be listed locally in /etc/shadow again in addition to the Kerberos Database because it is redundant work for me. I tried a login with the default setup and get this failure:

Debian GNU/Linux 10 deb10-base ttyS0

deb10-base login: ingo

Authentication failure

In journalctl I find to this:

Oct 06 15:33:08 deb10-base login[374]: pam_krb5(login:auth): user ingo authenticated as [email protected]
Oct 06 15:33:08 deb10-base login[374]: pam_unix(login:account): could not identify user (from getpwnam(ingo))
Oct 06 15:33:08 deb10-base login[374]: Authentication failure

That is exactly expected from the quoted documentation above. But I don't understand the comment where and what to modify the PAM configuration files. The current configuration files does not match the documentation.

What entry in what PAM configuration file I have to modify from required to sufficient? Are there maybe other things to do? If possible I would like to preserve the pam-auth-update config sections.

Forgot to mention that I started pam-auth-update and checked the options:

[*] Kerberos authentication
[*] Unix authentication
[*] Create home directory on login

I tried to uncheck "Unix authentication" but that makes the login unusable. I wasn't able to login again, even not as root. I had to recover from a snapshot.

  • It would help to show what have you already changed in PAM. Oct 6, 2019 at 15:55
  • @RuiFRibeiro I do not have modified anything in PAM from the default setup. Would it help if I paste the most important files from `/etc/pam.d/'?. It is a lot of stuff and it is default...
    – Ingo
    Oct 6, 2019 at 16:00
  • @RuiFRibeiro Not completely correct. I have updated the question at the end.
    – Ingo
    Oct 6, 2019 at 16:37

2 Answers 2


I can see two imperfect options here:

  • modify the generated block of /etc/pam.d/common-account and accept that pam-auth-update won't touch it anymore, or
  • dpkg-divert and modify /usr/share/pam-configs/krb5, regenerate /etc/pam.d/common-account and accept that updates of libpam-krb5 won't affect /usr/share/pam-configs/krb5 anymore.

In the first case, change required to sufficient on the line

account required pam_krb5.so minimum_uid=1000

In the second case, do the same in the Account: paragraph, which should result in the above change in /etc/pam.d/common-account after regenerating it.

  • First Option doesn't help. It doesn't change anything. For the second option I modified /usr/share/pam-configs/krb5 but when executing sudo dpkg-divert I get dpkg-divert: error: --add needs a single argument.
    – Ingo
    Oct 8, 2019 at 8:21
  • Does pam_krb5.so precede pam_unix.so in common-account? I'm hesitant to suggest concrete changes, because we're dealing with security here: PAM is a complicated beast and it's easy to inadvertently open up systems by misconfiguring it. Oct 8, 2019 at 8:41
  • Yes, you are right. Seems it's a general problem with authorization. I have made an answer. Thanks for your effort. +1, it helped me to get into the right direction.
    – Ingo
    Oct 8, 2019 at 21:42

After some more research I have found that it seems to be a general problem only having authentication with Kerberos. You get only authentication but no authorization. Authorization in this case is given by local accounts with password disabled. So you have to manage additional local accounts if you do not provide accounts from another source.

With NSS you can get accounts from a remote source, in particular from a LDAP server. This way login will always find an account for authorization, either from the LDAP server or from the local /etc/passwd file, mainly for system accounts like root. I only have to manage accounts at one place on the LDAP server.

I'm just going to setup a LDAP server for accounting.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .