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

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 — 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 — Separate IIS Site

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

  • If the site uses a different hostname from the Default Web Site, the machine's default SPN no longer matches the URL
  • If the application pool runs under a domain service account (rather than ApplicationPoolIdentity), IIS needs additional configuration to decrypt the Kerberos ticket using that account's credentials
  • 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 Machine account SPN — auto-registered Must be manually registered to match the new hostname
App pool account Typically ApplicationPoolIdentity May use a domain service account
useAppPoolCredentials required No Yes, if using a domain service account
Kerberos out-of-the-box ✅ Works automatically ❌ Requires 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
ApplicationPoolIdentity Built-in virtual account — uses the machine account SPN
DOMAIN\ServiceAccountName Domain service account — requires useAppPoolCredentials in Step 3

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.

If the application pool runs under ApplicationPoolIdentity (machine account):

setspn -S HTTP/srv-nodinite.yourdomain.com SERVERNAME$
setspn -S HTTP/srv-nodinite SERVERNAME$

Replace srv-nodinite.yourdomain.com with your FQDN, srv-nodinite with the short hostname, and SERVERNAME$ with the server's machine account name (computer name followed by $).

If the application pool runs under a domain service account:

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 (Domain Service Account Only)

This step is only required when the application pool runs under a domain service account (not ApplicationPoolIdentity).

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 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 only when using service/CyberArk 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