- 8 minutes to read

Restoring Kerberos Transparent Login After Upgrading to v7

After upgrading from Nodinite v6 to v7, users may encounter an unexpected browser login prompt when accessing the Web Client. This typically happens in environments where the IIS application pool runs under a domain service account (such as a CyberArk-managed account). Personal accounts cannot satisfy the prompt because MFA Conditional Access policies block them, leaving users stuck.

This guide explains why the upgrade changes Kerberos behaviour, and provides the three steps required to restore transparent single sign-on.

Important

This article is primarily a v7 upgrade troubleshooting guide.

  • Applies to v7: All remediation steps in this document.
  • Applies to v6: Architectural background only (to explain why behaviour changed).
  • Applies to both versions: Kerberos fundamentals such as DNS, SPN uniqueness, and browser zone trust.

For Nodinite v7, the IIS application pool identity must be a domain service account. Do not use machine account identities for v7 in production.

Note

This guide covers authentication failures (login prompt appearing). If you experience slow page loads with no login prompt, see the NTLM vs Kerberos Authentication performance guide instead.

Why v6 and v7 Behave Differently

Understanding the architectural change between v6 and v7 makes the fix much easier to reason about.

Nodinite v6 (Legacy Context) — Virtual Directory Under Default Web Site

In v6, Nodinite ran as a virtual directory nested under the IIS Default Web Site. In this topology:

  • The IIS application pool uses the machine account (ApplicationPoolIdentity)
  • The machine account has a Service Principal Name (SPN) automatically registered in Active Directory when the server joins the domain
  • The browser recognises the hostname, finds an existing SPN, and sends a Kerberos ticket automatically
  • No login prompt appears — authentication is fully transparent

Nodinite v7 (Required Configuration) — Separate IIS Site

In v7, Nodinite runs as its own separate IIS site. This small topology change has significant Kerberos implications:

  • The IIS application pool identity must be a domain service account
  • If the site uses a different hostname from the Default Web Site, the machine's default SPN no longer matches the URL
  • IIS must be configured to decrypt Kerberos tickets by using the app pool account credentials (useAppPoolCredentials=True)
  • Without these changes, Kerberos fails silently, the browser falls back to NTLM, and a login prompt appears
  • If the domain service account is a CyberArk-managed account with no known password, and personal accounts are blocked by MFA Conditional Access, the login prompt cannot be satisfied

The table below summarises the key differences:

Factor Nodinite v6 (Virtual Directory) Nodinite v7 (Separate Site)
IIS topology Virtual directory under Default Web Site Standalone IIS site
Default SPN Often machine account SPN — auto-registered Must be manually registered to match the v7 hostname and account
App pool account Often ApplicationPoolIdentity Must be DOMAIN\ServiceAccountName
useAppPoolCredentials required Not normally Yes (required for v7)
Kerberos out-of-the-box Often works with default topology Requires explicit configuration steps below

Three Steps to Restore Transparent Kerberos

Step 1: Gather Your Environment Details

Before making any changes, collect the following information. You will need it in Steps 2 and 3.

Hostname

The hostname is the URL hostname you use in the browser to access Nodinite v7.

Example: if you browse to https://srv-nodinite.yourdomain.com, the hostname is:

srv-nodinite.yourdomain.com

Important

The hostname must be a real DNS name, not just an entry in the hosts file. Kerberos uses DNS to locate the SPN in Active Directory. A hosts-file-only name will not work.

Application Pool Identity

  1. Open IIS Manager
  2. Click Application Pools
  3. Select the Nodinite application pool
  4. In the Actions pane, click Advanced Settings
  5. Note the value under Identity

Common values:

Value Description
DOMAIN\ServiceAccountName Required for Nodinite v7. Use this same account when registering SPN in Step 2, then enable useAppPoolCredentials in Step 3.

Warning

If your Nodinite v7 site currently runs as ApplicationPoolIdentity (or another machine/virtual account), change it to a dedicated domain service account before continuing.

Step 2: Register the Service Principal Name (SPN)

A domain administrator must register SPNs in Active Directory that map the Nodinite v7 hostname to the correct account.

Important

Only a domain administrator can run setspn to register SPNs. Raise a ticket to your AD team if you do not have this permission.

Check Existing SPNs First

Before registering anything, check what is already registered to avoid duplicates:

setspn -l DOMAIN\serviceaccount

If an HTTP/<hostname> entry already exists for the correct account, skip to Step 3.

Register SPNs

Register both the FQDN and the short (NetBIOS) name. This covers both URL formats users may type.

For Nodinite v7, register the SPN against the domain service account used by the IIS application pool:

setspn -S HTTP/srv-nodinite.yourdomain.com DOMAIN\serviceaccount
setspn -S HTTP/srv-nodinite DOMAIN\serviceaccount

Replace DOMAIN\serviceaccount with the actual account from Step 1.

Note

Always use HTTP in the SPN, even if the site is accessed over HTTPS. IIS registers HTTP SPNs regardless of whether TLS is in use.

Non-Default Ports

By default, browsers do not include the port number in the SPN lookup. This means an SPN registered without a port (e.g., HTTP/srv-nodinite.yourdomain.com) works correctly for standard ports 80 and 443.

If Nodinite is hosted on a non-default port (e.g., https://srv-nodinite.yourdomain.com:40001) and multiple IIS sites share the same server under different ports and identities, Kerberos may fail because the browser omits the port from the ticket request while IIS expects it.

In this case, set the following registry value on the IIS server to force the port to be included in the SPN:

# Run as Administrator on the IIS server
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" `
    -Name "FEATURE_INCLUDE_PORT_IN_SPN_KB908209" -Value 1 -Type DWord

Then restart the HTTP service:

iisreset

Warning

This registry setting is server-wide and affects all IIS sites on the machine. Only apply it if you are specifically experiencing Kerberos failures on non-default ports with multiple sites running under different identities.

Verify Registration 

setspn -l DOMAIN\serviceaccount

Confirm both the FQDN and short-name entries appear in the output.

Step 3: Configure IIS (Required for v7)

For Nodinite v7, this step is required because the application pool must run under a domain service account.

When a domain service account is used, IIS must be told to use that account's credentials to decrypt the incoming Kerberos ticket. This is controlled by the useAppPoolCredentials setting.

Enable useAppPoolCredentials in IIS Configuration Editor

  1. Open IIS Manager
  2. In the left pane, expand Sites and select your Nodinite v7 Web Client site
  3. In the Features View (centre pane), double-click Configuration Editor
  4. In the Section dropdown, navigate to: system.webServer/security/authentication/windowsAuthentication
  5. Locate the useAppPoolCredentials entry in the list
  6. Set its value to True
  7. Click Apply in the Actions pane

After applying, run an IIS reset:

iisreset

Tip

If you do not see the Configuration Editor feature in IIS Manager, ensure the IIS Management Console and IIS 6 Management Compatibility features are installed. See IIS Windows Features for the full list of required features.

Browser Configuration — Local Intranet Zone

Even with correct SPN registration and useAppPoolCredentials configured, browsers will only send Kerberos tickets to sites listed in the Local Intranet Zone. This zone tells the browser to trust the site for automatic credential negotiation.

Manual (Per-User, for Testing)

  1. Open inetcpl.cpl (Internet Options)
  2. Go to the Security tab
  3. Select Local Intranet → click Sites → click Advanced
  4. Add your Nodinite v7 URL or a wildcard pattern, for example:
    • https://srv-nodinite.yourdomain.com (specific host)
    • *.yourdomain.com (all hosts in the domain)
  5. Click OK
  6. Restart the browser

Deploy the zone assignment via Group Policy to ensure all users receive the setting automatically:

  1. Open Group Policy Management Console
  2. Navigate to: Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page
  3. Open Site to Zone Assignment List → Enabled
  4. Add an entry:
Name Value
https://srv-nodinite.yourdomain.com 1 (Local Intranet)
  1. Run gpupdate /force on affected machines

Verification

After completing all three steps, verify Kerberos is working:

  1. Open a new browser window and navigate to your Nodinite v7 URL
  2. Confirm no login prompt appears — the page loads directly into the Web Client
  3. On the client workstation, run klist and look for an HTTP service ticket:
klist

A successful entry looks like:

Server: HTTP/srv-nodinite.yourdomain.com @ YOURDOMAIN.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

If a ticket for HTTP/srv-nodinite.yourdomain.com is present, Kerberos is active and the login prompt will not reappear.

Quick Reference

Symptom Most Likely Cause Fix
Login prompt appears after upgrading to v7 SPN not registered for new hostname Step 2: Register HTTP SPN
Login prompt in v7 with domain service account useAppPoolCredentials not set Step 3: Enable in IIS Configuration Editor
Login prompt on browser, but curl --negotiate works Browser not in Intranet Zone Browser Configuration section above
Both browser and curl require login SPN missing entirely Step 2, then Step 3
setspn -S returns "duplicate SPN" SPN already registered to another account Remove the old SPN first: setspn -D HTTP/hostname OLDACCOUNT

Next Steps