无论是否情愿，并不是每家公司都能像Google一样在办公体系中完全移除了域控的（大部分）存在感，域仍然是安全人员觉得微妙的存在。 一方面各种域策略、账户的可视化配置方便了大部分企业的IT桌面支持人员在初创阶段做无脑配置，然而另一方面，域控天生与新时代ZeroTrust理念是无法完美契合的。最大的槽点不在于认证源仅仅只有固定密码可选（据传新的Windows Server终于将开始引入OTP，以及Azure AD在某种程度上是支持的），此外其他域提供的各种管理功能在现代互联网企业Linux+开源组件定制化的大技术栈下同样显得格格不入。
但在ZeroTrust理念指导下，我们仍然可以对Windows认证体系进行加固和改造，极大提高其安全性。本系列文章将介绍可能用到的各类工具以及微软自身提供的mitigations，随后讨论如何基于这些手段和理念构建纵深防御。
在上面提到Windows密码认证所固有的缺陷后，我们自然会提出如下的问题：如何改造固有的静态域认证体系？在这个理念指导下，可以采取什么样的手段？
一种显而易见的体系化改造是直接通过Windows Credential Provider提供的接入能力，改造认证源，取代Windows原有的认证能力，而本文将介绍的pgina就是其中的一个成熟的开源方案，pgina是一个开源的Windows Credential Provider认证框架，通过各种C#形式的插件，我们可以定制Windows的认证流程，取代传统的密码认证流程，与统一认证源完成打通，在某种程度上实现大一统SSO的梦想。
pgina架构介绍
pgina最早由David Wolff等开发并开源，借助Windows的Credential Provider体系，实现了ICrendtialProvider接口，实现了认证流程的定制。mutonufoai维护了一个fork版本，是目前比较活跃的分支。http://mutonufoai.github.io/pgina/
简单来说，在安装了pgina之后，我们可以在认证流中插入自定义的环节，Pgina原生提供了多种开箱即用的插件，通过这些插件与外部认证源打通。例如，我们可以通过自定义的Radius认证服务器或者通过http auth插件，来实现对OTP登录的支持，甚至更细粒度的控制。
pgina配置
我们以pgina接入radius认证后端为例，展示pgina的用法。需要注意的是pgina并不是一个中心的域控插件，需要安装部署到所有具体的目标机器上。
pgina认证流程区分为Authentication – Authorization – Gateway三个阶段。其中，Authentication阶段用于证明该用户提供的认证凭据是否正确，而Authorization阶段则决定该用户在凭据正确的情况下，其是否可以登录（例如只有某一个特定组的用户可以登录），Gateway阶段则更类似于认证通过之后的回调。例如在众多插件中，LocalMachine代表了该机器上的native认证，如果其他插件认证通过的用户在本机上不存在，则LocalMachine插件默认会在Gateway阶段创建对应的用户。当然，这个行为都是可配置的。
通过pGina插件在Windows认证中支持OTP认证
在有了这些基础知识之后，我们就可以通过插件连接到自定义的radius server，来对Windows开启OTP认证支持。受到Windows UI限制，用户可将OTP追加在其原始密码之前或之后，整体的流程如下图所示。
根据以上设计，我们甚至可以在某种程度上，摒弃域控体系的存在，而把认证源完全转移到统一的认证体系中。通过插件中所携带的信息，甚至可以做到对特定机器限定特定权限登录，以及检测到用户存在风险时自动拒绝登录等等。
根据实际测试经验和遇到的问题，有如下建议可供参考：
- 内置插件可用于快速测试功能，但在可用性上没有太多考虑，radius插件本身在高频使用中存在一些问题，建议根据其架构自行实现插件，通过自定义的认证协议与远端认证接口进行联调和实现
- 开启了插件认证的机器在被远程桌面时（如果允许远程桌面），远程桌面客户端侧需要关闭默认的网络级别验证，因为Network Level Authentication并不支持自定义的credential provider。关闭NLA并不会带来认证方式上的安全问题（例如hash被抓取之类的）
- pgina原版具有调试功能，但调试功能较为难用，建议通过log形式调试，pgina.fork并不支持调试。插件主要为C#语言编写，需要对C#有一定的了解。
此外，一个显而易见的问题是，原账户的密码应当如何处理？LocalMachine插件当然支持对原账户的密码继续生效，但这会造成显而易见的短板。一种安全的做法是通过终端能力下发定制化脚本，对原有的账户密码进行定期全随机化，包括本地Administrator用户、域控体系下的域用户等。当然，出于灾备的考虑，对部分账户还需要通过一些方式保留原始认证能力供网络、存储等意外因素导致自定义认证服务不可用时排障使用，具体细节在此不在赘述。
总结
以上介绍了pgina认证体系及其插件化应用，同时以将OTP引入Windows认证为例，给出了一个案例。基于插件化的能力，我们可以摒弃域控认证体系部分固有的弱点，引入TOTP二次认证体系，统一认证后端。API接口的能力允许我们对认证权限做更统一的细粒度规划，而不是拘泥于Windows域所固有的体系，降低维护成本，提高安全性。
注：该文已授权首发于 跳跳糖：
https://tttang.com/archive/1282/