Install SyncThing as a DOMAIN USER

[jdkniepkamp]

The issue here: Install as current user, access is granted, esp. if the current user is a domain user. Install as a local admin user - no access is granted to network shares.

I attempted to change the user that starts the service, but SyncThing does not start. Possibly I need to modify the config or the level of access granted.

The fix: In the installer, create an option to use a specific service account (ie. fabricom\SyncThingService) to run as a service. This would allow for granular NTFS permissions on connected UNC shares that require synchronization to non-domain joined resources.

Additional add to the installer: Offer the ability to change the default directory at installation, simplifying the post-install process.

[Bill-Stewart]

I'm not clear on what you're asking. If you install using admin install mode (per-computer), Syncthing creates a local account to run the service that is not a member of any groups. This is by design for security reasons: You must explicitly grant permissions to the service account to whatever folders you want to sync.

If you install using non admin (per-user), Syncthing starts as the current user. In this install mode, you can sync any folder from your user profile (which is usually what is desired) without needing to change permissions.

This is all spelled out in the documentation: https://github.com/Bill-Stewart/SyncthingWindowsSetup

Which installation mode did you use?

[jdkniepkamp]

Understood everything you indicated, based on the documentation.

For our purposes, I needed another option: a domain-joined service account to be used as a service-based installation. The local installation didn't allow us to navigate UNC paths. For instance, I attempted to install administratively, and this functioned, but only gave me access to LOCAL resources. I uninstalled it, the installed as current user (which was a domain user) and was able to add a UNC path as a folder in SyncThing. I uninstalled that, then installed administratively once more - then I added a domain service account as an administrative user on the machine

• then set the service to start using that domain service account, and now I have access.

Your installer would benefit by offering the choice of using a domain-joined service account if UNC paths to network resources are needed. That, or add the documentation necessary to let someone know that a domain-joined network service account needs permissions appropriate to run the SyncThing service, such as be a member of the Local Administrators group.

---

J. Kniepkamp

Email: @.*** Call/Txt: 352-399-8696

------ Original Message ------ From "Bill Stewart" @.> To "Bill-Stewart/SyncthingWindowsSetup" @.> Cc "jdkniepkamp" @.>; "Author" @.> Date 6/5/2024 11:52:43 AM Subject Re: [Bill-Stewart/SyncthingWindowsSetup] Install SyncThing as a DOMAIN USER (Issue #33)

I'm not clear on what you're asking. If you install using admin install mode (per-computer), Syncthing creates a local account to run the service that is not a member of any groups. This is by design for security reasons: You must explicitly grant permissions to the service account to whatever folders you want to sync.

If you install using non admin (per-user), Syncthing starts as the current user. In this install mode, you can sync any folder from your user profile (which is usually what is desired) without needing to change permissions.

This is all spelled out in the documentation: https://github.com/Bill-Stewart/SyncthingWindowsSetup

Which installation mode did you use?

— Reply to this email directly, view it on GitHub https://github.com/Bill-Stewart/SyncthingWindowsSetup/issues/33#issuecomment-2150409154, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPOAXVINU4GFSHWBNPNKXTZF4X4XAVCNFSM6AAAAABI24KFLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJQGQYDSMJVGQ. You are receiving this because you authored the thread.Message ID: @.***>

[Bill-Stewart]

Perhaps you are talking about LocalAccountTokenFilterPolicy? If this is the issue (you are logged on as an administrator and can't access a remote computer's share that's restricted to administrators), then (as noted in the Microsoft link) this is expected behavior for security reasons. The solution in that case would be to configure the LocalAccountTokenFilterPolicy value (not recommended, as it reduces security), or not run as administrator in the first place.

[jdkniepkamp]

EXACTLY! I would prefer NOT to run as an Admin, but I need to access UNC paths.
The local service account doesn't allow that (when installed administratively). This is why the option of designating a domain-added service account (non-administrator) to run the local service would be such a benefit. By doing so, a domain-joined service account would have access to authication-required UNC shares, not just local files on the syncthing host.

---

J. Kniepkamp

Email: @.*** Call/Txt: 352-399-8696

------ Original Message ------ From "Bill Stewart" @.> To "Bill-Stewart/SyncthingWindowsSetup" @.> Cc "jdkniepkamp" @.>; "Author" @.> Date 6/5/2024 12:35:00 PM Subject Re: [Bill-Stewart/SyncthingWindowsSetup] Install SyncThing as a DOMAIN USER (Issue #33)

Perhaps you are talking about LocalAccountTokenFilterPolicy https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction? If this is the issue (you are logged on as an administrator and can't access a remote computer's share that's restricted to administrators), then (as noted in the Microsoft link) this is expected behavior for security reasons. The solution in that case would be to configure the LocalAccountTokenFilterPolicy value (not recommended, as it reduces security), or not run as administrator in the first place.

— Reply to this email directly, view it on GitHub https://github.com/Bill-Stewart/SyncthingWindowsSetup/issues/33#issuecomment-2150494171, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPOAXRUUJKROOUJ2H6W5XLZF443JAVCNFSM6AAAAABI24KFLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJQGQ4TIMJXGE. You are receiving this because you authored the thread.Message ID: @.***>

[Bill-Stewart]

1. It seems odd to me that you would want to sync a remote computer's folder (a UNC path) from your local computer in the first place. If you can access it remotely anyway, why do you need to sync it? Th is unless, of course, you are talking about syncing it to some other host. In that case, I think the proper design would be to install Syncthing on the host where the folder exists and sync it from there rather than from your local host.

2. You could run as standard user (not admin) and access UNC paths, install Syncthing as the current user, and sync a UNC path. Of course, the UNC path would need to permit your current account access to it. (But, as noted, this is a string thing to want to do in the first place.)

With all that said, I guess I don't understand what you are really trying to do and what specifically isn't working.

[jdkniepkamp]

Happy to elaborate. We are in a controlled manufacturing space, where the manufacturing equipment is Internet accessible, but running software like WindowsXP Embedded, so vastly insecure. To control a broadcast attack to our domain, our security team dictated that we separate the networks, both from the Domain, and from the domain LANs. These machines live on an Island, with Internet-only access.

Since we still need to send them CAM / CAD instructions, we have internally built a share where the engineers write their software updates, and then sync that information over the Internet to the machine that hosts the CAM drawings. This way, manufacturing equipment still gets near-realtime access to the data they need, whilst maintaining a physical and logical disconnect from our domain systems.

The bridge here, being SyncThing, which can transmit the changes over the Internet.

Since the data is not on a physical drive, but rather a UNC share hosted by a sync service installed in our domain, we needed to configure the sync to connect to the UNC path. This path is not available to the CAM NAS device, as aforementioned it is disconnected logically and physically, hosting the data to the manufacturing equipment.

The UNC availability was not available to the local service account, as it needed to be an authenticated domain user, which I had configured as a service account in our org. Done right, I would have preferred to specify that domain service account user with my own password, eliminating the requirement to add it as a local admin on the SyncThing server.

I did NOT want to run it as 'current user' because this functionality has to happen at the server level, and this would be an even worse security risk and headache of maintaining an account always logged-on to a server - messy.

Hope that makes sense.

---

J. Kniepkamp

Email: @.*** Call/Txt: 352-399-8696

------ Original Message ------ From "Bill Stewart" @.> To "Bill-Stewart/SyncthingWindowsSetup" @.> Cc "jdkniepkamp" @.>; "Author" @.> Date 6/5/2024 1:04:57 PM Subject Re: [Bill-Stewart/SyncthingWindowsSetup] Install SyncThing as a DOMAIN USER (Issue #33)

It seems odd to me that you would want to sync a remote computer's folder (a UNC path) from your local computer in the first place. If you can access it remotely anyway, why do you need to sync it? Th is unless, of course, you are talking about syncing it to some other host. In that case, I think the proper design would be to install Syncthing on the host where the folder exists and sync it from there rather than from your local host.

You could run as standard user (not admin) and access UNC paths, install Syncthing as the current user, and sync a UNC path. Of course, the UNC path would need to permit your current account access to it. (But, as noted, this is a string thing to want to do in the first place.)

With all that said, I guess I don't understand what you are really trying to do and what specifically isn't working.

— Reply to this email directly, view it on GitHub https://github.com/Bill-Stewart/SyncthingWindowsSetup/issues/33#issuecomment-2150548092, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPOAXXMNIPPIYS36R3G6JDZF5ALTAVCNFSM6AAAAABI24KFLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJQGU2DQMBZGI. You are receiving this because you authored the thread.Message ID: @.***>

[Bill-Stewart]

Installing the service using a domain account is not something I would consider doing from the installer due to the potential risk. You're free to change to a less secure configuration in your own environment, of course, but it's not something I think it's a good idea to support by default.