如果企业已经使用本地AD多年，大量应用依赖LDAP或Kerberos认证，迁移到Azure时最怕的就是放弃这套架构重来。Azure AD域服务提供了一条折中路线：它不是把本地域控原样搬到云端，而是将Azure AD里的身份目录投影成一个可用的托管域，支持NTLM、Kerberos、LDAP和组策略。这样本地AD通过同步机制把用户和密码哈希送到Azure AD后，云上应用就能继续沿用传统认证协议。
一、两条集成路线：托管域与自建域控
开始动手前需要区分两个容易混淆的概念：Azure AD域服务（Azure AD DS）和在Azure虚拟机上自建AD DS。前者是微软托管的域服务平台，部署后你会得到一个只读的域控制器集合，可以管理用户、组、组策略对象和部分组织单位，但不能获得域管理员或企业管理员权限；后者则是完全由自己维护的Windows Server域控，拥有完整控制权。
这种权限差异决定了与本地AD的集成方式。Azure AD DS托管域不能像本地域控之间那样随意建立双向林信任，它的身份来源主要是Azure AD，而本地AD通过Azure AD Connect同步到Azure AD后，用户就能在托管域中使用相同的密码和用户主体名。如果应用场景需要严格的本地域信任关系，例如资源域和用户域分离、跨域授权，那么应当选择自建域控，并通过VPN或ExpressRoute与本地AD建立信任。绝大多数以云上传统应用认证为目标的项目，走Azure AD DS加目录同步已经足够。
从成本和管理角度看，托管域省去了域控补丁、备份和可用性设计，但牺牲了一定的灵活性；自建域控成本更高，却能完全复刻本地域的信任结构。后续步骤均以Azure AD DS托管域为主线展开，因为它更符合大多数混合身份迁移的需求。
二、网络与DNS：集成前必须打通的基础
无论选择哪种路线，本地数据中心与Azure虚拟网络之间的网络连通都是前置条件。Azure AD DS必须部署在一个虚拟网络子网中，部署后该子网的地址范围不可更改。本地AD所在的网络与这个虚拟网络之间需要通过站点到站点VPN或ExpressRoute建立私有连接，保证域认证流量不暴露在公网。
DNS解析是整个链路中最容易出问题的一环。Azure AD DS托管域自带了两个域控IP作为DNS服务器，但如果需要解析本地域名，就必须在虚拟网络的DNS设置中配置转发，或者在本地DNS服务器上添加条件转发指向托管域。下面这段PowerShell命令用于创建虚拟网络与本地网关之间的连接，并指定DNS服务器：
# 定义变量
$resourceGroup = "rg-hybrid-identity"
$location = "eastasia"
$vnetName = "vnet-aadds"
$subnetName = "snet-aadds"
$gatewaySubnet = "GatewaySubnet"
$localGatewayName = "lgw-onprem"
$connectionName = "conn-onprem-to-azure"
# 创建虚拟网络和子网
$vnet = New-AzVirtualNetwork -ResourceGroupName $resourceGroup -Location $location `
-Name $vnetName -AddressPrefix 10.2.0.0/16
Add-AzVirtualNetworkSubnetConfig -Name $subnetName -VirtualNetwork $vnet `
-AddressPrefix 10.2.1.0/24 | Set-AzVirtualNetwork
Add-AzVirtualNetworkSubnetConfig -Name $gatewaySubnet -VirtualNetwork $vnet `
-AddressPrefix 10.2.255.0/27 | Set-AzVirtualNetwork
# 创建网关和本地网关并建立连接（实际配置需先创建网关资源）
$pip = New-AzPublicIpAddress -ResourceGroupName $resourceGroup -Location $location `
-Name "pip-vpngw" -AllocationMethod Dynamic
$vnet = Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $resourceGroup
$gatewaySubnetId = (Get-AzVirtualNetworkSubnetConfig -Name $gatewaySubnet -VirtualNetwork $vnet).Id
$gwipConfig = New-AzVirtualNetworkGatewayIpConfig -Name "gwipconfig1" `
-SubnetId $gatewaySubnetId -PublicIpAddressId $pip.Id
New-AzVirtualNetworkGateway -ResourceGroupName $resourceGroup -Location $location `
-Name "vpngw-azure" -IpConfigurations $gwipConfig -GatewayType Vpn `
-VpnType RouteBased -GatewaySku VpnGw1
New-AzLocalNetworkGateway -ResourceGroupName $resourceGroup -Location $location `
-Name $localGatewayName -GatewayIpAddress "203.0.113.10" `
-AddressPrefix @("192.168.10.0/24")
New-AzVirtualNetworkGatewayConnection -ResourceGroupName $resourceGroup -Location $location `
-Name $connectionName -VirtualNetworkGateway1 (Get-AzVirtualNetworkGateway -ResourceGroupName $resourceGroup -Name "vpngw-azure") `
-LocalNetworkGateway2 (Get-AzLocalNetworkGateway -ResourceGroupName $resourceGroup -Name $localGatewayName) `
-ConnectionType IPsec -SharedKey "ChangeThisKey123!"
网络打通后，还需要在Azure虚拟网络的DNS服务器设置中写入托管域的域名解析地址。通常Azure AD DS部署完成后会提供两个IP，例如10.2.1.4和10.2.1.5，将它们配置为自定义DNS服务器。对于本地DNS，可以添加条件转发，将托管域域名转发到这两个IP，完成双向解析。
安全组也不能忽略。如果本地应用需要访问托管域的LDAP或Kerberos端口，必须在网络安全组中放行对应端口，例如TCP 389、636、3268、3269以及UDP 88。默认情况下Azure AD DS会创建自己的NSG，建议在其基础上追加规则，而不是替换整个NSG，否则可能阻断托管域的健康检查。
三、用Azure AD Connect同步本地身份
Azure AD DS的用户来源并不是直接读取本地AD，而是通过Azure AD Connect把本地AD中的对象和密码哈希同步到Azure AD。因此同步策略的设计会直接影响托管域中可用账号的完整性和安全性。对于需要传统认证的场景，必须在安装Azure AD Connect时选择密码哈希同步，而非仅使用传递身份验证或联合身份验证。因为托管域需要可用的NTLM和Kerberos凭据，密码哈希同步会把本地密码的哈希值安全地写入Azure AD，供托管域生成对应的Kerberos密钥。
安装时可以配置OU过滤，只同步需要进入云端的用户和组，避免服务账号或敏感账号暴露。同步规则的调整要谨慎，尤其注意userPrincipalName和sAMAccountName的对应关系。Azure AD DS托管域的域名通常采用Azure AD租户的初始域名或已添加的自定义域，本地用户的UPN后缀最好与其中一个匹配。以下PowerShell命令可查看Azure AD Connect的同步状态和最近的同步周期：
Import-Module ADSync # 查看同步周期设置 Get-ADSyncScheduler # 手动触发增量同步 Start-ADSyncSyncCycle -PolicyType Delta # 查看同步服务状态 Get-ADSyncServerConfiguration | Select-Object -Property ParameterName,Value
同步完成后，可以登录Microsoft Entra管理中心检查用户是否已从本地同步到Azure AD，并确认用户状态为“已同步”。如果在托管域中找不到某个用户，首先排查该用户是否被OU过滤排除，其次检查UPN后缀是否在托管域允许的域名列表中。密码哈希同步的首次全量同步可能需要较长时间，增量同步默认每30分钟运行一次，但手动触发有助于快速验证。
还要注意组策略对象不会通过Azure AD Connect同步到托管域。Azure AD DS提供了一组内置的组策略对象，但本地AD中的GPO需要手动重建或通过自定义配置迁移。对于中小型应用，往往只需要在托管域中新建几个基础GPO即可满足要求。
四、启用Azure AD域服务并完成验证
在目录同步和网络准备完成后，就可以在Azure门户中创建Azure AD DS托管域。部署时必须指定一个专门的子网，该子网不能与其他资源共用，且地址空间要足够容纳两个域控节点。SKU的选择影响性能和可用性，生产环境建议选择Standard或更高SKU，并在创建后根据负载调整。部署过程大约需要30到60分钟，完成后会得到两个IP地址。
下面这段Azure CLI命令展示了如何注册资源提供程序、检查虚拟网络并创建托管域资源：
# 注册资源提供程序
az provider register --namespace Microsoft.AAD
az provider show --namespace Microsoft.AAD --query "registrationState"
# 查看虚拟网络子网信息
az network vnet subnet show \
--resource-group rg-hybrid-identity \
--vnet-name vnet-aadds \
--name snet-aadds \
--query "{addressPrefix:addressPrefix, delegations:delegations}"
# 创建Azure AD DS托管域（需要在已注册完成后执行）
az resource create \
--resource-group rg-hybrid-identity \
--name contoso-aadds \
--resource-type "Microsoft.AAD/domainServices" \
--location eastasia \
--properties '{
"domainName": "aadds.contoso.com",
"subnetId": "/subscriptions/xxxx/resourceGroups/rg-hybrid-identity/providers/Microsoft.Network/virtualNetworks/vnet-aadds/subnets/snet-aadds",
"filteredSync": "Enabled",
"notificationSettings": {"notifyGlobalAdmins": "Enabled"}
}'
部署完成后，可以创建一台Windows Server或Windows 10测试虚拟机，将其加入托管域。加入域时使用已同步到Azure AD的用户凭据，这里有一个常见误区：加入域需要的是托管域本地管理员组的成员，而不是任意Azure AD用户。可以通过Azure AD DS管理控制台或通过分配“AAD DC Administrators”组来授予用户加入计算机的权限。加入域命令仍然使用传统的Add-Computer：
Add-Computer -DomainName "aadds.contoso.com" -Credential (Get-Credential) -Restart
重启后用同步用户登录，运行whoami和klist验证Kerberos票据。如果登录失败，可以检查本地DNS是否指向托管域DNS服务器，以及NSG是否放行了Kerberos端口UDP 88。另一个高频问题是用户密码在本地刚刚修改后，同步存在延迟，这时候需要等待下一个同步周期或手动触发增量同步。
五、常见误区与后续优化建议
很多人以为启用了Azure AD DS就等于把本地域控扩展到了云上，这是一个关键误解。托管域无法直接看到本地AD里的计算机对象，也不会自动复制本地组策略，更不支持架构扩展。它的本质是一个面向传统应用的托管身份服务，而不是完整的企业目录复制品。因此规划时要明确哪些应用必须依赖本地域控，哪些可以迁移到托管域。
安全方面建议开启Azure AD DS的安全审计，并将日志发送到Log Analytics工作区，以便跟踪LDAP查询和登录事件。对于需要LDAPS的应用，要提前准备证书并通过Azure Key Vault导入，同时确保应用信任证书链。托管域的备份由平台自动完成，但组织单位级别的恢复只能提工单，不能自助完成，这一点在灾难恢复预案中必须考虑。
如果后续业务发展需要跨域信任或完整域控权限，可以从托管域迁移到自建域控。迁移路径包括：在Azure虚拟网络中部署Windows Server域控，使用Azure AD Connect继续同步用户，将依赖托管域的应用重新加域，并通过DNS逐步切换。这个过程需要并行运行一段时间，但能补齐托管域的权限短板，适合企业规模较大或合规要求高的场景。
Azure AD域服务本地AD混合身份修改时间：2026-09-28 17:46:52