Can APM change the default domain on an NTLM request?

Are you talking about changing the NTLM SSO domain, or munging the domain that's used when you bypass APM for Office agents?

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.

    

So essentially you're disabling the access policy (and SSO) for anything that's not a browser. And that also assumes the client is internal and can do its own NTLM. I don't think you answered whether or not you were using the persistent cookie option in the access policy.

Okay, so just to be clear, I'm talking about the Persistent cookie option in the APM policy. Typically what happens with SharePoint is that APM sets a session-based cookie for the web application itself, but the browser doesn't share its memory with the office agents, so when they're triggered they don't send the access session cookie and ultimately break because they can't deal with whatever a new access session is asking them to do (ie. a logon page, 302 redirect to /my.policy, etc.). The persistent cookie option drops the access cookie into the file system so that the agent can use it.

So then the question becomes, is the agent using it and can you see the access session cookie (MRHSession) in the agent's communications to the virtual server? And if you can is it still returning a 401 response?

And on a side note, do you have OneConnect enabled on the VIP?

Hi,

I just read your question and I think the following question / answer can help you:

https://devcentral.f5.com/questions/sharepoint-and-office-integration-part-2

I had the same issue about sharepoint and create an irule resolving all encountered issues.

In this irule :

• persistent cookie is only for non browser and if the user chose "trusted computers" on logon page... (by type use of persistent temp cookie)
• Office authenticate with form and not with NTLM Auth
• webdav authenticate with Basic authentication