Home / server / Questions / 393989
Accepted
PhilR
Asked: 2012-05-31 06:39:40 +0800 CST

How to deny access to disabled AD accounts via kerberos in pam_krb5?

  • 772

I have a working AD/Linux/LDAP/KRB5 directory and authentication setup, with one small problem. When an account is disabled, SSH publickey authentication still allows user login.

It's clear that kerberos clients can identify a disabled account, as kinit and kpasswd return "Clients credentials have been revoked" with no further password / interaction.

Can PAM be configured (with "UsePAM yes" in sshd_config) to disallow logins for disabled accounts, where authentication is done by publickey? This doesn't seem to work:

account     [default=bad success=ok user_unknown=ignore] pam_krb5.so

Please don't introduce winbind in your answer - we don't use it.

linux active-directory kerberos pam

3 Answers

  1. I have read elsewhere other people asking for SSH to be "fixed" so that locked accounts can’t be logged into via SSH. (see Debian bug 219377) This request got rejected as a patch "because it breaks some expectations from users [who were] used to passwd -l only locking the passwd." (see Debian bug 389183) e.g. some people WANTED to be able to lock accounts from password logins, but still allow SSH key access.

    PAM will not deny SSH key authentication to accounts which have just been locked (e.g. due to invalid password attempts, because SSH key authentication is designed to not pay any attention to the password field, which is where accounts are usually locked from.)

    I understand that the password hash entry is implicitly checked at pam_authenicate() time, not at pam_acct_mgmt() time. pam_unix.so pam_sm_acct_mgmt() doesn't check the password hash at all, and pam_authenticate() is not called during public key authentication.

    If your intention is to be able to centrally disable accounts from logging in, there are other possible workarounds, including:

    Changing the login shell.

    (re)moving their authorized_keys file.

    Another option for denying access could be some use of DenyGroups or AllowGroups in the sshd_config. (then adding the user to a "sshdeny" group, or removing them from an "sshlogin" group to disable them from logging in.) ( read here: https://help.ubuntu.com/8.04/serverguide/user-management.html )

    From http://web.archiveorange.com/archive/v/67CtqEoe5MhDqkDmUMuL I read: "The problem is pam_unix checks just the expiration dates of the shadow entry, not the password hash field contents." If this is true, would expiring the account rather than locking it do what you need?

    The answer to your question is possibly "yes, if you're disabling them somewhere other than the password field"

    • 4
  2. Best Answer

    Did some more homework, and am answering my own question.

    In RedHat's pam_krb5 (pam_krb5-2.3.14-1/src/acct.c), unless the module participated in the authentication stage, the pam_sm_acct_mgmt() function returns either PAM_IGNORE or PAM_USER_UNKNOWN depending on the module config. It would therefore require changes to the pam_krb5 code to do what I want.

    JohnGH's answer is a good workaround; using "proxy" attributes to convey the same meaning, such as breaking the shell or adding to a "disabled-users" group.

    Another workaround (partially tested) is to set an account expiry date in the past, and use a module such as pam_unix to fail the account checks. This uses LDAP, rather than KRB5, but queries against the same centrally-managed user directory.

    • 4

  3. SSH key based authentication is independent of PAM. You have the following solutions:

    • disable keybased authentication in sshd_config
    • change and recompile sshd and add a hook so that keybased auth will check also if the account is valid via pam.

    If you want to use passwordless login via kerberos, you must make sure that:

    • you are not using pam for sshd
    • you have kerberos properly configured. E.g. you can do kinit -k host/server1.example.com@DOMAIN

    • you sshd is configured to use gssapi:

      KerberosAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM no

    • you use a kerberized ssh client like PuTTY v0.61 or newer.

    • 2