- 7 minutes to read

Missing HTTP SPN: Restoring Kerberos Transparent Login After v7 Upgrade

After upgrading from Nodinite v6 to v7, users may encounter an unexpected browser login prompt when accessing the Nodinite 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.

Important

This is not optional work. If the required HTTP/<hostname> SPN is missing, the browser cannot obtain a Kerberos ticket and users will continue to be prompted for credentials. The AD team must create the SPN before the site can work transparently.

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 on Windows, a domain service account is required only when using Windows Integrated Security (Kerberos/NTLM). If the installation runs in workgroup mode and uses OAuth 2.x (for example Microsoft Entra ID), this Kerberos-specific requirement does not apply.

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 (Kerberos Scenario) — Separate IIS Site

In v7, Nodinite runs as its own separate IIS site. When you use Windows Integrated Security, this topology change has significant Kerberos implications:

  • The IIS application pool identity should 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

If your Windows deployment does not use Integrated Security (for example workgroup mode with OAuth 2.x and external IdP sign-in), the SPN and useAppPoolCredentials steps in this page are not applicable.

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 DOMAIN\ServiceAccountName when using Integrated Security
useAppPoolCredentials required Not normally Yes, when using Integrated Security
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 Use this when your v7 site uses Windows Integrated Security (Kerberos/NTLM). Register SPN in Step 2 and enable useAppPoolCredentials in Step 3.

Warning

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

Step 2: Register the HTTP SPNs (Integrated Security Only)

A domain administrator must register HTTP/ SPNs in Active Directory that map the Nodinite v7 hostname from Step 1 to the application pool account. Raise a ticket to your AD team if you don't have Domain Admin rights.

Important

This is a blocking requirement. Kerberos is hostname-specific. Register both the short name and the FQDN (for example HTTP/srv-nodinite and HTTP/srv-nodinite.yourdomain.com). If the browser requests the FQDN but only the short name is registered, users keep getting the login prompt.

Follow Register HTTP SPNs in the IIS SPN guide for the commands, web farm and non-default port cases, and how to resolve duplicate SPN errors. After registering, clear the client's ticket cache with klist purge before you retest.

Step 3: Configure IIS (Integrated Security Only)

Because the v7 application pool runs as a domain service account, IIS must decrypt the incoming Kerberos ticket with that account's credentials. In the windowsAuthentication section, set useKernelMode and useAppPoolCredentials to True on the v7 Web Client site, for example Nodinite-PROD-WebClient, then run iisreset.

Follow Configure IIS Windows Authentication in the IIS SPN guide for the appcmd command and the IIS Configuration Editor steps with a screenshot.

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. Clear any old Kerberos tickets on the client workstation:
klist purge
  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: Configure IIS
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, or conflicts with the computer account See HTTP SPN ownership conflicts in HTTP SPNs for IIS

Next Steps