👥 User Management

SecTrail CM provides enterprise identity management with local user management, LDAP/Active Directory integration, RADIUS authentication, and OAuth/SSO support. This allows you to easily manage your users and integrate with your corporate directory and identity services.

User Types

SecTrail CM supports four different types of users:

1. Local Users

Local users are users defined and managed in SecTrail CM's own database.

Features:

• Created and managed within SecTrail CM
• Defined with username, password, and email address
• Role-based authorization support
• Ability to create dedicated users for API access

2. LDAP/Active Directory Users

Provides centralized identity management by integrating with your corporate Active Directory or LDAP servers.

Features:

• Centralized user management
• Login with existing corporate credentials
• Group-based authorization
• User-based authorization

3. RADIUS Users

Users authenticated through your RADIUS servers. They are created automatically in SecTrail CM upon their first successful login.

Features:

• Centralized authentication through a RADIUS server
• Two-factor authentication support via OTP/MFA (Access-Challenge)
• Automatic user creation on first login
• Role assignment via a default role or policy-based (group attribute) matching
• Optional fallback to local/LDAP authentication when servers are unreachable

4. OAuth Users

Users who log in through corporate OAuth 2.0 / OpenID Connect (SSO) identity providers.

Features:

• One-click corporate SSO login
• Supported providers: Entra ID / Microsoft, Keycloak, GitHub, Google, SecTrail MFA, Custom (OpenID Connect)
• Automatic user creation on first login (Auto-create users)
• Group-based role mapping via Entra ID groups (Microsoft Graph or the id_token groups claim)
• MFA is enforced on the identity provider (IdP) side

Local User Management

Creating a New User

1. Navigate to the Local Users tab from the Users menu
2. Click the Create button
3. Fill in the following information in the Add New Panel Users form:

Form Fields

• Name: User's first and last name
• Username: Username to be used for system login (must be unique)
• E-mail: User's email address (valid format: name@mail.com)
• User Role: Role to be assigned to the user
• Password: User password
• Confirm Password: Password confirmation

1. Click the Submit button to create the user

tip

Create users with dedicated API roles for API integrations. These users should only be used for API access.

User List

The Users screen displays all users in the system in table format.

On this screen:

Column Information:

• Name: User's full name
• Username: Username used for system login
• E-mail: User's email address
• Role: Role assigned to the user

User Operations

Action buttons are located on the right side of each user row:

• Edit (✏️): Edit user information
• Delete (🗑️): Remove user from the system

warning

Be careful when deleting users with active sessions. User deletion is irreversible.

LDAP/Active Directory Integration

SecTrail CM provides enterprise identity management by integrating with your Active Directory or LDAP servers.

LDAP Server Configuration

Creating a New LDAP Profile

You can create a new LDAP/AD profile using the Add New Ldap Server form.

Form Fields

• LDAP Name: Unique name for the LDAP profile
• LDAP Server: IP address or hostname of the LDAP/AD server. Multiple servers can be added using the Add More button
• Connection Type: Connection type selection
  • In Secure: Unencrypted connection (Port 389, for testing/development)
  • Secure: SSL/TLS encrypted connection (Port 636, for production)
• LDAP Port: Connection port number (default: 389 or 636)
• User DN: Administrator DN for LDAP connection
• Admin Password: Password for the administrator specified in User DN
• Base DN: Base DN where user searches will begin
• Manage Role: Default role for LDAP administrators
• User Role: Default role for LDAP users
• Test User: Username to test the connection

warning

Always test your LDAP connections. Incorrect configuration can prevent user logins and make system access impossible.

tip

Before configuring your first LDAP setup, ensure you have a local admin account that can log into the system. This way, you can access the system in case of LDAP issues.

LDAP Profile Management

The LDAP Profiles table displays all defined LDAP servers.

Table Columns:

• LDAP Name: Profile name
• IP Address: LDAP server IP address
• User DN: Administrator DN used for connection

Profile Operations:

Two action buttons are located on the right side of each profile row:

• Edit (✏️): Edit LDAP profile settings
  • You can update all configuration fields
  • Server address, port, DN information can be changed
  • You may need to re-enter the password
• Delete (🗑️): Delete LDAP profile
  • Deletion is irreversible
  • Remote Authentication Policies associated with this profile may be affected

caution

Before deleting an actively used LDAP profile, ensure that users logging in with that profile can access the system through another method.

Remote Authentication Policies

Remote Authentication Policy allows you to assign custom roles to LDAP/AD users on a group or user basis. This way, you can assign different roles based on AD group memberships.

Creating a New Policy

You can create a new policy using the Add New Remote Authentication Policy form.

Form Fields

• Policy Type: Type of policy
  • Group: AD group-based policy
  • User: Individual user-based policy
• Policy Value: Policy value (varies based on Policy Type)
  • If Group is selected: AD group DN is entered
  • If User is selected: Only username is entered
• User Role: Role to be assigned to users matching this policy

Policy List

The Remote Authentication Policy table displays all defined policies.

Table Columns:

• Policy Type: Type of policy (Group or User)
• Policy Value: Group DN or username
• Role: Assigned role

Policy Operations:

Two action buttons are located on the right side of each policy row:

• Edit (✏️): Edit policy settings
  • Policy type, value, or role can be changed
  • Edit carefully for active users
• Delete (🗑️): Delete policy
  • When a policy is deleted, users return to the default role in the LDAP profile
  • Active sessions are not affected, applies to new logins

Policy Priority Order

If multiple policies apply to a user, the priority order is as follows:

1. User Policies: Highest priority
2. Group Policies: Second priority

tip

Use group-based policies whenever possible. This simplifies management and works in harmony with your AD structure.

warning

Policy changes take effect in new sessions. Active users may need to log in again.

RADIUS Integration

SecTrail CM integrates with your RADIUS servers to provide centralized authentication and OTP/MFA support. RADIUS screens are accessed under the Radius Authentication section of the Users menu, which contains three tabs:

• Profiles: RADIUS server profile configuration
• Policy: Role assignment policies
• Users: List of users who logged in via RADIUS

Creating a RADIUS Profile

You can create a RADIUS server profile using the Add New RADIUS Profile form.

Form Fields

• Name: Name of the RADIUS profile
• Primary Host: IP address or hostname of the primary RADIUS server (e.g. 192.168.1.10)
• Secondary Host: (Optional) Backup RADIUS server. If the primary server does not respond, the secondary server is tried automatically (failover)
• Auth Port: Authentication port (default: 1812)
• Shared Secret: Secret key shared with the RADIUS server. Stored encrypted in the database; leave blank while editing to keep the current value
• NAS IP Address: (Optional) NAS IP address (e.g. 127.0.0.1)
• NAS Identifier: (Optional) Identifier sent as NAS-Identifier (attribute 32) in RADIUS requests (e.g. sectrail-cm)
• Timeout: Server response timeout in seconds (default: 5)
• Local/LDAP Auth Fallback: When enabled, falls back to local/LDAP authentication if RADIUS servers are unreachable
• Manage Role: Role assignment mode
  • Default: A fixed role is assigned to all RADIUS users
  • Policy: Roles are assigned according to RADIUS authentication policies
• User Role: (Visible only in Default mode) Default role assigned to RADIUS users
• Group Attribute: (Visible only in Policy mode) RADIUS attribute from which the group value is read (default: 11 / Filter-Id). Accepts a numeric ID, an attribute name (Filter-Id), or VSA notation (26:VendorId:VendorType)

note

Only one RADIUS profile can be defined at a time. Once a profile is created, the Create button is hidden; delete the existing profile to create a new one.

note

If you want to convey the user's email address, we expect your RADIUS server to send it via the Reply-Message attribute by default: a value in email format is saved directly; if none is sent, a placeholder address is assigned and you'll need to update it later by editing the user. Group Attribute can also be set to 18 / Reply-Message: if the RADIUS server sends two separate Reply-Message values, the one in email address format is used for email, and the other one for the group check.

RADIUS Profile List

The RADIUS Profiles table displays the defined RADIUS profile.

Table Columns:

• Name: Profile name
• Primary Host: Primary server address
• Secondary Host: Backup server address
• Auth Port: Authentication port
• Manage Role: Role assignment mode
• Local/LDAP Auth Fallback: Fallback status (Active/Passive)

An Edit (✏️) button is located on the right of each row; profiles are removed with the Delete button. The list can be exported as Excel/CSV/PDF.

RADIUS Login Flow and OTP/MFA

1. When a RADIUS profile is defined, login attempts are first authenticated against the RADIUS server

   

2. If the server returns an Access-Challenge response, the user is redirected to the Two-Factor Authentication screen and prompted for an OTP code (Verify OTP). The OTP's validity period depends on your RADIUS server's own configuration

   

3. On an Access-Accept response the user is logged in; if the user does not exist in SecTrail CM, an account of type RADIUS is created automatically. The email address is read from the Reply-Message attribute sent by the RADIUS server; if not provided, a placeholder address in the form username@radius.local is assigned

4. On an Access-Reject response or when servers are unreachable, local/LDAP authentication is attempted if Local/LDAP Auth Fallback is enabled; otherwise the login is rejected

tip

To populate user emails automatically, configure your RADIUS server to send the email address via the Reply-Message attribute.

RADIUS Authentication Policies

When Manage Role is set to Policy, roles are assigned according to RADIUS Authentication Policy records.

Form Fields

• Policy Type: Type of policy
  • User: Matches a specific RADIUS username (e.g. johndoe)
  • Group: Matches a RADIUS group attribute value (e.g. kron-admin-group)
• Policy Value: Value to match (username or group value depending on Policy Type)
• User Role: Role to be assigned to users matching this policy

Policy List

The RADIUS Authentication Policy table displays all defined policies.

Policy Priority Order

1. User Policies: Highest priority
2. Group Policies: Second priority — matched against the Group Attribute value returned by the RADIUS server

warning

In Policy mode, login is rejected if no matching policy is found for the user. Do not switch to Policy mode before configuring your policies.

RADIUS Users

The RADIUS Users screen lists all users created automatically via RADIUS login (type RADIUS).

Table Columns:

• Name: User's full name
• User Name: Username
• Email: Email address
• Role: Assigned role
• Type: User type

OAuth Integration

SecTrail CM integrates with OAuth 2.0 / OpenID Connect based corporate identity providers (SSO). Supported providers:

• Entra ID / Microsoft (Azure)
• Keycloak
• GitHub
• Google
• SecTrail MFA
• Custom (OpenID Connect): Any identity provider that supports standard OIDC discovery (publishes a /.well-known/openid-configuration endpoint) can be connected with this type — Okta, Auth0, ADFS (2016+), Authentik, etc.

OAuth screens are accessed under the OAuth Authentication menu, which contains three tabs:

• Profiles: OAuth provider profile configuration
• Policy: Role assignment policies
• Users: List of users who logged in via OAuth

Creating an OAuth Profile

You can create an OAuth provider profile using the Add OAuth Profile form. The same form is used (pre-filled with existing values) when editing a profile.

Form Fields

• Name: Name of the OAuth profile. For Custom (OpenID Connect), this name is also used in the login button's tooltip text (e.g. "Sign in with Okta"); these profiles are shown with a common/generic OAuth badge instead of a brand icon on the login screen
• Provider: Identity provider selection (Entra ID / Microsoft, Keycloak, GitHub, Google, SecTrail MFA, Custom (OpenID Connect))
• Client ID: Client ID of the application registered on the provider
• Client Secret: Secret key of the application. Leave blank while editing to keep the current value
• Server URL: (Required for Keycloak, SecTrail MFA, and Custom (OpenID Connect)) Server address (e.g. https://keycloak.example.com). The /.well-known/openid-configuration endpoint is queried automatically from this address to resolve the token/userinfo endpoints
• Tenant ID / Realm: (Required for Azure and Keycloak only) Tenant ID for Entra ID, Realm for Keycloak
• Auto-create users: When enabled, users signing in via OAuth for the first time are created automatically (JIT provisioning)
• Manage Role: Role assignment mode
  • Default: Users are assigned the fixed role from the profile
  • Policy: Roles are assigned according to OAuth authentication policies
• User Role: (Visible only in Default mode) Role assigned to users
• Group-based role mapping: (Visible only with Entra ID / Microsoft + Policy mode) When enabled, also reads the user's Entra ID groups via Microsoft Graph (requires the GroupMember.Read.All permission with admin consent), which lets policies match Graph's group display names too. This checkbox is specific to Entra ID; group matching itself is provider-agnostic — regardless of the provider (Keycloak, Custom OIDC, etc.), if the IdP's id_token includes a groups claim, those values are read automatically and matched against Group-type policies, no Graph permission required
• Callback URL: Contains an editable address field between the fixed https:// and /auth/{provider}/callback parts (pre-filled with the address the panel is currently being accessed through). If the panel is reachable from more than one address (IP, custom domain), set this field to match the Redirect URI registered on the provider exactly

note

Only one profile can be created per provider type (Entra ID, Keycloak, GitHub, Google, SecTrail MFA, Custom) — the callback URL must be unique per provider. Multiple profiles of different provider types can be defined at the same time; each profile has its own role-assignment policies that don't affect the others.

tip

Role assignment is re-applied on every login, not just the first one: changing the profile's default role or a policy takes effect for the affected user on their very next OAuth login. Roles of LOCAL/LDAP accounts matched by email are never modified by OAuth login.

Microsoft Entra ID Configuration Example

The steps below show how to create an App Registration in the Azure Portal and pair it with SecTrail CM.

1. Create a new app registration under Microsoft Entra ID → App registrations → New registration.

   • Supported account types: usually Single tenant (this organization only)
   • Redirect URI: select the Web platform and enter the exact value from the profile's Callback URL field (e.g. https://cm.yourcompany.com/auth/azure/callback)

   

2. Under Certificates & secrets → Client secrets → New client secret, create a secret and copy the value from the Value column (not the Secret ID — this value is only shown once, at creation time). Paste it into the profile's Client Secret field.

   

   tip

   Client secrets automatically expire at the end of the duration you choose (6/12/18/24 months). Create a new secret and update the profile's Client Secret field before it expires, or logins through that provider will stop working.

3. From the Overview page, copy Application (client) ID into Client ID, and Directory (tenant) ID into Tenant ID.

4. Configure permissions under API permissions:

   • User.Read (Delegated, Microsoft Graph) is usually present by default and is enough for basic login (name, email)
   • For group-based role mapping, add the GroupMember.Read.All (Delegated) permission and approve it with Grant admin consent (requires a Global Administrator or Privileged Role Administrator)

   

5. (Optional, does not require Graph permission) Under Token configuration → Add groups claim, you can have group information included in the ID token (Security groups or All groups). In this case the user's group IDs (GUIDs) arrive in the id_token and SecTrail CM reads them automatically without any Graph permission — a practical alternative when GroupMember.Read.All consent cannot be obtained.

   

6. (Recommended) Under Enterprise applications, find your new registration, set Assignment required? to Yes on the Properties page, then assign the users/groups allowed to sign in to SecTrail CM under Users and groups. This adds an extra access-control layer on the Entra ID side.

Common Errors

• AADSTS50011 (redirect URI mismatch): the Redirect URI on the app registration must exactly match the profile's Callback URL, including scheme, host, and path
• AADSTS50105 (user not assigned): if Assignment required is enabled (step 6), the signing-in user must be assigned to the Enterprise Application
• AADSTS65001 / "Admin consent required": if user consent is disabled for the tenant, an administrator must Grant admin consent for the permission from step 4
• If the id_token comes back empty or missing: make sure ID tokens is checked under Authentication → Implicit grant and hybrid flows on the app registration

OAuth Profile List

The OAuth Profiles table displays the defined OAuth profile.

Table Columns:

• Name: Profile name
• Provider: Identity provider (e.g. Entra ID / Microsoft)
• Auto-create users: Automatic user creation status (Yes/No)
• Manage Role: Role assignment mode

Profile Operations:

An Edit (✏️) button is located on the right of each row; profiles are removed with the Delete button above the table (after selecting a row).

• Edit (✏️): Edit the profile's settings
  • All fields can be updated; leave Client Secret blank to keep the current value
  • The address part of the Callback URL should be updated here whenever the panel starts being accessed from a new address (e.g. a custom domain)
• Delete: Remove the profile
  • All OAuth Authentication Policies records tied to this profile are deleted automatically as well
  • Users who previously signed in through this profile are not removed; they simply can no longer sign in through it

caution

Before deleting an OAuth profile that is actively in use, make sure users signing in through it can access the system another way (LOCAL, LDAP, or another OAuth profile).

OAuth Login Flow

1. When an active OAuth profile exists, a small button with the provider's icon is displayed on the login screen (hovering over it shows a "Sign in with {Provider}" tooltip)
2. Clicking the button redirects the user to the provider's login page, where authentication is performed by the provider
3. After successful authentication, the user is redirected back to SecTrail CM and account matching is performed:
   • The account is matched first by the provider's immutable user ID
   • If there is no match, it falls back to matching by email address (case-insensitive) — this also permanently binds the OAuth identity to an existing LOCAL/LDAP account
   • If multiple accounts match the same email, the login is rejected for security reasons
4. The role is assigned (and re-applied on every login for existing OAuth users): in Default mode the profile role, in Policy mode the role of the matching policy
5. If the user does not exist and Auto-create users is enabled, a new account of type OAUTH is created

tip

Multi-factor authentication (MFA) should be enforced on the identity provider (IdP) side. SecTrail CM does not prompt for an additional OTP on OAuth logins.

caution

Because account matching relies on the email address, the identity provider's email verification must be trustworthy. If you add a Custom (OpenID Connect) IdP that isn't fully controlled by your organization, make sure the email claim is verified on the provider side.

OAuth Authentication Policies

When Manage Role is set to Policy, roles are assigned according to the OAuth Authentication Policies records that belong to that profile — policies are scoped per profile and never affect another profile. The same form is used for both creating and editing a policy.

Form Fields

• Profile: The OAuth profile this policy applies to
• Policy Type: Type of policy
  • User: Matches the user's email address or UPN
  • Group: Matches the groups claim value returned in the identity provider's id_token (a GUID or a name, depending on the provider); for Entra ID, it also matches against the group display names returned by Microsoft Graph
• Policy Value: Value to match (varies based on Policy Type)
• User Role: Role to be assigned to users matching this policy

Policy List

The OAuth Authentication Policies table displays all defined policies.

Policy Operations:

An Edit (✏️) button is located on the right of each row; policies are removed with the Delete button.

• Edit (✏️): Change the Policy Type, Policy Value, Role, or the linked Profile
• Delete: Once removed, users who matched this policy are treated as matching no policy on their next login (rejected in Policy mode, unless the profile is switched to Default mode)

Policy Priority Order

1. User Policies: Highest priority
2. Group Policies: Second priority

warning

Group-based policies can work with any provider, as long as the IdP's id_token includes a groups claim; matching by name via Microsoft Graph is specific to Entra ID / Microsoft (see the configuration example above). In Policy mode, OAuth users without a matching policy are rejected at login; this rule only affects accounts of type OAUTH — LOCAL/LDAP accounts matched by email are never blocked.

OAuth Users

The OAuth Users screen lists all users created via OAuth login (type OAUTH). This screen is read-only; the list can be exported as Excel/CSV/PDF.

Table Columns:

• Name: User's full name
• User Name: Username
• Email: Email address
• Role: Assigned role
• Provider: Identity provider used for login

User Roles

In SecTrail CM, users are managed through role-based authorization. One or more roles can be assigned to each user.

Default Roles

• Admin: Full administrator privileges
• API: Dedicated role for API access

For detailed information about roles and permissions, see the Role and Permissions section.