为了便于管理分布在不同地方的 Windows VPS，也为了学习 AD 的应用，我使用一个单独的 Windows 2019 VPS 来建立了 Active Directory。建立之后没多久，它超出了流量限额。
3 月 25 号，我照原先一样起床，打开电脑，当我吃过早饭，登录域时，系统提示“指定的域不存在或无法联系”，第一反应是，那个讨厌的域控制器又在打补丁了，然后，我尝试通过服务商的 VNC 界面，连接到域控制器，没等我进入 VNC 界面，就看到了一行提示，大意是服务器的流量（2 TB）已经耗尽。流量耗尽？这是开啥玩笑呀？服务器都被服务商关停了，显然已无法通过登录系统进行调查，我猜一定是 Windows Update 分享补丁给网络上的其它计算机导致的。
熬过了快一个月，服务器恢复工作了，但好景不长，过了短短两天，服务商就报告服务器用掉了 500 GB 流量，这事儿真得仔细检查了，当我登录服务器，发现远程操作根本无法进行，因为速度太慢，服务商的页面上显示服务器的 CPU 耗费过多，已经进入了限制模式，我只得再度关闭服务器。当 CPU 限制模式解除后，我立即开启了服务器，然后用资源监视器监控着资源用量，终于 lsass.exe 引起了我的注意，因为它耗费了几乎 80% 的 CPU，难道是中毒了？我切换到了网络选项卡，发现 lsass.exe 正在大量发送数据。
很明显，这是中毒的表现，我首先检查防火墙，在“高级安全 Windows 防火墙”的“例外”中，我发现我在 Default Domain Controller Policy 指定的防火墙规则竟然与现存的规则并存，而没有覆盖现存的规则，结果是，现存的规则执行了宽松的标准，我立即删除了服务器上现存的规则。
当我删掉了服务器高级安全 Windows 防火墙原本的规则后，上传流量立即恢复了正常。难道是 lsass.exe 真的感染病毒了吗？我立即检查 lsass.exe 的完整性，并且用杀毒软件扫描了服务器，结果是没发现被病毒感染的迹象。
原来，Active Directory 的 LDAP 服务器不仅仅会监听 TCP 389 端口，而且也会监听 UDP 协议的 389 端口，这就是 CLDAP 协议，由于 CLDAP 协议早就过时，OpenLDAP 已经不再支持它，Windows Server 支持这种协议，还把它弄得非常非常糟，换句话说，除了让黑客能够探测 Active Directory，以及进行放大 DDoS 攻击，啥用也没有。
如何解决这个问题呢？如果你有硬件防火墙，可以在上面设置只允许受信任的 IP 连接 UDP 389 端口的规则，如若没有，在“Default Domain Controller Policy”组策略对象的“高级安全 Windows 防火墙”的“入站”中，配置只允许受信任的 IP 连接 UDP 389 的规则，并仔细检查域控制器上是否并行存在一条相同的规则，如果有，删除它。
不得不说，微软的设计确实是很奇怪，早已被废弃并且还会被用来进行攻击的 CLDAP，在微软这里用得那叫心安理得，如果域控制器连接到了 Azure AD，那么这种问题只可能更糟，因为 Azure AD 能够成功同步域用户的前提条件是必须能从 Internet 访问域控制器的 389 端口（TCP 和 UDP 都必须允许）。