Client/Server to Domain Controller (dc) ports for Azure NSG (firewall)

Microsoft Azure

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 : 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 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”.

Accessing GPO and ADUC interface for Azure AD Domain Services (AADDS)

Microsoft Azure

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:

*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.


Virtual machine as nfs (ISO) server for host esxi server



This is an old post i made on the VMware communities earlier this year, i am re-posting it as i don’t want it to get buried, given the amount of post they get in a day :D.

So I decided to post an observation i made during a non standard ESXI setup (couldn’t find anything about it so i am making a post).

This is not a fault or a question more of a discussion.

The circumstance below are due to the limitation of having only one server in a remote site.

What i noticed and i am pretty sure this is not supported or recommended, is that when you have a virtual machine on an esxi host that presents (as a datastore) a NFS full of ISO to VMWare (the esxi host) the machine hosting the NFS cannot use the ISO.

What i mean by the above is if you try and mount an ISO from the NFS datastore on the virtual machine hosting them it will lock up. Now if you try and mount it on any other Virtual machine it’s fine no problem.

The bellow diagram show our setup.

I assume it has something to do with the reconfiguration of the virtual machine when you mount the ISO, maybe a microsecond downtime for it to mount and due to this downtime the ISO presented becomes unavailable and in turn locks up the mount, it’s worth noting when i say it locks up the entire virtual machine locks up. Eventually vmware does pop up a message and ask if i should cancel the mount as it noticed that it’s causing problems. Maybe someone with better understating than me can explain why this behavior occurs.


Now i know there are other ways of doing this like putting the images directly on the datastore but our situation requires that ISO s are synced on regular bases so we use DFS to sync from main site and NFS(usually located on different server) to present to ESXI servers.


VMware virtual nfs to same esxi