Naradox

Sign-in and account security

Protect each person's access to your deployment.

Use your own account, confirm the correct sign-in method, and prepare recovery before you need it. Identity administrators can then manage accounts and sessions without giving everyone deployment-wide firewall permissions.

1. Open your installed Naradox deployment

Use the HTTPS address supplied by your deployment administrator. Your naradox.com customer-portal account manages downloads, licenses, and support; it does not automatically create a user inside your deployment. See accounts and permissions for that distinction.

  • Local account: enter your username and password and select Sign in; when Entra sign-in is also configured, choose Local sign-in first. Provide an Authenticator or backup code if prompted. An accepted invitation uses your email address as the local username.
  • Microsoft Entra account: choose Sign in with Entra ID and complete your organization's sign-in. Your identity administrator must have configured and authorized access to this application.

Only configured sign-in methods appear. Once signed in, check the account identity in the account menu. If the expected workspace is missing, ask the access administrator to review your role, grants, and team memberships. A successful sign-in does not itself grant firewall access.

2. Set a password you can keep private

For a local account, open the account menu and select Change password. Enter your current password, choose and confirm a different password, and submit. Naradox accepts 8–1024 characters and requires an uppercase letter and a special character; follow the displayed password checklist. Recent passwords cannot be reused.

A successful change ends your active Naradox session. Sign in again with the new password and your authenticator when enabled. Store the password in your organization's approved password manager. An administrator-created account should receive its initial credentials through your organization's secure process.

Entra users manage their password and identity-provider MFA through their organization. The local Change password and Two-factor auth actions apply to local accounts.

3. Enroll and test your local authenticator

  1. Open the account menu and choose Two-factor auth. Check whether MFA is already enabled or required for this account.
  2. Enter your current password and select Start setup.
  3. Add the displayed QR code or Manual setup key to your authenticator. Store the displayed Backup codes securely so you can recover access if the device is lost.
  4. Enter the current six-digit Authenticator code and choose Enable. Starting setup alone does not enable MFA.
  5. After confirmation signs you out, wait for the next authenticator code and sign in again. Confirm that your password and authenticator work together.

Backup codes are single-use alternatives at sign-in. Treat the setup key, QR code, and backup codes as credentials; keep them out of support requests and shared screenshots.

Replacing a device

While signed in, open Two-factor auth, enter your current password, and choose Replace authenticator. Enroll the replacement, save its new backup codes, and choose Confirm replacement. Your current authenticator stays active until confirmation; successful replacement ends the session and replaces the old authenticator and backup codes.

When the account requires MFA, it cannot be disabled through either self-service or administrative Reset 2FA. Use replacement or the recovery path below.

4. Know when Naradox will ask you to sign in again

Each user has one active Naradox session. Signing in from another browser or device ends the previous session, whose open pages return to sign-in. Use separate named accounts for operators and reviewers; sharing one account also interrupts the other person's session.

The default limits are 15 minutes without session activity and one hour from sign-in, whichever comes first. Your deployment may use different limits. Ordinary authenticated activity, including automatic data refreshes, can restart the inactivity timer. Identity checks and session-status monitoring do not extend it. Activity never extends the maximum session duration.

Use Sign out from the account menu when finished. Password changes, MFA changes, administrator revocation, and relevant account changes can also end a session. After signing in again, reopen the current request or job result before deciding whether an interrupted action needs another attempt.

Recover access without losing the account's safeguards

  • Forgotten local password: select Forgot password? on local sign-in and enter the account's email address. The response does not reveal whether an account exists. If delivery is configured and the account is eligible, use the emailed link to set a new password. Resetting the password does not remove your authenticator requirement.
  • No reset option or email: ask the identity administrator to check the account's email, active status, and SMTP delivery. Under Identity & Access > Users, an authorized administrator can choose Reset password in the user's Actions menu; sending a new administrative reset link invalidates older outstanding links.
  • Lost authenticator: sign in with an unused backup code, then replace the authenticator. If no backup code or usable session remains, contact the deployment administrator. Reset 2FA can clear optional MFA but is rejected when MFA is required.
  • Required MFA with no recovery access: the host operator follows the interactive local-account recovery procedure under First login in the bundled docs/INSTALL_ADMIN.md. It confirms a replacement authenticator before saving; it does not turn off the MFA requirement.
  • Expired invitation or reset link: request a new link. An invitation's temporary validation error offers Retry; an expired or invalid invitation needs replacement by the administrator.
  • Login temporarily limited: stop repeated attempts, observe the displayed retry delay, and verify the credentials. Shared network addresses can also share a login-attempt budget.

For an Entra failure, the identity administrator checks application assignment and the configured provider. For other errors, collect the time, sign-in method, and sanitized message using the support guidance. Exclude passwords, codes, invitation links, and reset links.

For administrators: prepare a named account

An Identity manager can manage identities. App-role assignment requires separate role-assignment authority; it is not included merely by managing users. An Administrator can perform the complete setup. Access administrators manage teams, grants, and firewall scopes; follow Access and permissions for that workflow.

  1. Open Identity & Access > Users. Confirm that the installed license has available named-user capacity.
  2. Choose Add user > Invite user, enter the person's email, and select Send invitation. If delivery is unavailable, Open SMTP settings leads to configuration; have an authorized administrator prepare and test email delivery first.
  3. Use Local account for direct account creation when an invitation is unsuitable. For an existing Entra configuration, authorize the person in Entra, have them sign in, and confirm their account appears in Users.
  4. Choose No app role when access will come only from grants, firewall scopes, or explicit reviewer selection. Assign an administrative or deployment-wide app role only for the corresponding job.
  5. Confirm successful sign-in, required MFA, and the intended access using the person's own account.

Where local administrator MFA is mandatory, create new local users without privileged roles, have them enroll MFA, and only then assign the privileged role. For the initial deployment, enroll the local administrators before the host operator enables LOCAL_ADMIN_MFA_REQUIRED=true under the installation procedure. Enabling the requirement before enrollment can block their login.

Local accounts, active Entra seats, and unexpired pending invitations reserve capacity. Disabling a local user retains that reservation. Use licensing recovery when reserved seats prevent a replacement license or account admission.

For the saved SMTP configuration and its delivery test, follow Platform operations.

For administrators: introduce Entra sign-in

Follow If you want SSO later in the bundled docs/INSTALL_ADMIN.md with your Entra administrator. Require assignment on the Naradox Enterprise Application and assign the approved users or groups. In Naradox, the provider form is under Platform > Settings > Auth > Entra ID SSO.

Enter the intended tenant and client IDs, production redirect and logout addresses, and client-secret value. Verify the effective saved addresses against the application registration. Treat a change to the tenant or client ID as an identity-provider change: it revokes existing Entra ID sessions and clears the stored client secret unless a replacement is supplied.

Test an assigned user and confirm an unassigned user is rejected before changing your existing login arrangement. Keep a documented, tested local-administrator recovery path. Entra application assignment admits the identity; the installed Naradox access configuration controls its product permissions.

For administrators: review sessions and remove access

With identity-management permission, open Platform > Overview > Active sessions. Check the user, last activity, and IP; Details includes the session's first-seen time and browser information. Use Revoke to end a selected Naradox session. Revocation alone does not prevent an active account from signing in again.

Manage the two time limits under Platform > Settings > Auth > Session time limits. Review Sign out after inactivity and Maximum session duration together. The Auth settings also contain local-login protection; investigate unexpected failures before changing those limits.

When a person leaves, disable their account in Users and review the affected grants, team memberships, reviewer requirements, and pending work. For Entra users, coordinate the application assignment with your identity administrator. Release seat only releases licensed capacity and ends current Naradox sessions: roles, teams, and grants remain assigned, and the person can reserve another seat on a later eligible sign-in. Deleting a Naradox Entra user does not delete their upstream account.

Re-enabling a disabled user also requires role-assignment authority over their retained roles. Naradox protects the last active local administrator from deletion, disabling, or demotion. Use Audit and evidence to investigate account and permission changes with the appropriate audit access.

Sign-in and Account Security | Naradox