Broken auth, LDAP dbargs stopped working

[Gergely Czuczy]

Most of these turned out to be an LDAP syncrepl issue, which solved many 
of the problems. After a reboot, the "wrong principal in request" 
message also disappeared, however it's still not clear what caused this 
error message.

What remains is the following, when I'm trying to authenticate to a 
service, but now ssh works:
(('Unspecified GSS failure.  Minor code may provide more information', 
851968), ('Success', 100001))

I'm running pykerberos's test.py, when having an initialized user principal:
python test.py -s host@`hostname` gssapi
It's reading the princ from /etc/krb5.keytab

I've traced it back to pykerberos1.2.2's (github has 1.1.2 FYI) 
src/kerberosgss.c:644, it's a call to gss_accept_sec_context() in 
authenticate_gss_server_step(), which returns 851968/100001 for the 
major/minor code.

Anyone has any idea where to dig, and what to look for to get this 
sorted out? This error message seems kinda strange.

The KVNOs are all right, DNS forward+reverse is matches and working 
properly, I can init with the keytabs, and after such a test, I can see 
the SPN showing up in klist:
# klist
Default principal: user at REALM

Valid starting     Expires            Service principal
(...)
05/15/15 08:41:09  05/16/15 08:31:52  host/$hostname at REALM

When setting KRB5_TRACE, it writes the following:
[17374] 1431680361.377998: ccselect module realm chose cache 
FILE:/tmp/krb5cc_0 with client principal $user at REALM for server 
principal host/$hostname at REALM
[17374] 1431680361.378177: Retrieving $user at REALM -> 
krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from 
FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[17374] 1431680361.378207: Getting credentials $user at REALM -> 
host/$hostname at REALM using ccache FILE:/tmp/krb5cc_0
[17374] 1431680361.378271: Retrieving $user at REALM -> 
host/$hostname at REALM from FILE:/tmp/krb5cc_0 with result: 0/Success
[17374] 1431680361.378347: Creating authenticator for $user at REALM -> 
host/$hostname at REALM, seqnum 355886755, subkey aes256-cts/EC84, session 
key aes256-cts/CA36
[17374] 1431680361.378694: Decrypted AP-REQ with server principal 
host/$hostname at REALM: aes256-cts/FBE1
[17374] 1431680361.378711: AP-REQ ticket: $user at REALM -> 
host/$hostname at REALM, session key aes256-cts/CA36
[17374] 1431680361.379501: Negotiated enctype based on authenticator: 
aes256-cts
[17374] 1431680361.379515: Authenticator contains subkey: aes256-cts/EC84

So, what should I be looking for, when the minor code is a success?

On 2015-05-13 16:02, Gergely Czuczy wrote:
> Hello,
>
> I have an installation of MIT Kerberos with an OpenLDAP backend, on CentOS6:
> krb5-devel-1.10.3-37.el6_6.x86_64
> krb5-workstation-1.10.3-37.el6_6.x86_64
> krb5-server-ldap-1.10.3-37.el6_6.x86_64
> krb5-server-1.10.3-37.el6_6.x86_64
>
> And starting of today, for some unknown reason, it started misbehaving.
> First was, one of the boxes refuses kerberos authentication, getting the
> following error message:
> (('Unspecified GSS failure.  Minor code may provide more information',
> 851968), ('Success', 100001))
> A couple of times, I also got "Wrong principal in request" for the minor
> code, however at this very moment, I cannot reproduce that one.
>
> This is a web application, which worked yesterday. Also, ssh with GSSAPI
> auth works all over the boxes, except for this one, it always falls back
> to PAM.
>
> What's also strange is, I've used to store the principals of users and
> hosts in LDAP, in their respective entries, under
> ou=(users,hosts),dc=..., respectively. Now, whenever I do an addprinc
> with -x dn=$dn, the principal is getting added, but it's not showing up
> under the entity's LDAP entry.
>
> Clock is in sync, the DNS entries back and forward are properly done.
>
> I'm at a loss, I'm running out of ideas where to look for. Could someone
> please give me a couple of suggestions, where and what to look for? This
> stuff used to work, but for some unknown reason it stopped working.
> krb5kdc.log and kadmin.log are silent of any errors, as I've checked.
>
> Thanks in advance,
> Gergely
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos