This article provides an introduction to how Integrated Windows Authentication (IWA) works with the ProxySG appliance. See the IWA Authentication Fundamentals and Deployment Guidelines paper for extensive functional and technical details, further recommendations, and illustrations.
Integrated Windows Authentication (IWA) can provide a single sign on (SSO) user experience when configured correctly. IWA uses credentials from the user’s initial workstation log on. Hence, domain users are not prompted for credentials, in both explicit and transparent proxy deployments. Users from any trusted domain can be authenticated. Blue Coat has implemented two flavors of IWA: IWA-Direct and IWA-BCAAA.
The supported authentication mechanisms are Basic, NTLM (NT LAN Manager), and Kerberos. Basic and NTLM must go to a Domain Controller (DC) to validate credentials and determine group membership.
Kerberos is more scalable then NTLM; ProxySG (IWA-Direct) or BCAAA (IWA-BCAAA) can directly validate Kerberos tickets. Basic is very scalable as well, since the ProxySG appliance is able to cache Basic credentials. However, the majority of ProxySG appliance users no longer accept Basic credentials for security reasons.
Kerberos is one of the best solutions to NTLM scalability problems. Unfortunately, it’s not widely well understood, and therefore tends to be under-utilized. Kerberos is a solid, scalable authentication protocol. It is faster and more secure than NTLM.
Performance enhancement options include Netlogon/MaxConcurrent API tuning choices, and IP and cookie surrogates.
Authentication Mechanism: Use Kerberos instead of NTLM whenever possible.
Surrogates: Use surrogates whenever possible. Consider using X-Forwarded-For header based surrogates in proxy chains.
Use IWA-BCAAA instead of IWA-Direct if:
Troubleshooting customer performance issues with NTLM: