Bug 144064
Summary: | Kerberos PAM login fails with Windows KDC | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Evan Champion <evanchampion> | ||||
Component: | pam_krb5 | Assignee: | Nalin Dahyabhai <nalin> | ||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3 | CC: | mark, mattdm, tmraz | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-02-03 22:14:33 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Evan Champion
2005-01-04 10:31:40 UTC
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. |