User-ID via NTLM and a BC explicit proxy

[A_Gardner]

All,
I have an unusual install that dances around the borders of existing documentation and I'm hoping somebody can verify (or direct me towards documentation that does) whether this will work.

The user's browser are currently configured to use a BC proxy as an explicit proxy (port 8080).  The PA is acting as a transparent proxy (vwire config) and is physically in line with the BC proxy so that all traffic must transit through the PA to get to the BC.  Because the server infrastructure is managed by a separate 3rd party from the network infrastructure the only real option for User-ID that I have is to use captive portal, redirect the user to a L3 interface and get the User-IDs via NTLM auth (they are using IE as a standard browser).  User traffic will need to go through a firewall to get to the L3 redirect interface.

Has anybody got this definitely working and are there any tweaks that may be required?

The reason I wonder is that the user's browser will be expecting to communicate with a proxy and will therefore be using proxy mode rather than server mode.

Will the PA attempt an HTTP redirect for traffic on port 8080?  Will the browser accept a redirect that comes from the PA?  If it does accept the redirect then what port will it use to contact the L3 redirect interface, port 8080 or 80/443 depending on the traffic?  Will the browser attempt to go to the redirected site via the BC proxy, effectively making the interaction browser (proxy mode) -> BC explicit proxy, BC explicit proxy (server mode) -> redirected site (L3 redirect interface) and therefore User-ID will effectively associate the User-ID with the IP address of the proxy?

Unfortunately due to geographical limitations and changes in the design the early testing wasn't representative of this scenario.

Any help will be much appreciated.

Message was edited by: Andy Gardner It from further checking and harassing some friendly PA tech support it looks like this will work if done right.  The PA intercepts the browser/proxy communication OK and injects back the redirect properly.  The important part is to have the redirect go to an IP that the browser will bypass the proxy to get to (usually an Intranet type IP address).  Also remember that the redirect will be a browser / server interaction so port 80 or 443 instead of the proxy port. I'll know for sure on Friday evening 🙂

[mikand]

The downside of putting the PA between the client and the proxy, that is: Client <-> PA <-> Proxy <-> Internet

is that the PA will only detect the "outer" application and that is "http-proxy". It will not detect whatever the client is actually doing such as youtube, facebook etc (however url-filtering will still work if im not mistaken).

Another drawback is that ssl-termination (decryption) will most llikely not work so you will be blind for SSL traffic aswell.

Is it completely impossible for you to set it up as the following instead?

Client <-> Proxy <-> PA <-> Internet

Because this way, given that the proxy is configured for keepsource=yes (or "reflect client ip" or whatever it might be called - that is packet sent from Proxy has the client ip as srcip) you can use UserID out of the box (that is for example if the clients are part of an Active Directory or such which the UserID then can get a mapping from through PAN-agents (either local in PANOS 5.0 or dedicated machines running PAN-agents (which can also be runned directly on the Domain Controllers))). AND you will at the same time be able to use ssl-termination along with proper appid's.

In the above example any NATing will be performed by the PA aswell (unless you have some other box closer to the Internet that does this for you).

[A_Gardner]

Thanks for the reply mikand.

The topology is pretty much predefined due to the clients needs and existing support structure.  Moving things around as you suggest would also require a redesign of the current failover mechanisms.

I can't use User-ID easily out of the box due to overall environment complications, the server infrastructure is maintained by a different 3rd party.  Overall as an example of implementing PA in to a complex pre-existing environment this project has likely managed to highlight many of the potential pitfalls along the way.

I do think however that you underestimate what the PA is capable of.  The boxes are already installed and inline, they just aren't doing any complex policy processing yet.  Looking at monitor / traffic I can see applications such as linkedin-base, gmail-base etc. being identified.  SSL intercept is supported as part of transparent proxying and once that is activated in the config I expect to see more of the ssl traffic being identified as well.

[ericgearhart]

A_Gardner:  if the PA is correctly identifying App-IDs, then maybe mikand's drawing needs an addition on the right. It's not normal to have a proxy server hanging directly off the Internet, so it would make sense that the proxy is "behind" the PA before going out to the Internet.

If what's really happening is this:

Client <--> PA <-->Proxy <--> PA (a separate zone possibly that the proxy sits in, on separate interfaces?) <--> Internet

... then the PA seeing actual App-IDs makes sense.

[mikand]

The drawback of such setup in my opinion is that you will get half of everything.

That is a single session will actually take two sessions within the PA.

[ericgearhart]

A possible solution could be to have the proxy add "X-Forwarded-For" HTTP headers that the PA can interpret, so the PA can do user identification using the client IP. You'd have to get User-ID set up for that to work, either on t he PA itself or via the User-ID agent. I believe adding this header is this is a common feature with web proxies.

I've never done the X-Forwarded-For HTTP header parsing with PA, but it looks neat. These two forum thread links look promising:

I think the PA can even strip out the X-Forwarded-For header as the traffic leaves out to the Internet, so your internal IP space doesn't "leak out" in the HTTP headers.

[mikand]

However that stripping is somewhat bogus within PA since PA cant alter the length of the packets it will just replace the "x-forwarded-for: x.x.x.x" with "x-forwarded-for:         " which then will fire some IPS's all around the internet regarding malformed http-request (according to another thread in there) - dunno if that has been fixed in PA yet or not...