# 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. **<user@acme.com>**, 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.