【问题标题】:MIT Kerberos fails to locate TGT in MSLSA cacheMIT Kerberos 无法在 MSLSA 缓存中找到 TGT
【发布时间】:2012-01-12 11:52:07
【问题描述】:

我正在努力使用使用 MIT Kerberos 进行身份验证的 Windows 应用程序。

如果用户使用域用户帐户登录 Windows,klist 表明他从 AD 获得了预期的票证,包括这张票:

#1>     Client: jalf @ TESTREALM.COM
        Server: krbtgt/TESTREALM.COM @ TESTREALM.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 1/12/2012 9:46:27 (local)
        End Time:   1/12/2012 19:46:27 (local)
        Renew Time: 1/19/2012 9:46:27 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)

但是,当我们尝试在应用程序中使用此票证时,Kerberos 库似乎找不到那个票证。

以下是相关代码的简化版本:

// Open the MSLSA cache
krb5_cc_resolve(kcontext, "MSLSA:", &mslsa_ccache);
// Create a cursor for traversing the cache
krb5_cc_start_seq_get(kcontext, mslsa_ccache, &cursor);
// Check all the credentials in the cache
while (!(code = krb5_cc_next_cred(kcontext, mslsa_ccache, &cursor, &creds)))  {
    // Find the one with the INITIAL flag set
    if ( creds.ticket_flags & TKT_FLG_INITIAL ) {
        // ticket found
        krb5_free_cred_contents(kcontext, &creds);
        break;
    }
    krb5_free_cred_contents(kcontext, &creds);
}

krb5_cc_end_seq_get(kcontext, mslsa_ccache, &cursor);

但无论出于何种原因,我们从不输入// ticket found 部分。 在调试器中运行代码,我可以看到它找到了klist 显示的其他几张票,但由于某种原因,它始终找不到我们感兴趣的票。

谁能解释这种行为,或者如何解决它?天真地,我希望klist 的输出与使用krb5_cc_next_cred 遍历缓存的结果相匹配。

我对 Kerberos 比较陌生,并且从一位离职的同事那里继承了这段代码,所以我可能遗漏了一些重要的基本信息。

【问题讨论】:

    标签: windows active-directory kerberos


    【解决方案1】:

    您可能无权访问 LSA 中的会话密钥。只有 SSPI 可以访问。你可以试试这个

    原因 2:在某些 Windows 平台上使用本机票证缓存时会引发此异常。 Microsoft 添加了一项新功能,在该功能中,他们不再导出 Ticket-Granting Tickets (TGT) 的会话密钥。因此,在 Windows 上获得的本机 TGT 具有“空”会话密钥和空 EType。受影响的平台包括:Windows Server 2003、Windows 2000 Server Service Pack 4 (SP4) 和 Windows XP SP2。

    解决方案 2:您需要更新 Windows 注册表以禁用此新功能。应添加注册表项 allowtgtsessionkey - 并正确设置 - 以允许在 Kerberos Ticket-Granting Ticket 中发送会话密钥。

    在 Windows Server 2003 和 Windows 2000 SP4 上,这是所需的注册表设置:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
    Value Name: allowtgtsessionkey
    Value Type: REG_DWORD
    Value: 0x01  ( default is 0 )
    

    默认值为0;将其设置为“0x01”允许会话密钥包含在 TGT 中。 这是 Windows XP SP2 上注册表设置的位置:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
    Value Name: allowtgtsessionkey
    Value Type: REG_DWORD
    Value: 0x01
    

    Java 的 GSS impl 在这里也失败了。这是 Oracle 推荐的。您可能会遇到与 MIT Kerberos 相同的问题。

    此更改仅在重新启动后生效。

    【讨论】:

    • +1,谢谢,非常有帮助。这似乎是问题所在。我需要在星期一再测试一下,如果一切顺利,我会接受答案。 :)
    • 好像是这样。它仍然有点不稳定,但这似乎是一个不同的问题。当您登录 Windows 帐户时,有时 LSA 缓存中的票证似乎很少或没有。
    • 这很好。 Windows 登录检索您的域的 TGT。其他应要求。也许基于 SSPI 的解决方案更适合您。虽然这意味着要重写你的代码。
    • 是的,一个 SSPI 方法会很好,但我们通过一层其他库(XMLRPC-c 反过来调用 cURL,在某些情况下执行 Kerberos 身份验证)和 cURL 的SSPI 支持似乎很不稳定。此外,这是一个跨平台的应用程序,而 SSPI 显然只是 Windows 上的一个选项。不过,我会尝试更多地使用它。感谢您的帮助
    • cURLs GSS-API 在 Unix 上也很垃圾。经过几个技巧后,我能够在 Unix 上编译,但所有步骤都可以使它工作。算了。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-04-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多