Can APM change the default domain on an NTLM request?

It's not that easy. NTLM is a challenge-response authentication mechanism, and servers (at least Windows servers) do not send the domain information in the NTLM challenge. Essentially it works like this:

1. The client sends an unauthenticated request.

    

2. The server responds with a 401 Unauthorized with a WWW-Authenticate header and a small "challenge" value.

    

3. The client encrypts this challenge with the hash of its password and sends it back in an Authorization header with a new request.

    

4. The server sends the username, challenge sent to the client, and response from the client to the domain controller.

    

5. The domain controller retrieves the user's hashed password from its directory, encrypts the challenge, and then compares the two encrypted values.

    

At no point in this interaction does the server specify which credentials the client should use, so the client will always use the credentials they used to logon to the domain (at least for NTLM and Kerberos). In other words, there's nothing in the challenge to munge.

In lieu of that, I can think of at least two options:

1. Most Office agents at least support NTLM authentication. You could technically employ VIP-targeting and direct traffic to different internal APM VIPs based on the User-Agent. Normal web traffic can go to the policy that does forms auth. Office agents can go to the internal APM VIP that does client side NTLM.

    

2. The most common way to handle SharePoint Office agents is by enabling the persistent cookie option in the access policy. By default APM session cookies are stored in browser memory, and when an Office agent is triggered it doesn't have access to the browser's memory, so it tries to start a new access policy. By enabling a persistent cookie, the APM session token is stored as a file-based cookie, which Office agents can access. Persistent cookies are continuously updated with the configured idle time of the session.