How-to manage NIM configuration

Identity Manager Identity Manager Show & Tell
, , ,
1

Overview

Managing an NIM (Netwrix Identity Manager) configuration can feel complex when you’re starting a new project. Configurations touch multiple layers — connectors, workflows, forms, policies, and rules — and it’s not always clear where a given setting lives, how it’s structured, or how to move it safely between environments as a project matures.

Description

This document is meant to remove that confusion. It first clarifies what an NIM configuration actually is: its structure, its main components, and how they relate to one another. It then walks through the different ways you can modify a configuration — from the built-in administration tools to more advanced customization options — so you can choose the right method depending on the change you need to make. Finally, it covers how to move a configuration from one environment to another (for example, from development to test, or from test to production), including the precautions to take so nothing gets lost or broken along the way.

Whether you’re setting up your first NIM project or maintaining an existing deployment, this guide should give you a clearer mental model of how configurations work and the confidence to manage them without guesswork.

Feel free to share feedback, questions, or your own tips for handling NIM configurations in the comments below.

:floppy_disk: This guide is available to download as a PDF: Netwrix Identity Manager - Gestion Configuration

Part 1 — Functional Scope and Storage in the Database

What is an NIM configuration?

All configuration items are stored in the NIM database. These configuration items impact the operation of the NIM.

Model & Connectors

  • Entity Model
  • Connectors to systems
  • Synchronization & provisioning

Access governance

  • Role Model (roles, rules)
  • Role Assignment & Role Mining
  • Governance Policies

Application & Safety

  • Workflows & notifications
  • Profiles & Permissions (HMI)
  • Technical parameters, translations

Reference: Identity Manager -export-Configuration

Marked Items vs. Unmarked Items

Item NOT marked

  • Created/modified via UI.
  • Stored in the database, like any configuration element.
  • But ignored by the XML/base comparison made during a deployment (configuration import).
    • → An XML import never touches it.

Item marked for export

  • Item previously loaded by an import.
  • Or created via the UI but exported at least once and marked via --mark-for-export (or --mark-rolemodel-for-export for the RoleModel).
  • Enter the XML/base comparison with each subsequent import. Any marked element will be synchronized with the next deployment.
    • → Absent from deployed XML = deleted in the database.

The diagram below illustrates how marked and unmarked items behave across successive imports and exports:

Marking flow diagram showing how items A, B, and C move between marked and unmarked states across import/export cycles
Marking flow diagram showing how items A, B, and C move between marked and unmarked states across import/export cycles1920×1080 143 KB

Part 2 — XML Import and Direct Changes in the UI

Import XML vs. UI modification

Deploy XML — Usercube-Deploy-Configuration

  • Versionable in Git (diff, review, history) and reproducible on all environments.
  • Calculates insert/update/delete against the base; traceability and rollback via Git.
  • Requires a build → commit cycle → deployment for each change.

UI modification — web interface, live

  • Immediate effect, no technical skills required; autonomy of the business/security teams (e.g. RoleModel).
  • Not captured in the XML, therefore not versioned, unless explicitly exported, and its marking then becomes definitive (see Part 3).

Part 3 — --mark-for-export and --mark-rolemodel-for-export

What Export Marking Does

  1. Export marked — --mark-for-export [--mark-rolemodel-for-export]
  2. Generation + Marking — The XML is generated AND the element is marked “to be exported” in the database.
  3. Next import — Absent from deployed → deleted in the database.

Netwrix Golden Rule: export all UI changes before redeploying XML, and deploy all XML before redeploying changes to UI.

Marking crosses environments — and never cancels out

Marking follows the element from one environment to another

  • The RoleModel is exported with --mark-rolemodel-for-export from environment A, and then the resulting XML is imported to environment B.
    • → On B, it is also included in the XML/base comparison: B is now committed to maintaining it in its XML for each subsequent import.

A marked item is never unmarked

  • There is no command or option to remove an element from the XML/base comparison once it is assigned to it, whether it comes from a local export (mark-for-export) or an XML import to a new environment.
    • → There is no going back to a 100% HMI state for an item that is already marked.

Remember: exporting/importing the RoleModel (or any UI-managed block) to a new environment should be an assumed and documented decision — not a reversible test.

Part 4 — Development and Deployment Pipeline

During the development phase

  • One domain, one management mode — decide by functional block (RoleModel, connectors, workflows…) whether it is driven by XML/Git or by the HMI, never both at the same time.
  • Never reflexively mark — only use --mark-for-export / --mark-rolemodel-for-export if the intention is to bring the element under Git control for a long time.
  • XML proofread like code — each XML evolution is developed on a dedicated Git branch, tested in development, and then reviewed before merging.
  • Isolate secrets and environment URLs — keep technical parameters (connections, URLs) out of versioned functional XML, or parameterized by environment.

3-environment deployment pipeline

  1. Development — XML written and tested by integrators; free UI for the RoleModel.
  2. Integration / Qualification — XML merged from Git; functional validation and non-regression.
  3. Production — Only validated and tagged XML is deployed; live RoleModel/UI.

Recommended Git flow:
Dev branch → merge on main → release tag → Dev deployment → validation → deployment Integration → sign-off → deployment Production

Key points to remember

  • XML = versioned in Git; UI = direct, immediate editing.
  • An unmarked UI element is never touched by an import.
  • Mark for export = final commitment, which crosses environments and can never be canceled.
  • 3 environments minimum, with a Git flow that goes from dev to production.

Part 5 — Summary

The diagram below summarizes the full lifecycle: configuring server A via initial XML import and UI enrichment, exporting and merging that configuration with server B’s own XML, and deploying the merged result to server B.

Summary diagram showing the configuration flow between NIM Server A and Server B, including XML export, merge, and deployment steps
Summary diagram showing the configuration flow between NIM Server A and Server B, including XML export, merge, and deployment steps1920×1080 198 KB

Flow steps:

  1. Conf XML init → Netwrix Identity Manager Server A
  2. UI configuration enrichment (manual) → Server A
  3. Server A → Conf XML A
  4. Export: merge Conf XML init + UI enrichments (marked for update)
  5. Conf XML A and Server B’s Conf XML B → merged (diff) into Merge Conf A+B
  6. Merge Conf A+B deployed → Netwrix Identity Manager Server B

(*) Minimum adjustments to make after merging and before deploying the configuration to server B:

  • JSON appsettings* files: connector connections
  • XML configuration: agent(s) URI, role model query/navigation rules, settings (authentication, application display)
2 Likes