Azure Active Directory Domain Services (AADDS) | Domain Join for external Windows Client Workstations with P2S VPN at Logon Screen established
First I must tell you, that even it is possible to join your windows client workstations to AADDS, Microsoft itself does not recommend this deployment!
They recommend for windows 10 devices Azure AD Join
- Azure AD Join is better suited for mobile clients (e.g. tablets, laptops)
- Supports BYO devices
- Devices are managed using MDM (Intune)
- Works even in the absence of VPN/ExpressRoute connection. More resilent to VPN/ExpressRoute outages.
The main reason for AADDS is to expand your on-Premise network to the cloud and join Azure virtual machines to the Azure AD Domain. Therefore you can use your corporate credentials to log-in to VMs, no need for local administrator accounts. Further you can use GPOs to manage & secure domain joined VMs.
Another main reason to use AADDS is to migrate on-prem applications to Azure VMs. Most of them support LDAP Authentication and can therefore migrated to Azure and users are still able to use their existing corporate credentials. The app is deployed in Azure transparent to end-users.
Even the new AADDS domain is a different Active Directory Domain and using a different primary security identifier (SID) as your on-prem Active Directory, Applications referencing to that SID can still authenticate the users from on-prem because users will be automatically synchronized from Azure AD including the SIDHistory attribute to AADDS. The SIDHistory Attribute includes the on-prem SID so that the user had two identities, the on-prem and the new azure ad domain.More about was presented at Ignite in New Zealand in 2016.
https://channel9.msdn.com/Events/Ignite/New-Zealand-2016/M248
If you still want join external windows client workstations to your Azure Active Directory Domain Services (AADDS) instance, the most convenient way to do this, is from inside your on-Premise network.
The on-Premise network needs to be connected over an IPSec-VPN or Azure ExpressRoute to the Azure VNet from AADDS. In order for domain join is working, you need to create a DNS stub zone or conditional forwarder for the Azure AD Domain. The client must be able to resolve the Azure AD Domain in an IP for one of the two domain controller VMs, which are behind the AADDS.
But what if I had no on-Premise network or do not want one and prefer a Cloud-Only solution?
In that case you must be able, for domain join to be working, to establish a point-to-site P2S VPN Connection from logon screen.
Therefore you must setup RADIUS authentication for your Point-to-site configuration and install the Network Policy and Access Services (NPS) Server Role within a Windows Server VM in your VNet. The NPS Server Role is Microsofts implementation of a Remote Authentication Dial-In User Service (RADIUS).
For the first part of domain join, the default Azure VPN client and connection from logged in account is working.
After successfully established the vpn connection, you must determine the gateway to your subnet from the domain controllers of the AADDS instance.
We need the gateway for the second part of the domain join. The Azure VPN Client did setup the routing for you behind the scenes using the CMROUTE.DLL and a textfile with routing informations to update your routing table during establishing the connection.
You will see these files later when we must determine the VPN Host FQDN for the second part of domain join.
Here you can see my IP Address from my P2S VPN Connection. It is one of the Address pool you had defined in the Point-to-site configuration in Azure.
Now we can use a trace to determine the Gateway we use to reach our domain controllers. The domain controllers IPs you will find at the properties of your Azure AD Domain instance. An instance is using two domain controllers.
So try one of the IPs to trace
You can see that the Gateway IP is in my case 172.32.0.1 and the subnet of the domain controllers are 172.30.20.0/24.
Because we must setup for the second part manual the Azure P2S VPN Connection, we lost the update of the routing table at establishing the connnection. This update was only temporarily and is lost after disconnecting the vpn.
So we can update the routing table manual and permanent with the netsh command.
Before we can update the routing table, we must create the manual vpn connection. With netsh you must specify the Interface Name of the VPN Connection resp. adapter.
The manual setup of the Azure P2S VPN Client we can do with PowerShell in a few steps.
As you already extracted and installed the VPN Client Package, we use here the EAP-MSCHAPv2 Package, you must also extract the VpnClientSetupAmd64.exe Install File and see further following files:
Btw. you can also see here the above mentioned cmroute.dll and routes.txt files.
For setup manual the P2S VPN, open the *.pbk file with an text editor. Inside you will find the PhoneNumber parameter which contains our FQDN of the VPN Host for dialin. So note this FQDN.
Further you will see the *.cer File which is the Root Certificate from the corresponding Server Certificate of the VPN Host.
Install this Root Certificate to your Trusted Root Certification Authorities Windows Store if not already present.
Now we can create our manual Azure P2S VPN Connection with PowerShell. For the Serveraddress use the noted FQDN above and for Authentication Mode use Eap.
The parameter -AllUserConnection will make this connection available at logon screen. The -TunnelType Automatic will first try to connect over IKEv2 and if not successful due to maybe some firewall restrictions outbound on client side will fall back to SSTP.
Add-VpnConnection -Name AzureP2S -ServerAddress azuregateway-foobar.vpn.azure.com -AllUserConnection -SplitTunneling -AuthenticationMethod Eap -TunnelType Automatic -EncryptionLevel Required -PassThru
Because as mentioned above we lost the update of the routing table without to establish the vpn connection over the native Azure P2S vpn client, we must setup the routing ourselves with the netsh command and the Gateway and Subnet we noted above. Further we need the Interface Name of the VPN Connection which is the -Name parameter of the Add-VpnConnection Cmdlet.
netsh interface ipv4 add route <IP address/mask> “Interface Name” <IP Gateway> metric=1 | metric optional
netsh interface ipv4 add route 172.30.0.0/16 “AzureP2S” 172.32.0.1
You can see that I added the complete /16 Subnet to my routing table and not only the 172.30.20/24 Subnet, in which the domain controllers reside. That’s because I want to access the whole address space of my VNet and not only the subnet of AADDS. But for domain join of course the subnet with the domain controllers are critical and mandatory.
So now we can do the domain join! First part you can use the native or as now created the manual VPN P2S Connection to establish a connection to our Azure VNet.
If you want to be sure to reach the domain controllers, you can execute an trace or ICMP Echo request (PING) to the Azure AD Domain and should get an ICMP Echo reply from one of the domain controllers. If not check your DNS Servers from the Azure VNet, they must be able to resolve the Azure Ad Domain and be accessible from your P2S subnet.
Join your Windows 10 client as usual to the domain and restart the computer to finish the first part!
After restart to complete the domain join, we must be able to connect with a domain admin user directly against a domain controller. Therefore we must be able to establish the Azure P2S vpn connection from the logon screen. This is not possible with the native Azure P2S vpn client as mentioned and therefore we created with Add-VpnConnection PowerShell Cmdlet the manual P2S vpn connection and the -AllUserConnection parameter.
Please note that this connection is only available at logon screen after domain join, despite setting the -AllUserConnection. So if you will test if the connection is at logon screen available before domain join, don’t wondering that you can’t see it there!
The first part was connecting with the native Azure P2S VPN and domain join.
Now comes the second part with the initial first logon against the domain controllers after the domain join.
Therefore we have now our manual created Azure P2S VPN Connection at the logon screen and can use a domain admin user from the Azure AD Domain to logon to windows 10. So click on the icon with the two monitors at the bottom on the right for the Network sign-in.
Here you can see the Network sign-in and the name of our created Azure P2S VPN Connection. In my Case AzureP2S. Enter your domain admin user account like username@azuredomain.tld and your password.
The username and the password will be verified.
The connection is established and the local profil for the domain admin user will be created
That’s it!
Below you will find some useful and interesting links about all this.
Links
Configure a Point-to-Site VPN connection to a VNet using native Azure certificate authentication: Azure portal
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portalConfigure a Point-to-Site connection to a VNet using RADIUS authentication: PowerShell
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-how-to-radius-psIntegrate Azure VPN gateway RADIUS authentication with NPS server for Multi-Factor Authentication
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-radius-mfa-nspEnable Azure Multi-Factor Authentication (MFA) for VPN users
https://docs.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-mfaNew-EapConfiguration
https://docs.microsoft.com/en-us/powershell/module/vpnclient/new-eapconfiguration?view=win10-psAdd-VpnConnection
https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconnection?view=win10-psCreate and install VPN client configuration files for P2S RADIUS authentication
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-vpn-client-configuration-radiusDeconstructing the Azure Point-to-Site VPN for Command Line usage
https://dougrathbone.com/blog/2013/11/27/deconstructing-the-azure-point-to-site-vpn-for-command-line-usageMicrosoft Azure P2S VPN Client (Non Admin)
https://www.itninja.com/software/microsoft/azure-p2s-vpn-client-non-admin/1-16669Azure Point-to-Site VPN with RADIUS Authentication
https://thetechl33t.com/2018/01/08/azure-point-to-site-vpn-with-radius-authentication/Configure a Point-to-Site connection to a VNet using RADIUS authentication: PowerShell
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-how-to-radius-ps
