Enterprise Network segmentation is a concept that dates back to the start of enterprise IT systems. The simplest demonstration of this is separating application and infrastructure components between the different Business Units and departments in the enterprise. The small resource entity hierarchy tree shown in the architecture diagram shows the management group based separation between the business units.
In the conventional defense strategy, networking was used as the first line of defense. This strategy has changed now with the network based security shifting right and the Identity based security becoming the first line of defense.
Implementing a clear access control mechanism to control access to the Cloud resources (primarily IAAS and the PAAS resources that are exposed strictly through the private network) based on the identity of the users brings these 2 controls into the mix.
In our scenario,
- Azure AD would have groups clearly separated by the Business Units or Departments with each group having the corresponding users, service principals etc.,
- We have segmented the Azure Network into two VNETS (HR and IT) that would host the infrastructure of the departments respectively.
- There would be a Hub Network that hosts the Active Directory Domain Services common to the several peered department VNets. The ADDS would host a managed domain, contoso.internal.net for an example.
- The ADDS components have a defined one-way synchronization setup with Azure AD (synchronization of changes always flow from AAD to ADDS and never the other way round)
- Each of the Spoke Networks will have a Gateway Subnet that would host a route based VPN Gateway that helps in creating the S2S and P2S connections with Clients
- Each of the Spoke Networks would also have a Radius Server that would help in establishing Radius Authentication (more on RADIUS AuthN in a bit,). The Radius Server would be domain joined to the managed domain. This is an important step as the Radius server needs to connect to the ADDS to complete the authN verification
Quick refresher on AAD & ADDS
Azure Active Directory Domain Services (ADDS) is one of the Identity modernization techniques suggested by Microsoft when maintaining Hybrid Identities (connected & disconnected). ADDS lets us create a managed domain on Azure and synchronize users and groups from Azure AD to offer authentication services. Users and groups can be the security groups created natively in AAD or synced from an on-premises AD DS environment using Azure AD Connect before being synchronized to the Azure AD DS managed domain. Note: ADDS is designed to have an one-way communication with AAD and requires the credentials (inclusive of the password) to be synced to its AD store. Hybrid authN setup with PTA (Pass-through Authentication) and PTA with ADFS wont work in this setup.
All users and groups from an Azure AD directory are synced to the managed domain by default. If you have particular requirements, you may opt to synchronize just a subset of users. For our scenario, we will be synchronizing only the Groups (HR, Admin and IT) whose users need to authenticate and get access to the cloud resources.
What is a Radius Server AuthN and its application in Az P2S VPN
Remote Authentication Dial-In User Service (RADIUS) is a client-server networking protocol that runs in the application layer. The RADIUS protocol uses a RADIUS Server and RADIUS Clients. A RADIUS Client (or Network Access Server) is a networking device (like a VPN concentrator, router, switch) that is used to authenticate users. A RADIUS Server is a background process that runs on a UNIX or Windows server. It lets you maintain user profiles in a central database. Hence, if you have a RADIUS Server, you have control over who can connect with your network.
When a user tries to connect to a RADIUS Client, the Client sends requests to the RADIUS Server. The user can connect to the RADIUS Client only if the RADIUS Server authenticates and authorizes the user. The working of the RADIUS Server depends on the exact nature of the RADIUS ecosystem. However, all servers have AAA capabilities (Authentication, Authorization, and Accounting). In some RADIUS ecosystems, a RADIUS Server can also act as a proxy client to other RADIUS Servers.
Reference & for more reading on Radius server: https://www.getkisi.com/guides/radius-server
- Administrators do not want to be handling the distribution, installation, expiration and renewal of certificates in hundred’s of client machines
- Many customers have a requirement to avoid the native “Sync-all” behavior as this causes many unnecessary users/groups to be synchronized into the managed domain. Sometimes this can be concerns based on Security as well
- Often, administrators want only those users who expect to work with apps secured by Azure AD DS to be synchronized into the managed domain
- For customers who are concerned about the additional infrastructure to be maintained (Radius servers per network), Azure AD native authentication for P2S can be an easier solution, however Native Azure AD authentication is only supported for OpenVPN protocol and Windows 10 and requires the use of the Azure VPN Client. Not all environments support OpenVPN yet and the Operating system support list needs to expand.
The solution would talk about how can the Radius server uses Network Access Policies that can help in authenticating and authorizing the users based on the ADDS credentials. The credentials that the user would use (Username and the password would still be the same as that of AAD. Only the home realm would change to the managed domain).
We need to install the Network Policy & Access Server role on the radius server and then configure the required settings to allow the Azure VPN Gateway to authenticate user connection requests against ADDS.
A new Network Policy called “Grant Access Network Policy” needs to be created in each Radius server that would dictate the controls specific to the Virtual Network that it authenticates the connections requests for. The policy grants access to a user if the policy requirements are met, specifies the type of connection (VPN), a specific group that users must be a member of to be authenticated (VPN Users), constrains the authentication method to EAP-MSCHAPv2, and finally specifies that the VPN Gateway will issue an IP address to the client from the VPN client address pool.
Grant Access Network Policy Network Access Server : Remote Access VPN Server AuthZ Condition: Contoso.Internal\HRAdminsGroup Authentication Method: Microsoft Secure Password (EAP- MSCHAP v2)
Next create a new RADIUS client which specifies the Azure VPN Gateway as the requester, specifies the same shared password we input into the Azure VPN Gateway settings, and enables the Domain Controller/NPAS to begin fielding RADIUS requests.
Once the VPN Gateway and RADIUS server are configured, we then install the VPN client from the Azure Portal on various end-user PC’s and used it to connect to the Azure environment.
Security Validation & Verification
With this solution, the users of a specific group will have access to the networking resources that are allocated to them and nothing more e.g., The HR department users cannot login and get connected to the VNET that is provisioned for IT. After being connected (passing the identity line of defense) the users will now have all the network level access controls that would dictate the ingress and egress restrictions at L3 & L4.