OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found

[Matthias Gerstner]

Douglas E. Engert wrote:

> This sounds like our site, AD for the KDCs, and OpenAFS, but we have some
> extra pam routines, pam_afs2 and pam_krb5_ccache, for systems where the vendor's
> pam_krb5 does not know about AFS.

In my case it's part of the infrastructure at my university. We're
running the Kerberos/OpenAFS setup for about three months now on about
100 clients with Gentoo Linux.
On the pam side we use pam_krb5 for authentication and
pam_openafs_session from debian for getting AFS tokens during login.

We're still gaining experience with this setup. It's running
surprisingly stable after a hard time for setting up the whole thing.
Only the OpenSSH issue is causing some headache now.

>>--
>>-bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found)
>>--
>>
> 
> 
> Does the host have a host/<fqdn>@<REALM> principal in the krb5.keytab?

No there's no such keytab entry on the OpenSSH server. Is it needed?

I'm sorry that I'm not too familiar with kerberos as I first began
working with it related to the mentioned infrastructure setup.

I didn't think that there's needed any additional kerberos setup /
communication when wanting to login via a ssh server.

>>Also the variable KRB5CCNAME isn't defined. I've investigated about this
>>problem already on the net and tried different setups and approaches but
>>to no avail. I need the kerberos5 ticket for use of OpenAFS.
>>
> 
> 
> DOes it write it to some other location?

I don't see a trace of the kerberos ticket. klist does not recognize
anything. The only thing I can imagine is that OpenSSH is keeping the
ticket in memory as I've read in some older postings on the net.

And there have also been discussed issues about the KRB5CCNAME
environment variable being defined too late in the pam processing when
using OpenSSH. But this postings are mostly rather old and I guess these
problems are fixed in the meantime.

But my problem may be somehow similar to the before mentioned ones.

> Yes it is critical. It is an authorization check that says this
> user principal is allowed to use this local unix account.
> 
> It looks at the ~/.k5login and the  krb5.conf  [realm] auth_to_local
> variables to do test the mapping.
> 
> By default, if the kerberos principal is user at realm  and the local account
> is username and user == username  and realm == default-realm-of-host,
> then krb5_kuserok does not need to check the .k5login.
> 
> (With AD the realm is the uppercase of the AD domain name, fully qualified)

These conditions all apply to my setup. The AD domain name is the
default realm in krb5.conf and unix usernames are the same as the
kerberos usernames.

krb5.conf:
--
[libdefaults]
	default_realm = SOME.DOMAIN.DE
[,,,]

kinit in66666
Password for in66666 at SOME.DOMAIN.DE
[...]

id in66666
uid=66666(in66666) [...]

So everything should be allright with krb5_kuserok ...

Thanks so far,

Matthias Gerstner