Heartbeat and Password Rotation Failures on Accounts in Protected Users Group

A fix for this issue has been implemented in version 2025.3.12.0

Heartbeat and Password Rotation Failures on Accounts in Protected Users Group

avatar

I am now experiencing password rotation and heartbeat failures on accounts in the Protected Users group after upgrading to DVLS version 2025.3.3.0. Once I remove the accounts from the group, everything works as expected. It appears that DVLS is using NTLM authentication instead of Kerberos. I get the following audit log in the domain controller when the user is in the Protected Users group at the time of rotation & heartbeat:

NTLM authentication failed because the account was a member of the Protected User group.

Account Name: [Redated Account Name]
Device Name: [Redacted Domain Controller Name]
Error Code: 0xC000006E

In DVLS, I am getting an LDAP Code 49 failure when attempting the heartbeat or password rotation. Interestingly enough, password rotation & heartbeats work for members of the Protected Users group if the provider is set to use LDAP instead of LDAPS account, which isn't ideal. I am happy to provide more logs if needed, but not really sure where to go from here.

All Comments (11)

avatar

Thanks for this report, I know what the issue is, we reduced the number of retries when authenticating the user. When using LDAPS we first try to connect with a SimpleBind and if we get a 49 (bad password) we simply fail, instead of retrying with Kerberos. We did this to reduce the number of retries, we had customers who has low lockout count values (3) which would have accounts get locked out quickly if we retried authentication with too many systems. I have logged a ticket and we will change this logic to fix your issue. I think a workaround for now would be to disable LDAPS, which should fix the issue. Don't worry LDAP connections are still internally encrypted by the SASL protocol when using Kerberos.

Thanks,
Paul

avatar

Paul, thank you so much for the explanation and ticket. I really appreciate it!

avatar

Hello,

Thank you for being so patient!

I am pleased to inform you that the issue has been resolved in the latest Devolutions server version (2025.3.12.0):
https://docs.devolutions.net/server/getting-started/installation/upgrade-server

We also recommend that you first perform the update in a staging/test environment:
https://docs.devolutions.net/server/kb/how-to-articles/create-server-staging-instance

Please let us know if this works or if you encounter any issues.

Best regards,

Maxim Robert

avatar
Hello,

Thank you for being so patient!

I am pleased to inform you that the issue has been resolved in the latest Devolutions server version (2025.3.12.0):
https://docs.devolutions.net/server/getting-started/installation/upgrade-server

We also recommend that you first perform the update in a staging/test environment:
https://docs.devolutions.net/server/kb/how-to-articles/create-server-staging-instance

Please let us know if this works or if you encounter any issues.

Best regards,


@Maxim Robert
Hi,
Is this issue fixed while using LDAPS with protected user ? Cause we are facing this issue on our side in 3.15.

avatar

Hello @maximetremblay ,

Thank you for your feedback.

The fix should be applied to LDAPS in version 2025.3.12.0 as mentioned in the release notes. In the meantime, as Paul mentioned above, the workaround is to disable LDAPS if it is still not working, which should fix the issue. Don't worry, LDAP connections are still internally encrypted by the SASL protocol when using Kerberos.

Do you get the same error message on version 2025.3.15.0 as the one mentioned in the first message of this thread? If it's not the same one, please post the error message you get.

Best regards,

Érica Poirier

avatar

Hi,
We wont disable LDAPS and yes we still face the issue. We may have another workaround thanks for the update.

avatar

Hi Devolutions-Forum,
we still get the heartbeat / out of sync error message with LDAP or LDAPS. It is possible to check out the credentials but the message won't go away.
The DVLS Version is 2026.2.7.0

Best wishes,

avatar

Hello @baehrm,

Thank you for the report, and sorry to hear the issue is still occurring for you. For context: the original NTLM-fallback problem was fixed in 2025.3.12.0 (and carried into the first 2026.1 iteration), so a recurrence on 2026.2.7.0 points to a different underlying cause in your environment rather than the original bug. We do have another internal ticket opened to handle this new situation. To understand what's happening on your end, could you share the following?

The error itself:
1- The exact error message and LDAP result code you see on the failing heartbeat — is it still an LDAP Code 49, or something different? The precise wording matters here.
2- You mentioned credential checkout works, but the "out of sync" message won't clear — does the heartbeat itself report success at any point, or does it fail every time? A screenshot of the entry's status/heartbeat detail would help.
From the domain controller — this is the most important part. At the exact timestamp of a failed heartbeat, please pull the Security event log and let us know:
3- Do you see NTLM events (4776, with error 0xC000006E, and any 4822 Protected Users block) at that time?
4-Do you see any Kerberos events (4768 / 4769) at that same timestamp, or none at all? If there are no Kerberos events, authentication never attempts Kerberos and goes straight to NTLM.
On the environment/configuration:
5- Is the DVLS host domain-joined, and does the DC your provider targets have a registered ldap/<fqdn> SPN? The output of setspn -Q ldap/<your-dc-fqdn> would confirm this.
6- In the provider settings, are you connecting to the DC by its real FQDN, or through an alias / load-balanced name (which may not have its own SPN)?
7- What does your AD topology look like — specifically, is the Kerberos realm the same as the domain name, or is the domain you're using actually a UPN suffix alias of a different real realm?
A quick comparison test:
8- Does the User Validity diagnostic succeed for the same account (in both DOMAIN\user NetBIOS and UPN form) that fails in the heartbeat? If the diagnostic passes but the heartbeat fails, the two paths are diverging, and that's a strong clue.

I encourage you not to share log details publicly. You can send them to service@devolutions.net with a reference to this thread — we can dig into the anonymized DC logs there.

Thank you for your collaboration.

Érica Poirier

avatar

Hi Erica,
thank you for the guide.
The problem was with the (7) - the Domain "testdomain.local" has 3 domain controllers (dc1.testdomain.local, dc2...) and I used "testdomain.local" as DC. The domain itself is not part of the SPNs for the DCs which caused the problem.
After switching to a single DC the rotation and the heartbeat worked.

Is it possible to configure multiple DCs for the heartbeat/ rotation?

Best wishes,

avatar

Hello,

Thank you for your feedback. That's good news that you have found the root cause of the issue.

Only one DC can be configured for the heartbeat/password rotation. Otherwise, when left blank, it uses the DC provided by the current Windows session. I'll create a post in the Feature Request section from your post above.

Please let us know if you have any further questions.

Best regards,

Érica Poirier

avatar

Érica Poirier

A fix for this issue has been implemented in version 2025.3.12.0