Hide Forgot
Description of problem: I have a Windows Active Directory that I am trying to authenticate against with either pam_krb5 or pam_winbind. Both fail with similar Kerberos errors, so I'll only discuss pam_krb5 for now for simplicity. I have followed all the instructions I can find on the subject and the advice from various mailing lists and believe something is not working as advertised. I used samba with use kerberos keytab = yes to join the domain and create /etc/krb5.keytab. This worked fine, and kinit works fine. I can access fileshares via Kerberos and can use gssftp and ktelnet off my local machine with Kerberos ticket authentication. However, login via anything using PAM -- like ssh or gdm -- fails. The PAM auth section works fine, but the PAM account section fails on the line: account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so If I comment this line out, login proceeds fine with Kerberos ticket authentication. The user I am trying to login as exists in /etc/passwd and has password set to "*" in /etc/shadow. ~user contains a .k5login. Version-Release number of selected component (if applicable): pam_krb5-2.1.2-1 krb5-devel-1.3.6-2 krb5-libs-1.3.6-2 krb5-workstation-1.3.6-2 samba-common-3.0.10-1.fc3 samba-client-3.0.10-1.fc3 How reproducible: Always Steps to Reproduce: 1. setup authconfig for Kerberos. 2. Use samba "net ads join" to join domain, create /etc/krb5.keytab -- works fine 3. kinit and "smbclient -k '\\server\share'" -- works fine 4. ssh localhost, login at gdm, etc. -- fails I have removed /var/cache/samba/*, /etc/samba/*.tdb and /etc/rb5.keytab and tried "net ads join" many times. "net ads join"; does not report any errors (completely clean). Actual Results: Login via ssh with pam_krb5: Jan 4 17:39:54 fedora sshd[8761]: Authorized to user, krb5 principal user@COMPANY.COM (krb5_kuserok) Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: configured realm 'COMPANY.COM' Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flags: forwardable Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: no ignore_afs Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: user_check Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: no krb4_convert Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: warn Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: ticket lifetime: 36000 Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: renewable lifetime: 36000 Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: banner: Kerberos 5 Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: ccache dir: /tmp Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: keytab: /etc/krb5.keytab Jan 4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: authenticating 'user@COMPANY.COM' to 'krbtgt/COMPANY.COM@COMPANY.COM' Jan 4 17:39:56 fedora sshd[8761]: pam_krb5[8761]: krb5_get_init_creds_password(krbtgt/COMPANY.COM@COMPANY.COM) returned -1765328360 (Preauthentication failed) Jan 4 17:39:56 fedora sshd[8761]: pam_krb5[8761]: pam_acct_mgmt returning 7 (Authentication failure) Expected Results: Should succeed with system-auth as configured by authconfig. Additional info: /etc/krb5.conf: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = COMPANY.COM dns_lookup_realm = false dns_lookup_kdc = true default_tgs_enctypes = rc4-hmac default_tkt_enctypes = rc4-hmac permitted_enctypes = rc4-hmac [realms] COMPANY.COM = { } [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } /etc/krb5.keytab: Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 14 01/04/05 00:14:27 host/fedora.company.com@COMPANY.COM 14 01/04/05 00:14:30 cifs/fedora.company.com@COMPANY.COM 14 01/04/05 00:14:25 fedora$@COMPANY.COM 14 01/04/05 00:14:25 FEDORA$@COMPANY.COM 14 01/04/05 00:14:26 host/fedora@COMPANY.COM 14 01/04/05 00:14:26 host/FEDORA@COMPANY.COM 14 01/04/05 00:14:27 host/FEDORA.company.com@COMPANY.COM 14 01/04/05 00:14:28 HOST/fedora@COMPANY.COM 14 01/04/05 00:14:28 HOST/FEDORA@COMPANY.COM 14 01/04/05 00:14:29 HOST/fedora.company.com@COMPANY.COM 14 01/04/05 00:14:29 HOST/FEDORA.company.com@COMPANY.COM 14 01/04/05 00:14:29 cifs/fedora@COMPANY.COM 14 01/04/05 00:14:30 cifs/FEDORA@COMPANY.COM 14 01/04/05 00:14:31 cifs/FEDORA.company.com@COMPANY.COM 14 01/04/05 00:14:31 CIFS/fedora@COMPANY.COM 14 01/04/05 00:14:32 CIFS/FEDORA@COMPANY.COM 14 01/04/05 00:14:32 CIFS/fedora.company.com@COMPANY.COM 14 01/04/05 00:14:33 CIFS/FEDORA.company.com@COMPANY.COM /etc/samba/smb.conf: [global] workgroup = COMPANYNT realm = COMPANY.COM security = ads use kerberos keytab = yes /etc/pam.d/system-auth: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so ~user/.k5login: user@COMPANY.COM
The problem is due to an IMHO invalid attempt by pam_krb5 to perform account validation if the user was not authenticated by pam_krb5. When using with sshd via GSSAPI, sshd performs the authentication and .k5login account validation before passing the user off to PAM for any additional authorization and session tasks. pam_krb5 thus is not called for PAM authentication. As a result, when it gets to performing PAM account validation, it doesn't know whether or not it should do anything. Not wanting to do nothing, pam_krb5 tries to determine if the user has a Kerberos account -- the logic being that if the user has a Kerberos account, probably that is what the user authenticated with, and therefore pam_krb5 can go ahead and perform the account validation tasks. It does so by authenticating on the Kerberos server with the user's principal but a garbage password. This is supposed to fail with KRB5KDC_ERR_PREAUTH_FAILED if a user has an account but has the wrong password, but because Active Directory requires preauthentication, when done against a Windows KDC it instead fails with KRB5KDC_ERR_PREAUTH_FAILED. This causes PAM account validation to fail, and the whole user login fails. If pam_krb5 didn't authenticate the user, then I am very confused as to why it is attempting to authorize the user. Not only does the existing code make some strong assumptions about how the Kerberos server will behave in this scenario, but it slows down login by the time taken to do the garbage authenticate (possibly significant on the WAN), and unnecessarily generates logon errors on both the local system and the KDC. I attached a proposed patch, which simply returns PAM_USER_UNKNOWN if pam_krb5 didn't originally authenticate the user. This allows pam_krb5 to interoperate properly when a Kerberos-aware service performs the authentication, it works with the existing system-auth generated by authconfig, and is consistent with the old pam_krb5-1.3 behaviour.
Created attachment 109550 [details] patch to acct.c to fix PAM account behaviour when pam_krb5 did not authenticate the user
Ah, this has been dogging my organization for some time now, with AD logins+NIS. Interestingly enough, commenting out the line specified above (account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so) also fixes the fact that the RedHat ES 4 build we have wasn't running user crontabs. Logs looked like: Mar 15 16:54:01 SERVERNAME crond[31156]: Authentication failure After the change, worked like a charm. This also allows 'su [username]' to work again, whereas before I had to use 'ksu [username]' to su out of root to a normal user. This may also have been our problem with logging into dovecot's POP/IMAP, but that test machine isn't alive anymore so I can't confirm. Either way, it's looking to be like Evan Champion above is on the right track.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Fedora Core 3 is not maintained anymore. If you can reproduce this bug in Fedora 7 or 8 please reopen this bug.