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.