We also use NTLM and yes NTLM normally query ever request which might decrease performance.
Therefor we wrote a little ruleset to surrogate an authorized user. The first request is authorized and the result (User, Groups) is stored in a local PDs variable with 1 minute lifetime.
The next requests fetches the values from the storage. This works as long as the user uses the internet. If there is no Internet connection for 1 minute the user has to authorize again. (PDs variable does not exists any more)
This is great to reduce NTLM request.... but.... everthing has a disadvantage - this breaks authentication on servers with more than 1 user!!! The first user opens the Proxy and all other will use its user credential to use the
proxy... (example Citrix).
We use Kerberos for aprx.3000 users with NTLM fallback as described in Web Gateway: Configuring Kerberos (simplified guide). Works OK and speed is little better then NTLM, but the main advantage is lower AD DC utilization.
We had some troubles with some apps/browser version doing incorrect Kerberos authentication, so in some rare cases clients still use NTLM.
We started to implement Kerberos on security impuls and proposal from MS partner to prioritize Kerberos over NTML in the future.
hi frank, I guess you did this in order to increase proxy performance/speed? did the users noticed the improvement?
yes! sure! It must be faster. NTLM Handshake required 3 client Proxy exchanges for each request... you can verify this using Rule trace (Code 407/407/200).
Maybe you can look at NTLM cache settings and Authentication statistics.
In our deployment, I can see aprx. 80% NTLM requests are served by NTLM cache on MWG appliance. This also can speed it up.
Also MWG 7.5 come with 64bit malware engine and McAfee proposed 24GB of RAM for supported HW. See McAfee Web Gateway 7.5.0 recommended memory (RAM) upgrade
frank, wouldn't Kerberos Authentication do the same trick and additionally resolve your issue with terminal servers(citrix)?
Kerberos has the advantage that there is no need to talk to the DCs for authentication. But as far as I know only group IDs (SIDs) rather than group names are transmitted in the Kerberos ticket, so MWG needs to do NTLM or LDAP to lookup the group SIDs from the DC. On top of that Kerbros authentication will still cause MWG to send a "407" to the client to authenticate for every TCP session. Franks approach will cause MWG to not even ask for authentication.
lubomir, thanks, I checked ntlm cache and it's set to 30min,also in authentication statistics I see that we have 80% ntlm cache hits...
- Kerberos returns only groups IDs not group name
- LDAP/NTLM is not needed. We use group ID in our rules.
The rule is like: Authentication.UserGroups is in List
List contains SID of the group fetched via Kerberos ticket
For old clients which does not support Kerberos, the NTLM fallback rule is used as described in Kerberos MWG guide. Such clients use NTLM and works with clasic group names, not SIDs