If both the first and second proxy are doing NTLM authentication, you will not have any success.
You cannot put two 407 authentications inline from the same client. it will reek havoc.
You can, however, inject some headers from the first proxy to the second proxy to identify the authenticated user from the first proxy.
On your rule above, you can add the events to your next hop proxy rule:
Header.Add ("X-Authenticated-User", String.Base64Encode (Authentication.UserName))
Header.Add ("X-Authenticated-Groups", String.Base64Encode (List.OfString.ToString (Authentication.UserGroups, ", ")))
This will encode the users and groups into the http header for passing to the next-hop proxy.
On the other proxy, you would extract those values and use them as the username and groups, and remove them fromt he headers so they don't get forwarded any further.
Name: Extract X-Authenticated-User
Rule Criteria: Header.Exists ("X-Authenticated-User") equals true
Set Authentication.UserName = String.Base64Decode (Header.Get ("X-Authenticated-User"))
Name: Extract X-Authenticated-Groups
Rule Criteria: Header.Exists ("X-Authenticated-Groups") equals true
Set Authentication.UserGroups = String.ToStringList (String.Base64Decode ("X-Authenticated-Groups"), ",", " ")
My proxies are all in a single network and runtime cluster. How would I specify the header removal configuration on the 2nd proxy?
And where would those rules go? I'm not clear at what point the cycle starts from when it's passed to the next hop?
I see. It's hard to say exactly where in your overall rule set they would be placed.
I would check if X-Authenticated-User exists, and skip over the normal authentication rules entirely.
If the rules are shared on all the proxies, it will use the X-Authenticated-user if it exists, and do the normal authentication if it does not exist.
The Header.RemoveAll will remove the values from forwarding.
You'll need to do some testing to get it right in your network. Spin up a couple fo VMs in a lab (which i'm sure you have already)
Authentication and next-Hop proxy rules almost always go into the Request cycle.
Next-Hop proxy is sort of confusing because it doesn't actually occur immediatly when the rule hits in the flow. It's more like the request gets tagged to next hop, and actually hops when the transaction (request/response/embedded) actually completes.
I wasn't having much luck with this as couldn't seem to get the authentication sorted out - in packet captures I could see the first proxy using ntlm auth and then passing the get request onto the next-hop proxy which then tried ntlm. The headers were in the request that was passed to the next-hop but would still request auth so not quite there..... but then I had a Eureka moment and realised I can achieve the desired result by adding an entry to our proxypac files that tells it to use the relevant proxy for that domain host
Tested and working in 5 mins - much easier!
for the assistance even if I couldn't get it working.
Hi Eric, for your header injection method, what happens if the HTTP transaction is using the CONNECT method ? upstream needs to perform SSL break I assume ?
Nope, MWG will not need to perform SSL inspection for CONNECTs in order for the auth related items to persist for the transactions within the tunnel. One simply needs to have an event to say "Authentication.IsAuthenticated=true" and UserName,Groups,Realm, etc... will be persisted. (hope that makes sesnse)
Thanks Jon, will give it a try in the lab.
So far so good, there is a slight error in Eric's instructions, he missed the "Header.Get" in the user groups decoding part. Anyway, figured that out, and rule trace central shows me that the groups are being decoded, but for some reason It wont write these out to my block page, or allow me to use authentication.usergroups as a criteria - odd.
Check out the ISA chaining ruleset in the library. It has all of this.