Actually got it solved. It wasn't a krb error. I've downgraded pykerberos from 1.2.2 to 1.1 and now it's working.
On 2015-05-15 11:02, Gergely Czuczy wrote: > 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@REALM > > Valid starting Expires Service principal > (...) > 05/15/15 08:41:09 05/16/15 08:31:52 host/$hostname@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@REALM for server > principal host/$hostname@REALM > [17374] 1431680361.378177: Retrieving $user@REALM -> > krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > [17374] 1431680361.378207: Getting credentials $user@REALM -> > host/$hostname@REALM using ccache FILE:/tmp/krb5cc_0 > [17374] 1431680361.378271: Retrieving $user@REALM -> > host/$hostname@REALM from FILE:/tmp/krb5cc_0 with result: 0/Success > [17374] 1431680361.378347: Creating authenticator for $user@REALM -> > host/$hostname@REALM, seqnum 355886755, subkey aes256-cts/EC84, session > key aes256-cts/CA36 > [17374] 1431680361.378694: Decrypted AP-REQ with server principal > host/$hostname@REALM: aes256-cts/FBE1 > [17374] 1431680361.378711: AP-REQ ticket: $user@REALM -> > host/$hostname@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@mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos