- 10 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 Service Principal Name (SPN) (Integrated Security Only)

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 Required SPNs

Before continuing, confirm that the application pool account has the required HTTP entries for the exact hostnames users access.

Use setspn -l to list every SPN currently registered to the service account, and use setspn -Q to verify whether a specific SPN exists for one hostname:

setspn -l DOMAIN\serviceaccount
setspn -Q HTTP/HOSTNAME
setspn -Q HTTP/HOSTNAME.yourdomain.com

Important

This is a blocking requirement. Kerberos is hostname-specific. If either HTTP/HOSTNAME or HTTP/HOSTNAME.yourdomain.com is missing, the browser cannot obtain a valid Kerberos ticket for that host and will keep prompting for credentials.

When the browser requests the FQDN (HOSTNAME.yourdomain.com) but the AD team only added the short machine name (HOSTNAME), the site still fails even though the short-name SPN appears to exist.

If either entry is missing, register both before continuing:

setspn -S HTTP/HOSTNAME.yourdomain.com DOMAIN\serviceaccount
setspn -S HTTP/HOSTNAME 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 and Multiple IIS Bindings

For a normal site on the default HTTP(S) ports, the browser usually does not include the port in the Kerberos SPN lookup. A standard SPN such as HTTP/srv-nodinite.yourdomain.com is normally sufficient for ports 80 and 443.

This becomes relevant only when the same IIS server exposes multiple bindings or identities that create ambiguity. Typical examples include:

  • multiple IIS sites on the same server using different ports
  • multiple hostnames or aliases pointing to the same server
  • a single host being presented with different bindings or identities across environments (for example, PROD and TEST on the same box)

In these cases, Kerberos can fail because the browser requests a ticket for the exact host binding while the service is configured under a different identity or binding. This is not the usual case for a single site on a standard port; it is a special case for multi-binding/multi-identity IIS environments.

If a non-default port is unavoidable, the cleanest design is to use separate DNS names or TLS hostnames so the SPN remains unambiguous. This is preferred over relying on port-based distinctions, because the browser and Kerberos stack are fundamentally host-based.

If the server must support a non-default port and the site is not uniquely identified by hostname, apply the following registry value on the IIS server to force the port into the SPN lookup:

# 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.

Important

After changing SPNs, clear the Kerberos ticket cache on the client workstation before retesting. Stale tickets can keep the browser using the old service principal and make it look like the SPN change failed.

klist purge

Then reopen the browser and retry the site.

Step 3: Configure IIS (Integrated Security Only)

For Nodinite v7, this step is required only when using Windows Integrated Security (Kerberos/NTLM), because the application pool uses 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. 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: 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