[jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
Darran Lofthouse (JIRA)
issues at jboss.org
Tue Feb 16 13:52:00 EST 2016
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163874#comment-13163874 ]
Darran Lofthouse commented on SECURITY-921:
-------------------------------------------
I don't think this is the correct fix. As mechTypes are the mechanisms from the client in descending priority order and as mechToken is the token being optimistically being sent from the client the assumption is that this would be the clients preferred token type.
As the most preferred mechType is not our most preferred mech type the client is asked to send our most preferred mechType so possibly there is a bug in the message we are sending to the client which is why it can not respond - alternatively although the client has claimed it can support the type we want when challenged it decides it does not want to after all.
I would suggest some detailed Wireshark traces to see if there is a problem with the message we are sending back as if that is faulty that needs fixing first.
Secondly this code change may be working as the actual mechType is 'Windows Kerberos V5' so we may want to check if the first mechType in the list is either of the two variants of Kerberos.
I think this proposed change risks the client saying it prefers NTLM and sending in an NTLM token but if it also claims it could support Kerberos then we would attempt to use the NTLM token and not prompt the client to use Kerberos.
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1
> Environment: *
> Reporter: Harald Krause
> Assignee: Darran Lofthouse
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list