Step 2: Auth

Choose the sign-in model for the new Nodinite Environment. The Portal stores these values in the generated package, and the installer uses them to configure the Web Client, Web API, Log API, and MCP Server, and to create the first administrator so that you can sign in after the installation.

This step follows Step 1: Basics and comes before Step 3: Infrastructure. You choose the mode once per Environment; to switch later, follow Migrate Authentication Method.

Example of the Portal Auth step in the Environment wizard.

Click the Auth step button to review the authentication settings.

Example of the Authentication step with Windows Authentication selected in the Portal.

Auth Mode

Choose one authentication model for the Environment:

• Windows auth: Active Directory and integrated security, for domain-joined Windows Server installations
• OAuth2: OpenID Connect with an identity provider such as Microsoft Entra ID; required for the container runtimes

The rest of the page changes with this choice.

Diagram: the Auth step in Portal order. Windows auth (teal) adds the first administrator. Both modes share the service account defaults, optional gMSA, and the Secret Management certificate (green). OAuth2 (purple) then needs one block per Core Service plus the Nodinite Claims that map to Roles through Policies.

Windows Authentication

When Windows auth is selected, the page asks for the administrator and the service account defaults. On Windows Server, the IIS web sites use Windows Authentication; see IIS Authentication settings and, for Kerberos, HTTP SPN for IIS.

Windows settings

Enter the initial administrator account and domain. The installer creates this first User, so that you can sign in to the Web Client after the installation.

Example of the Windows settings section with the administrator account and domain.

Service Account Defaults

This section is the same for Windows auth and OAuth2. Decide whether the Environment runs in Domain mode or Workgroup mode, and whether to use gMSA accounts. gMSA requires the default Domain mode. By default, all services use the same account; you can override it per service in Step 4: Servers.

The service account needs the Logon as a Service right on every server; the Monitoring Service account also needs DCOM Local Activation permission (Monitoring Service prerequisites).

Example of the Windows administrator domain input used when Windows auth is selected.

Example of the service account defaults section with domain and account name values for the Windows services.

If you use gMSA accounts, the account name must end with the $ suffix. The Portal validates this and does not generate the package while the account name is invalid. The choice also affects the Secret Management section.

Example of gMSA validation: the account name must end with the $ suffix, such as svc-account$.

Important

A gMSA account must exist in Active Directory before the installer runs; the installer does not create or manage gMSA accounts. The account also needs access to the certificate store used for secret management; see Install Certificates for gMSA.

Secret Management

This section, also shared by both modes, configures the certificate that encrypts secrets, such as passwords and connection strings, in the installed Environment. See Secret Management for how it works.

• Keep Auto-generate certificate (recommended) enabled unless your organization requires pre-provisioned certificates.
• Make sure each service account can access the certificate store used by its service; with gMSA, see Install Certificates for gMSA.

Example of the Secret Management certificate configuration, including the auto-generated certificate option for service secret encryption.

OAuth 2.x / OIDC

When OAuth2 is selected, configure discovery and client settings from your identity provider.

• OAuth 2.x / OIDC requires TLS; set the certificate in Step 4: Servers.
• Register the applications in the identity provider before you generate the package; for Microsoft Entra ID, follow Register Nodinite Applications in Entra ID.
• Install Nodinite v7 - OpenID explains every field; OpenID Field Mapping Quick Reference maps each Portal field to its Entra ID value.

The Portal shows the OAuth configuration as one large section; enter the values in the order the fields appear.

OAuth2 settings

Enter the Discovery URL first, so that the identity metadata resolves before you continue with the client and API values (field details).

Example of the OAuth2 settings area, where you enter the Discovery URL first.

Installation Client

In Installation Client, enter, in this order:

• Client ID
• Installation Client Scopes
• Installation Client Claims

The installer CLI authenticates as this client, without user interaction, for installations, updates, and maintenance tasks. The Portal doesn't store its secret: the CLI prompts for it, or you pass it with --oauth2-agentinstall-secret (Step 7).

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 (field details):

• Require HTTPS Metadata (keep it checked: OAuth2 requires HTTPS, and the installer rejects non-HTTPS discovery URLs)
• Client ID
• Callback Path
• Signed-Out Callback Path
• Signed-Out Redirect URI
• Access Denied Path
• Scopes

The Portal doesn't store the Web Client secret either: the CLI prompts for it, or you pass it with --oauth2-webclient-secret (Step 7).

Web API

After the Web Client, add the Audiences value for the Web API (field details). Scripts and services that call the Web API request tokens for this audience; see Call the Web API with OAuth 2.0 Client Credentials.

Log API

Next, configure the Log API (field details):

• Enable Authentication
• Audiences

The Log API has its own app registration, with the Application ID URI api://<client-id> and requestedAccessTokenVersion 2. In Audiences, enter the plain Application (client) ID of that registration, not the api:// URI. Callers request tokens with the scope api://<logapi-client-id>/.default.

Example of the Log API OAuth section.

For the app registration, app roles, and client setup, see Protect the Log API with OAuth 2.0 and Entra ID.

MCP Server

After the Log API, configure the MCP Server values (field details):

• MCP Server Audiences
• Web Client MCP Server Scope

Example of the input fields for the MCP Server.

For remote MCP clients, see MCP Endpoint External Access; for hosting, see MCP Endpoint in Core Services.

Nodinite Claims

The final OAuth block is Nodinite Claims, where you define the claims used for authorization (field details).

Click Add to add an entry.

Example of the Nodinite Claims panel.

Enter the key, then the value, one entry per value (comma-separated values aren't supported): for App Roles, the key http://schemas.microsoft.com/ws/2008/06/identity/claims/role and the app role value; for groups, the key groups and the group Object ID. The bare key roles doesn't match.

Example of an empty Nodinite Claims entry.

Note

The input fields are case sensitive. Copy and paste the values.

After the installation, grant access in the Web Client by mapping Claims to Roles through Policies.

Next Steps

• Step 3: Infrastructure
• Step 1: Basics

Related Topics

• Install Nodinite v7
• Install Nodinite v7 - OpenID
• Register Nodinite Applications in Entra ID
• OpenID Field Mapping Quick Reference
• Migrate Authentication Method
• gMSA accounts
• Secret Management
• Claims Overview
• What is a Policy?
• Troubleshooting OAuth 2.0 Validation Failures