关于 Kerberos、委派和 SPN 的混淆
我正在尝试编写一个执行 Kerberos 委派的概念验证应用程序。我已经编写了所有代码，并且似乎可以正常工作（我的身份验证正常），但生成的安全上下文没有设置 ISC_REQ_DELEGATE 标志。
所以我想也许端点之一（客户端或服务器）被禁止委托。但是我没有针对 SPN 进行身份验证。只有一个域用户对抗另一个域用户。作为 InitializeSecurityContext() 的 SPN，我传递“[email ;protected]”（这是运行服务器应用程序的用户帐户）。据我了解，域用户默认启用委派。无论如何，我要求管理员检查，并且“帐户敏感且无法委派”复选框已关闭。
我知道，如果我的服务器作为网络服务运行并且我使用 SPN 连接到它，那么我需要 AD 中的计算机帐户选中“信任计算机进行委派”复选框（默认情况下关闭），但是……事实并非如此吧？或者是吗？
另外 - 当设置计算机帐户中的复选框时，更改是否立即发生，还是必须重新启动服务器 PC 或等待一段时间？
I'm trying to write a proof-of-concept application that performs Kerberos delegation. I've written all the code, and it seems to working (I'm authenticating fine), but the resulting security context doesn't have the ISC_REQ_DELEGATE flag set.
So I'm thinking that maybe one of the endpoints (client or server) is forbidden to delegate. However I'm not authenticating against an SPN. Just one domain user against another domain user. As the SPN for InitializeSecurityContext() I'm passing "[email protected]" (which is the user account under which the server application is running). As I understand, domain users have delegation enabled by default. Anyway, I asked the admin to check, and the "account is sensitive and cannot be delegated" checkbox is off.
I know that if my server was running as a NETWORK SERVICE and I used an SPN to connect to it, then I'd need the computer account in AD to have the "Trust computer for delegation" checkbox checked (off by default), but... this is not the case, right? Or is it?
Also - when the checkbox in the computer account is set, do the changes take place immediately, or must I reboot the server PC or wait for a while?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据 此 ISC_REQ_DELEGATE 仅在以下情况下才会被忽略您使用约束委派。我非常确定要发生约束委派，您必须明确说明允许帐户在 Active Directory 中委派哪些服务（AD 管理单元中用户或计算机的委派选项卡）。
我不确定使用 UPN 与 SPN 的规则。您是否尝试过打开Kerberos 事件日志记录并查看事件日志？这些消息通常很神秘，但通常可以破译。
您对网络服务场景的描述是准确的。默认情况下，对委派的信任处于关闭状态，但 NETWORK SERVICE 可能有权自行注册 SPN（我认为这可以由组策略确定）。
当您勾选该框时，更改会立即发生，但可能必须传播到域中的所有域控制器（我通常在具有单个 DC 的测试域中进行测试）。因此，重新启动您的服务应用程序就足够了，不需要重新启动。
路边票据驻留在客户端计算机上。它们有一个过期时间，可以使用 klist 或 kerbtray 手动刷新。
According to this ISC_REQ_DELEGATE is only ignored if you use constrained delegation. I'm pretty sure for constrained delegation to happen, you have to explicitly state which services the account is allowed to delegate to in Active Directory (delegation tab for a user or computer in the AD snap in).
I'm not sure of the rules using UPNs vs SPNs. Have you tried turning on Kerberos event logging and looking in the event log? The messages are often cryptic but usually possible to decipher.
Your description of the NETWORK SERVICE scenario is accurate. Trust for delegation is off by default, but NETWORK SERVICE might have permission to self register an SPN (I think this can be determined by group policy).
When you tick the box the change takes place immediately, but may have to propogate throughout all the domain controllers in the domain (I typically test in a test domain with a single DC). So, restarting your service app is enough, you don't need to reboot.
The Kerb tickets reside on the client machine. These have an expiry time, and can be flushed manually using klist or kerbtray.