搞懂这个，域安全少走好多弯路！
嘿，朋友们！今天咱们来聊一个特别容易让人绕晕的话题——是否约束委派入门教程，说真的，我第一次接触这玩意儿的时候，脑袋里全是问号：啥叫委派？约束又是约束个啥？不约束又会怎样？别急，今天我就用最接地气的方式,带你从零开始把这事儿整明白。
委派到底是个啥？先别被术语吓到
你可以这么想：你在公司里是个普通员工，但有件事你自己没权限办，得找经理帮你签字，经理签完字，事儿就成了——这就是“委派”的雏形，在Windows域环境里，委派（Delegation）就是让一个服务（比如Web服务器）能代表用户去访问另一个服务（比如数据库）的机制。
那问题来了：如果谁都能随便代表别人去干活，那不就乱套了吗？所以微软搞出了两种模式：约束委派和非约束委派，咱们这篇是否约束委派入门教程，重点就是帮你分清这俩到底选哪个、怎么配。
非约束委派：方便是真方便，危险也是真危险
非约束委派（Unconstrained Delegation）说白了就是：用户把票（TGT）交给服务A，服务A可以拿着这张票去访问任何服务，对，你没看错，是任何！这就好比你让助理帮你拿快递，结果助理拿着你的身份证能把你的银行卡、社保、房产全查一遍……
很多老系统默认就开着非约束委派，因为省事啊，但一旦攻击者拿下一台配置了非约束委派的机器，就能直接抓走域管员的票据，—域控就沦陷了，所以现在安全圈里一提到非约束委派，大家的表情都是：😱
约束委派：给权限上个“紧箍咒”
约束委派（Constrained Delegation）就温柔多了，它允许你明确指定：服务A只能代表用户去访问服务B、C、D这几个，别的想都别想，这就合理多了对吧？就像给助理一张清单：只能去菜鸟驿站和顺丰网点,别的地方不许去。
配置约束委派的时候，你会看到两个选项：仅使用Kerberos和使用任何身份验证协议，一般来说选Kerberos更安全，但有些老应用不支持，那就只能妥协，这里划重点：是否约束委派入门教程的核心结论就是——能用约束就别用非约束，能用基于资源的约束委派（RBCD）就更香了。
基于资源的约束委派：新时代的答案
后来微软又推出了基于资源的约束委派（Resource-Based Constrained Delegation，简称RBCD），这个更绝：不是由前端服务说了算，而是由后端资源自己决定“谁可以代表用户来访问我”，比如数据库服务器说：“我只信任Web服务器A和B，别的我都不认。”这样一来，权限控制就反过来了,更符合最小权限原则。
配置RBCD需要用到PowerShell，比如Set-ADComputer配合PrincipalsAllowedToDelegateToAccount参数，听起来复杂，但实操一遍就懂了，我建议你在测试环境里先玩一圈，别直接上生产——别问我怎么知道的,说多了都是泪😭
到底选哪个？给你一张决策表
- 非约束委派：除非是2003时代的老古董应用，否则别用,高危！
- 约束委派：传统场景够用，配置简单,但需要前端服务有权限。
- 基于资源的约束委派：新项目首选，权限更精细,但需要后端资源配合。
记住咱们这篇是否约束委派入门教程的一句话总结：能约束就别放纵，能RBCD就别普通约束。
动手试试：最小化配置示例
假设你有个Web服务器WEB01要访问数据库SQL01,用约束委派：
Set-ADComputer WEB01 -PrincipalsAllowedToDelegateToAccount SQL01$
如果是RBCD，反过来在SQL01上设置：
Set-ADComputer SQL01 -PrincipalsAllowedToDelegateToAccount WEB01$
看，其实就一行命令的事儿，但前提是你得搞清楚谁信任谁、票据怎么走，不然配完了访问不了,你又得抓耳挠腮半天。
最后唠叨几句
搞域安全啊，委派这块儿真的是重灾区，很多内网渗透里，攻击者第一件事就是找非约束委派的机器，所以作为防守方，你至少得知道自家域里哪些机器开了委派、是哪种委派，定期跑一下Get-ADComputer -Filter {TrustedForDelegation -eq $true},心里才有底。
好了，这篇是否约束委派入门教程就到这儿，希望你看完之后，不再被“约束”“非约束”绕晕，有啥问题欢迎留言，咱们一起唠！别忘了把这篇是否约束委派入门教程分享给身边搞运维的小伙伴，少一个人踩坑，多一份安全嘛！😊