Azure Domain Controller (dc) to On-Premise Domain Controller (dc) One-way trust ports for Azure NSG (firewall)

Microsoft Azure

Here is a quick post about what ports you need to open, there direction and protocol if you want to establish a one way trust between an Azure domain and your On-Premise domain. Please note that as of writing this post Azure AD Domain Services does not offer the ability of creating a Domain or Forest trust so you will need to spin up an IAAS virtual machine and create a domain on it. I will also go over some tips if you want to limit the communication between Azure AD subnet (where your domain controllers reside) to only one or two domain controllers in your On-Premise environment, as well as what needs to be configure in order to get Kerberos working. The below ports will need to be opened on the Azure subnet hosting your domain controller and on the On-premise firewall (but in reverse obviously):

Name Priority Source IP Source Port Destination IP Destination Port Protocol Access
Inbound Rules
AD DNS from On-Premise AD 100 On-Premise AD site Subnet * Local Subnet Range 53 * Allow
AD Kerberos from On-Premise AD 101 On-Premise AD site Subnet * Local Subnet Range 88 * Allow
AD LDAP from On-Premise AD 102 On-Premise AD site Subnet * Local Subnet Range 389 * Allow
AD RPC from On-Premise AD 103 On-Premise AD site Subnet * Local Subnet Range 135 TCP Allow
Outbound Rules
AD DNS to On-Premise AD 100 Local Subnet Range * On-Premise AD site Subnet 53 * Allow
AD Kerberos to On-Premise AD 101 Local Subnet Range * On-Premise AD site Subnet 88 * Allow
AD LDAP to On-Premise AD 102 Local Subnet Range * On-Premise AD site Subnet 389 * Allow
AD SMB to On-Premise AD 103 Local Subnet Range * On-Premise AD site Subnet 445 TCP Allow
AD RPC to On-Premise AD 104 Local Subnet Range * On-Premise AD site Subnet 135 TCP Allow
AD dynamic range to On-Premise AD 105 Local Subnet Range * On-Premise AD site Subnet 49152-65535 TCP Allow

*If you are using LDAP SSL you need to open port 636 as well

The above ports and solution will give you a strong and secure environment with the following advantages:

  • No password hashes are kept in the cloud making it more secure
  • Single sign on with On-Premise account
  • Easier user management
  • DNS replication
  • And if you chose to not set up Kerberos which i recommend:
    • Only the Azure domain controllers have access to On-Premise domain controllers (it uses NTLM authentication to proxy requests)

As mentioned above i strongly recommend that you  don’t set up Kerberos authentication between the azure computers and the On-Premise domain and there is a very good reason for that. The lesser of two evils. So for you whats more dangerous using NTLM authentication or opening Kerberos ports from every computer in Azure to your On-Premise domain controllers. For me personally it’s safer to use NTLM and this way the Azure domain controller can proxy requests to the On-Premise domains. However if you want to enable Kerberos you are more than welcome you just need to make sure you open port 88 and 464 from the azure servers to the On-Premise domain controllers.

To make things more secure we can also limit which domain controllers are used for DNS and for LDAP authentication. Before we get into this please read this great article as it will be vital for restricting LDAP authentication. Obviously limiting which dns server we want to use is pretty easy we can just use conditional forwarders instead of stub zones but for LDAP it’s more tricky. For LDAP once you have created an empty zone (with the same names as the Azure zone) you need to go into DNS and modify the SRV records for that zone, usually what you want to do is leave the SRV records for the domain controllers you want to use as they are but set all other domain controllers SRV records with a priority of 10 for the empty zone. This will ensure that the lower priority domain controllers are only contacted unless they are all down in which case you will probably need a disaster recovery plan in which you open the rules to all other domain controllers. Also any new domain controllers you promote will need there SRV priority value adjusted.

Leave a Reply