探知未来 / 运维笔记

现代办公网安全体系建设系列之一:统一化新型认证体系探索

Einic Yeo · 5月3日 · 2019年 · · · · ·

背景

无论是否情愿,并不是每家公司都能像Google一样在办公体系中完全移除了域控的(大部分)存在感,域仍然是安全人员觉得微妙的存在。 一方面各种域策略、账户的可视化配置方便了大部分企业的IT桌面支持人员在初创阶段做无脑配置,然而另一方面,域控天生与新时代ZeroTrust理念是无法完美契合的。最大的槽点不在于认证源仅仅只有固定密码可选(据传新的Windows Server终于将开始引入OTP,以及Azure AD在某种程度上是支持的),此外其他域提供的各种管理功能在现代互联网企业Linux+开源组件定制化的大技术栈下同样显得格格不入。

但在ZeroTrust理念指导下,我们仍然可以对Windows认证体系进行加固和改造,极大提高其安全性。本系列文章将介绍可能用到的各类架构工具以及微软自身提供的mitigations,随后讨论如何基于这些手段和理念构建纵深防御。

在上面提到Windows密码认证所固有的缺陷后,我们自然会提出如下的问题:如何改造固有的静态域认证体系?在这个理念指导下,可以采取什么样的手段?

一种显而易见的体系化改造是直接通过Windows Credential Provider提供的接入能力,改造认证源,取代Windows原有的认证能力,而本文将介绍的pgina就是其中的版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!一个成熟的开源方案,pgina是一个开源的Windows Credential Provider认证框架,通过各种C版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!#形式的插件,我们可以定制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选项可供选择,如下图所示。

如果需要完全利用pgina的能力,则需要首先了解其的认证体系设计。

pgina认证流程区分为Authentication – Authorization – Gateway三个阶段。其中,Authentication阶段用于证明该用户提供的认证凭据是否正确,而Authorization阶段则决定该用户在凭据正确的情况下,其是否可以登录(例如只有某一个特定组的用户可以登录),Gateway阶段则更类似于认证通过之后的回调。例如在众多插件中,LocalMachine代表了该机器上的native认证,版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!如果其他插件认证通过的用户在本机上不存在,则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插件当然支持对原账户版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!的密码继续生效,但这会造成明显的版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!短板。一种安全的做法是通过终端能力下发定制化脚本,对原有的账户密码进行定期全随机化,包括本地Administrator用户、域控体系下的域用户等。当然,出于灾备的考虑,对部分账户还需要通过一些方式保留原始认证能力供网络、存储等意外因素导致自定义认证服务不可用时排障使用,具体细节在此不在赘述。

总结

以上介绍了pgina认证体系及其插件化应用,同时以将OTP引入Windows认证为例,给出了一个案例。基于插件化的能力,我们可以摒弃域控认证体系部分固有的弱点,引入TOTP二次认证体系,统一认证后端。API接口的能力允许我们对认证权限做更统一的细粒度规划,而不是拘泥于Windows域所固有的体系,降低维护成本,提高安全性。

参考文献

https://github.com/pgina/pgina

http://mutonufoai.github.io/pgina

0 条回应