If you have ever tried searching for how big your Azure Gateway Subnet needs to be you will find conflicting posts about it’s minimum size, you will also find posts stating that the size depends on the features you chose, but they never actually give you a table of what features require what size. For example on github Microsoft recommends that you use a minimum of /27 if you are going to use Expressroute and Siste-Site VPN, while in other articles state that you need /28 as a minimum.

If you are going for ExpressRoute with or without BGP it’s best to contact Microsoft for exact Subnet Ip requirements.

If you are going for the normal Dynamic Routing (route-based) VPN there is an easy way to work out how big your VPN Subnet needs to be. The basic rule is that for every VPN you create one ip address is used from the Subnet. So if you are going to use a “HIGH PERFORMANCE VPN GATEWAY” which has a limit of 30 connection and you want to use all 30 you will need a /26 Subnet, this is because a /27 subnet will only give you ironically 27 free Ip addresses.

So i ran into a little bit of an issue today, i was trying to find out how i can add more network security rules to a network security group (NSG) in the Azure Resource Manager (ARM) mode under Powershell. Now the old trick under the classic mode of using SET wasn’t working (where the rule will be created if it doesn’t exists) as it was giving me an error that the rule didn’t exists, fair enough ADD would be used for new rules and SET to modify existing once, so i tried that but my rules weren’t saving. After some investigating i found out that you also need to SET (by using the pipeline) the Azure Network Security Group in order for the rules to be saved and since i couldn’t find this information anywhere online here is a blog about it with some examples below.

For Azure Powershell 1.0

Using the Add command to add an additional rule to An Azure ARM NSG:

 

Using the Set command to change the Rule (change the above rule to UDP):

 

Using the Remove command to remove a rule:

 

For Azure Powershell 0.9.8

Using the Add command to add an additional rule to An Azure ARM NSG:

 

Using the Set command to change the Rule (change the above rule to UDP):

 

Using the Remove command to remove a rule:

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.

As most of you know trying to find what domain controller ports you need to open between a server/pc and a DC can be a nightmare. Especially if you want to be more specific and include traffic direction. Most of the posts out there give you a bunch of ports and that’s it, no explanation on direction and which once you really need. With this post i am aiming to help anyone one out there who is lost or confused.

With the introduction of Network Security Groups in Azure more and more organization are using them to secure the communications between there Azure subnets, this is a very good practice but can sometimes prove difficult when it comes to complex applications like Active Directory (AD) and it’s port requirements. The firewall rules below will give clients the ability to communicate with a domain controller and fulfill all the required AD functions like login in, joining a computer to the domain, obtaining group policy and so on. Note that these rules are all one way outbound rules from Client to DC, this is always the case with active directory as the client connects to the DC and not the other way around. While these rules are for Azure NSG you can modify and use them with any firewall. Also please note that you would also need to created identical inbound rules on the Domain Controller subnet if you have NSG enabled, it’s also worth noting that azure NSG are stateful.

Name	Priority	Source IP	Source Port	Destination IP	Destination Port	Protocol	Access
Outbound Rules
NTP Sync Primary Domain Controller	100	Local Subnet Range	*	Primary AD site Subnet	123	UDP	Allow
AD RPC Primary DC	101	Local Subnet Range	*	Primary AD site Subnet	135	TCP	Allow
AD Kerberos change Primary DC	102	Local Subnet Range	*	Primary AD site Subnet	464	*	Allow
AD LDAP Primary DC	103	Local Subnet Range	*	Primary AD site Subnet	389	*	Allow
AD LDAP GC Primary DC	104	Local Subnet Range	*	Primary AD site Subnet	3268	TCP	Allow
AD DNS Primary DC	105	Local Subnet Range	*	Primary AD site Subnet	53	*	Allow
AD Kerberos Primary DC	106	Local Subnet Range	*	Primary AD site Subnet	88	*	Allow
AD SMB Primary DC	107	Local Subnet Range	*	Primary AD site Subnet	445	TCP	Allow
AD DYN Primary DC	108	Local Subnet Range	*	Primary AD site Subnet	49152-65535	TCP	Allow

I have set my Domain controllers as NTP servers as per the article here : http://setspn.blogspot.co.uk/2015/06/synchronizing-time-on-azure-virtual.html. If you have not done this step you will need to open a port to what ever NTP server you are using and omit the first rule above.

If you are using SSL for your AD you will also need to add two more rules to the table the LDAP GC SSL on TCP 3269 and LDAP SSL TCP 636. If you are not using SSL you don’t need to include them.

If you are looking to make things more secure and easier to manage you could also restrict RPC traffic to a single port. there is an article on the Microsoft support website https://support.microsoft.com/en-us/kb/224196. Please note that this needs to be applied on all domain controllers, it applies both to replication and client communication. Once implemented you will need to modify the last rule port range from 49152-65535 to what ever port you have chosen like “51515”.

Since Microsoft released a preview version for the Azure AD Domain Services there have been a number of posts asking how to actually manage it and how to access things like GPO and ADUC. Since it’s a very new service there isn’t any how to’s (or i haven’t been able to find them) so here is a quick one:

You first need to deploy the AADDS, but please keep in mind that as of writing this post it’s only available in the US. I am not going to repeat this part as there is a nice post on technet:

http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx#pi168980=3

*Please note that if you are creating a test environment you probably are not going to configure password replication so your username will not work. Easiest way to fix this is to create a “New user in your organization” and add them to the “aad dc administrators” group.

Once you have a AADDC (Azure Active Directory Domain Controller), you will need a virtual machine in the same network or a network which has vnet to vnet VPN with it. Once the VM is up you need to join it to the domain with an account from the “aad dc administrators” group. Once joined you should have Administrators access with the same account you joined it to the domain with. If not please log in with the local account and run “gpupdate /force”. This is because in the AADDS your are not part of Domain Admins, so there is a default GPO which adds “aad dc administrators” as administrators on all domain joined computers.

To use the two features mentioned below you need to log in with a member of the “aad dc administrators” group.

GPO Administration:

To administer GPOs you need to add the Group Policy Management Feature to the machine above:

Once installed you can open the tool and you will see the below default GPOs. Please note that currently you can only edit the two GPOs highlighted in yellow, you also can’t add any filtering to the GPOs or create additional once. You will also not be able to add additional ADMX templates (the 2012  R2 defaults are available)

 

ADUC Administration:

Please note that you have very limited rights in the ADUC. Currently you can only modify certain things in the “AADDC Computers” OU like Adding , Disabling, Resetting, Deleting computer objects.

To administer ADUC you need to add the ADUC Feature to the machine above:

 

As mentioned above currently you are very limited to what you can actually do but as a side note any groups or users you add from the Azure management portal to the Directory will appear in the “AADDC Users” OU.