- 6 minutes to read

Login Prompt from the Web Client asks you for a password / can't log in

With Windows Authentication, users sign in to the Nodinite Web Client transparently with their domain credentials. A password prompt, a 401 Unauthorized, or a refused login means that one link in the chain is broken: the user is unknown to Nodinite, the browser doesn't offer Kerberos, or IIS can't accept the Kerberos ticket. This page helps you find which.

The authentication mode is set per environment in the Nodinite Portal (Step 2: Auth → Auth mode). If your environment uses OAuth 2.0 / OpenID Connect, users sign in at your identity provider instead; check the Web Client values in Step 2: Auth → Web Client and Install Nodinite v7 - OpenID, then confirm the user's Claims and Policies.

Note

Web Client URL: In Nodinite v7 the Web Client runs at the root of its own IIS web site, for example https://nodinite.contoso.com:<port>/. The host name and port come from the Portal (Step 4: Servers → Core platform services).

Understanding Transparent Sign-In

flowchart LR User["fa:fa-user User in browser"] Zone{"Site in Local Intranet zone
or allowed by policy?"} SPN{"HTTP SPN on the right account
and IIS set to match?"} Registered{"User or AD group
registered in Nodinite?"} OK["fa:fa-circle-check Signed in"] Prompt["fa:fa-key Password prompt
or slow NTLM fallback"] Denied["fa:fa-ban Access denied"] User --> Zone Zone -->|"Yes"| SPN Zone -->|"No"| Prompt SPN -->|"Yes, Kerberos"| Registered SPN -->|"No"| Prompt Registered -->|"Yes"| OK Registered -->|"No"| Denied style OK fill:#93d16d style Prompt fill:#FFD525 style Denied fill:#c33d34

Diagram: transparent sign-in needs three things: the browser offers credentials (green path continues), Kerberos works end to end, and the user is known to Nodinite. Yellow marks a prompt or NTLM fallback; red marks a refused login.

Gate What must be true Where to fix it
Browser The site is in the Local Intranet zone, or allowed by the AuthServerAllowlist policy Browser configuration below
Kerberos An HTTP SPN exists for the host name in the address bar, on the account IIS uses to decrypt tickets (useAppPoolCredentials) HTTP SPN for IIS
Nodinite The Windows identity is a User or a member of a registered Windows AD Group, with a Role Add or manage User

Common Troubleshooting Checklist

Issue / Check Resolution
Is the Windows identity added as a user or part of a registered AD Group? User must exist in Nodinite. Users that are not registered, directly or through an AD group, can't sign in
Test locally on the Nodinite server If sign-in works locally, the issue is on the network or client side (browser zone, firewall, domain connectivity). A 401 when you browse locally by host name is the loopback check, see IIS Authentication settings
Did the prompt start after upgrading from v6 to v7? v7 runs the Web Client in its own IIS site, often with a new host name or app pool identity. Register the HTTP SPNs, see Kerberos Transparent Login After v7 Upgrade
Verify that the Windows Authentication role is installed in IIS - See IIS Windows Features ⚠️ Most common problem on new servers - Windows Authentication must be installed in IIS
Windows Authentication role installed in IIS
Example: Windows Authentication role installed in IIS.
Check the HTTP SPN and useAppPoolCredentials The SPN owner and the IIS setting must match. Run setspn -Q HTTP/<hostname> for the short name and the FQDN; see HTTP SPN for IIS
Verify the 'Access this computer from the network' local policy The Windows default includes Everyone; restrictive policies may block domain users
Access this computer from the network local policy
Example: Windows default policy with Everyone in the list.
Browser configuration - See Browser configuration below Edge, Chrome, and Firefox only pass Windows credentials automatically to trusted sites

Tip

Sign-in works but every page is slow? The browser has fallen back to NTLM. See NTLM vs Kerberos Authentication for the diagnostic script and the fix.

Browser Configuration

Browsers send Windows credentials automatically only to sites they trust for it. Users of a site outside that zone see a password prompt, especially over HTTPS with a fully qualified host name.

Add the Site to the Local Intranet Zone (Windows)

Edge and Chrome on Windows use the Windows Internet Options zones.

  1. Open Internet Options (inetcpl.cpl).
  2. Go to the Security tab → Local intranet → Sites → Advanced.
  3. Add your Nodinite URL, for example https://nodinite.contoso.com.
  4. Click Add, then Close, and OK to save.
  5. Restart the browser.

For many users, deploy the zone assignment with Group Policy instead; see NTLM vs Kerberos Authentication.

Note

The Trusted sites zone does not log on automatically by default. Use the Local intranet zone, or change the Trusted sites User Authentication → Logon setting to Automatic logon with current user name and password.

Edge and Chrome Policies

As an alternative to the zone, set the AuthServerAllowlist policy (Edge: Microsoft Edge → HTTP authentication → Authentication server allowlist; Chrome: Google Chrome → HTTP authentication) to your host name or domain, for example *.contoso.com. Check the effective value at edge://policy or chrome://policy. PowerShell examples are in Configure Edge/Chrome authentication policies.

Mozilla Firefox

Firefox doesn't use the Windows zones:

  1. Navigate to about:config.
  2. Search for network.negotiate-auth.trusted-uris and add your host name or domain, for example https://nodinite.contoso.com or .contoso.com (comma-separated).
  3. To allow the NTLM fallback, add the same value to network.automatic-ntlm-auth.trusted-uris.

HTTPS and Certificates

Use a certificate that the client trusts and whose subject or SAN matches the host name in the address bar; the installer finds and binds it from the host name and certificate subject in Step 4: Servers → Core host Configuration. Certificate warnings before the login prompt point to a certificate problem, not an authentication problem. See How to perform hardening and TLS Troubleshooting.

Network and Firewall Issues

If sign-in works locally but fails remotely:

  • Firewall blocking Kerberos: The client must reach the domain controllers (Kerberos: 88, LDAP: 389, 636)
  • DNS resolution: The client must resolve the server host name; browse with the host name or FQDN, never the IP address (Kerberos needs a name to build the SPN)
  • Time synchronization: Kerberos requires client and server clocks within 5 minutes
  • Domain connectivity: The client must reach a domain controller to get a ticket

See Troubleshooting Kerberos authentication for advanced diagnostics.

Note

Nodinite v6 is no longer supported. To move an existing v6 installation, follow Updating from v6 to v7.

Next Steps