caddy: Reverse proxy on ASP.NET sites using NTLM authentication is not working
1. What version of Caddy are you running (caddy -version)?
Caddy 0.8.2
2. What are you trying to do?
I’m trying to use Caddy as reverse proxy for MS Dynamics CRM installation to get more robust and balance loading, better performance (maybe) by applying HTTP/2 on context served by MS CRM.
3. What is your entire Caddyfile?
localhost:2020
gzip
log access.log
proxy / https://azure.based.installation.of/mscrm/
4. How did you run Caddy (give the full command and describe the execution environment)?
Just typed caddy in cmd.exe
I’m using Windows 8 / 64;
I’m tested scenario in whole zoo of browsers: FF, IE, Chrome most recent version available;
MS CRM hosted on Azure.
MS CRM requires authentication, and normally uses simple Windows NTML.
No IFD (Internet Facing Deployment) is used (it’s more or less cookie-based auth mechanism);
5. What did you expect to see?
I expected Caddy to be completely transparent, like Fiddler2, for example, normally does.
6. What did you see instead (give full error messages and/or log)?
Instead I get never ending sequence of requests asking to enter my credentials.
Replying with 401 is normal behavior for NTLM auth, but as soon as browser supplies correct credentials, token is issued and these 401 re-directions stop. But not in this case. I suppose that Caddy misses to transfer some important header or any other information is not substituted correctly. As result, transparency of proxy literally becomes opaque.
I don’t think that information in Caddy’s access log is valuable here, since information about headers there is not present, as I can see — but I looked through it briefly, and URL used are 100% correct.
But. I can provide RAW output from fiddler for investigation. For privacy reasons I will replace actual urls and authorization tokens (and yes, I have treble checked my password, I’m entering it without spelling errors).
Request:
GET http://localhost:2020/[removed]/_common/styles/global.css.aspx?lcid=1053&ver=-2039462857 HTTP/1.1
Accept: text/css, */*
Referer: http://localhost:2020/
Accept-Language: en-US,en;q=0.7,ru;q=0.3
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
DNT: 1
Host: localhost:2020
Authorization: Negotiate [removed]
Response:
HTTP/1.1 401 Unauthorized
Content-Length: 341
Content-Type: text/html; charset=us-ascii
Date: Tue, 08 Mar 2016 11:57:39 GMT
Server: Caddy
Server: Microsoft-HTTPAPI/2.0
Www-Authenticate: Negotiate [removed]
Proxy-Support: Session-Based-Authentication
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Not Authorized</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Not Authorized</h2>
<hr><p>HTTP Error 401. The requested resource requires user authentication.</p>
</BODY></HTML>
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 20 (9 by maintainers)
I’m looking into using caddy as a reverse proxy just for this case. If Caddy can svolve this, it is unique among the open source alternatives.
@mholt I’m going to research this with http/2 disable and keep-alive to see if it is duable vs reporting services on IIS that uses NTLM / Negotiation
Yeah, it was removed from core and moved here as a plugin: https://github.com/caddyserver/ntlm-transport
For reference, the list of known Caddy v2 plugins is here for the time being: https://caddy.community/t/list-of-caddy-2-modules/7839
We can reopen this issue if there is some movement that shows this is feasible. 👍