[37668] in Kerberos
Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?
daemon@ATHENA.MIT.EDU (Jordan Soet)
Mon Aug 29 18:28:41 2016
In-Reply-To: <57C1816D.3030808@openfortress.nl>
To: kerberos@mit.edu
From: "Jordan Soet" <Jordan.Soet@ca.ibm.com>
Date: Mon, 29 Aug 2016 15:25:52 -0700
MIME-Version: 1.0
Message-Id: <OF20615D8C.353BD16D-ON8825801E.007727E2-8825801E.007B45C7@notes.na.collabserv.com>
Content-Type: multipart/mixed; boundary="===============1586430419432430527=="
Errors-To: kerberos-bounces@mit.edu
--===============1586430419432430527==
Content-Type: multipart/related; boundary="=_related 007B45718825801E_="
--=_related 007B45718825801E_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="US-ASCII"
Thanks for the help, when I looked at the output, it contained mech=20
1.3.6.1.5.2.5 which I guess is GSS=5FIAKERB=5FMECHANISM ... Looking into th=
at=20
I think I had a somewhat similar problem to this:=20
http://stackoverflow.com/questions/23759016/spnego-kerberos-no-credential-f=
ound-error-with-requests-from-linux-client
But it wasn't a problem with my reverse dns - that was set up properly,=20
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=20
the TGS-REQ was failing with an "UNKNOWN=5FSERVER" error, and looking into =
that a bit more I realized I had a problem with the name. When using AD I=20
had had a SPN with CamelCase and that hadn't caused a problem, but with=20
the MIT KDC it did, which was a stupid problem that I should've figured=20
out.=20
Thanks for your help :)
Thanks,
Jordan Weitman-Soet=20
Safer Payments Software Developer=20
Phone: 1-778-327-7338 | Tie-Line: 3177338 | Mobile: 1-778-867-5683=20
E-mail: Jordan.Soet@ca.ibm.com=20
1190 Homer St Suite 401=20
Vancouver, BC V6B 2X6=20
Canada=20
From: Rick van Rein <rick@openfortress.nl>
To: Jordan Soet/CanWest/IBM@IBMCA
Cc: kerberos@mit.edu
Date: 08/27/2016 05:03 AM
Subject: Re: GSS=5FS=5FCONTINUE=5FNEEDED when doing Kerberos=20
authentication?
Hi Jordan,
> I looked into it, but my negotiate messages look like this:=20
>
> "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=20
GSSAPI content which, at least in this early phase, is DER-encode. You=20
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=20
https://github.com/vanrein/hexio/blob/master/derdump
There will be a number of OIDs to signal content following; these you can=20
lookup on duckduckgo.com. You should see a general offer packet providing =
the available mechanisms, followed by one that it takes a proactive guess=20
it -- normally Kerberos.
If you're still confused, you could also try sending the output here.
-Rick
--=_related 007B45718825801E_=--
--===============1586430419432430527==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1586430419432430527==--
