Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?
Thanks for the help, when I looked at the output, it contained mech 1.3.6.1.5.2.5 which I guess is GSS_IAKERB_MECHANISM ... Looking into that I think I had a somewhat similar problem to this: http://stackoverflow.com/questions/23759016/spnego-kerberos-no-credential-found-error-with-requests-from-linux-client But it wasn't a problem with my reverse dns - that was set up properly, but the problem was some errant capitalization of the service principal in the kdc database. When I looked at the wireshark output I saw that it was the TGS-REQ was failing with an "UNKNOWN_SERVER" error, and looking into that a bit more I realized I had a problem with the name. When using AD I had had a SPN with CamelCase and that hadn't caused a problem, but with the MIT KDC it did, which was a stupid problem that I should've figured out. Thanks for your help :) Thanks, Jordan Weitman-Soet Safer Payments Software Developer Phone: 1-778-327-7338 | Tie-Line: 3177338 | Mobile: 1-778-867-5683 E-mail: jordan.s...@ca.ibm.com 1190 Homer St Suite 401 Vancouver, BC V6B 2X6 Canada From: Rick van Rein <r...@openfortress.nl> To: Jordan Soet/CanWest/IBM@IBMCA Cc: kerberos@mit.edu Date: 08/27/2016 05:03 AM Subject:Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication? Hi Jordan, > I looked into it, but my negotiate messages look like this: > > "Negotiate YIID..." which I think means that they're kerberos messages? You should base64-decode it [Section 4.1 of RFC 4559] and dump that as GSSAPI content which, at least in this early phase, is DER-encode. You should make a dump of the decoded binary content with a tool like "openssl asn1parse" with a few layout options or, for much more/better information, with my Python script on https://github.com/vanrein/hexio/blob/master/derdump There will be a number of OIDs to signal content following; these you can lookup on duckduckgo.com. You should see a general offer packet providing the available mechanisms, followed by one that it takes a proactive guess it -- normally Kerberos. If you're still confused, you could also try sending the output here. -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?
Hi Jordan, > I looked into it, but my negotiate messages look like this: > > "Negotiate YIID..." which I think means that they're kerberos messages? You should base64-decode it [Section 4.1 of RFC 4559] and dump that as GSSAPI content which, at least in this early phase, is DER-encode. You should make a dump of the decoded binary content with a tool like "openssl asn1parse" with a few layout options or, for much more/better information, with my Python script on https://github.com/vanrein/hexio/blob/master/derdump There will be a number of OIDs to signal content following; these you can lookup on duckduckgo.com. You should see a general offer packet providing the available mechanisms, followed by one that it takes a proactive guess it -- normally Kerberos. If you're still confused, you could also try sending the output here. -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?
On Thu, 25 Aug 2016, JSoet wrote: > Hi, I'm implementing SPNEGO & Kerberos authentication in our application's > webserver code and have it working fine when the KDC is Active Directory. > I'm now testing it with an MIT KDC instance and when I attempt to > authenticate a user who has a ticket from that KDC I get a > GSS_S_CONTINUE_NEEDED status when I call gss_accept_sec_context... > > My understanding was that this couldn't happen for kerberos authentication > though, and the GSS_S_CONTINUE_NEEDED is only for other potential > authentication types. For example, when I was investigating other > implementations the mod_auth_kerb module in the apache webserver and the > kerberos module for the flask webserver both ignore the possibility of > continuation and in the apache webserver it has this comment "This is a > _Kerberos_ module so multiple authentication rounds aren't supported. If we > wanted a generic GSS authentication we would have to do some magic with > exporting context etc." Some non-krb5 GSS mechanisms require multiple calls to gss_accept_sec_context(); likewise if the negotiation portion of SPNEGO is used (i.e., the client picks something that the server won't do). But it's hard to diagnose from just what has been said so far. I would try running the server with KRB5_TRACE set in the environment (a path to a log file) and see if the trace output helps make things clear. Otherwise, it's probably going to be a matter of dissecting the actual protocol messages exchanged, seeing what OIDs are sent, etc. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?
> So, you should have a look at what travels between the peers. Thanks, Rick, I looked into it, but my negotiate messages look like this: "Negotiate YIID..." which I think means that they're kerberos messages? Anyone have any other ideas of what could be causing the continue_needed message then? Could it be something with the DNS, I'm not really that confident of my DNS setup, but don't really know what to look into to determine if it's properly set up? (Although I also have ignore_acceptor_hostname = true and I'm passing GSS_C_NO_CREDENTIAL to gss_accept_sec_context, so I'm not sure if that even matters?) I also noticed that if I switch the server back as it was before (with the keytab for the service principal of the Active Directory kdc, and the previous hostname, although with the krb5.conf still pointing at both realms) and then try and do a login when I have a ticket of one of the users from the new MIT realm it also gives me a continue_needed, so could it be something to do with the tickets themselves? I've noticed that the tickets 'renew until' time is already passed (but the tickets don't expire until 12 hrs in the future), but I'm not sure what to change to make the renew time longer, the krb5.conf on the client has renew_lifetime set as 7d... And in the kdc.conf on the kdc server the max_renewable_life is set as 5d... ? -- View this message in context: http://kerberos.996246.n3.nabble.com/GSS-S-CONTINUE-NEEDED-when-doing-Kerberos-authentication-tp45900p45912.html Sent from the Kerberos - General mailing list archive at Nabble.com. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?
Jordan, > I haven't tried to implement the continuation of the context yet, because it > will be a fair amount of work, so I thought I'd email the group to ask > whether it's likely that there is just a problem with my setup, or if I'm > mistaken and it is possible to get a continue_needed when working with > Kerberos? Have you had a look at the data that is actually exchanged? SPNEGO is a switch between mechanisms and may decide to change to another mechanism, for whatever reason, including failure to use your MIT krb5 system. But it might also prefer to attempt another mechanism (or maybe none) initially. You are correct that SPNEGO can make an educated guess and attach one possible mechanism's output along with the SPNEGO bytes, in the hope that it passes through directly; with Kerberos, that would mean that it one exchange suffices. But SPNEGO may have other things on its mind as well. So, you should have a look at what travels between the peers. -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
