MIT Kerberos 无法在 MSLSA 缓存中找到 TGT
我正在努力开发一个使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可能无权访问 LSA 中的会话密钥。只有SSPI可以访问。你可以试试这个
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
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.