- 10 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 - legacy v6.

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

IIS_IUSRS Group Membership

When running Nodinite Web Applications with named service accounts (instead of local administrators), you must add these accounts to the Windows built-in IIS_IUSRS group to ensure proper file system access and IIS permissions.

Why IIS_IUSRS Group Membership Matters

The IIS_IUSRS group is a Windows built-in security group that grants the minimum permissions required for IIS application pools to function correctly. When you configure a service account that is not a local administrator, Windows requires explicit group membership to:

Read configuration files - Access web.config, redirection.config, and other IIS configuration files
Execute ASP.NET applications - Run .NET Framework applications in IIS
Access encryption keys - Read RSA machine keys for encrypted configuration sections
Write temporary files - Create temporary ASP.NET compilation files and session state

Tip
Best Practice: Use the IIS_IUSRS group for least-privilege deployments instead of granting local administrator rights. This follows security hardening principles and reduces attack surface.

How to Add Service Accounts to IIS_IUSRS

Computer Management console showing the IIS_IUSRS group. Add your Nodinite service accounts here if they are not local administrators.

Step-by-Step Instructions:

Open Computer Management - Press Win+R, type compmgmt.msc, press Enter
Navigate to Groups - Expand System Tools > Local Users and Groups > Groups
Open IIS_IUSRS - Double-click the IIS_IUSRS group
Add Service Accounts - Click Add... and enter your Nodinite service account(s):
- Log API App Pool service account
- Update Client App Pool service account
- Any other named accounts used by Nodinite web applications
Apply Changes - Click OK to save
Restart IIS - Run iisreset in an elevated command prompt or PowerShell

Important
No restart required for Windows: Group membership changes take effect immediately for new logons. However, existing IIS application pool processes must be restarted via iisreset to pick up the new group membership.

Which Accounts Need IIS_IUSRS Membership?

Refer to the authentication table at the top of this page to determine which service accounts require IIS_IUSRS membership:

Web Application	App Pool Account Type	IIS_IUSRS Required?
Web Client	ApplicationPool Identity (built-in)	No - built-in identity already has permissions
Web API	ApplicationPool Identity (built-in)	No - built-in identity already has permissions
Log API	Named Account	Yes - if not a local administrator
Update Client	Named Account	Yes - if not a local administrator

This table shows which Nodinite web applications require IIS_IUSRS group membership for their service accounts.

Note
ApplicationPool Identity accounts (e.g., IIS APPPOOL\NodiniteWebClient) are automatically granted IIS_IUSRS permissions by Windows and do not require manual configuration.

Troubleshooting IIS_IUSRS Issues

Symptom: "Cannot read configuration file due to insufficient permissions" error
Solution: Ensure the service account is in IIS_IUSRS and has Read rights on %windows%\system32\inetsrv\config
Detailed troubleshooting guide

Symptom: "Access to the path is denied" when accessing web application
Solution: Verify IIS_IUSRS group has Read/Execute permissions on the Nodinite installation folder

Symptom: Web application fails to start after changing App Pool service account
Solution: Add the new service account to IIS_IUSRS, then run iisreset

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