Subsections of Solutions
Azure AD DS synchronization issues
Problem description
After connecting the Azure network to Acreto and sending all traffic through Acreto vGateway, Azure Active Directory Domain Services managed domain fails to synchronize with Microsoft Windows Active Directory servers.
Symptom 1: Domain synchronization alerts
In Azure, you can see an alert:
Name: The managed domain has not completed synchronization with Azure AD for a long time
Severity: Critical
ID: AADDS500
Symptom 2: Logs contain something
In Azure, you can see an alert:
Name: The managed domain is experiencing a network error
Severity: Critical
ID: AADDS104
Cause
Most likely, your Azure network’s routing table has a default route (0.0.0.0/0
) defined that routes all traffic through Acreto vGateway.
It means that also communication required to synchronize with Azure AD DS is sent through Acreto, and is SNAT’ed (its source IP address is replaced) to Acreto Allocated IP address.
Microsoft detects that synchronization traffic goes from a different source IP address than expected, and blocks that traffic. This breaks synchronization between Azure AD DS and the target server.
Solutions
Solution 1: Separate Azure AD DS virtual network from Acreto networks (recommended)
- Deploy Azure AD DS into a separate virtual network ("ADDS virtual network")
- Configure default route in Azure AD DS to use default Azure gateway
- Deploy Acreto vGateway and resources connected to Acreto into another virtual network ("resources virtual network"), and peer that network to the ADDS virtual network
- Configure routing table in the resources virtual network to push all traffic (0.0.0.0/0) via Acreto vGateway
- In case Acreto users are authenticated using Azure AD DS, ensure that traffic from ADDS virtual network to subnet 100.64.0.0/16 is routed through resources virtual network and Acreto vGateway
See Azure virtual network design for details.
Solution 2: Define static routes on resources
- In Azure routing table, use default value for the route to 0.0.0.0/0
- On each resource (server) that uses Acreto, define a static default route that will go
Solution 3: Define explicit routes to send Azure AD DS traffic through the Azure gateway
Create routing configuration that will route IP addresses from Azure service tags through standard Azure gateway, while keeping default route pointing to Acreto vGateway. You can download a list of Azure IP Ranges and Service Tags – Public Cloud.
See User-defined routes for more details.
See also
Please refer to the following additional material:
Windows Activation failure
Problem description
Windows activation fails when all the Internet traffic goes through Acreto.
This article describes how to resolve the KMS activation problem you might experience when you force all the traffic to go through Acreto.
Symptom
You enable forced tunneling on Azure virtual network subnets to direct all Internet-bound traffic back to your on-premises network. In this scenario, the Azure virtual machines (VMs) that run Windows fail to activate Windows.
Cause
The Azure Windows VMs need to connect to the Azure KMS server for Windows activation. The activation requires that the activation request come from an Azure public IP address. The activation fails in the forced tunneling scenario because the activation request comes from Acreto instead of from an Azure public IP address.
Solution
Use the Azure custom route to route activation traffic to the Azure KMS server to resolve this problem.
The IP address of the KMS server for the Azure Global cloud is 23.102.135.246. Its DNS name is kms.core.windows.net. If you use other Azure platforms such as Azure Germany, you must use the IP address of the corresponding KMS server. For more information, see the following table:
Platform | KMS DNS | IP |
---|---|---|
Azure Global | kms.core.windows.net | 23.102.135.246 |
Azure Germany | kms.core.cloudapi.de | 51.4.143.248 |
Azure US Government | kms.core.usgovcloudapi.net | 23.97.0.13 |
Azure China 21Vianet | kms.core.chinacloudapi.cn | 42.159.7.249 |
How to
Update the route table of the Subnet where Windows VM was created :
-
Login to Azure portal
-
Goto you Virtual network whose subnet’s route table needs to be modified.
-
In the virtual network menu bar, choose Subnets.
-
Select the subnet for which the route table needs to be updated.
-
In the Route table, add the following route :
- Route name - kms.core.windows.net
- Address prefix - 23.102.135.246/32
- Next Hop - Internet
-
Select Save.
Verify
With the custom route, the Window activation traffic goes directly to the Azure KMS server, and the process will be successfully completed.