Sophos made a great article regaring running Sophos XG with Azure AD authentication, here are the steps:
- New features in the XG Firewall v18 MR5 release 06 Apr 2021; Secure SD-WAN with XG Firewall and Azure Virtual WAN 01 Apr 2021; Protecting Sophos customers from HAFNIUM 08 Mar 2021; Kicking off tomorrow – Sophos XG Firewall Academy 2021 25 Jan 2021.
- Go to the Azure Portal and click New in the upper left corner. In the new blade, type Sophos and press enter. In the Everything blade, click Sophos XG Firewall. In the Sophos XG Firewall blade, click on Create. In the Create Sophos XG Firewall blade, Basics section, configure the following.
- XG Firewall on Azure Author: Sophos Subject: Sophos XG Firewall on Azure Quick Start Guide Created Date: 9/20/2016 10:09:29 AM.
Configure Sophos XG Firewall to forward Syslog messages to your Azure workspace via the Syslog agent. In the Azure Sentinel portal, click Data connectors and select Sophos XG Firewall connector. Select Open connector page. Follow the instructions on the Sophos XG Firewall page.
Sophos Xg Firewall Home
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*.
Sophos Xg Firewall Download
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.
Table of Contents
- 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.
- 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.
- 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.
- 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.
Source: Sophos XG Firewall: Integrate XG Firewall with Azure AD – Recommended Reads – Sophos (XG) Firewall – Sophos Community
Sophos Xg Firewall Azure Marketplace
Related Posts