Configuring Chrome and Firefox for Windows Integrated Authentication

Windows Integrated Authentication (WIA) comes as standard with Microsoft’s own internet browsers. However, you may want the benefits that comes with it while using the internet browser of your own choosing. Thankfully you can still get the benefits of Windows Integrated Authentication (WIA) with both Chrome and Firefox browsers, but it requires some configuration to ensure that the browsers can properly handle the authentication process. We’ll run through why this is worth some brief effort and show you the practical steps you’ll need to take. 

What is Windows Integrated Authentication (WIA)?

Windows Integrated Authentication allows a users’ Active Directory credentials to pass through their browser to a web server. Windows Integrated Authentication is enabled by default for Internet Explorer but not Google Chrome or Mozilla Firefox. Users who use the non-Microsoft browsers will receive a pop-up box to enter their Active Directory credentials before continuing to the website.

This adds additional steps and complexity for users who are using web based applications like self-service password reset solutions such as Specops uReset. In an effort to make this process as easy as possible for end-users, many IT administrators enable Windows Integrated Authentication for the third party browsers. This can be done with Chrome and Firefox with a few additional steps. This article will show you how to enable Windows Integrated Authentication for Google Chrome and Mozilla Firefox.

Why use Windows Integrated Authentication (WIA) for Firefox and Chrome?

Using Windows Integrated Authentication (WIA) offers several benefits, making it a popular choice in many corporate and enterprise environments. Here are some key reasons why you might want to use it on whichever browser you have equipped:

1. Enhanced Security:

   • Single Sign-On (SSO): Users only need to log in once to their Windows machine, reducing the risk of password exposure and making it harder for unauthorized users to gain access.
   • Strong authentication: WIA primarily uses Kerberos, which is a robust and secure protocol that provides strong authentication and reduces the risk of credential theft.

2. Improved user experience:

   • Seamless access: Users can access network resources and applications without the need to re-enter their credentials, making the process more efficient and user-friendly.
   • Reduced friction: Fewer login prompts mean less interruption and a smoother workflow, which can increase productivity.

3. Centralized management:

   • Active Directory integration: WIA works seamlessly with Active Directory, allowing for centralized management of user accounts and permissions.
   • Policy enforcement: Administrators can enforce security policies and manage user access more effectively through Active Directory.

4. Reduced administrative overhead:

   • Less password management: With SSO, users are less likely to forget their passwords, reducing the number of password reset requests and support calls.
   • Simplified configuration: Once set up, WIA requires minimal ongoing configuration and maintenance.

5. Compliance and auditing:

   • Audit trails: WIA can help in maintaining detailed audit logs of user activities, which is crucial for compliance with regulatory requirements.
   • Consistent authentication: Ensures that all users are authenticated in a consistent and secure manner, which is important for maintaining compliance standards.

6. Scalability:

   • Easily scalable: WIA can be easily scaled to accommodate growing numbers of users and resources, making it suitable for large organizations.
   • Flexible deployment: It can be deployed in various network environments, including both on-premises and cloud-based setups.

7. Integration with other Microsoft services:

   • Integration: WIA works well with other Microsoft services and products, such as SharePoint, Exchange, and SQL Server, providing a cohesive and integrated security solution.

Configuring delegated security for Mozilla Firefox

To configure Firefox to use Windows Integrated Authentication:

1. Open Firefox.

2. In the address bar type about:config

3. You will receive a security warning. To continue, click I’ll be careful, I promise.

4. You will see a list of preferences listed. Find the settings below by browsing through the list or searching for them in the search box. Once you have located each setting, update the value to the following:

** MyIISServer.domain.com should be the fully qualified name of your IIS server that you are setting up the Windows Integrated Authentication to.

Negotiate authentication is not supported in versions of Firefox prior to 2006.

Configuring delegated security in Google Chrome

Note: The latest version of Chrome uses existing Internet Explorer settings. Older version of Chrome require additional configurations (see below).

You can use three methods to enable Chrome to use Windows Integrated Authentication. Your options are the command line, editing the registry, or using ADMX templates through group policy. If you choose to use the command line or edit the registry, you could use Group Policy Preferences to distribute those changes on a broader scale. Below are the steps for the three methods:

To use the command line to configure Google Chrome

Start Chrome with the following command:

Chrome.exe –auth-server-whitelist=”MYIISSERVER.DOMAIN.COM” –auth-negotiate-delegatewhitelist=”MYIISSERVER.DOMAIN.COM” –auth-schemes=”digest,ntlm,negotiate”

To modify the registry to configure Google Chrome

Configure the following registry settings with the corresponding values:

Registry: AuthSchemes

Data type: String (REG_SZ)

Windows registry location: Software\Policies\Google\Chrome\AuthSchemes

Mac/Linux preference name: AuthSchemes

Supported on: Google Chrome (Linux, Mac, Windows) since version 9

Supported features:Dynamic Policy Refresh: No, Per Profile: No

Description: Specifies which HTTP Authentication schemes are supported by Google Chrome. Possible values are ‘basic’, ‘digest’, ‘ntlm’ and ‘negotiate’. Separate multiple values with commas. If this policy is left not set, all four schemes will be used.

Value: “basic,digest,ntlm,negotiate”

AuthServerWhitelist

Data type: String (REG_SZ)

Windows registry location: Software\Policies\Google\Chrome\AuthServerWhitelist

Mac/Linux preference name: AuthServerWhitelist

Supported on: Google Chrome (Linux, Mac, Windows) since version 9

Supported features: Dynamic Policy Refresh: No, Per Profile: No

Description: Specifies which servers should be whitelisted for integrated authentication. Integrated authentication is only enabled when Google Chrome receives an authentication challenge from a proxy or from a server which is in this permitted list. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will try to detect if a server is on the Intranet and only then will it respond to IWA requests. If a server is detected as Internet then IWA requests from it will be ignored by Chrome.

Value: “MYIISSERVER.DOMAIN.COM”

AuthNegotiateDelegateWhitelist

Data type: String (REG_SZ)

Windows registry location: Software\Policies\Google\Chrome\AuthNegotiateDelegateWhitelist 

Mac/Linux preference name: AuthNegotiateDelegateWhitelist

Supported on: Google Chrome (Linux, Mac, Windows) since version 9

Supported features: Dynamic Policy Refresh: No, Per Profile: No

Description: Servers that Google Chrome may delegate to. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will not delegate user credentials even if a server is detected as Intranet.

Example Value: ”MYIISSERVER.DOMAIN.COM”

To use ADM/ADMX templates through Group Policy to configure Google Chrome

1.       Download Zip file of ADM/ADMX templates and documentation from: https://www.chromium.org/administrators/policy-templates

2.       Add the ADMX template to your central store, if you are using a central store.

3. Configure a GPO with your application server DNS host name with Kerberos Delegation Server Whitelist and Authentication Server Whitelist enabled.

Each of these three methods achieve the same results for configuring Google Chrome for Windows Integrated Authentication. The method that is best for you will depend on how your organization is set up.  Personally, I would use the command line or the registry if you are deploying across an enterprise. You can easily distribute a shortcut on the user’s desktop with the command and distribute that with Group Policy preferences. If you choose to use the registry method, that is able to be distributed with Group Policy.

With a variety of third-party browsers available, many users will receive a pop-up box to enter their Active Directory credentials before continuing to an IIS hosted web application. This leads to additional steps, complexity and confusion for many end-users. By setting up Windows Integrated Authentication into Chrome and Firefox, you will be able to give your users the greatest amount of flexibility for their choice of browser as well as ease of use with your web-based applications.

Making everyday IT tasks easier for end users and IT admins is something we specialize in. Our self-service password reset solution Specops uReset guarantees end user adoption thanks to its flexible approach to multi-factor authentication.

Save your IT service desk from password reset calls