gss_acquire_cred 返回密钥表条目未找到错误

发布于 2024-07-06 17:50:12 字数 1209 浏览 6 评论 0原文

我一直在尝试按照这篇 Microsoft 文章中的指南进行身份验证使用 Kerberos 和 AD 对抗 Apache。我已经用kinit成功测试了apache服务器和AD服务器之间的通信。但是，当我尝试使用 IE 访问服务器上的受限页面时，出现内部服务器错误，并且 apache 错误日志中出现以下内容。

[Wed Sep 24 14:18:15 2008] [debug] src/mod_auth_kerb.c(1483): [client 172.31.37.38] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Wed Sep 24 14:18:15 2008] [debug] src/mod_auth_kerb.c(1174): [client 172.31.37.38] Acquiring creds for HTTP/[email protected]
[Wed Sep 24 14:18:15 2008] [error] [client 172.31.37.38] gss_acquire_cred() failed: Miscellaneous failure (see text) (Key table entry not found)

我已经在 apache 进程上运行了 truss 并确认它实际上加载了 keytab 文件。我想知道 keytab 文件的格式是否有问题......

HTTP/[email protected]

但我不确定我缺少什么。或者还有什么要检查的。

有什么建议么？

谢谢

彼得

原文

I have been trying to follow the guidelines in this Microsoft article to authenticate
against Apache with Kerberos and AD. I have successfully tested the communication between the apache server and the AD server with kinit. However when I attempt to access a restricted page on the server with IE I get an Internal server error and the following appears in the apache error log.

[Wed Sep 24 14:18:15 2008] [debug] src/mod_auth_kerb.c(1483): [client 172.31.37.38] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Wed Sep 24 14:18:15 2008] [debug] src/mod_auth_kerb.c(1174): [client 172.31.37.38] Acquiring creds for HTTP/[email protected]
[Wed Sep 24 14:18:15 2008] [error] [client 172.31.37.38] gss_acquire_cred() failed: Miscellaneous failure (see text) (Key table entry not found)

I have run a truss on the apache process and confirmed that it is in fact loading up the keytab file ok. I am wondering if there is something wrong with the format of the keytab file...

HTTP/[email protected]

I am not sure what I am missing though. Or what other things to check.

Any suggestions?

Thanks

Peter

分享到QQ

分享到微博

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

发布评论

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

勿挽旧人 2024-07-13 17:50:12

好的。 Keytab 应包含服务主体名称，在本例中为“HTTP/[email protected] ”和加密密钥。我看到 MS 文档说只是将其回显到文件中，但我认为这是不对的。

您需要使用 ktpass 实用程序来创建密钥表。 MS 文档位于此处。

特别是，您需要指定 KRB5_NT_SRV_HST，其余大部分选项都可以使用默认值。

我的计算机上的示例：

C:\>ktpass /out test.keytab /princ HTTP/[email protected] 
           /ptype KRB5_NT_SRV_HST /pass *
Type the password for HTTP/srvnfssol1.dev.local:
Key created.

Output keytab to test.keytab:

Keytab version: 0x502
keysize 62 HTTP/[email protected] 
ptype 3 (KRB5_NT_SRV_HST) vno 1 etype 0x1 (DES-CBC-CRC) 
keylength 8 (0xa7f1fb38041c199e)

如果 Active Directory 服务器是 KDC，则需要使用 /map 参数，其中是代表服务器的 Active Directory 中的计算机帐户。

关于这一切如何运作的一些细节。当您浏览该网站时，它应该使用 WWW-Authenticate: Negotiate 标头进行响应，并且您的浏览器将向 KDC（活动目录服务器）发送请求以获取该服务的 kerberos 票证。 AD 服务器将使用服务主体名称查找票证的加密密钥，并将加密的服务票证发送回浏览器。一旦浏览器获得服务票证，它将使用包含该票证的身份验证标头重新发出 HTTP 请求。 apache 服务器将在密钥表中查找其密钥、解密票证并授予访问权限。

发生“找不到密钥表条目”错误是因为 apache 在密钥表中找不到自己。如果名称解析/领域设置不正确，也可能会发生这种情况。

您应该能够在客户端、tcp 或 udp 端口 88 上使用wireshark 查看所有 kerberos 请求 AP-REQ/AP-REP/TGS-REQ/TGS-REP。

Ok. Keytabs are supposed to contain the Service principal name, in this case "HTTP/[email protected]" and the encryption key. I see where the MS docs say just to echo that to a file, but I don't think that's right.

You'll need to use the ktpass utility to create the keytab. The MS docs are here.

In particular, you'll need to specify KRB5_NT_SRV_HST, and most of the rest of the options can be default.

Sample of it on my machine:

C:\>ktpass /out test.keytab /princ HTTP/[email protected] 
           /ptype KRB5_NT_SRV_HST /pass *
Type the password for HTTP/srvnfssol1.dev.local:
Key created.

Output keytab to test.keytab:

Keytab version: 0x502
keysize 62 HTTP/[email protected] 
ptype 3 (KRB5_NT_SRV_HST) vno 1 etype 0x1 (DES-CBC-CRC) 
keylength 8 (0xa7f1fb38041c199e)

If the active directory server is the KDC, you'll need to use the /map <name> argument, where <name> is the computer account in active directory representing the server.

Some details on how all this works. When you browse to the website it should respond with a WWW-Authenticate: Negotiate header, and your browser will send a request to the KDC (active directory server) to get a kerberos ticket for the service. The AD server will look up the encryption key for the ticket using the service principal name, and send an encrypted service ticket back to the browser. Once the browser has the service ticket, it'll reissue the HTTP request with an authenticate header containing the ticket. The apache server will look up its key in the keytab, decrypt the ticket, and grant access.

The "key table entry not found" error happens because apache isn't finding itself in the keytab. Can also happen if the name resolution/realms aren't set up right.

You should be able to see all the kerberos requests AP-REQ/AP-REP/TGS-REQ/TGS-REP using wireshark on the client, tcp or udp port 88.

回复收藏 0 原文

~没有更多了~