- 0 minutes to read

Migrate Authentication Method in Nodinite v7

Use this guide to migrate an existing Nodinite v7 environment between:

  • Windows Authentication / Kerberos OpenID Connect / OAuth 2.0
  • OpenID Connect / OAuth 2.0 Windows Authentication / Kerberos

This authentication migration guide focuses on safe transition sequencing, retained environment data, and authorization realignment.

The migration path is the same at a high level, but prerequisites and post-migration access management differ. Complete the prerequisite checks for your target authentication method before you start the transition.

Understand the Migration Model

You are not changing authentication in place on running binaries. Instead, you must:

  1. Uninstall binaries without removing databases or settings files.

    Important

    You MUST use the OLD uninstall script (i.e. the one that was used to install or update the current environment). If you can not find this, download a new ZIP package BEFORE commiting any changes for the new type of authentication. The uninstall script from the new ZIP package will not work because it is designed for the new authentication model, which is not yet in place.

  2. Update authentication settings for the Environment in the Nodinite Portal.

  3. Download a new ZIP package and run the installer again using the normal update flow.

flowchart LR A[Current Authentication Method] --> B[Uninstall Binaries Keep Data] B --> C[Update Environment in Portal] C --> D[Download New ZIP] D --> E[Run Installer with Update Flow] E --> F[Reassign Roles or Claims]

Diagram: Authentication migration uses a controlled reinstall flow where databases and settings are retained, then authorization is re-aligned for the target identity model.

Prerequisites Before Any Migration

Validate prerequisites for the target authentication model before you uninstall anything:

For OpenID Connect deployments, also ensure TLS prerequisites are ready:

Standard Migration Workflow

Step 1: Uninstall Without Removing Data

Run the v7 uninstall script, but do not remove configuration files or databases.

This keeps your Environment state so you can reinstall with the new authentication method.

Step 2: Update Environment in the Portal and Download New ZIP

In Portal, open the existing Environment and change authentication settings to the target model.

  • Save the environment changes.
  • Download the new generated ZIP package.

Step 3: Reinstall with the Standard Update Instructions

Run the installer from the newly downloaded package.

  • Follow Updating Nodinite v7.
  • Because settings and databases already exist, treat this as a standard update-style installation.

Path-Specific Notes

Windows/Kerberos to OpenID Connect

After switching to OpenID Connect, authorization no longer depends on classic Windows group resolution in the same way. Re-map access using Claims, Policies, and assigned groups in your identity provider.

Email alarm plugin impact:

  • Email Alarm Plugin can no longer be used in this model.
  • Replace it with E-mail with options.
  • Reason: the simple Email Alarm Plugin depends on user email data resolved through Role/User mechanics that do not apply the same way after moving to OpenID Connect.

Recommendation: use E-mail with options as your standard plugin because it provides richer capabilities and is the strategic option going forward.

If you refer to the plugin family without punctuation, this is the same Email with Options plugin.

OpenID Connect to Windows/Kerberos

After switching back to Windows/Kerberos, revalidate domain-based authorization mappings.

  • Reassign the correct Active Directory users and groups to Nodinite Roles.
  • Verify service account assumptions for Windows-integrated access.

Reconcile Roles and Authorization After Migration

Regardless of migration direction, you must realign authorization for the new model.

  • Review and update Role assignments.
  • If using OpenID Connect, validate Policies and Claims mapping.
  • If using Windows/Kerberos, validate users and groups from Active Directory.

In many Environments, only the initial administrator can access the system immediately after migration until Role assignments are updated.

Optional Identity Cleanup After Migration

After successful migration, identity administrators often remove obsolete configuration from the previous model.

Typical examples include:

  • Old groups or service accounts.
  • Unused Claims or Policies.
  • Legacy app registrations or integration artifacts.

This cleanup is organization-specific, so this guide does not prescribe one universal procedure.

Final Verification and Operational Review

After migration and access remapping:

  • Verify administrator and non-administrator sign-in paths.
  • Verify role-based access for expected user groups.
  • Verify alarm behavior if email notifications are in use.
  • Review Post-installation and apply relevant hardening, backup, and maintenance practices.

Next Step