Logon As A Service
Empower your Nodinite environment with secure, least-privilege service account management. This guide explains how to configure 'Logon as a Service' rights for Nodinite applications and services running on Windows Servers, ensuring compliance, security, and smooth operations across your infrastructure.
- ✅ Step-by-step instructions for setting 'Logon as a Service' rights
- ✅ Ensures least-privilege, secure deployments
- ✅ Supports multi-server and multi-environment scenarios
- ✅ Best practices for password, policy, and account management
Info
On this page, you will learn the minimum privilege required for any Nodinite Windows Service to run on the hosting Windows Server. [!IMPORTANT] Changes made on a Domain Controller may take some time to replicate with other domain controllers in your network. You may need to log out and then log in using the service account (a stop/start operation may also do the trick).
First, issue the following command from an elevated command prompt on the Windows Server to update group policies:
gpupdate /force
Nodinite provides many applications and services that you can install on one or more Windows Servers, potentially with multiple Environments:
- Core Services, each an IIS web site on Windows Server
- Logging Agents
- Monitoring Agents
The Nodinite services above require different access rights on hosting Windows Servers and SQL Server Databases. You choose the service identities in the Nodinite Portal, in the Service Account Defaults of the Auth step, per Core Service in the Servers step, and per agent in the Agents step; the CLI then configures the IIS application pools with those identities. Each identity still needs the Windows rights on this page.
Note
On Windows Server, three Windows prerequisites apply to the Nodinite service identities: the Log on as a service right (this page), DCOM Local Activation for the Monitoring Service, and a configured MSDTC. Network ports are listed on each component's Prerequisites page, for example the Monitoring Service firewall settings.
Stay secure with least privileges
We designed Nodinite Monitoring Agents and services to run with minimum permissions (least privilege):
Diagram: Nodinite service account privilege model. Green accounts (domain service accounts, gMSA, and built-in accounts) provide least-privilege access. Yellow accounts (local administrator) only for specific Monitoring Agents. Red accounts (Local System) should be avoided. The blue boxes are the rights each account needs: Logon as a Service, SQL Server access to the Configuration Database and Log Databases, SPN registration, and file system access.
- Each Windows Service can run with the same account, or you can use different accounts for each instance/service installed.
- Separate accounts increase security and allow fine-tuned access.
- The BizTalk and Windows Server Monitoring Agents require their account to be part of the local administrators group; the other services and agents don't. Review the prerequisites page for each agent.
- Some Nodinite service accounts require interactive logon (e.g., the Logging Service and agents that install or update their Monitoring Agent Database).
- Always use dedicated service accounts—never assign accounts used by physical persons.
- Custom domain accounts require Service Principal Names (SPN) for Kerberos authentication in distributed environments or when NTLM is disabled.
- Manage service account passwords as part of your policy and maintenance.
Important
With Nodinite v7, you can change the service account password without losing access to encrypted secrets; changing the service account itself means moving the secret-encryption certificate. See Service Account Password Changes.
Eliminate Password Expiration with gMSA Accounts
Nodinite v7 supports Group Managed Service Accounts (gMSA): Active Directory handles password rotation automatically, and no administrator ever knows the password. The trade-off is that you provision the secret-encryption certificate yourself in the LocalMachine store, from your own PKI; see Install Certificates for gMSA.
A gMSA still needs the Log on as a service right described below. For the comparison with traditional accounts and the setup steps, see Configure Group Managed Service Accounts (gMSA).
What are the minimum user permissions required to install a Windows service?
You must be a Local Administrator to run the Nodinite CLI (Step 7: Run the CLI Workflow) and to install Nodinite Windows Services.
Only processes with Administrative privileges can open handles to the SCM (Service Control Manager) that can be used by the CreateService and LockServiceDatabase functions (see the following MSDN 'Service Security and Access Rights' article for details).
What are the minimum user permissions required to run a Windows service?
The minimum user permission required to run a Windows service is the Log on as a service right — one of the core Service Account rights — a local policy set by a Local Administrator on the server or via group policy.
This security setting allows a security principal to Log on as a service. Windows Services can run under built-in accounts (Local System, Local Service, Network Service), which have this right by default. Any service running under a different user account must be assigned the Log on as a service right.
Important
The default setting in Windows is None (!). This means that the account (even the Local Administrator) must be assigned this right.
How to add a service account to a local policy
- Open Administrative Tools in the Control Panel.
Example of the Administrative Tools folder that holds Local Security Policy. - Open Local Security Policy.
Example of the Local Security Policy console, where the Log on as a service policy lives under User Rights Assignment. - Add the account to the policy 'Log on as a service'. If the account is already in use, log on/restart to get the new privileges.
Example of adding the Nodinite service account; for a gMSA, include the trailing$.
Nodinite Service Accounts are used for:
- Monitoring Service—Shared or specific service identity
- Read/Write access to Configuration Database and Log Databases
- Logging Service—Shared or specific service identity
- Read/Write access to Configuration Database and additional rights on Log Databases
- Web Client, Web API, Log API, and MCP Server—Shared or specific service identity of the IIS web site
- Monitoring Agents—Shared or specific service identity; for some, also review the Monitoring Agent Database
- Logging Agents—Shared or specific service identity; sometimes with 'Read/Write' access to the Nodinite Configuration Database
Important
When using custom domain service accounts (not built-in accounts like Network Service), you must register Service Principal Names (SPNs) for Kerberos authentication in distributed environments or when NTLM is disabled. SPNs are required in two distinct areas:
- SQL Server, linked servers, Always On Availability Groups: See Service Principal Names (SPN)
- IIS application pool account — Nodinite v7 Web Client: See Restoring Kerberos Transparent Login After Upgrading to v7
Nodinite v7 — pure Kerberos environments (NTLM disabled): If NTLM is disabled organisation-wide, the v7 Web Client will not be operational unless HTTP SPNs are registered for the IIS application pool service account and
useAppPoolCredentialsis configured in IIS. The SQL Server SPN guide alone does not cover this requirement. [!WARNING] Windows Server Monitoring Agent - Additional Remote Monitoring RequirementsWhen the Windows Server Monitoring Agent monitors remote Windows Servers, the service account requires additional configuration beyond "Logon as a Service" rights:
- Service account must be in the local Administrators group on each remote server being monitored
- UAC Remote Token Filtering may block remote administrative access even when the account is in Administrators group
- See Prerequisites for Windows Server Monitoring Agent for complete requirements
- See How to Monitor Remote Scheduled Tasks for UAC token filtering troubleshooting
This additional requirement applies only to the Windows Server Monitoring Agent when monitoring remote servers, not to other Nodinite services or agents. [!TIP] The AppPool accounts are not required to be part of the Local Administrator group. If the accounts used are not Local Administrator, add them to the IIS_IUSRS group and ensure they have 'Read/Change/Write' permissions on all Web Application folders installed.
Local Administrator
Follow these steps to add an account to the Local Administrator group on a Windows Server. Repeat on all servers hosting Nodinite Core Services and Monitoring Agents that require elevated privileges.
- Open the Server Manager
- Click Tools in the right corner of Server Manager and select Computer Management
- Expand Local Users and Groups and select Groups. Double-click on the Administrators group
- Add the AD service accounts that should be part of the highly privileged local Administrator's group
Add Service Account on Domain Controller
Note
You need to be a member of the Domain Admins group to add AD accounts to the local Administrators group locally on the Domain Controller
If you need to work on the Domain Controller, you cannot find the Local Users and Groups in 'Computer Management'. To add any account to the local Administrator group on the domain controller, open Active Directory Users and Computer or use an Administrative command prompt:
net localgroup Administrators /add {domain}\{user}
Replace {domain}\{user} with the account to be added (without the brackets).
Warning
Adding a service or user account to the local Administrators group grants the account permissions to make changes in your Active Directory environment, not just the local server
Add Service Account on Read Only Domain Controller (RODC)
If your Domain Controller is installed as a Read-Only Domain Controller, follow the steps for delegating local administration on an RODC to add the service account(s) local admin rights.