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
user ccache file is not created during login.
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.
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
(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.
> 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
(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).
> 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
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
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
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
Marcus, can you check if the packages listed in comment #10 fix the problem on your system?
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
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.
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.
This issue is still a serious problem for RHEL 5 systems. Will there be a backport of the fix to this release?