Sophos Utm Azure

Posted on  by admin

Sophos made a great article regaring running Sophos XG with Azure AD authentication, here are the steps:

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:

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

Oct 05, 2016 The deployment of the Sophos XG firewall appliance through the new Azure Portal only allows up to two network interface cards. If you will like to have more than two networks connecting to the XG firewall, you’ll need to do a programmatic deployment. Azure AD is Microsoft’s cloud-based identity and access management service. You must get consent and authorization from your Azure AD Admin to use your companies Azure AD with Sophos Central. You must have a Central login that matches your Azure AD login (the emails must match).

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

Pre-requisites required to use Azure AD Federation for your method of authentication: You must have an Azure Active Directory account with Microsoft. Azure AD is Microsoft’s cloud-based identity and access management service. You must get consent and authorization from your Azure AD Admin to use your companies Azure AD with Sophos Central. The Sophos XG Firewall data connector allows you to easily connect your Sophos XG Firewall logs with Azure Sentinel, to view dashboards, create custom alerts, and improve investigation. Integration between Sophos XG Firewall and Azure Sentinel makes use of Syslog.

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

  1. 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.
  2. Once the AD domain services are deployed, you should see the health status as “Running”.
  3. 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.

  4. 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.
  5. 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 protected]

    • 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 protected]>

      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/[email protected]
      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.
  6. 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.
  7. 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.
  8. 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.
  9. 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).
  10. 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.
  1. 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.
  2. Import the groups from Azure AD as shown below.
  3. Select the server from the list of authenticated servers from Configure > Authentication > Services.
  4. 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

Related Posts

Sophos UTM firewall can be configured to use Azure MFA for Two-Factor authentication.

After installing MFA extension with the help of great guide from Microsoft: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension you only need to define couple of settings in UTM and enable policies in NPS server to get it working.

Unfortunately I only were able to set it up using PAP as authentication method. I believe this is limitation on UTM.

Here are steps I took to accomplish this.

First add your Sophos UTM as RADIUS client on NPS server.

I am assuming that NPS server is located in IP address 192.168.100.100 and Sophos UTM is used as GW for this network with IP address 192.68.100.1

Add Sophos UTM Firewall as RADIUS client. Use UTM’s IP for the network as client IP. Select long shared secret (UTM supports up to 48 characters).

Next create connection request policy for the UTM.

Select Authenticate requests on this server.

Under conditions add UTM’s IP as Client IP

Leave rest of the settings as default.

Azure Sentinel Sophos

Next you’ll have to create Network policy for SSL VPN authentication traffic.

I created one policy for each service I want to use radius authentication.

Again we’ll use UTM’s IP as client IP and I also added user group check for VPN enabled users. use ssl as NAS identifier.

Under Authentication Methods only select PAP. Select NO on security warning.

Leave rest of the settings as default.

Now login to UTM and navigate under Definitions & Users -> Authentication Services -> Servers

Step By Step Site To Site VPN Microsoft Azure And Sophos UTM ...

Add new authentication server and select RADIUS as backend type. Select Network Policy server as server or create new network host object.

Use same 48 character shared secret. Extend advanced settings and change timeout to 60 seconds.

You can see Nas-Identifiers used by services from the Nas-Identifier dropbox.

The Azure Problem - General Discussion - UTM ... - Sophos

Thats it. Now you should have Azure MFA enabled SSL VPN set up. To enable MFA for other services just create another network policy and use different Nas-Identifier.