How Does Browser NTLM Authentication Work?

NTLM Authentication of Domain Users

For domain users, the NTLM response is authenticated via the MSCHAP mechanism in RADIUS. RADIUS must be enabled on the appliance.

The following settings on the Users tab of the SSO configuration apply when configuring NTLM authentication:

NTLM Authentication of Non-Domain Users

With NTLM, non-domain users could be users who are logged into their PC rather than into the domain, or could be users who were prompted to enter a user name and password and entered something other than their domain credentials. In both cases, NTLM allows for distinguishing these from domain users.

If the user name matches a local user account on the SonicWall appliance then the NTLM response is validated locally against the password of that account. If successful, the user is logged in and given privileges based on that account. User group memberships are set from the local account, not from LDAP, and (as the password has been validated locally) include membership of the Trusted Users group.

If the user name does not match a local user account, the user is not logged in. The Allow limited access for non-domain users option does not apply for users authenticated via NTLM.

Credentials for NTLM Authentication in the Browser

For NTLM authentication, the browser either uses the domain credentials (if the user is logged into the domain), thus providing full single-sign-on functionality, or prompts the user to enter a name and password for the website being accessed (the SonicWall appliance in this case). Different factors affect the browser’s ability to use the domain credentials when the user is logged into the domain. These factors depend on the type of browser being used:

Internet Explorer – Internet Explorer uses the user’s domain credentials and authenticates transparently if the website that it is logging into the firewall (the SonicWall appliance) is in the local intranet, according to the Security tab in its Internet Options. This requires adding the firewall to the list of websites in the Local Intranet zone in the Internet Options.

This can be done via the domain’s group policy in the Site to Zone Assignment List under Computer Configuration, Administrative Templates, Windows Components, Internet Explorer, Internet Control Panel, Security Page.

Google Chrome – Behaves the same as Internet Explorer, including requiring that the firewall is added to the list of websites in the Local Intranet zone in the Internet Options.
Firefox – Uses the user’s domain credentials and authenticates transparently if the website that it is logging into (the SonicWall appliance) is listed in the network.automatic-ntlm-auth.trusted-uris entry in its configuration (accessed by entering about:config in the Firefox address bar).
Safari – Although Safari does support NTLM, it does not currently support fully transparent logon using the user’s domain credentials.
Browsers on Non-PC Platforms – Non-PC platforms, such as Linux and Mac, can access resources in a Windows domain through Samba, but do not have the concept of “logging the PC into the domain” as Windows PCs do. Hence, browsers on these platforms do not have access to the user’s domain credentials and cannot use them for NTLM.

When a user is not logged into the domain or the browser cannot use their domain credentials, it will prompt for a name and password to be entered, or will use cached credentials if the user has previously opted to have it save them.

In all cases, should authentication fail when using the user’s domain credentials (which could be because the user does not have the privileges necessary to get access), then the browser prompts the user to enter a name and password. This allows the user to enter credentials different from the domain credentials to get access.

NOTE: When NTLM is enabled for Single Sign-On enforcement, an HTTP/HTTPS access rule with Trusted Users as Users Allowed must be added to the LAN to WAN rules in the Firewall > Access Rules page. This rule will trigger an NTLM authentication request to the user. Without the access rule, other configurations such as restrictive Content Filter policies might block the user from Internet access and prevent the authentication request.