Support NTLM Authentication

[hez2010]

What should we add or change to make your life better?

Support proxy a server which are using NTLM Authentication.

Why is this important to you?

Azure DevOps Server, Windows Admin Center and other many Microsoft products are using NTLM/Kerberos Authentication, which cannot be reverse proxied by most servers directly.

NTLM Authentication appears to violate HTTP’s convention of “stateless” by using HTTP requests to authenticate underlying connections. So, once a connection is authenticated, all requests using that connection have to be aware that the underlying connection is authenticated and set headers accordingly: authentication takes multiple round-trips as well.

But it doesn't mean that a reverse proxy server is not able to support NTLM Authentication.

In nginx’s docs:

Allows proxying requests with NTLM Authentication. The upstream connection is bound to the client connection once the client sends a request with the “Authorization” header field value starting with “ Negotiate ” or “ NTLM ”. Further client requests will be proxied through the same upstream connection, keeping the authentication context.
In order for NTLM authentication to work, it is necessary to enable keepalive connections to upstream servers. The proxy_http_version directive should be set to “ 1.1 ” and the “Connection” header field should be cleared.

I hope that YARP can provide built-in NTLM support.

[Tratcher]

Note: Yes this is possible, but it's extremely difficult and risky to implement. Any cross contamination between connections would be a major security breach.

NTLM also messes with the connection pooling logic because it reserves connections that can't be shared with anyone else. This has been a source of performance issues elsewhere like .NET 4.x's HttpWebRequest.

And then there's the issue of dealing with impersonation...

[samsp-msft]

@davidsh

[dragouf]

@Tratcher what is the issue with impersonation ? Because I did a reverse proxy by myself to transfer api request from an angular app to avoid CORS. I use impersonation to transfer NTLM auth and I was wondering if it's ok from a security point of view

[Tratcher]

Impersonation has caused a number of issues like dotnet/runtime#29935. If it works for you, great.

[samsp-msft]

Triage: After further consideration we have recognized that YARP will not support pass-through of NTLM/Kerberos or other connection-based authentication mechanisms.

[MattiasMartens]

I'd like to request some more context here. In general, a .NET server can connect to an NTLM-enabled remote service using its credentials cache (in vanilla AspNetCore this is CredentialCache.DefaultNetworkCredentials).

Is this issue saying that YARP
A) will not support a client providing NTLM credentials to a YARP-enabled server that it then proxies on to a cluster; or
B) will not attempt to authenticate with NTLM at all?

I ask because I am having an issue with YARP against an NTLM-authenticating cluster. Implementing NTLM authentication from the server with my hand-rolled reverse proxy was fairly trivial. I would like to establish whether the same is possible with YARP, or if this decision excludes that.

[Tratcher]

YARP will not support forwarding NTLM auth requests through the proxy because it does not support the connection level affinity required for NTLM. Note there's not a check in place to prevent this, it will just fail most of the time.

You can authenticate from the client to YARP or from YARP to the destination (or both), just not end-to-end through the proxy.

[Bob-HL]

YARP will not support forwarding NTLM auth requests through the proxy because it does not support the connection level affinity required for NTLM. Note there's not a check in place to prevent this, it will just fail most of the time.

You can authenticate from the client to YARP or from YARP to the destination (or both), just not end-to-end through the proxy.

How to authenticate from YARP to the destination please? It seems YARP just forwards the 'WWW-Authenticate' response to the client.

[MattiasMartens]

How to authenticate from YARP to the destination please? It seems YARP just forwards the 'WWW-Authenticate' response to the client.

You can do this by configuring YARP with a custom HttpClient:

// Add reverse proxy capability to the server
var proxyBuilder = services
    .AddReverseProxy()
    .ConfigureHttpClient((context, handler) =>
    {
        // Set credentials here
        handler.Credentials = CredentialCache.DefaultNetworkCredentials;
    })
    // Load configuration here
    .LoadFromConfig(Configuration.GetSection("..."))
    .AddTransforms(context => {
        // Load request content fully into buffer instead of providing it as a stream.
        // This is needed to prevent the multi-message NTLM auth flow from
        // prompting the request stream to be read more than once, which is an error.
        context.AddRequestTransform(async transformContext => {
            await transformContext.ProxyRequest.Content.LoadIntoBufferAsync();
        });
    });

[CTDProgrammer]

How do I set up a test of the above code to see what gets passed? Will I get user groups and what other sorts of information?

I have YARP and web api projects and I am trying different sorts of configurations to "connect" them but it's not really working out. How do I see the handler.Credentials in the first and the User object in the second with a breakpoint or something or other?

[Muhammad-1990]

How to authenticate from YARP to the destination please? It seems YARP just forwards the 'WWW-Authenticate' response to the client.

You can do this by configuring YARP with a custom HttpClient:

// Add reverse proxy capability to the server

var proxyBuilder = services

    .AddReverseProxy()

    .ConfigureHttpClient((context, handler) =>

    {

        // Set credentials here

        handler.Credentials = CredentialCache.DefaultNetworkCredentials;

    })

    // Load configuration here

    .LoadFromConfig(Configuration.GetSection("..."))

    .AddTransforms(context => {

        // Load request content fully into buffer instead of providing it as a stream.

        // This is needed to prevent the multi-message NTLM auth flow from

        // prompting the request stream to be read more than once, which is an error.

        context.AddRequestTransform(async transformContext => {

            await transformContext.ProxyRequest.Content.LoadIntoBufferAsync();

        });

    });

This helped big time. Thank you. Tried and tested and works. If you reading this then bump up the original comment to help others. I actually ended up removing YARP and manually cloning and forwarding my request. I've since reverted. Il spare the details of the scenario and complexities, but I can say I managed to authenticate incoming with bearer tokens and then "downgraded" to ntlm for specific forwards to an on-prem dynamics365 endpoint that uses a wonky adfs setup that sits in a DMZ.