Active Directory

Active Directory (AD) is Microsoft's implementation of a directory service and is a central component of Windows 2000/2003 servers. It stores information about a broad range of resources residing on a network, including users, groups, computers, printers, applications, services, and any type of user-defined objects. As such it provides a means of centrally organizing, managing, and controlling access to these resources.

Note – Sophos UTM on AWS supports Active Directory 2003 and newer.

The Active Directory authentication method allows you to register Sophos UTM on AWS at a Windows domain, thus creating an object for Sophos UTM on AWS on the primary domain controller (DC). Sophos UTM on AWS is then able to query user and group information from the domain.

Note – The default group Domain User, which is automatically created by the AD, cannot be used for reverse authentication as this is denied by Sophos UTM on AWS. The default group Domain User is not returned by the AD in the memberOf attribute. If your want to use AD groups for reverse authentication, create new groups in AD. Manual created groups are returned by the AD in the memberOf attribute.

To configure Active Directory authentication, proceed as follows:

  1. On the Servers tab, click New Authentication Server.

    The dialog box Add Authentication Server opens.

  2. Specify the following settings:

    Backend: Select Active Directory as backend directory service.

    Position: Select a position for the backend server. Backend servers with lower numbers will be queried first. For better performance, make sure that the backend server that is likely to get the most requests is on top of the list.

    Server: Select or add an Active Directory server. For how to add a network definition, see Definitions & Users > Network Definitions > Network Definitions.

    SSL: Select this option to enable SSL data transfer. The Port will then change from 389 (LDAP) to 636 (ldaps = LDAP over SSL).

    Port: Enter the port of the Active Directory server. By default, this is port 389.

    Bind DN: The full Distinguished Name (DN) of the user to bind to the server in LDAP notation. This user is needed if anonymous queries to the Active Directory server are not allowed. The bind user must have sufficient privileges to obtain all relevant user object information from the Active Directory server in order to authenticate users; a requirement usually met by the administrator of the domain.

    Each DN consists of one or more Relative Distinguished Names (RDN) constructed from some attributes of the Active Directory user object and includes its username, the node where it resides, and the top-level DN of the server, all specified in LDAP notation and separated by commas.

    • The username must be the name of the user who is able to access the directory and is to be specified by the CN designator (e.g., CN=user). While using a popular account with domain permissions, such as "admin" is possible, it is highly recommended for best practices that the user not have admin rights, as it is sufficient for them to have read permission on all objects of the subtree starting at the given base DN.
    • The information of the node where the user object resides must include all subnodes between the root node and the user object and is usually comprised of so-called organizational units and common name components. Organizational units (indicated by the combined folder/book icon in the Microsoft Management Console) are to be specified by the OU designator. Note that the order of the nodes is from the lowest to the highest node, that is, the more specific elements come first (e.g., OU=Management_US,OU=Management). On the other hand, default Active Directory containers (indicated by a simple Folder icon) such as the pre-defined Users node are to be specified using the CN designator (e.g., CN=Users).
    • The top-level DN of the server can consist of several domain components, each specified by the DC designator. Note that the domain components are given in the same order as the domain name (for example, if the domain name is example.com, the DN part would be DC=example,DC=com).

    An example bind user DN for a user named administrator whose object is stored in the Users container in a domain called example.com would look like this: CN=administrator,CN=Users,DC=example,DC=com

    Authentication: Microsoft Management Console

    Now, suppose you create an organizational unit called Management with the subnode Management_US and move the administrator user object into it, the DN of the administrator would change to: CN=administrator,OU=Management_US,OU=Management,​DC=example,​DC=com

    Password: Enter the password of the bind user.

    Test server settings: Pressing the Test button performs a bind test with the configured server. This verifies that the settings on this tab are correct, and the server is up and accepts connections.

    Base DN: The starting point relative to the root of the LDAP tree where the users are included who are to be authenticated. Note that the base DN must be specified by the full distinguished name (FDN) in LDAP notation, using commas as delimiters (e.g., O=Example,OU=RnD). Base DN may be empty. In this case, the base DN is automatically retrieved from the directory.

    Username: Enter the username of a test user to perform a regular authentication.

    Password: Enter the password of the test user.

    Authenticate example user: Click the Test button to start the authentication test for the test user. This verifies that all server settings are correct, the server is up and accepting connections, and users can be successfully authenticated.

  3. Optionally, make the following advanced settings:

    Authentication timeout (sec): Enter the timeout for the communication with the server to support higher latency scenarios if you use third party authentication solutions.

  4. Click Save.

    The server will be displayed in the Servers list.

Cross Reference – Find information about configuring user authentication with Active Directory in the Sophos Knowledge Base.

User Principal Name

Sometimes users should be required to use the User Principal Name notation 'user@domain' when entering their credentials, for example when using Exchange servers in combination with Active Directory servers.

  • Clone a desired server to start a new server
  • Change Backend to LDAP
  • Change User Attribute to >
  • Enter userPrincipalname into Custom field.

If not present already, this will set up a 'LDAP Users' group which you will have to use instead of the 'Active Directory Users' group.

Note – The format domain\user is not supported. Use the format user@domain instead.