matt
November 5, 2019, 7:51pm
41
@hez2010 I spent just an hour on it this morning because it was REALLY bugging me for some reason.
And…
IT WORKS!!
My implementation is super spikey, i.e. not at all commit-worthy. But now I know how to do it and with some time I can clean things up and push it.
It is effectively what NGINX’s commercial ntlm directive does: Module ngx_http_upstream_module
But ours is free.
I do not know what implications this feature has when enabled. Under the hood, we use a separate http.Transport for every request.RemoteAddr (client connection address) that we see, so it definitely isn’t as fast as your streamlined HTTP/2 pipelines. But that’s NTLM for you.
4 Likes
matt
November 5, 2019, 11:38pm
42
@hez2010
I have cleaned up my implementation and pushed it (300th commit to v2, too): reverse_proxy: Add support for NTLM · caddyserver/caddy@8e51528 · GitHub
You can build from the v2 branch to use it right away, or wait for beta 10.
Scroll down from here and you’ll see how to use the http_ntlm transport module: Home · caddyserver/caddy Wiki · GitHub
Here’s my config, for example:
{
"handler": "reverse_proxy",
"transport": {
"protocol": "http_ntlm",
"tls": {
"insecure_skip_verify": true
}
},
"upstreams": [
{"dial": "wac:1080"}
]
}
1 Like
alexandzors
November 6, 2019, 12:30am
43
Thanks Matt! I’ve been wanting this for so long and I’m glad to finally see that it’s possible to reverse proxy WAC with NTLM.
matt
November 6, 2019, 12:52am
45
Let me know if it works for you too
hez2010
November 6, 2019, 1:57am
46
I just tried the new http_ntlm module but still stuck at “Bootstrapping the application” again.
My caddyfile:
{
"apps": {
"http": {
"servers": {
"srv0": {
"listen": [
":80"
],
"routes": [{
"match": [{
"host": [
"test.hez2010.com"
]
}],
"handle": [{
"handler": "subroute",
"routes": [{
"handle": [{
"handler": "reverse_proxy",
"transport": {
"protocol": "http_ntlm",
"tls": {
"insecure_skip_verify": true
}
},
"upstreams": [{
"dial": "localhost:1080"
}]
}]
}]
}]
}]
}
}
}
}
}
This time I saw a lot of 401s in caddy’s log, and lots of 400s in browser’s network request records.http://test.hez2010.com.
matt
November 6, 2019, 7:16am
47
D’oh. As part of the cleanup I accidentally read/transferred something wrong:
Anyway, I’ve pushed the fix and tested that it works with your backend. (Although, I’m getting 403 / access denied errors from WAC, different from before – did you change something in your backend WAC configuration? It’s OK if you did but I wasn’t able to get the exact same results as before)
Can you pull the latest on the v2 branch and try again? Thank you!
hez2010
November 6, 2019, 7:58am
48
This time it works, but I got access denied too.
2019/11/06 07:49:15.354 e[31mERRORe[0m http.log.access handled request {"request": {"method": "GET", "uri": "/api/settings/admin", "proto": "HTTP/1.1", "remote_addr": "120.236.174.144:30142", "host": "test.hez2010.com", "headers": {"Accept": ["application/json, text/plain, */*"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3952.0 Safari/537.36 Edg/80.0.320.3"], "Content-Type": ["application/json; charset=utf-8"], "Accept-Language": ["en-US,en;q=0.9"], "Connection": ["keep-alive"], "Referer": ["http://test.hez2010.com/errors/forbidden"], "Accept-Encoding": ["gzip, deflate"], "Authorization": ["Negotiate TlRMTVNTUAADAAAAGAAYAIQAAABGAUYBnAAAAAAAAABYAAAADgAOAFgAAAAeAB4AZgAAABAAEADiAQAAFYKI4goAukcAAAAPJ1IL8gJrZEnNhEQL3sj3q2gAZQB6ADIAMAAxADAARABFAFMASwBUAE8AUAAtAEMARAAyAEMANQAyAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMLsVky5/A4KfcZgtngrywEBAAAAAAAAGUejr3aU1QF7HQSGcCw/xwAAAAACAB4AaABlAHoAMgAwADEAMAAtAHQAZQBzAHQALQB2AG0AAQAeAGgAZQB6ADIAMAAxADAALQB0AGUAcwB0AC0AdgBtAAQAHgBoAGUAegAyADAAMQAwAC0AdABlAHMAdAAtAHYAbQADAB4AaABlAHoAMgAwADEAMAAtAHQAZQBzAHQALQB2AG0ABwAIABlHo692lNUBBgAEAAIAAAAIADAAMAAAAAAAAAABAAAAACAAAOAArFjBDPP4KI0rBfm6YjcorJy/d5/2RdvheUm/+K8CCgAQAAAAAAAAAAAAAAAAAAAAAAAJACoASABUAFQAUAAvAHQAZQBzAHQALgBoAGUAegAyADAAMQAwAC4AYwBvAG0AAAAAAAAAAACURheVy66r6mCKVAN5tk1f"], "Dnt": ["1"]}}, "common_log": "120.236.174.144 - - [06/Nov/2019:07:49:15 +0000] \"GET /api/settings/admin HTTP/1.1\" 403 96", "latency": 0.008572, "size": 96, "status": 403}
Access wac from caddy vs directly access:
I found the x-xsrf-token was missing, may be the reason for forbidden?
Cookies difference:
1 Like
matt
November 6, 2019, 8:03am
49
@hez2010 Ah yes
It’s because you’re on an HTTP page, but the WAC backend is setting secure-only cookies. You have to do one of these things:
Use HTTPS on the front end (recommended)
Configure WAC to set non-secure cookies
Cheat
#3 is the most fun, so let’s do that:
{
"handler": "reverse_proxy",
"transport": {
"protocol": "http_ntlm",
"tls": {
"insecure_skip_verify": true
}
},
"headers": {
"response": {
"replace": {
"Set-Cookie": [
{
"search": "; secure",
"replace": ""
}
]
}
}
},
"upstreams": [
{"dial": "wac:1080"}
]
}
Notice that we are rewriting the Set-Cookie header so it is no longer a secure cookie.
I did this while I was developing the fix, so I know it works.
1 Like
hez2010
November 6, 2019, 8:14am
50
Wow it works well!
2 Likes
matt
November 6, 2019, 8:20am
51
Likewise, it was fun.
Have fun not paying for nginx
2 Likes
matt
November 19, 2019, 9:47pm
52
FWIW, Beta 10 has been released, which includes NTLM proxying. For free.
2 Likes
system
February 17, 2020, 9:47pm
53
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
Nice find! That’s not a Caddy issue, fortunately.