java - GSSAPI缺陷票

Question

我很抱歉，如果确实有一些直截了当的地方，我对此表示错-我一直很难找到有关GSSAPI和JAAS的大量信息。

我正在编写一个程序，该程序向IIS服务器发出请求并使用Kerberos进行身份验证。

我有两个VM：第一个是Active Directory域控制器。另一个正在运行IIS服务器。

在我的计算机上，我正在运行一个使用GSSAPI和JAAS进行身份验证的程序。它很大程度上基于the Oracle tutorials for GSSAPI，因为在此阶段，我只是想尽全力。它使用KrbLoginModule登录以根据域中的某些给定测试用户创建主题，所有这些用户似乎都工作正常。在网络跟踪中，我的机器和域控制器VM之间有一个AS-REQ，AS-REP，TGS-REQ和TGS-REP（如果正确的话，应该是正确的）。

然后，我的程序使用上面生成的主题来运行一些主要基于code from the GSSAPI/JAAS tutorial的GSSAPI代码。它创建名称/凭据/上下文时没有任何错误，但是当尝试建立上下文时，事情就开始出错了。

我最初是在上下文循环中完成该过程的（在上面的链接中），但是当它尝试开始从服务器（即token = new byte[inStream.readInt()];）读取令牌时，它读取的length整数很大（1213486160，少数几个一次我检查-好像是每次。这导致了OutOfMemoryError。

然后，我开始使用initSecContext的“流版本”，它接受输入和输出流（我向服务器提供了已打开的套接字的输入/输出流-我想这就是它想要的）。起初这似乎工作得很好。它建立了一个以上的迭代，但是当您尝试包装/解包消息时，事情又开始出错。当您尝试解开消息时，它会引发错误：

org.ietf.jgss.GSSException, major code: 10, minor code: 0
    major string: Defective token
    minor string: Bad token tag: 7284

为此，网络跟踪显示了一条TCP消息，其长度与生成的令牌相同（我假设它将是发送的包装令牌）。然后是一个ICMP重定向。我不确定是否没有问题，但是我想提到一下（我注意到它几乎包含了第一个TCP消息的全部）。

然后是一个HTTP响应。这是一个400错误的请求。在响应的主体中，它表示这是一个无效动词（我假设它是动词时，其含义类似于“ GET”或“ POST等。是这种情况吗？）。跟踪还指出，这是对“第一条TCP消息。经过一番谷歌搜索，我发现了a guy who had a similar problem。事实证明这是关于一种防病毒软件，使发送的请求的标头陷入混乱（也许与重定向有关？）。

然后，我的机器中又收到一些TCP消息（连续3条）（它们包含我使用wrap方法在消息中发送的数据），然后是服务器发送的length = 0 TCP确认。

因此，我不确定它可能是什么（也许是重定向，但这似乎不太可能）。

更新：

我正在另一个VM（在同一Active Directory域上）上运行它，但它仍收到HTTP 400错误请求响应。与以前不同的是，它现在肯定使用Kerberos（上面是发送NTLM请求）。

网络跟踪显示AS和TGS请求和响应，然后发送票证。然后，IIS服务器将抛出400错误请求（再次，无效动词）。两者之间有一个细微的差别：Bad Request响应不再是对发送令牌的确认，尽管在400之前有一个空的ack TCP消息。

该程序仍认为已建立其上下文，但是如果您尝试包装一条消息，则它会中断：

General failure, unspecified at GSSAPI level
    minor string: Error in method wrap, error: java.net.SocketException:
        Unrecognized Windows Sockets error: 0: socket write error

更新：

如前所述，当我使用initSecContext读取令牌时，我期望基于本教程的长度优先（即token = new byte[inStream.readInt()];）。我得到的是1213486160，它导致OutOfMemoryError。我意识到，但是，1213486160是0x48545450，以ASCII形式是“ HTTP”。因此，我阅读了下一组字符，“响应令牌”是HTTP 400错误请求。

这使我产生疑问，即是否应该按照教程中所示的长度读取整数。我觉得这个问题有些不同，所以我做了一个new question here。不过，这可能不是问题（例如，不是什么原因导致它首先发送“错误请求”），因此我暂时将这个问题保持开放状态。

另一个更新：

所以我看了被initSecContext吐出并编码为Base64的令牌，它是YII ...（即协商令牌）。

当我通过chrome登录时，我还仔细查看了网络跟踪，并在AS和TGS消息之后，它发送了带有标头行Authorization的HTTP GET请求：Negotiate YII .....，而不是我的程序发送带有令牌长度的TCP消息，然后是令牌。

这向我建议，我不需要执行建立上下文步骤（至少，如本教程中所示），或者我需要获取令牌并将其发送到HTTP请求而不是直接的TCP消息中。是否存在使用GSSAPI / Kerberos对IIS进行身份验证的人（或任何人的示例，我似乎找不到真正的人）？

Answer 1

确保客户端计算机加入与IIS服务器相同的Active Directory域中，以便Kerberos身份验证起作用。 “有缺陷的令牌”通常表示客户端计算机发送了NTLM身份验证令牌，而服务器需要Kerberos令牌。有这种不良行为发生的原因。


如果客户端计算机不在同一AD域中，则它必须位于与IIS服务器的域具有2种信任关系的域中。如果AD域位于同一林中，则默认情况下会发生这种情况。
必须配置从其他域访问IIS服务器的权限。摘要：如果对这些问题的回答为否，那么这说明了为什么出现基本身份验证后备。仅在Kerberos身份验证失败后才尝试基本身份验证。