Configuration - Authentication

Authentication controls how the Nodinite Non-Events Monitoring Agent calls Log Views through the Web Client APIs. This page centralizes authentication guidance for both Non-Events Configuration - Authentication and ACK/NAK Configuration - Authentication.

Mandatory Access and Governance Baseline

Important

Role-based security on Log Views is mandatory regardless of authentication method. Authentication only proves identity. Authorization is still enforced by role membership on each Log Views.

For every Non-Events deployment, apply this baseline:

• Create a dedicated Non-Events role and grant it only the required access to relevant Log Views.
• Assign that dedicated Role to the identity used by the Non-Events Monitoring Agent (service account, impersonated account, or mapped OAuth identity).
• Validate authorization after changes to authentication mode, Log Views, or Role membership.

OAuth Policy and Claims Mapping

If you use OAuth 2.0 / OIDC, include Policies and Claims as part of this same vital configuration.

• Define required Claims for the OAuth identity context used by the Non-Events agent.
• Create Policies with appropriate Claims and assign those Policies to the dedicated Non-Events Role.
• Verify the Identity Provider issues expected Claims and that resulting Policies authorize access to the intended Log Views.

Use Tags to Manage Large Configuration Estates

When you maintain many Non-Events configurations and many Log Views, Tags become a vital operational feature for administrators and Nodinite users.

Use Tags consistently to:

• Group related Non-Events configurations and Log Views by domain, team, environment, or business process.
• Speed up filtering, review, and troubleshooting across large monitoring estates.
• Keep configuration intent visible even though Non-Events configurations and Log Views are closely tied by design but loosely coupled in the Nodinite platform architecture.

Understanding Authentication Modes

You can configure one of three authentication methods based on your security model and platform setup:

• Windows Authentication (default) - Uses the Windows identity of the service account running the agent.
• Windows Authentication with Impersonation - Uses a specific domain user account when the service account does not have required access.
• OAuth 2.0 / OIDC (Client Credentials) - Uses Identity Provider-issued tokens when Nodinite v7 is configured with OpenID Connect.

Info

Available from version 6.5.0.0 and later. OAuth 2.0 / OIDC support requires Nodinite v7 with OpenID Connect configured. For earlier versions, use Windows authentication or impersonation.

Diagram: Authentication decision flow showing when to choose Windows authentication, Windows impersonation, or OAuth 2.0 / OIDC based on access model and identity architecture.

Authentication Method Comparison

Windows Authentication

Windows authentication uses the service account identity of the Non-Events Monitoring Agent.

Selected Choice Flow

Diagram: Windows authentication flow where the agent service account directly accesses Log Views without additional credentials.

Example of Windows authentication selected in the Authentication tab.

Tip

Create a dedicated Non-Events role for the service account and add it to all monitored Log Views. This approach often removes the need for impersonation.

Windows Authentication with Impersonation

Use impersonation when the service account running the agent cannot access required Log Views.

Selected Choice Flow

Diagram: Windows impersonation flow where the agent switches identity to a specific domain user to reach protected Log Views.

Example of Windows impersonation selected in the Authentication tab.

Configure these values:

• Domain User - Enter the Windows account to impersonate (format: DOMAIN\User).
• Password - Enter the password for the impersonation account.

When impersonation is active, (*) appears in the Authentication tab label.

Note

Impersonation applies only to Windows authentication mode. If you use OAuth 2.0 / OIDC, configure client credentials instead.

OAuth 2.0 / OIDC (Client Credentials)

When Nodinite v7 uses OpenID Connect, configure OAuth 2.0 client credentials so the agent can request tokens from your Identity Provider.

Selected Choice Flow

Example of OAuth 2.0 / OIDC authentication enabled in the Authentication tab.

OAuth Fields

Use this single table as the source of truth for the current OAuth implementation in the Non-Events configuration dialog.

OAuth Configuration Guidance

• Enable Protected only when Nodinite v7 is configured with an Identity Provider (Azure AD, Entra ID, or other OIDC provider).
• Register the application in your Identity Provider and grant permissions to Nodinite Web API resources.
• Ensure the IDP Token Endpoint is reachable from the server hosting the Non-Events Monitoring Agent.
• Store a copy of the Client Secret securely in your organization's secret management system.
• For Azure AD and Entra ID setup details, follow Install Nodinite v7 - OpenID Connect.

OAuth 401 Troubleshooting Checklist

If a customer still gets 401 Unauthorized after filling all OAuth fields, verify these items in order:

1. Authentication Method is correct: Set to OAuth 2.0 Client Credentials.
2. Token URL tenant is correct: The tenant in Token URL must match where the app registration exists.
3. Scope targets the correct API: Scope must point to the Nodinite Web API application audience, usually api://<webapi-client-id>/.default.
4. Client Secret is valid: Secret is not expired/revoked and copied as the secret value.
5. Application permissions and consent: Required API permissions are granted and admin consent is completed in Identity Provider.
6. Role-based access is still configured: The dedicated Non-Events Role still has access to required Log Views.
7. Claims and Policies mapping is valid: OAuth identity receives expected Claims, mapped through Policies, then assigned to the dedicated Non-Events Role.
8. Agent host can reach IdP and Web API: No network/proxy/TLS blocks between Monitoring Agent host, IdP Token URL, and Nodinite Web API.

PowerShell 7 Quick Verification

Use these commands from the server where the Non-Events Monitoring Agent runs.

# Set values from your OAuth configuration
$TenantId = "<tenant-id>"
$ClientId = "<client-id>"
$ClientSecret = "<client-secret>"
$Scope = "api://<webapi-client-id>/.default"
$TokenUrl = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
$WebApiBaseUrl = "https://<nodinite-host>/api"

# 1) Basic network reachability to IdP token endpoint
Test-NetConnection -ComputerName "login.microsoftonline.com" -Port 443

# 2) Request token with client credentials
$Body = @{
    client_id = $ClientId
    client_secret = $ClientSecret
    scope = $Scope
    grant_type = "client_credentials"
}

try {
    $TokenResponse = Invoke-RestMethod -Method Post -Uri $TokenUrl -Body $Body -ContentType "application/x-www-form-urlencoded"
    $AccessToken = $TokenResponse.access_token
    "Token acquired. Expires in: $($TokenResponse.expires_in) seconds"
} catch {
    # Typical failures here are invalid_scope, invalid_client, or invalid_grant
    $_.Exception.Message
    throw
}

# 3) Decode token payload to verify audience and claims quickly
$TokenParts = $AccessToken.Split('.')
$Payload = $TokenParts[1].PadRight($TokenParts[1].Length + (4 - $TokenParts[1].Length % 4) % 4, '=')
$JsonPayload = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($Payload)) | ConvertFrom-Json
$JsonPayload | Select-Object aud, iss, appid, roles, scp, tid | Format-List

# 4) Call a protected Nodinite Web API endpoint with bearer token
Invoke-RestMethod -Method Get -Uri "$WebApiBaseUrl/logviews" -Headers @{ Authorization = "Bearer $AccessToken" }

Verify with the Actual Log View API URL

Use the Copy API URL button on the target Log Views configuration and test that exact URL with the acquired token.

Important

Paste the full URL exactly as copied from Log Views, including the complete query string (logViewId and URL-encoded searchJson). Do not trim parameters.

# Paste the exact URL from the Log View "Copy API URL" button
$LogViewApiUrl = "https://Nodinite.acme.com:40001/api/Search/FlowSearch?logViewId=0&searchJson=..."

Invoke-RestMethod -Method Get -Uri $LogViewApiUrl -Headers @{ Authorization = "Bearer $AccessToken" }

Expected behavior:

• If token and authorization are correct, you get a JSON response from the Log View API.
• If the URL is malformed or truncated, you usually get 404 or model/query parsing errors.
• If token is valid but authorization is missing, you typically get 401/403.

Typical outcomes when URL-related configuration is wrong:

• Wrong host, port, or path -> 404 Not Found or connection/TLS errors.
• Token is valid, but API audience is wrong (aud mismatch) -> 401 Unauthorized.
• URL points to a Log View outside assigned Non-Events Role permissions -> 401/403 depending on deployment behavior.
• Stale copied URL (deleted or changed Log View context) -> request fails even though OAuth token acquisition succeeds.

Common Misconfiguration Signatures

Tip

In OAuth mode, a successful token request does not by itself guarantee authorization to Log Views. Keep the Claims + Policies + Roles chain aligned.

Example OAuth 2.0 Values

• Protected: Checked
• Client ID: 12345678-1234-1234-1234-123456789abc
• Client Secret: your_secure_client_secret
• Scope: api://nodinite-prod-webapi/.default
• IDP Token Endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token

Warning

Upgrading from Nodinite v6 to v7 with OAuth? After enabling OpenID Connect in v7, you must update existing Non-Events and ACK/NAK configurations (Step 13) with OAuth credentials. Monitoring fails until authentication settings are updated and properly setup.

Where to Configure Authentication

Use the Authentication tab to apply the authentication settings described above. The same settings apply to both Non-Events and ACK/NAK configurations.

Next Step

• Non Events - Configuration - Non-Events
• Non-Events - Configuration - ACK-NAK
• Scheduling

Related Topics

• Configuration
• Claims
• Policies
• Install Nodinite Non-Events Monitoring Agent
• Monitoring Agents
• Applications