I created a P1
Recently I was working on some security measures for a client. This client uses 20+ RDS servers hosted in Azure which their key users use for their day to day operations.
All of these servers where assigned a Public IP Address. There was no documentation on this, nobody could tell us why. Since there was no good business case to keep them and we didn’t see any direct impact we decided to remove them.
Oops! The next morning nobody could log in to the Microsoft Office 365 Applications and it was clear that these Public IP addresses where used as trusted locations in the Azure AD Conditional Access policies. Specifically the Conditional Access policy that controls on Microsoft 365 Apps in this case.
Using Availability Sets
An easy, quick, cheap and clean solution was the use of Availability Sets.
Read more on Availability Sets here.
So what a lot of people don’t know is that machines using the same availability set are communicating with the same static IP assigned to the availability set.
If you use that IP address for your trusted locations in your “Conditions” controls, Conditional Access exclusions for RDS are made easy. You can’t see the IP of the AVS in the Azure Portal but if you log in to one of your RDS Hosts and use a “whatismyip” service, you’ll have it quick.
Any new machines deployed within the same AVS will automatically be whitelisted by that Conditional Access Policy. You don’t have to add new Public IP’s anymore to every new hosts you deploy, for the sole purpose of having a static outbound IP that you can add to your Trusted Locations.
Note: Make sure you add your machines to an availability set during deployment. After deployment it’s not possible.