- 4 minutes to read

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

If the Nodinite Web Client prompts you for a password or prevents login, this guide helps you quickly identify and resolve the most common causes. Ensure seamless access by following these troubleshooting steps:

✅ Ensure Windows Authentication is enabled in IIS
✅ Verify user or AD group is registered in Nodinite
✅ Add HTTPS sites to browser Trusted Sites or Local Intranet zone
✅ Check firewall and local policy settings for domain communication
✅ Configure IIS authentication providers correctly

Nodinite relies on Windows Authentication and uses integrated security. IIS and Windows must be properly configured, and firewall settings must allow communication with domain controllers.

Note

Web Client URL varies by version and configuration:

  • Nodinite v7: http://localhost:40000 (default) or https://localhost or https://servername (with TLS on port 443)
  • Nodinite v6: http://servername/WebClient or https://servername/WebClient (with TLS)

See Install Nodinite v7 or Upgrading from v6 to v7 for version-specific configuration details.

The proper setup for IIS and Windows is described in the Install Nodinite guide.

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 not registered or part of an AD group cannot log in
Test locally on the Nodinite server If login works locally, the issue is network-related (firewall, browser configuration, domain connectivity)
Verify Windows Authentication role is installed in IIS - See IIS Windows Features Most common problem - Windows Authentication must be installed in IIS
Windows Authentication Role
Example: Windows Authentication role installed in IIS.
Check IIS Authentication providers - See IIS Authentication settings Ensure Negotiate and NTLM providers are enabled (Kerberos preferred)
Verify 'Access this computer from the network' local policy Windows default includes Everyone - restrictive policies may block domain users
Local Policy
Example: Windows default policy with Everyone in the list.
Modern browser Windows Authentication - See Browser Configuration below Chrome, Edge, Firefox require configuration to pass Windows credentials automatically

HTTPS/TLS Local Browsing - Trusted Sites Requirement

When accessing Nodinite Web Client over HTTPS on localhost or local network, Windows and browsers require the site to be in the Trusted Sites or Local Intranet zone to automatically pass credentials.

Symptom

  • Browsing to https://localhost/WebClient or https://servername/WebClient prompts for password
  • Same URL with http:// works without prompt (but HTTPS fails)
  • Certificate warnings may appear before login prompt

Solution: Add to Trusted Sites (Windows)

  1. Open Internet Options (Windows Settings or inetcpl.cpl)
  2. Go to Security tab → Trusted sites
  3. Click Sites button
  4. Uncheck "Require server verification (https:) for all sites in this zone" (if using self-signed certificates)
  5. Add your Nodinite URL:
    • https://localhost
    • https://servername.domain.com
    • https://nodinite.yourdomain.com
  6. Click Add, then Close
  7. Click OK to save

Tip

For production environments with valid SSL certificates, keep "Require server verification" checked and ensure your certificate is trusted by Windows. See How to perform hardening for HTTPS configuration guidance.

Modern Browser Configuration

Different browsers handle Windows Authentication differently:

Microsoft Edge (Chromium)

  • Inherits Windows Internet Options - Adding to Trusted Sites (above) automatically enables SSO
  • Alternatively, configure via edge://settings/privacy:
    • Enable "Automatically sign in to sites using Windows credentials"

Google Chrome

  • Windows: Inherits Internet Options Trusted Sites (same as Edge)
  • Manual configuration: Add to allowed authentication servers:
    1. Navigate to chrome://policy
    2. Set AuthServerAllowlist policy to https://servername.domain.com or *.yourdomain.com
    3. Or use Group Policy: Computer Configuration → Administrative Templates → Google Chrome → Authentication server allowlist

Mozilla Firefox

  • Does not use Windows Internet Options - requires manual configuration:
    1. Navigate to about:config
    2. Search for network.automatic-ntlm-auth.trusted-uris
    3. Add value: https://servername.domain.com or .yourdomain.com (comma-separated)
    4. Search for network.negotiate-auth.trusted-uris and add the same value

Note

For detailed browser SSO configuration, see Microsoft's Browser configuration for Windows Authentication guidance.

Network and Firewall Issues

If login works locally but fails remotely:

  • Firewall blocking Kerberos/NTLM: Ensure TCP/UDP ports for domain authentication are open (Kerberos: 88, LDAP: 389, 636)
  • DNS resolution: Client must resolve server hostname to access via FQDN (not IP address)
  • Time synchronization: Kerberos requires client and server clocks within 5 minutes - see PACVerification
  • Domain connectivity: Client must reach domain controllers for authentication

See Troubleshooting Windows Authentication for advanced diagnostics.

Next Steps

Access Management

Windows Authentication Mode:

OAuth 2.0/OpenID Connect Mode:

  • Claims - Authorization key/value pairs for OIDC/OAuth 2.0
  • Policies - Groups of Claims that define permission sets
  • Roles - Assign Policies to control access

IIS and Windows Configuration

Installation and Setup