云主机跑了一个AD后，最容易踩的几个坑

业务上云后，很多团队都会顺手把域控也往云上放。想法不难理解：应用在云上，账号、权限、组策略也放到云上，看起来路径更短，管理也集中。云主机跑了一个AD这件事，本身并不少见，测试环境、分支办公、轻量统一认证里都有人这么做。

问题不只是“能不能搭”，还包括“能不能稳”。AD是基础设施，和普通业务软件不一样。它一旦出问题，影响的不只是某台服务器，登录、权限、策略、成员服务器发现域控这些链路都可能跟着出问题。很多团队前期觉得省事，后期却把时间花在补架构、补流程、补恢复能力上。

如果你准备让云主机跑了一个AD，有些地方最好在上线前就想清楚，不然后面基本都会补课。

为什么大家会想到把AD放到云主机上

AD，也就是Active Directory，主要承担统一身份认证、设备管理、权限控制和策略下发。过去它大多在本地机房里，现在云资源更普遍，业务服务器、文件服务、内部应用都在云上，域控也跟着上云，看起来很自然。

• 没有稳定机房，想减少本地硬件投入和维护压力。
• 分支机构人不多，但又需要统一账号体系和基本权限管理。
• 开发、测试、培训、演示环境需要快速起一个域环境。
• 某些业务系统依赖AD认证，放在云上能少绕一层链路。
• 远程办公变多后，希望终端和账号不要各自为政。

这些理由都成立，所以别把“云上AD”看成特殊做法。要区分的是：你搭的是一个临时能用的环境，还是一个要长期托底的认证系统。两者在设计上差很多。

哪些场景可以用，哪些场景别急着上

比较适合的情况

• 中小团队需要一个轻量但正规的统一认证环境，规模不大，需求清楚。
• 开发测试、培训、POC验证，目标是快速验证域集成和策略效果。
• 主要业务本来就在云上，认证链路也希望尽量留在云内。
• 异地办公较多，本地没有专职IT长期驻场，云上更容易集中维护。

容易出问题的情况

• 只准备一台云主机，没有冗余，没有恢复预案，连备份是否能用都没验证过。
• 想把AD和数据库、Web、文件共享、打印服务都装在同一台实例上，图省机器数。
• 网络本来就不稳定，VPN、专线、跨地域访问经常抖动，却还要靠它承载统一认证。
• 对合规、审计、安全边界要求高，但运维流程还停留在手工改配置、靠人记步骤。

有个判断很实用：云主机跑了一个AD并不可怕，反复出故障，多半和单点运行、混装业务、边界模糊有关。

一个很常见的落地场景：前期省事，后面集中返工

一个二十来人的电商团队，早期没有机房，系统都在云上。为了统一员工账号和文件共享，运维在一台Windows云主机上快速搭了AD，又顺手把共享目录、打印服务和一套内部应用也放了进去。刚开始看着很顺：员工能统一登录，权限也比原来清楚，管理层会觉得这台机器“很值”。

问题通常不会在第一天出现，往往是在业务开始依赖它之后慢慢冒出来。

• 补丁重启安排在夜里，第二天上班一批员工登录缓慢，排查半天才发现域控恢复后服务还没完全稳定。
• 共享目录权限越改越乱，临时员工离职后账号没有及时禁用，留下多余访问权限。
• 内部应用升级时抢占资源，域控响应跟着变慢，成员服务器偶发找不到域服务。
• 有人误删了一个OU下的策略，终端配置一片混乱，改回去也要花时间重新生效。
• 只有一台域控，想回滚、想恢复都很被动，任何操作都怕再出连锁反应。

这种情况最后往往还是要返工：加第二台域控，拆分文件服务，重做GPO分层，把备份和账号流程补齐。表面看是技术故障，实际是把关键基础服务当成了普通Windows主机来用。

云上部署AD，最容易踩的五个坑

1. 只有一台域控

很多团队一开始都会说，先上一台，后面再补。问题是AD一旦被正式环境依赖，“后面再补”经常会拖很久。单台实例宕机、磁盘异常、系统更新失败，认证链路就可能直接受影响。规模不大也一样，至少两台域控是比较基本的配置。

2. DNS没规划清楚

AD对DNS的依赖非常高。能加域但组策略不生效、偶发登录慢、成员服务器找不到域控，这类故障很多最后都会落到DNS上。云环境里最怕的是混用：一部分指向公网DNS，一部分指向自建DNS，一部分又保留了云厂商默认解析。前期似乎也能用，后期故障会非常隐蔽。

这里不要偷懒。客户端和服务器该指向谁，转发怎么做，内部名称怎么解析，最好一开始就定下来。

3. 域控和业务混装

把文件共享、第三方应用、中间件甚至数据库都放在域控上，短期看像是节省成本，实际是把风险往一台机器上堆。域控本来就承担身份认证职责，越纯净越好。业务一旦占满资源，或者某个组件更新出问题，受影响的就不只是应用本身。

还有个常被忽略的点：混装后权限边界也容易乱。运维为了处理应用故障频繁登录域控，应用服务账号、共享权限、管理员权限掺在一起，后面很难梳理。

4. 备份有了，恢复没练过

很多团队说自己有云盘快照，也有备份策略，但这只能说明“留了东西”，不代表“真能恢复”。AD涉及目录数据一致性、系统状态、复制关系，恢复不是把一块盘挂回去那么简单。没演练过，真出故障时往往没人敢动，或者一恢复又带出新的复制问题。

至少要定期验证一次：系统状态备份是否完整，单台故障怎么接管，误删对象怎么恢复，快照能不能安全使用。没有这一步，备份很容易只停留在台账里。

5. 管理口暴露太宽

云上环境和本地机房最大的区别之一，就是网络边界更复杂，也更容易因为图方便把口子开大。3389、LDAP、RDP这类端口如果直接暴露到公网，或者安全组规则放得过宽，域控就是一个高价值目标。攻击者不需要拿下很多机器，拿到域控权限，后果就足够大。

这类问题在初期很容易被忽视，因为“先让远程能连上再说”通常是最快的做法。但一旦上线，就很少有人回头认真收口。

更稳一点的实施方式

如果决定让云主机跑了一个AD，从第一天起就按正式基础设施来做，不要按临时环境的标准放行。

基础架构上，至少做到这些

1. 准备两台域控，尽量分布在不同可用区或不同故障域。这样单实例维护、异常或底层故障时，不会整套认证一起掉。
2. 域控只承担域控职责。文件服务、内部应用、数据库能拆就拆，不要因为前期机器少就混在一起。
3. 把DNS关系定清楚。客户端、成员服务器、域控自身的解析路径要统一，别把默认DNS、外部DNS、自建DNS混着用。
4. 管理入口尽量收敛到VPN、堡垒机或专用管理网段，不要让远程桌面直接面向公网长期裸露。
5. 建立系统状态备份、快照和恢复演练机制。要提前明确故障时由谁处理、按什么步骤恢复，而不是只看配置项有没有做上。

账号和运维流程也别省

• 把域管理员账号和日常办公账号分开。平时收邮件、开文档、远程处理普通事务，不要直接用高权限账号。
• 离职、转岗、临时外包账号要有清晰流程，谁提、谁批、谁停用，别靠口头通知。
• GPO按部门、设备类型、环境分层管理。测试机和正式办公终端混在一个策略层里，迟早会出误伤。
• 关键变更要留痕。哪怕没有很重的流程系统，也至少要知道谁在什么时间改过OU、权限、策略。
• 定期检查时间同步、复制状态和事件日志。很多AD故障都有前兆，日志里往往会提前给出提示。

这些事听起来不算高级，但AD能不能长期稳定，很多时候就看这些细节有没有被认真执行。

云上的AD，难点一直都在后半程

很多技术方案前期都像部署题，到了正式运行阶段就变成运维题。云主机跑了一个AD尤其明显。安装角色、提升域控通常不复杂，复杂的是后面一年里它是否稳定、是否可恢复、权限是否收得住、审计能不能跟上。

如果只是为了测试某个应用的域集成，单台云主机当然也能凑合；但只要它开始承载正式办公、账号体系和终端管理，就应该按关键生产系统对待。前面少花的一点机器和规划成本，后面很可能变成认证中断、权限失控或者恢复失败时的成倍代价。

把话说实一点：AD不用想得特别重，也别做得太轻。它不是只有大企业才会用的复杂系统，也不是装完几个功能就能长期省心的Windows服务。边界划清楚，冗余做出来，DNS理顺，恢复练过，再谈“云上跑得稳”。这时候，云上的AD才算真的能落地。