MIT Kerberos 无法在 MSLSA 缓存中找到 TGT

发布于 2024-12-26 13:07:42 字数 1594 浏览 3 评论 0原文

我正在努力开发一个使用 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 比较陌生,并且从一位离开的同事那里继承了这段代码,因此我可能错过了一些重要的基本信息。

I'm struggling with a Windows application which uses MIT Kerberos for authentication.

If a user logs on to Windows with a domain user account, klist shows that he gets the expected tickets from the AD, including this one:

#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)

However, when we try to use this ticket in our application, the Kerberos library does not seem to find that one.

Here's a simplified version of the relevant code:

// 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);

But for whatever reason, we never enter the // ticket found part.
Running the code in the debugger, I can see that it finds several of the other tickets shown by klist, but for some reason it never finds the one we're interested in.

Can anyone explain this behavior, or how to get around it? Naively, I'd expect the output from klist to match the results of iterating over the cache with krb5_cc_next_cred.

I'm relatively new to Kerberos, and inherited this code from a coworker who left, so it's possible that I'm missing some vital fundamental piece of information.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

那片花海 2025-01-02 13:07:42

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

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

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

在 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 时您可能会遇到同样的问题。

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

You probably do not have access to the session key in the LSA. Only SSPI can access. You can try this

Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an "empty" session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4) and Windows XP SP2.

Solution 2: You need to update the Windows registry to disable this new feature. The registry key allowtgtsessionkey should be added--and set correctly--to allow session keys to be sent in the Kerberos Ticket-Granting Ticket.

On the Windows Server 2003 and Windows 2000 SP4, here is the required registry setting:

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

By default, the value is 0; setting it to "0x01" allows a session key to be included in the TGT.
Here is the location of the registry setting on Windows XP SP2:

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

Java's GSS impl fails here too. This is recommended by Oracle. You may suffer from the same problem with MIT Kerberos.

This change goes in effect after a reboot only.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文