Broken auth, LDAP dbargs stopped working
gergely.czuczy at harmless.hu
Fri May 15 05:02:18 EDT 2015
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
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
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:
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:
 1431680361.377998: ccselect module realm chose cache
FILE:/tmp/krb5cc_0 with client principal $user at REALM for server
principal host/$hostname at REALM
 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
 1431680361.378207: Getting credentials $user at REALM ->
host/$hostname at REALM using ccache FILE:/tmp/krb5cc_0
 1431680361.378271: Retrieving $user at REALM ->
host/$hostname at REALM from FILE:/tmp/krb5cc_0 with result: 0/Success
 1431680361.378347: Creating authenticator for $user at REALM ->
host/$hostname at REALM, seqnum 355886755, subkey aes256-cts/EC84, session
 1431680361.378694: Decrypted AP-REQ with server principal
host/$hostname at REALM: aes256-cts/FBE1
 1431680361.378711: AP-REQ ticket: $user at REALM ->
host/$hostname at REALM, session key aes256-cts/CA36
 1431680361.379501: Negotiated enctype based on authenticator:
 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:
> I have an installation of MIT Kerberos with an OpenLDAP backend, on CentOS6:
> 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,
> Kerberos mailing list Kerberos at mit.edu
More information about the Kerberos