gMSA account support for SQL database configuration in NDM

Products Directory Manager Ideas
,
1

What is a one-sentence summary of your feature request?

Allow the use of gMSA accounts to configure the SQL database via the Configuration Tool.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

When deploying Netwrix Directory Manager in customer environments subject to strict security constraints, using traditional accounts with credentials (login/password) can be problematic or even prohibited.

Currently, although NDM supports gMSA (Group Managed Service Accounts) for certain use cases, it is not possible to use them when configuring the SQL database connection via the Configuration Tool Wizard (section “Database Settings” > “Account Credentials”).

This limitation raises several issues:

  • Non-compliance with customer security policies (no password storage)
  • Increased complexity in managing service accounts
  • Operational risk related to password management and rotation

Adding gMSA support for SQL connections would enable:

  • Better integration with secure environments
  • Reduced risks associated with credentials
  • Simplified administration

How do you currently solve the challenges you have by not having this feature?

Currently, we must use standard service accounts with passwords for SQL connections, which requires:

  • Secure storage of credentials
  • Manual management of password rotation
  • Exceptions to security policies in certain environments

In some cases, this blocks or significantly complicates the deployment of the solution.

Upload any supporting images that you think should be considered in this idea.

image
image992Ă—871 59.4 KB

2

Hi Cedric, thank you for this — and for the detail and screenshots you’ve included. This is a clear and well-framed request.

I want to be transparent with you: this is a genuine gap, not a configuration issue on your part.

You have done everything correctly. The way gMSA accounts work — with passwords managed entirely by the OS and never known to any application — means the current SQL configuration path in the Configuration Tool cannot complete the connection test against a gMSA identity. The failure you’re seeing is not user error.

We do have some existing gMSA infrastructure in the product already, which tells me this is a solvable problem. However, after looking into this a little further I also want to be honest: the work required to do this properly is not trivial, and our current engineering commitments mean I can’t give you a near-term date on a fix.

What I do want to say clearly:

if this is blocking an active deployment, please don’t wait —

reach out to us directly.

There are deployment approaches that may help you move forward in the interim, and I’d rather we find a path through this with you than have it sit as an unresolved blocker. You can contact support and reference this post, or reply here and we’ll make sure the right people are engaged.

We will track this request. The use case - deploying in environments where stored credentials are prohibited, is increasingly common and entirely legitimate, and it deserves a proper solution.

Thank you for taking the time to raise it here.

2 Likes