How to configure Integrated Windows Authentication?

Integrated Windows Authentication (IWA) offers a secure and seamless way for users to access web applications by automatically using their existing Windows login credentials, eliminating the need for repeated logins.

Understanding Integrated Windows Authentication (IWA)

Integrated Windows Authentication, often referred to as NTLM or Kerberos authentication, allows a web server (like Internet Information Services - IIS) to authenticate users based on their Windows domain credentials. This provides a single sign-on experience within a corporate network, enhancing both security and user convenience.

Configuring IWA on IIS (Server-Side)

Setting up IWA primarily involves enabling the Windows Authentication feature on your web server and disabling conflicting authentication methods.

Step-by-Step Configuration for Modern IIS (8.0 and later)

1. Install Windows Authentication Role (if not already installed):
   • Open Server Manager.
   • Click Manage > Add Roles and Features.
   • Navigate to Server Roles, expand Web Server (IIS) > Web Server > Security.
   • Check Windows Authentication and complete the installation wizard.
2. Open IIS Manager: Access IIS Manager through Administrative Tools.
3. Navigate to the Target Website or Application: In the Connections pane, expand your server, then Sites, and select the specific website or application you wish to configure (e.g., Default Web Site).
4. Open Authentication Settings: In the main content pane (Features View), double-click Authentication.
5. Enable Windows Authentication: Right-click Windows Authentication and select Enable.
6. Disable Anonymous Authentication: Right-click Anonymous Authentication and select Disable. This prevents unauthorized access and forces clients to authenticate using Windows credentials.
7. Configure Advanced Settings (Optional but Recommended):
   • Right-click Windows Authentication and select Advanced Settings....
   • You can set the Providers order (typically Negotiate first for Kerberos, then NTLM).
   • Consider Enable Kernel-mode authentication for performance, but be aware of potential Kerberos issues with certain configurations.
8. Verify Application Pool Identity: Ensure the application pool running your website has an identity (e.g., NetworkService or a dedicated service account) that can access necessary resources and is trusted for delegation if Kerberos is used.

Configuring IWA for Older IIS Versions or Specific UI Paths

For some older IIS configurations or specific administrative interfaces, the steps might appear slightly different:

• Right-click on your target website (e.g., Default Web Site) in IIS Manager.
• Select Properties and navigate to the Directory Security tab.
• Click the Edit button next to "Enable anonymous access" to open the "Authentication Methods" dialog.
• In this dialog, you must disable anonymous access and ensure that Integrated Windows authentication (or similarly named option) is enabled. This process allows you to edit the authentication methods for this resource.

Configuring Client Browsers for IWA

For a seamless IWA experience, client web browsers must be configured to automatically send user credentials to the web server.

Internet Explorer and Microsoft Edge

These browsers are generally well-suited for IWA within a Windows domain environment:

• Add the site to a trusted zone:
  • Open Internet Options (from Control Panel or Edge settings).
  • Go to the Security tab.
  • Select Local intranet or Trusted sites zone.
  • Click Sites and add the URL of your web application (e.g., http://yourserver or http://yourserver.yourdomain.com).
• Configure user authentication:
  • With the appropriate zone selected, click Custom level....
  • Scroll down to User Authentication > Logon.
  • Select Automatic logon only in Intranet zone or Automatic logon with current user name and password.

Google Chrome

Chrome typically inherits security zone settings from Internet Explorer on Windows. If IWA isn't working:

• Ensure the site is added to the Local intranet or Trusted sites zone as described for IE/Edge.
• If still experiencing issues, you may need to add --auth-server-whitelist="*yourdomain.com,yourserver.com" to Chrome's shortcut target or configure it via Group Policy.

Mozilla Firefox

Firefox requires explicit configuration:

• Type about:config in the address bar and accept the warning.
• Search for network.automatic-ntlm-auth.trusted-uris.
• Double-click the entry and add a comma-separated list of the web server's domain or hostnames (e.g., yourserver.yourdomain.com,yourserver).
• You might also need to check network.negotiate-auth.trusted-uris for Kerberos.

Common Issues and Troubleshooting

• Service Principal Names (SPNs): For Kerberos authentication, correct SPNs are critical. If the application pool runs under a service account, you might need to register an SPN using setspn -A HTTP/YourServerName YourDomain\ServiceAccount. For more details, refer to Microsoft's documentation on SPNs.
• Loopback Check: If accessing the website from the same server it's hosted on, the Windows Loopback Check Security Feature might block authentication. You may need to disable it (not recommended for production) or configure BackConnectionHostNames in the registry.
• DNS Resolution: Ensure client machines can correctly resolve the web server's hostname to its IP address.
• Firewall: Verify no firewalls are blocking communication on ports used by IWA (e.g., Kerberos uses UDP/TCP 88, NTLM uses TCP 445).
• Double-Hop Scenarios: For applications requiring delegation (e.g., accessing a backend database using the user's identity), Kerberos delegation (constrained or unconstrained) must be properly configured in Active Directory.
• Provider Order: Ensure Negotiate is prioritized in IIS Advanced Settings for Kerberos. If Negotiate fails, NTLM can be used as a fallback.

Practical Considerations

Feature	Integrated Windows Authentication
User Experience	Seamless single sign-on (SSO) within a domain.
Security	High; leverages existing domain security infrastructure.
Complexity	Can be complex to configure (especially Kerberos/SPNs).
Best Use Cases	Internal corporate applications, intranets, domain-joined clients.
Client Requirement	Domain-joined client, proper browser configuration.

Integrated Windows Authentication is an excellent choice for internal applications where users are primarily on domain-joined machines. It provides a secure, efficient, and user-friendly authentication experience by leveraging the existing Active Directory infrastructure.