Introduction to Working with IWA on the ProxySG Appliance

Products

• ProxySG Software - SGOS

Issue/Introduction

This article provides an introduction to how Integrated Windows Authentication (IWA) works with the ProxySG appliance. See attached pdf "IWA Authentication Fundamentals and Deployment Guidelines" for extensive functional and technical details, further recommendations, and illustrations.

Resolution

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.
 

Recommendations

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:

• NTLM is used for authentication AND
• MaxConcurrentAPI settings have been modified AND
• Surrogates cannot be used
   

Troubleshooting customer performance issues with NTLM:

• Discuss the modify MaxConcurrentAPI settings option.
• If they’re not willing to modify MaxConcurrentAPI settings, using nltest.exe (from the Windows resource kit) is another option. Nltest.exe can tell you which DC BCAAA is using for Schannel, and will allow you to forcibly switch to a DC that you specify. Some customers run nltest.exe in a cron job each night to ensure their BCAAA servers are always using the fastest DCs.
• Another solution is to create multiple IWA-BCAAA realms on the ProxySG appliance, and to deploy a BCAAA server for each realm. Incoming requests can be authenticated by one realm or the other by client subnet, HTTP header, or some other criteria known prior to authentication.