Step 2: Auth
Choose the primary sign-in model for the new Nodinite Environment. The Portal stores these values so the installation script can configure the Web Client, Web API, and related services correctly.
This step follows Step 1: Basics and prepares the values that Step 3: Infrastructure validates before the final review and package generation.
Example of the current Portal Auth step in the environment wizard.
Click on the Auth step button to review the authentication settings that the installer will use to prepare the environment. The Portal collects these values and writes them into the generated installation package.
Example of the Authentication step with Windows Authentication selected in the Portal.
Auth Mode
This section is where you choose one authentication model for the Environment:
- Windows auth for domain-integrated Windows installations
- OAuth2 for OpenID Connect based identity providers
The second section on the page changes based on this choice.
Windows Authentication
When Windows auth is selected, the page expects Windows-specific values for administrators and service account defaults.
Windows settings
Enter information about the initial administrator account and domain defaults. The Portal uses these values to create the first user which ensures that you can sign in to the Web Client after the installation is complete.
Example of the Windows settings section with administrator account and domain defaults.
| Mandatory | Variable | Default | Description |
|---|---|---|---|
| Authentication Method | Windows |
Uses Active Directory and integrated security | |
| Administrator domain | <DomainName> |
Domain prefix for account names | |
| Administrator account | <NodiniteAdminUsrAccountName> |
Initial administrator account | |
| Administrator email | i.e. <nodiniteadmin@acme.com> |
Optional email address, populates the User entry and affects the Email Alarm plugin when used with Nodinite Monitor Views |
Service Account Defaults
You need do further decide wheter this is Domain mode or Workgroup mode and wheter to use gMSA accounts or not. You must use the default Domain mode to use gMSA accounts. The default is to use the same account for all services, but you can override this on the Servers page.
| Mandatory | Variable | Default | Description |
|---|---|---|---|
| Domain Name | <DomainName> |
Domain used for the default service account pattern | |
| Account Name | <DefaultServiceAccountName> |
Base account used by services unless overridden |
Example of Windows administrator domain input used when Windows auth is selected.
Example of the service account defaults section with domain and account name values for Windows services.
If you opt to use gMSA accounts, the account name must end with the $ suffix. The Portal validates this and will not allow the package to be generated if the account name is invalid. In addition, this choice affects the Secret Management section.
Example of gMSA validation where the account name must end with the $ suffix, such as svc-account$.
Important
Opting in to use gMSA accounts requires that the service account is pre-provisioned in Active Directory before the installer runs. The installer does not create or manage gMSA accounts. In addition, the service account must be configured with the correct permissions to access the certificate store used for secret management. See gMSA accounts for more information.
OAuth 2.x / OIDC
When OAuth2 is selected, configure discovery and client settings from your identity provider.
- OAuth 2.x / OIDC requires TLS.
- Prepare identity provider values before generating the install package.
- Continue with Install Nodinite v7 - OpenID for the detailed mapping.
- Use OpenID Field Mapping Quick Reference to map each Portal field to the correct Entra ID value.
The OAuth configuration is shown as one large section in the Portal, but you should enter values in the same order that the fields appear on the page.
OAuth2 settings
Enter the Discovery URL first so the identity metadata is resolved before you continue with client and API values.
Example of the OAuth2 settings area where the Discovery URL metadata endpoint is provided first.
Installation Client
In Installation Client, provide values in this order:
- Client ID
- Installation Client Scopes
- Installation Client Claims
Use OpenID Field Mapping Quick Reference to map each value from Entra ID before you move on to the Web Client block.
Example of the Installation Client section with Client ID, Installation Client Scopes, and Installation Client Claims.
Web Client
The Web Client section is the first OAuth application block in the lower half of the page.
Complete these fields in the order shown:
- Require HTTPS Metadata
- Client ID
- Callback Path
- Signed-Out Callback Path
- Signed-Out Redirect URI
- Access Denied Path
- Scopes
Web API
After Web Client, configure Web API and add the required Audiences value.
Log API
Next, configure Log API:
- Enable Authentication
- Audiences
Example of the mid-section OAuth settings where Web Client, Web API, and Log API values are configured in sequence.
MCP Server
After Log API, configure MCP Server values:
- MCP Server Audiences
- Web Client MCP Server Scope
Nodinite Claims
The final OAuth block is Nodinite Claims, where you define claim mappings used for authorization.
Example of the lower OAuth section showing MCP Server values followed by the final Nodinite Claims block.
Secret Management
This section configures how certificates for encrypted secrets are handled in the generated installation.
- Keep Auto-generate certificate (recommended) enabled unless your organization requires pre-provisioned certificates.
- Validate that the service account model can access the certificate store used by each service.
Example of Secret Management Certificate Configuration, including the auto-generated certificate option for service secret encryption.