Broken auth, LDAP dbargs stopped working

Gergely Czuczy gergely.czuczy at harmless.hu
Fri May 15 05:28:33 EDT 2015


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 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
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos



More information about the Kerberos mailing list