Skip to content

Active Directory Authentication Backend

Web Filtering Proxy is also able to use the built-in Microsoft Windows single-sign-on proxy authentication with the Negotiate authentication scheme (both Kerberos and NTLM) when users are authenticated by your Microsoft Active Directory environment.

The following settings are required to enable this type of authentication.

Setting Description
Operating System The application needs to be installed on the Microsoft Windows Server (we have both 2016 and 2019 in our test lab).
Server The server that the application is installed on must be joined to your Active Directory.
Browsers Workstations that your users run browsers on must be joined to your Active Directory.
Proxy Settings Proxy settings in the browser must be pointing to the proxy by FQDN (i.e. in our test lab we specify the winproxy-ad.diladele.lan as the proxy name).


Note that this single-sign-on proxy authentication is only supported in the domain joined scenario. Currently no other configuration tasks are needed to be done by the administrator, a simple Active Directory join of the server where Web Filtering Proxy runs is enough.

Enable Authentication in Policy

To configure the single-sign-on proxy authentication, you need to actually enable it in policy settings. This can be done in Admin UI / Your Policy. Click the Configure Settings menu and select the Authentication tab.

Policy Authentication using Active Directory

Set radio button to Negotiate Authentication and click OK. Note that enabling authentication per policy allows your proxy to be more flexible in regards to user authentication.

Do not forget to Restart the Web Filtering Proxy service in order for the changes to be applied.

Presentation in Browser

After single-sign-on proxy authentication is enabled, your browser will just browse normally without showing any pop-ups when accessing the Internet.

The access log and monitoring table at Admin UI / Monitor will nevertheless show the logged in user name.

Successful Negotiate Proxy Authentication

How it Works

Here is the sequence of events that happens behind the scenes completely transparently to the user and administrator when Microsoft Active Directory proxy authentication is enabled.

  1. The user types the URL to visit in the address bar of the browser.
  2. Browser sends the request to the proxy server.
  3. Proxy server detects that this request is processed by the policy that requires the Active Directory authentication. Proxy replies with 407 Please Authenticate response indicating the Negotiate authentication scheme to be used.
  4. Browser requests the Kerberos ticket from the domain controller specifying the FQDN of the proxy to be used (can be verified by the klist command on the browser machine). Browser then re-sends the request to the proxy attaching the Kerberos ticket.
  5. Proxy verifies the attached ticket and processes the request. The response is sent to the browser and presented to the user.


Important note is that the proxy is set as FQDN in the browser settings and the server where the application runs is joined to the Active Directory. If you set the proxy in the browser settings as IP address then only NTLM scheme will be used.

User Groups Lookup

If you are enabling proxy authentication to be able to use the Active Directory groups as policy members one more semi automatic configuration step is required. Open Admin UI and click the Proxy Settings menu.

Active Directory Group Lookup Settings

Open the Negotiate Authentication node on the left and click the Detect button. This will let the application know where to search for user groups.

Active Directory Group Lookup Settings

By default, the application uses built-in Windows authentication to authenticate itself to LDAP server for user/group membership lookups. You can use another account if required. This is not recommended though and may be needed only when deploying Web Safety Proxy in NLB cluster.