VSTS - Restrict access by IP

Premise

Keeping the source code safe is as imperative as keeping the applications safe. If your source repository is in cloud and you can’t control who can download the code from where then it’s a big concern for any enterprise.

Visual Studio Team Services (a.k.a VSTS here after), is Microsoft’s cloud based project management tool including requirements management, development lifecycle, build & deployment & a code repository as well. Since it is cloud based, can be assessed from anywhere by developers who has permissions to check-out code which is a big security issue for any company as they would prefer to limit the source code to corporate network only.

Solution

VSTS as a product in itself doesn’t have this feature to limit access to white-listed IPs. Although, this can be achieved with a hybrid use of Azure Active Directory (a.k.a Azure AD here after).

VSTS supports two forms of authentication, either you manage the users in VSTS directly or you connect VSTS to an Azure AD and perform the user management tasks there. The latter is what we are going to use to achieve our goal.

Pre-requisites

1. VSTS subscription with owner or service administrator permissions
2. Azure subscription with owner or service administrator permissions
3. Azure AD Premium with admin permission

(Note, in 1 & 2, same Microsoft account should have these permissions as Azure subscription automatically picks up the VSTS subscription connected to the account)

Configuration

In order to limit VSTS access to white-listed IPs, we are going to use “Conditional Access” feature of Azure AD. The reason we require premium Azure AD subscription is because conditional access feature is only available in premium.

Step 1: Configure VSTS to use Azure AD for authentication.

I do not wish to repeat these steps as there is a very nice official MS article available with pretty pictures to achieve this. Please follow the steps mentioned in below article.

https://www.visualstudio.com/en-us/docs/setup-admin/team-services/manage-organization-access-for-your-account-vs

Step 2: Enable Conditional Access in Azure AD for VSTS.

1. Sign in to the Azure CLASSIC portal using an account that is a global administrator for Azure AD.
2. On the left pane, select Active Directory.
3. On the Directory tab, select your directory.
4. Select the Applications tab.
5. Select the application (VSTS) that the rule will be set for.
6. Select the Configure tab. You should see a screen like below:-

    

    First turn “Enable Access Rule” ON. Click “All users” or “Groups” depending upon your requirement. I did for all users. Under Rules, select the last radio button as “Block access when not at work”.

    Then click the link below as “Click here to define/edit your work network location” and you should see a screen shown below. Here you can add the IPs to which you wish to restrict the access.

    Enter your IP address range in CIDR format. I was sitting on home WIFI so just added my single IP there. Scroll down and click Save. Go back to the previous screen and Save the settings.

     

    (There are more settings available on this screen for conditional access like MFA when not on corporate network, device registration or recognition. You can all select whatever you want but in my case, I only configured the IP range to which I wish to restrict access of VSTS)

     You have now successfully enabled “Conditional Access” on VSTS. Go back and try to login into your VSTS from an IP not listed above and you should see below message post login.

     

    
Neat right.

     Although, post this configuration this is obvious but just repeating, conditional access is a feature of Azure AD and not VSTS and hence it can be applied to any applications which is using Azure AD (premium) for authentication like Office 365 or any other app.

     Hope this helped and let me know if you face any issue while configuring this.

Microsoft Azure - Remote Desktop Solutions (Part 2)

In my previous blog, I discussed two solutions available to allow remote access to your end users into your environment. In this blog, we will discuss the second option called Remote Desktop Services.

Remote Desktop Services (RDS), formerly known as Terminal Services, is a server role in Windows Server that provides technologies that enable users to access session-based desktops, virtual machine-based desktops, or applications in data centre from both within a corporate network and from the internet.

RDS is officially supported on Microsoft Azure since 2014 and with the release of Windows 2016, it now offers even more flexibility, cost efficiency and extensibility.

Depending on your environment and preferences, you can set up the RDS solution for session-based virtualization, as a virtual desktop infrastructure (VDI), or as a combination of the two:

• Session-based virtualization : Leverage the compute power of Windows Server to provide a cost-effective multi-session environment to drive your users’ everyday workloads

• VDI : Leverage Windows client to provide the high performance, app compatibility, and familiarity that your users have come to expect of their Windows desktop experience. VDI can be deployed in various flavours, I will discuss those later in this blog.

Within these virtualization environments, you have additional flexibility in what you publish to your users:

• Desktops : Give your users a full desktop experience with a variety of applications that you install and manage. Ideal for users that rely on these computers as their primary workstations or that are coming from thin clients, such as with MultiPoint Services.

• RemoteApps : Specify individual applications that are hosted/run on the virtualized machine but appear as if they’re running on the user’s desktop like local applications. The apps have their own taskbar entry and can be resized and moved across monitors. Ideal for deploying and managing key applications in the secure, remote environment while allowing users to work from and customize their own desktops.

Below is a high level architecture of an RDS deployment and it components

In above RDS architecture, below three core roles are required to setup an RDS environment:-

• Remote Desktop Session Host (RDSH): The Session Host allows a server to host session-based desktops or RemoteApp programs. Applications are installed and published from the Session Host servers.
• Remote Desktop Connection Broker [RDCB]: This role handles user sessions by load balancing among the RD Session Host servers. Also allows disconnected users to reconnect to their existing sessions without starting a new one.

• Remote Desktop Web Access [RDWA]:   This role provides a web portal to access the RDS environment. Also allows Windows 7 & 8 desktops to connect using the  RemoteApp and Desktop Connection.

• Remote Desktop Gateway [RDG]:  This role enables remote users to use the Remote Desktop Protocol (RDP) over HTTPS. It is placed on the edge of your network and acts as the entry point to your RDS environment externally.

• Remote Desktop Virtualization Host [RDVH]:  This allows RDS integration with a Hyper-V hypervisor to manage virtual desktops.

• Licensing: RDS comes with a 120 day trial period. When the trial period ends RDS will no longer accept connections. The RDS License role handles the licensing for RDS. It manages the Remote Desktop Services client access licenses (RDS CALs) that are required for each device or user to connect to a Remote Desktop Session Host (RD Session Host) server. You use RD Licensing to install, issue, and track the availability of RD CALs on a Remote Desktop license server.

Now, coming back to VDI deployment flavours. Windows Server 2016 offers the following deployment scenarios:

• Virtual machine (VM)–based.  In this scenario, Windows 10 VMs run in a Hyper-V infrastructure. You use Remote Desktop Services to provide users remote connectivity to the VMs. You can use the VM-based deployment scenario with pooled or personal VM collections.

• Session-based.  In this scenario, remote users connect to Remote Desktop Services in Windows Server 2016 and run their application in Windows Server 2016 sessions. Only Remote Desktop Services is required for this scenario.

	Session-based Desktop Deployment	Windows MultiPoint Server 2012	VM-based Desktop Deployment
User operating system experience	Windows Server 2012 R2	Windows 8.1	Windows 8.1
Support for full-fidelity video, with coverage for all media types and highly synchronized audio, rich media support, Microsoft Silverlight, 3D graphics, and Windows Aero	Microsoft RemoteFX	Requires direct video–connected stations, USB zero client–connected stations, USB-over-Ethernet zero clients, or RDP–over-LAN with RemoteFX	Requires RemoteFX
Directly connect the VDI session to client USB devices	Standard RDP connection provides limited support of USB device RemoteFX required for broader support of USB devices	Standard RDP connection provides limited support of USB device Direct video–connected stations, USB zero client–connected stations, USB-over-Ethernet zero clients, or RDP-over-LAN with RemoteFX required for broader support of USB devices	Standard RDP connection provides limited support of USB device RemoteFX required for broader support of USB devices
Supported client devices	Any device that supports RDP or RemoteFX (including Windows Thin PC)	Supports the following: Direct video–connected stations USB zero client–connected stations USB-over-Ethernet zero clients Any device that supports RDP or RemoteFX	Any device that supports RDP or RemoteFX (including Windows Thin PC)
Scaling	As many as hundreds of users for each server, but multiple servers can be added to scale to higher numbers	As many as 20 users	Up to hundreds of users for each server, but multiple servers can be added to scale to higher numbers
High availability	Supports load balancing and clustering of resources	Unavailable	Supports load balancing and clustering of resources

Also, below table provides a comparison of Pooled and Personal Virtual Desktop Collections.

	Pooled	Personal
Changes are made to	Transient virtual hard disk	VM virtual hard disk
Changes saved after session ends	No (except for user profile changes)	Yes
VM instances	Single VM master image that all users in the collection share	Separate VM instances created from a mater VM for each user
Number of images to manage	One master image	An image for each user (after the VM instance is created)
Infrastructure services	Managed network Remote Desktop Services HyperV	Managed network Remote Desktop Services HyperV
Network connectivity	Support standard Remote Desktop Services by using low-bandwidth connections RemoteFX connection requires medium- to high-bandwidth connections (depending on content being displayed)	Support standard Remote Desktop Services by using low-bandwidth connections RemoteFX connection requires medium- to high-bandwidth connections (depending on content being displayed)
Storage requirements	Storage for master image and transient virtual hard disks Storage for each User Profile Disk (if used)	Requires separate VM storage for each user; if the average storage for the master VM is 100 GB and there are 100 users, 10 TB of storage will be required
Manageability	Only one image to manage, so use stand-alone image-management tools; changes to the master image are reflected the next time a session is initiated	Manage by using technologies and products such as Group Policy, Windows Server Update Services, or Microsoft System Center 2012 R2 Configuration Manager
User flexibility	Users cannot install apps Users cannot be an administrator on their VM	Users can install apps Users can be an administrator on their VM
User profile storage	Transient virtual hard disk (VHD; user profile changes are lost) User Profile Disk (user profile changes are retained)	Stored and retained in the VM VHDs
User, operating system, and app configuration management	Roaming Profiles Folder Redirection Microsoft User Experience Virtualization (UE-V) Microsoft Application Virtualization (App-V) User Profile Disk	Roaming Profiles Folder Redirection UE-V App-V Locally stored on VM

As mentioned earlier, Azure has added supported quite a while back and a standard deployment of RDS on Azure looks like below:-

A highly available deployment that contains all necessary components to have the highest guaranteed uptime for your RDS environment will look like below:-

Hopefully, this would have given you a high level overview of RDS services. You can read more about it and what’s new is available in RDS 2016 on Microsoft official pages. A quick summary is available on a poster here.