generally NTLM requires the machine to be member of the domain in order to correctly authenticate the domain user. However, the authentication process between client and proxy can also happen using basic authentication, which is unsercure as credentials are embedded into the traffic as part of a header in base64 encoded fashion. This fallback to basic will happen automatically. As alternative, you can check if the client will authenticate via NTLM and fall back to authentication server with SSL which will be more secure. regardless which way you choose there will be user involvement by typing in credentials. An alternative might be Kerberos, which provides seamless authentication is an open standard, this supported on Mac OS X, Linux and also on MWG.
Thanks Michael - makes sense.
I'm currently in the processof testing NTLM globally but goal is to define by regions ( US-UK-etc,etc). We have a rule that we defined to test VIP or proxies but somehow it applied to all proxies globally . Any recommendation or best practice approachto define NTLM by regions ??
Describe a litle more how you want to do that?
Do you only want certain proxies to talk to their closest DCs and not cross outside of their local network?
You can define which specific DCs each proxy can talk to so it won't go out of their network.
Or is their some other desired effect you want?
In short- we want to enable NTLM per geographic location which will allow my team to concentrate and resolve any issues that come up only for that region ( a bulk rollout of NTLM is not what we want to do).
We were debating on setting up the rules to apply to the VIP & appliance IP address of the region or to use the UUID of the appliances of the region . We tried both methods but somehow the rules were bypassed and NTLM were applied globally - so all my users were asked to authenticate .
Ideally my goal is to enable NTLM based on region ( utalizing appliance ip and VIp) and having all appliances pc's / tablets / smartphones / etc that try to use the proxy at this location to authenicate so we have a clear understanding of browsing or ability to audit. Would also need a bypass for the legacy appliances e.g wyse terminals, printers, etc.
Well, you have 2 approaches i can think of:
a) Only authenticate if the Client.IP is in certain subnets.
Client.IP is in ip range list 'Authenticated Client IPRanges'
You can add regional subnets as you expand.
b) Only authenticate if any client is going to a specific proxy.
System.HostName is in list 'Authenticated Proxy List'
You can add proxy host names to the list as you expand.
System.HostName is an easier criteria to work with than UUID, but you could do either.
Put the condition on the authentication rule set and add entries to the lists as you widen the authentication reach.
If you go with A, then people outside the subnet will not authenticate no matter which proxy you use. Users in the US or the UK would authenticate if they are in that particular Client.IP range regardless of which proxy they use.
If you go with B, then people using a specific proxy will authenticate, but if you change your settings to go to a different proxy, they may not. This might be good for IT in the US to test authentication in the UK by changing their proxy settings manually or the other way around.
For either, you have to decide what happens if people use the proxy outside of their natural region.
I don't think you could actually put a criteria on the VIP of the proxy, only the Proxy.IP which is the native listening IP address.