Caveats for NTLM/Kerberos Authentication

These notes apply only to Windows servers as targets. If the site uses Kerberos as a protocol, but isn’t running on Windows using NTLM with Kerberos as a backup, you can ignore these caveats.

Successful NTLM Is Invisible

When NTLM/Kerberos authentication fails, you will see an HTTP 401 error in the waterfall. However, if authentication succeeds, you will see absolutely nothing but a normal HTTP 200 reply. There will be no indication that NTLM / Kerberos authentication has been performed.

Determining If ADFS is Used

NTLM / Kerberos authentication must be initiated by the identity provider.

The easiest way to identify whether ADFS is used is by setting the HTTP Authentication Scheme to “None” in the test configuration. (This setting is on the Advanced tab under HTTP Authentication.) Then run an instant test and wait for the 401 in the waterfall. Look in the Waterfall tab of the instant test view on ThousandEyes.

• When ADFS is used, you will initially land on the https://example.com/adfs/ls/? URL.

• If NTLM / Kerberos authentication is configured on the identity provider, you will immediately be redirected to https://example.com/adfs/ls/wia? URL (notice the wia part) which will challenge the browser using HTTP Basic Authentication.

If the IdP service doesn’t challenge you with HTTP Basic Authentication, and instead shows you an interactive login form, there is nothing you can do to start the NTLM/Kerberos authentication. (If this happens you’ll see the form as a screenshot in the test view, taken when the test errors out.) There is, however, a workaround involving changes to the User-Agent string that is sent by the ThousandEyes agent. You can find this under the test settings on the Advanced tab, HTTP Request area.

Why Am I Not Being Challenged?

There are different reasons why the IdP service might not challenge you, even if you think that it should. Two of these reasons are:

• You are making your connection request from the wrong source subnet. Check if the ThousandEyes agent’s source IP might be the reason.

• You are using the wrong User-Agent string in the ThousandEyes test configuration. Changing the User-Agent to something Windows-based might induce an HTTP Basic Authentication challenge.

Changing User-Agent String to Induce a Basic Authentication Challenge

The same transaction can yield different authentication responses based on the User-Agent string, which can be set as part of the ThousandEyes test configuration, under the Advanced tab, in the HTTP Request section.

Starting from exactly the same transaction, we get different sorts of authentication workflows depending on the type of User-Agent string used. When a Linux-based User-Agent string is used, we get an interactive login page, whereas when a Windows-based User-Agent string is used, we get an NTLM authentication challenge.

If the Negotiate Header is Sent First or Exclusively

A target website authentication response can contain two lines in the header, WWW-Authenticate: NTLM and WWW-Authenticate: Negotiate. These lines can come in either order. If the NTLM line comes first, there’s a test configuration change that you’ll need to perform in order to get your test to authenticate.

The page load or transaction test will fail under these conditions:

• NTLM authentication is used by the website.

• The target webserver sends the WWW-Authenticate: Negotiate header first or exclusively, and

• The test is configured as NTLM in the test settings under HTTP Authentication

Browser-based tests can only perform NTLM authentication if the server sends WWW-Authenticate: NTLM first or exclusively, and the test is configured on the ThousandEyes side to use Basic authentication. This might seem counterintuitive but that’s how it works.

The other possibility is that the target web server could send WWW-Authenticate: Negotiate second in the response header. If this is the case, then you might need to work with the web site’s administration team to request a configuration change.

Username Formats for NTLM

In many other forms of authentication, the username is in the form of an email, i.e. [e-mail], or sometimes just the user portion. NTLM, however, typically requires the DOMAIN\username format, i.e. acme\user.

Sometimes both the domain and the username are completely unrelated to the email, i.e. it could be something like acme\133434. Try the simple CompanyName\username format first, and if that fails, ask the identity provider administration team for the correct domain and username.