This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 563442

Summary: user disallowed by .k5login file
Product: [Fedora] Fedora Reporter: Marcus Moeller <marcus.moeller>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: andrew, nalin
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: pam_krb5-2.3.7-3.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-24 19:28:48 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Marcus Moeller 2010-02-10 03:50:18 EST
Description of problem:

I have set up pam krb5 authentication with nss_ldap, using the following gssapi parameters in ldap.conf:

# Activate SASL
use_sasl on
#Service acount nssldap for active directory access
sasl_authid nssldap/mydomain
rootsasl_auth_id nssldap/mydomain
rootuse_sasl yes

getent works fine as root.

While trying to log in as LDAP user, i got the following error messages:

login: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_$UID' not found) 

so I guess the credential file is not created correctly.

Here is an output of /var/log/secure during login:

Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: debug
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flags:
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: no ignore_afs
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: no null_afs
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: user_check
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: no krb4_convert
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: krb4_convert_524
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: krb4_use_as_req
Feb 10 09:37:41 localhost login: pam_krb5[1741]: will try previously set password first
Feb 10 09:37:41 localhost login: pam_krb5[1741]: will let libkrb5 ask questions
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: no use_shmem
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: no external
Feb 10 09:37:41 localhost login: pam_krb5[1741]: flag: warn
Feb 10 09:37:41 localhost login: pam_krb5[1741]: ticket lifetime: 36000s (0d,10h,0m,0s)
Feb 10 09:37:41 localhost login: pam_krb5[1741]: renewable lifetime: 604800s (7d,0h,0m,0s)
Feb 10 09:37:41 localhost login: pam_krb5[1741]: banner: Kerberos 5
Feb 10 09:37:41 localhost login: pam_krb5[1741]: ccache dir: /tmp
Feb 10 09:37:41 localhost login: pam_krb5[1741]: ccname template: FILE:%d/krb5cc_%U_XXXXXX
Feb 10 09:37:41 localhost login: pam_krb5[1741]: keytab: FILE:/etc/krb5.keytab
Feb 10 09:37:41 localhost login: pam_krb5[1741]: token strategy: v4,524,2b,rxk5
Feb 10 09:37:41 localhost login: pam_krb5[1741]: called to authenticate '$USER', realm '$DOMAIN'
Feb 10 09:37:41 localhost login: pam_krb5[1741]: authenticating '$USER@$DOMAIN'
Feb 10 09:37:41 localhost login: pam_krb5[1741]: trying previously-entered password for '$USER', allowing libkrb5 to prompt for more
Feb 10 09:37:41 localhost login: pam_krb5[1741]: authenticating '$USER@$DOMAIN' to 'krbtgt/$DOMAIN@$DOMAIN'
Feb 10 09:37:41 localhost login: pam_krb5[1741]: krb5_get_init_creds_password(krbtgt/$DOMAIN@$DOMAIN) returned 0 (Success)
Feb 10 09:37:41 localhost login: pam_krb5[1741]: got result 0 (Success)
Feb 10 09:37:42 localhost login: nss_ldap: failed to bind to LDAP server ldap://$DOMAIN/: Local error
Feb 10 09:37:42 localhost login: nss_ldap: could not search LDAP server - Server is unavailable
Feb 10 09:37:42 localhost login: pam_krb5[1741]: account checks fail for '$USER@$DOMAIN': user disallowed by .k5login file for '$USER'
Feb 10 09:37:42 localhost login: pam_krb5[1741]: authentication fails for '$USER' ($USER@$DOMAIN): Permission denied (Success)
Feb 10 09:37:42 localhost login: pam_krb5[1741]: pam_authenticate returning 6 (Permission denied)

The user does not have a homedir (should be created using pam_mkhomedir), so I wonder why it complains about a .k5login file.

Also, I had to disable SELinux as otherwise I got the following error messages:

setroubleshoot: SELinux is preventing /bin/login "lock" access on /tmp/krb5cc_0

Best Regards
Marcus
Comment 1 Marcus Moeller 2010-02-10 05:08:32 EST
user ccache file is not created during login.
Comment 2 Nalin Dahyabhai 2010-02-10 11:55:02 EST
Generally speaking, this won't work -- pam_krb5 (reassigning to that component) assumes the user's ID to read .k5login, mainly to avoid problems with NFS root squashing.  At that point, without a usable credential cache around (it's still doing an authorization check here, so it hasn't created one yet), it loses the ability to look up the location of the user's home directory and krb5_kuserok() returns a failure.

The module could probably add an option to create a temporary ccache that would be accessible to the user for the duration of the krb5_kuserok() call.  I'm on the fence about whether or not it should be a default setting, because even though it'll be slower, I can see it being needed for users with NFS home directories which are accessed using RPCSEC_GSS.
Comment 3 Marcus Moeller 2010-02-10 12:58:23 EST
Hi Nalin,

I have already tried to create a home directory for that user in advance, even with a .k5login file. I am not sure if the main problem is that no credential file is created at all, as if I create one for this specific user from root account, login is possible.

Also please note, that exactly the same setup worked fine on RHEL 5
Comment 4 Nalin Dahyabhai 2010-02-10 13:19:20 EST
(In reply to comment #3)
> Hi Nalin,
> 
> I have already tried to create a home directory for that user in advance, even
> with a .k5login file. I am not sure if the main problem is that no credential
> file is created at all, as if I create one for this specific user from root
> account, login is possible.

If supplied with credentials for the user, when pam_krb5 drops privileges, it'd still able to look up the location of the user's home directory, so .k5login could allow or deny access (note that by default, if a .k5login file exists, the user's principal name has to be listed in it in order for access to be allowed -- it's not implicit).  If the lookup fails, krb5_kuserok() unconditionally returns a failure, and pam_krb5 interprets that as an indication that access should be denied.

> Also please note, that exactly the same setup worked fine on RHEL 5    

The version of pam_krb5 in RHEL5 doesn't switch to the user's privileges (that was added around 2.2.22), so credentials for the root user would have been accessible, and I expect that this case would have succeeded.
Comment 5 Marcus Moeller 2010-02-10 14:17:09 EST
> If supplied with credentials for the user, when pam_krb5 drops privileges, it'd
> still able to look up the location of the user's home directory, so .k5login
> could allow or deny access (note that by default, if a .k5login file exists,
> the user's principal name has to be listed in it in order for access to be
> allowed -- it's not implicit).  If the lookup fails, krb5_kuserok()
> unconditionally returns a failure, and pam_krb5 interprets that as an
> indication that access should be denied.

Hmm, strange. The user home is queried via LDAP and located at /nas/$USER. I have created this directory and added a .k5login file with the content you mentioned. The error message still occurs.

And what about if the home dir does not exist yet (e.g. should be created with pam_mkhomedir)?

Is there perhaps a way to debug the procedure? 

Best Regards
Marcus
Comment 6 Nalin Dahyabhai 2010-02-10 14:36:54 EST
(In reply to comment #5)
> > If supplied with credentials for the user, when pam_krb5 drops privileges, it'd
> > still able to look up the location of the user's home directory, so .k5login
> > could allow or deny access (note that by default, if a .k5login file exists,
> > the user's principal name has to be listed in it in order for access to be
> > allowed -- it's not implicit).  If the lookup fails, krb5_kuserok()
> > unconditionally returns a failure, and pam_krb5 interprets that as an
> > indication that access should be denied.
> 
> Hmm, strange. The user home is queried via LDAP and located at /nas/$USER. I
> have created this directory and added a .k5login file with the content you
> mentioned. The error message still occurs.

Is there a credential cache available for the user when you do this?  I believe the key difference is whether or not a process running as the user has access to the credential cache, which it will need in order to contact the directory server to look up information about the user.  When that fails, the code won't even be able to check if the directory exists; it'll just give up.

> And what about if the home dir does not exist yet (e.g. should be created with
> pam_mkhomedir)?
> 
> Is there perhaps a way to debug the procedure?

Passively, it's either debug statements in pam_krb5 or nss_ldap (whether or not there's a cred cache available, what UID the process is running under at that moment).  Otherwise, you'd have to attach to the process with a debugger (I tend to use 'login' for this sort of thing -- either at the console or via 'telnet localhost' -- as it doesn't have to spend time dealing with windowing systems or the privilege separation logic that sshd does).
Comment 7 Marcus Moeller 2010-02-10 14:51:23 EST
> Is there a credential cache available for the user when you do this?  I believe
> the key difference is whether or not a process running as the user has access
> to the credential cache, which it will need in order to contact the directory
> server to look up information about the user.  When that fails, the code won't
> even be able to check if the directory exists; it'll just give up.

LDAP is set up to use GSSAPI/SASL. A ticket for the nnslap user is received via cron from root account (using keytab) and stored in /tmp/krb5cc_0.

getent works fine as root.

username lookup also works (from what ldap debug says) but the users cc is not created during login so the rest fails.

Best Regards
Marcus
Comment 8 Marcus Moeller 2010-02-11 08:04:24 EST
Little update:

Had to add:

krb5_ccname FILE:/tmp/krb5cc_0

to ldap.conf (thought this was default) and chmod 644 /tmp/krb5cc_0

What still exists is that SELinux prevents access to this file. Is there perhaps a special file context that could be used, and/or could the policy be updated?

Best Regards
Marcus
Comment 9 Fedora Update System 2010-03-08 17:34:51 EST
pam_krb5-2.3.11-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/pam_krb5-2.3.11-1.fc13
Comment 10 Fedora Update System 2010-03-08 18:07:15 EST
pam_krb5-2.3.7-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/pam_krb5-2.3.7-3.fc12
Comment 11 Nalin Dahyabhai 2010-03-08 18:16:42 EST
Marcus, can you check if the packages listed in comment #10 fix the problem on your system?
Comment 12 Fedora Update System 2010-03-10 01:46:11 EST
pam_krb5-2.3.7-3.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pam_krb5'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/pam_krb5-2.3.7-3.fc12
Comment 13 Fedora Update System 2010-03-23 20:45:51 EDT
pam_krb5-2.3.11-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2010-03-24 19:28:43 EDT
pam_krb5-2.3.7-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Andrew Meredith 2012-09-05 12:57:08 EDT
This issue is still a serious problem for RHEL 5 systems. Will there be a backport of the fix to this release?