feat(pedm): account tracking

[allan2]

This commit adds tracking of user accounts and domain accounts. Changes to accounts on the system such as name change, creation, removal, and even SID change are captured.

Accounts now use an internally generated stable ID. This stable ID can be used to build policies in a robust manner.

The functionality has been tested with real account creation, deletion, and removal on Windows for both DB backends.

This commit also includes query helpers for parametrization and bulk insertion.

A basic endpoint, /accounts, is added for displaying info about existing accounts in a fashion similar to Get-LocalUser.

[github-actions[bot]]

Let maintainers know that an action is required on their side

• Add the label https://github.com/Devolutions/devolutions-gateway/labels/release-required when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label https://github.com/Devolutions/devolutions-gateway/labels/release-blocker if a follow-up is required before cutting a new release

• Add the label https://github.com/Devolutions/devolutions-gateway/labels/publish-required when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label https://github.com/Devolutions/devolutions-gateway/labels/publish-blocker if a follow-up is required before publishing libraries

[CBenoit]

Hi @allan2 Could rebase this PR on master please? Thank you!!

[thenextman]

I've had a look through these changes and I do think it's a worthwhile improvement.

That being said, I'm questioning whether we want to merge this now given that we're in the 11th hour for 2025.2 release.

If we go ahead with this, we'll need to restructure the way data is managed internally; that's probably not a huge issue since the rest of the configuration stuff is not yet ported to SQLite. However if we do see it through, it does have an impact:

• We don't have time to thoroughly test this
• It implies a whole bunch of refactoring on the RDM side, which I also don't see that we have time to do. Work on RDM at this point should be tweaks and bug fixes, not reworking the UX.

What's the side effect of not having these changes? Well, we won't track the changes that @allan2 wrote in the PR notes but honestly I'd consider that to be a bit of an edge case

• User SID changes are not common. The main reason that impact us would be that the user gets moved from one Active Directory to another (noting that in this case the SID is not really "changed": a new user is created in the new AD, the history is copied over, and the old is deleted)
• User name changes are still uncommon, but perhaps more of a worry. What happens if a user name changes right now? I didn't try it, but it's likely that the profile assignment will be lost (but reassigning to the "new" user is quite easy) and the log interface will be weird (because logs will be available for both the old and the new username). I don't see either of those as a particular problem, given the disruption that occurs in general when you rename a Windows user.

It seems trivial to me to go with what we have for now, and after merging this it should not be too troublesome to migrate the data in the user table to account; that's just an internal representation and can be done easily; the real work is in adjusting the APIs and ensuring we get a consistent experience in RDM. I don't think there's time to do that now.

A middle ground would be to merge this but not integrate it at this point. As long as we are assured that the account sync is not introducing issues in general in the service,.

[thenextman]

And furthermore: if we get a case where the customer is having issues due to a renamed user or an altered SID; it's relatively easy to just recreate the configurations on the RDM side. There are very few options. If it so happened that we had a customer deploy this, with many dozens of users on the machine and lots of configuration (very unlikely at this point) and they were affected by those circumstances, it could be fixed directly in the DB. I think coding around the problem is worthwhile, but not something we have time to put our attention on this week.