Sophos Firewall: Integrate Sophos Firewall with Azure AD

Overview

This document is applicable to all the XG Firewalls running all versions. To integrate the XG firewall with Azure AD, we need to create a new service called “Azure AD Domain services”.

With this integration, administrators can use Azure AD for the following:

Captive portal authentication of internal firewall users.
Authentication agent for windows, mac, linux.
SSL VPN authentication.
Sophos Connect client.
Use the SSO using the Synchronized security UserID*.

Note: SSO with synchronized security and Azure AD needs to meet some specific requirements which are outside the scope of this document.

Azure AD DS replicates identity information from Azure AD to a Microsoft-operated set of domain controllers, so it works with Azure AD tenants that are cloud-only, or synchronized with an on-premises AD DS environment. The same set of Azure AD DS features exists for both environments.

Azure AD domain services offer an LDAP interface to XG that can replicate the working of an on-premise Active Directory. This article assumes there is an existing Azure AD environment in place.

Overview
Azure configuration
Firewall configuration

Azure configuration

Login in to the Azure portal and create Azure AD domain services, this step will take 60-90 minutes to deploy. Please see the documentation from Microsoft on how to deploy Azure AD domain services.
Once the AD domain services are deployed, you should see the health status as “Running”.
Click on Synchronize, you can either select scoped or chose to synchronize all the Azure AD.

Note: The following step is required for cloud-only user accounts in Azure AD, as the Azure AD account is not synchronized with AD domain services until the user has changed the password by logging in to their office365 login. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD.
Each user needs to login to the Office 365 portal and change the password. If it’s a new user logging into office 365 for the first time, they will be prompted for the password change.
Once the AD domain services are deployed, it's recommended to enable LDAPs if the firewall is sending LDAP bind request over the internet. For additional security, Sophos recommends creating an IPsec tunnel to Azure over which to bind the LDAP.

Note: Azure accepts self-signed certificates for this purpose. In this example, we use OpenSSL to generate a self-signed chain of certificates. Azure only accepts certs with “extendedkeyusage for server authentication”.

Below is the process to generate self-signed Certs with EKU:serverauth:
- In order to create the Certificate Authority Private Key and Certificate, you first need to create a private key for the CA with the name azureADca.key.
  
  $ openssl genrsa -out azureADca.key 4096
  Generating RSA private key, 4096 bit long modulus
  ..........................................................................................................................................................++
  ................++
  e is 65537 (0x10001)
- Create the CA certificate to be used to validate signed certificates, called azureADca.pem.
  
  $ openssl req -x509 -new -nodes -key azureADca.key -days 3650 -out azureADca.pem
  You are about to be asked to enter information that will be incorporated
  into your certificate request.
  What you are about to enter is what is called a Distinguished Name or a DN.
  There are quite a few fields but you can leave some blank
  For some fields there will be a default value,
  If you enter '.', the field will be left blank.
  -----
  Country Name (2 letter code) []:CA
  State or Province Name (full name) []:ON
  Locality Name (eg, city) []:Burlington
  Organization Name (eg, company) []:<Your org>
  Organizational Unit Name (eg, section) []:Salesengineering
  Common Name (eg, fully qualified host name) []:<Commaon name>
  Email Address []:email@email.com
- Create a text file and copy/paste the below text. Save the file as “azureAD-eku.conf” or any name of your choice.
  
  [client_server_ssl]
  extendedKeyUsage = serverAuth
- Now that this file exists, you need to generate a private key for the LDAP cert with the name “ldapssl_private.key”.
  
  $ openssl genrsa -out ldapssl_private.key 4096
  Generating RSA private key, 4096 bit long modulus
  ...................................++
  ..........++
  e is 65537 (0x10001)
- Next, create a certificate signing request to sign with the CA you previously created with the name “azureADldapssl.csr” and fill in the following values in yellow.
  
  $ openssl req -new -key ldapssl_private.key -out azureADldapssl.csr
  You are about to be asked to enter information that will be incorporated
  into your certificate request.
  What you are about to enter is what is called a Distinguished Name or a DN.
  There are quite a few fields but you can leave some blank
  For some fields there will be a default value,
  If you enter '.', the field will be left blank.
  -----
  Country Name (2 letter code) []:CA
  State or Province Name (full name) []:ON
  Locality Name (eg, city) []:Burlington
  Organization Name (eg, company) []:firewallinabox
  Organizational Unit Name (eg, section) []:Sales Engineering
  Common Name (eg, fully qualified host name) []:<yourdomainname>
  Email Address []:<email@email.com>
  
  Please enter the following 'extra' attributes
  to be sent with your certificate request
  A challenge password []:<Password>
- You now need to sign the request, while including the signing extensions created earlier. The following command will create the signed cert with the name “azureADcert.crt”.
  
  $ openssl x509 -req -extensions client_server_ssl -extfile azureAD-eku.conf -in azureADldapssl.csr -CA azureADca.pem -CAkey azureADca.key -CAcreateserial -out azureADcert.crt -days 365
  Signature ok
  subject=/C=CA/ST=ON/L=Burlington/O=firewallinabox/OU=Sales Engineering/CN=firewallinabox.tk/emailAddress=email@email.com
  Getting CA Private Key
  $
- Convert the certificate into PFX format, as Azure accepts the certs in the PFX format.
  
  $ openssl pkcs12 -export -out XGazureADcert.pfx -inkey ldapssl_private.key -in azureADcert.crt -certfile azureADca.crt
  Enter Export Password:
  Verifying - Enter Export Password:
- Next, upload the XGazureADcert.pfx file into Azure AD.
Under Azure AD domain service, navigate to properties and make a note of the following, Secure LDAP external IP address. If you are connecting through an IPsec tunnel, you can use the internal addresses which are 10.201.1.4 and 10.201.1.5 in this example.
Make sure the admin group is selected with the correct administrator group used on the XG to send LDAP bind requests to AD domain services.
In the Azure portal, navigate to Azure AD > Users and make sure the user is part of the AAD DC Administrators group inside Azure AD.
In the Azure portal, navigate to the Network security groups > Inbound security rules, then add a new inbound security rule allowing the LDAPs traffic from your firewalls public IP. (This is optional and only required if you are using an IPsec tunnel for additional security).
The administrator account you will be using on the XG Firewall must be first logged in to Office365, and the password needs to be changed upfront.

Firewall configuration

Login to the XG Firewall web UI and navigate to Configure > Authentication > Servers > Add and use the following settings we have from the Azure AD domain services.
Import the groups from Azure AD as shown below.
Select the server from the list of authenticated servers from Configure > Authentication > Services.
Test the authentication with the user portal and the login should be successful.