Disclaimer: This information is posted as-is and the content should be referenced at your own risk
An LDAP authentication server, when connected to Active Directory, provides essentially the same capabilities as the Active Directory authentication server. This includes transparent identification of Web Proxy users from NTLM information provided by the browser. The identification does not involved inferences based on IP address, so your user attribution is more defensible. (With any authentication method, HTTPS inspection is required to avoid ip-to-user inferences being made about encrypted session.)
The LDAP syntax needs documentation, and I have always found the documentation difficult to locate. My environment has multiple Active Directory domains, so we use AD SSO for the primary domain, and LDAP SSO for all of the others. For sites that have disabled SMB v1, it should be possible to configure SSO for UTM using LDAP exclusively.
The most important thing to know about LDAP is that the configuration is completely dependent on the AD folder structure. So if you want to reorganize your Active Directory structure, do so before configuring LDAP objects. If the LDAP objects are moved to a new folder path, your LDAP configuration will break and need to be reconfigured.
Most Active Directory folders are Organizational Units, and are referenced in the LDAP syntax using OU=name. However, the fixed folders provided in every AD configuration are containers, and are referenced in LDAP syntax using CN=name. The CN folders include \Computers, \Users, and \Domain Admins. (In Group Policy Management, you can link a group policy to an OU but not to a CN.) User objects and Group objects are also containers (CN) in LDAP. Domain name components are identified by DC=value.
Other features:
- Quote marks are not used.
- LDAP strings are case insensitive.
- Name components are separated by commas, delimiting spaces are ignored but usually omitted.
Specific syntax examples:
- The “example.com” domain is identified using
dc=example,dc=com - The “div1.example.com” domain is identified using
dc=div1,dc=example,dc=com - The user named “LDAP_Lookup” in location “\Users” is identified using
cn=LDAP_Lookup,cn=Users, dc=example,dc=com - The user named “LDAP_Lookup” in location “\Folder1\Folder2” is identified using
cn=LDAP_Lookup,ou=Folder2,ou=Folder1, dc=example,dc=com
Configuring an LDAP server in UTM
In Active Directory, create an account to perform the LDAP Lookups. For demonstration purposes, assume it is named LDAP_UTM in path \ServiceAccounts. After creation, make it a member of the Domain Admins group.
In UTM, navigate to: Definitions and Users… Authentication Services… [Servers] tab… [New Authentication Server] button. The notes below itemize each setting:
- Object Name: Anything you want, such as “LDAP for Example.com”
- Type=LDAP
- Port: 389 with SSL unchecked, or port 636 with SSL checked.
SSL is better, because traffic is encrypted, but setting up a commercial certificate on a domain controller is a little bit complicated. - Bind DN: This is the information for the account that logs onto the domain controller to perform LDAP lookups. For my example, the path will be:
CN=ldap utm,OU=Service Accounts,DC=example,DC=com - userAttribute: I set this to “>” for a custom attribute
- Custom Attribute:
userPrincipalName for a qualified name (username@example.com), or
sAMAccountName for an unqualified name (username).
The qualified name avoids ambiguity if you have more than one domain configured. - Base DN: This is the entry point in your domain for performing user and group lookups. Presumably you want this to be your entire domain, so in our example the value will be:
dc=example,dc=com
Once the Authentication server is configured, you can test it, but remember that the test string also needs to be in LDAP syntax, such as:
cn=testuser,ou=folder3,ou=folder4,dc=example,dc=com
Any user retrievable by the LDAP server becomes a member of the local LDAP Users group. But you will rarely want to grant any permission to everybody, so you need to create UTM group definitions that link to AD group definitions. The following assumes that each group has already been created in Active Directory and the group members have been added, although membership can be modified at any time.
For each group, navigate to Definitions and Users… Users and Groups… [Groups] tab… [New Group] button. The notes below assumes an Active Directory group named “Webfilter-JobSearchAllowed” has already been created in Active Directory path \WebFilterGroups
- Group name: For consistency, I recommend using the same name as the Active Directory group, or a variant that indicates the domain as well, such as “Webfilter-JobSearchAllowed Example.Com”
- Group Type: BackEnd Membership
- Backend: LDAP
- Check an LDAP attribute: Selected
- Attribute: memberOf
- Value: Group name and path in LDAP syntax, such as:
CN=Webfilter-JobSearchAllowed,OU=WebFilterGroups,DC=Example,DC=com
After creating these group definitions in UTM, you can return to the Authentication Server page and use the [Test] button to review group memberships. You should be able to see that appropriate users are in both the LDAP Users group and the appropriate Active-Directory derived groups.
Of course, the group definition does not make anything happen -- the group has to be applied to a UTM function to be useful. In my example, the final step is to create a Web Protection Filter Action to allow the JobSearch category, then create a Web Protection Policy and attach the WebFilter-JobSearchAllowed group , then link the Policy to the Filter Action.