Closed zzbe closed 2 months ago
Yes, this is by design because account creation would result in creation of a domain account, and there's not a way to synchronize the account password across multiple DCs in a domain. What is the reason you would want to install the Syncthing service on a DC?
Well, we only have a single DC so I don't have many options and I'm not wasting another VM just to run syncthing. I don't see how in a multi DC environment SyncthingServiceAcct wouldn't sync just like any other account and honestly it doesn't even matter. I'm using Syncthing on a DC just as an intermediate to sync few important files between PCs.
Anyway, for now installing an older version works just fine – it updates and everything. Was just wondering for the future, when that might not be the case anymore.
I don't see how in a multi DC environment SyncthingServiceAcct wouldn't sync just like any other account...
Because if you install the Syncthing service on a different DC, the password would no longer be in sync and the service would only start on the latest installed DC (as that's the install that last set the service account's password).
Rather than installing the service, I would recommend creating a Group Managed Service Account (gMSA) instead and run Syncthing using a scheduled task. This would be more secure and there wouldn't be any password complications.
Ok, now I understand what you mean. Still, I'd appreciate it if you could add some '--ignore-dc-error' flag to let it go through. (I only ever need it to run on a single DC, even if I added more.)
I'll look into gMSA when I have more time.
I would just like to know what is the reason for this and if there is a way to circumvent this? (So far installing an older release works.)