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.
Specific syntax examples:
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:
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
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.