- 7 minutes to read

IIS Authentication Settings

Configure your Nodinite Web Applications securely and efficiently in IIS. This guide details the required authentication settings for each Nodinite web component, ensuring least-privilege operation, robust security, and smooth troubleshooting.

✅ Step-by-step IIS authentication settings for all Nodinite web apps
✅ Ensures secure, least-privilege deployments
✅ Prevents common authentication and access issues
✅ Troubleshooting tips for real-world scenarios

If you are reading this page, "someone" has usually changed some settings in the IIS. This guide helps you get the IIS reconfigured with the supported settings to run Nodinite.

This page describes the IIS authentication settings that you must set on the following Nodinite Web Applications:

Example Nodinite App Pools from within the IIS management console.

Web Application	Anonymous Authentication	ASP.NET Impersonation	Windows Authentication	App Pool Account
Web Client	Disabled	Enabled	Enabled	ApplicationPool Identity
Web Api	Disabled	Enabled	Enabled	ApplicationPool Identity
Log API	Enabled	Disabled	Disabled	Named Account
Update Client	Disabled	Disabled	Enabled	Named Account

Note
Basic Authentication and Forms Authentication are always Disabled for Nodinite Web Applications

Important
If the named App Pool accounts are not members of the Windows local administrators group, then you must add accounts to the local 'IIS_IUSRS' group.

Web Client

The Nodinite Web Client runs with the ApplicationPool Identity (e.g. low-level rights). Therefore, end-users must authenticate with the IIS using their Windows credentials. Nodinite has Role-based security, and a Nodinite Administrator manages and grants who gets access.

IIS Authentication Settings for the Web Client.

Web Api

The Web API runs with the ApplicationPool Identity (low-level rights), and Users impersonate with this user account. The information is set during the first installation of Nodinite.

Due to password protection for the impersonated user, you cannot easily edit the authentication settings. You must perform manual changes to the Web.Config file first.

Here's an example of an error message managing the permissions when encryption is applied on the web.config file.

Make a copy of the web.config file.
Remove the encrypted section from the web.config file and save (or decrypt the web.config file).

Remove the identity section.
Make sure to set the Authentication settings as in the image below:

IIS Authentication Settings for the Web API.
Replace web.config with your original file from step 1 (or re-encrypt it).

Empty impersonation

If the ASP.NET impersonation is not set or is missing, you will get the following error message:

Here's an example of the error message as seen within the Install and Update Tool.

Decrypt the web.Config file first.
Set account details for the impersonation, either using the IIS MMC or editing the web.config file using a text editor.

Here's an example in IIS about how to set the account to perform the impersonation with.
Encrypt the web.Config file.
If you changed the account or password, you must manually replace the encrypted connection string again, this time in clear text. On Application Pool Start, it will be re-encrypted

<connectionStrings>
    <add name="NodiniteConfigDatabase" connectionString="Data Source=.;Initial Catalog=NodiniteConfig_Dev;Integrated Security=True;Encrypt=True;TrustServerCertificate=True" />
</connectionStrings>

Decrypt

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pd system.web/identity -app "/Nodinite/%Environment%/WebAPI" -site "Default Web Site"

PROD Example in Default Web Site

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pd system.web/identity -app "/Nodinite/Prod/WebAPI" -site "Default Web Site"

TEST Example in Default Web Site

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pd system.web/identity -app "/Nodinite/Test/WebAPI" -site "Default Web Site"

Note
You may need to change the actual Web Site and the Environment name of the Web Api depending on installation/settings in IIS.

Encrypt

To re-encrypt; replace the -pd parameter with -pe

PROD Example in Default Web Site

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pe system.web/identity -app "/Nodinite/Prod/WebAPI" -site "Default Web Site"

TEST Example in Default Web Site

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pe system.web/identity -app "/Nodinite/Test/WebAPI" -site "Default Web Site"

Important
Web.Config is an XML file, if you have special characters in the password, then, these must be XML encoded.

Char	XML Encoded
&	`&`
"	`"`
'	`'`
<	`<`
>	`>`

Table with special characters that must be XML encoded.

Tip
Use XML Tools in Notepad++ to XML encode the password with special characters.

Log Api

Currently, the Log API can be invoked from just about any service and application. The Log API is not authenticated; hence all the requests to create new Log Events to the Nodinite databases must be performed with an AppPool configured with a named account. See also the prerequisites for:

Configuration Database
Log Databases

IIS Authentication Settings for the Log API.

Update Client

The Install and Update Tool runs with an AppPool configured with a named account. The initial installer must explicitly grant Active Directory Users and/or groups; read more about assigning access rights.

IIS Authentication Settings for the Nodinite Update Client.

Other Nodinite Windows Services

Nodinite has multiple other Windows Services where it is possible to run each with a different Windows Active Directory service account. If you want to change the service account currently in use, please review the prerequisites page for each such service.

How to set Logon as a Service right

Troubleshooting Authentication Issues

401 Unauthorized When Accessing via Hostname Locally

Problem: Accessing Nodinite Web Client via FQDN (e.g., https://nodinitedev28.test.acme.com) from the IIS server itself returns 401 Unauthorized, but works from remote machines.

Symptoms:

✅ PowerShell installation script fails with 401 Unauthorized when verifying HTTPS binding
✅ Local browser access via hostname fails with authentication error
✅ Remote users can access successfully
✅ Accessing via https://localhost works locally

Root Cause: Windows loopback security check blocks local IIS access via hostname when using Windows Authentication. This is a security feature that prevents potential reflection attacks.

Why This Happens (Scenario-Specific):

This loopback check is enabled by default on ALL Windows installations - it's not a bug or customer-specific issue. Most customers never encounter it because:

Remote access - Users typically access Nodinite from their workstation, not from the IIS server itself
localhost usage - Accessing via https://localhost or https://127.0.0.1 bypasses the check
NetBIOS machine name - Using just the server name (e.g., https://SERVER01) often works
Remote script execution - Installation/verification scripts run from a remote machine, not locally on IIS

This specific issue occurs when ALL of these conditions are met:

✅ PowerShell script or browser running ON the IIS server (local execution)
✅ Accessing via FQDN (e.g., nodinitedev28.test.acme.com) not localhost/IP
✅ Windows Authentication enabled on the web application
✅ Hostname in URL doesn't match local machine name (this is typically the root cause)

Note
Common misconception: Adding the FQDN to the local hosts file (e.g., 127.0.0.1 nodinitedev28.test.acme.com) does NOT bypass this check. While the hosts file routes the request to localhost, Windows still compares the hostname in the HTTP request against the machine name - they don't match, so the loopback check still blocks it.

If you encounter this, it's typically during:

Initial installation when PowerShell script verifies HTTPS bindings locally
Testing from RDP session on the IIS server using FQDN
Automated deployment scripts running directly on the target server

Solution 1: Disable Loopback Check (Quick Fix)

Run this PowerShell command as Administrator on the IIS server:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

No restart required - takes effect immediately.

Warning
Security Impact: Applies to all hostnames on the server. Use Solution 2 for production environments.

Solution 2: Whitelist Specific Hostnames (Recommended)

Whitelist only your Nodinite hostname:

# Create registry path if it doesn't exist
$regPath = "HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0"
if (-not (Test-Path $regPath)) {
    New-Item -Path $regPath -Force
}

# Add your hostname to the whitelist
$hostname = "nodinitedev28.test.acme.com"
New-ItemProperty -Path $regPath -Name "BackConnectionHostNames" -Value $hostname -PropertyType MultiString -Force