Enable Windows Integrated Authentication on an Active Directory Domain

This guide is provided for configuring Windows Integrated Authentication (Kerberos/NTLM) with a Group Managed Service Account (gMSA) on the Web Portal.

Due to the unique nature of each company’s network and architecture, we cannot provide support for issues arising from following this documentation. It meets the technical requirements for Web Portal with Windows Integrated Authentication, but implementation is at your own responsibility.

Domain configuration

The Active Directory environment must support Kerberos or NTLM authentication.

Set up a Managed Service Account (gMSA)

Install the Web Portal service and run it with a domain managed service account instead of a domain admin account.

Prerequisites

• Active Directory schema level: Windows Server 2012 or later (required for gMSA)
• At least one domain controller running Windows Server 2012 or later
• KDS root key created (one-time setup)
• Membership in Domain Admins or Account Operators to create the account

Create the KDS root key (if not already created)

Run on a domain controller in an elevated PowerShell session:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

This makes the root key immediately available.

Create the gMSA

Use New-ADServiceAccount:

New-ADServiceAccount `
  -Name "WebPortalSvc" `
  -DNSHostName "WebPortalSvc.domain.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "YourServerGroup" `
  -Enabled $true

• Name: gMSA account name
• DNSHostName: FQDN for the account
• PrincipalsAllowedToRetrieveManagedPassword: computers/group allowed to use this gMSA

Grant administrative rights (optional / as needed)

By default, a gMSA has no special privileges.

To grant domain-level access (optional):

Add-ADGroupMember -Identity "Domain Admins" -Members "WebPortalSvc$"

To grant local admin/logon capability (if needed):

Add-ADGroupMember -Identity "Administrateurs" -Members "WebPortalSvc$"

Important: the trailing $ is required for gMSA account references in AD.

Reboot requirement

A reboot is required before continuing and installing/using the service account. Also refresh policies.

Install the gMSA on target servers

Run on each server that will use the gMSA:

Install-ADServiceAccount -Identity "WebPortalSvc"

Test installation:

Test-ADServiceAccount -Identity "WebPortalSvc"

Configure services to use the gMSA

1. Grant Log on as a service to the account:

   • Open Group Policy Editor
   • Go to: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
   • Open Log on as a service
   • Add DOMAIN\WebPortalSvc$

2. Ensure NTFS permissions on Web Portal files/folders:

   • Right-click application folder/executable > Properties > Security
   • Add DOMAIN\WebPortalSvc$
   • Grant at least Read & Execute (or Full Control if required by your deployment)

3. Configure service identity:

   • Account: DOMAIN\WebPortalSvc$
   • Password: leave blank

Configure Service Principal Name (SPN)

The web service must be registered in Kerberos.

Run on a domain controller:

setspn -A HTTP/webserver.domain.com DOMAIN\WebPortalSvc

Replace with your server FQDN and account.

If the Web Portal hosting server uses HTTP.sys, register SPN against the machine account:

setspn -S HTTP/portal.hiyoko.com:8008 WIN-HLBO0AGABB7
setspn -S HTTP/portal.hiyoko.com:8009 WIN-HLBO0AGABB7

Configure network on the client machine

To put a domain-joined client in the correct subnet:

1. Identify the correct network interface
2. Remove existing static IP (if incorrect)
3. Assign static IP, subnet mask, and default gateway matching DNS/DC subnet
4. Set DNS server addresses

Important: assign static IP addresses to domain controller and clients. Security policy synchronization requires machines to be in the same subnet in this context.

Allow required client connectivity

UDP/TCP 53 may be blocked, which prevents DNS queries.

Troubleshooting steps

Check DNS server status

On domain controller:

net start DNS

Verify DNS service is running.

Verify DNS server IP

On client:

ipconfig /all

Confirm DNS server IP matches the domain controller IP.

Test basic connectivity

On client:

ping <DC_IP_Address>

If ping fails, troubleshoot network/firewall routing.

Check firewall rules

Ensure inbound/outbound UDP/TCP 53 is allowed on client and server.

Test with nslookup

nslookup domain.com <DC_IP_Address>

If this works, default DNS server may be misconfigured or unreachable.

Review Event Viewer

On the domain controller, check DNS-related errors.

Configure Mozilla Firefox for Windows Integrated Authentication

Firefox does not use WIA by default.

Step 1: trusted negotiate URIs

1. Open Firefox
2. Go to about:config
3. Accept warning
4. Set network.negotiate-auth.trusted-uris to your domains, for example:
   • intranet.domain.com, domain.com

Step 2: trusted NTLM URIs

Set network.automatic-ntlm-auth.trusted-uris to the same domain list.

Step 3: Kerberos delegation URIs (if required)

Set network.negotiate-auth.delegation-uris, for example:

• domain.com

Step 4: restart browser

Restart Firefox to apply changes.

Configure Google Chrome for Windows Integrated Authentication

Chrome uses Windows/system authentication settings.

Via Group Policy (recommended)

1. Download Chrome ADMX templates:
   • https://chromeenterprise.google/policies/
2. Copy chrome.admx and chrome.adml to:
   • C:\Windows\PolicyDefinitions
   • C:\Windows\PolicyDefinitions\en-US
3. Open gpedit.msc
4. Go to:
   • Computer Configuration > Administrative Templates > Google > Google Chrome
5. Enable integrated authentication for intranet sites and configure trusted sites:
   • intranet.domain.com, domain.com
6. Apply policy:

gpupdate /force

Other methods

Other methods (Chrome command line switches and flags) were not successful in this context.

Configure Microsoft Edge for Windows Integrated Authentication

Edge uses Microsoft Edge policies and Windows security zone settings.

Enable automatic logon in intranet zone

1. Open Internet Options
2. Security tab > Local Intranet > Custom Level
3. Under User Authentication, set:
   • Automatic logon only in Intranet zone

Configure Edge policies via GPO

Step 1: install Edge ADMX templates

1. Download:
   • https://www.microsoft.com/en-us/edge/business/download
2. Copy msedge.admx and msedge.adml to:
   • C:\Windows\PolicyDefinitions
   • C:\Windows\PolicyDefinitions\en-US

Step 2: edit policy settings

1. Open gpedit.msc
2. Go to:
   • Computer Configuration > Administrative Templates > Microsoft Edge
3. Enable:
   • Configure the list of servers that Microsoft Edge can delegate credentials to
4. Configure trusted servers:
   • intranet.domain.com, domain.com

Step 3: apply policies

gpupdate /force

Other methods

Other methods (Edge command line switches and flags) were not successful in this context.

Troubleshooting integrated authentication

Check Kerberos tickets

On Windows client:

klist

You should see a ticket for HTTP/webserver.domain.com.

Clear cached credentials/tickets

klist purge

Verify SPN registration

On domain controller:

setspn -L serviceaccount

Ensure HTTP/webserver.domain.com is listed.

Debug Kerberos in Firefox

Start Firefox with logging:

set NSPR_LOG_MODULES=negotiateauth:5
set NSPR_LOG_FILE=%USERPROFILE%\Desktop\firefox.log
start firefox.exe

Review firefox.log for authentication errors.

Check Chrome policies

In Chrome, open:

chrome://policy

Ensure AuthServerWhitelist and AuthNegotiateDelegateWhitelist are applied.

Check Edge policies

In Edge, open:

edge://policy

Ensure AuthServerWhitelist and AuthNegotiateDelegateWhitelist are applied.