Hi @ts678 , good to be here .
Yes, I understand the cross-platform requirement; it is a great feature and makes this product appealing to a much broader audience. I don’t want to suggest any changes that diminish cross-platform functionality.
Web GUI logon
OS-backed authentication can improve security significantly: the OS supports comprehenstive password and account-lockout policies; authentication attempts are logged centrally; users don’t need to memorise yet another password. Many users do not regard this functionality as essential (and many users probably don’t have a password on the web GUI altogether!). In Windows we can use OS API calls to validate user credentials. In Linux, similarly, we can validate against the Linux PAM authentication modules.
For avoidance of doubt, the web GUI authentication should be used only to control access to the web GUI. We do not suggest to use these credentials to execute any backup jobs (Duplicati already has functionality to access network resources using credentials stored in the job configuration).
Windows Service user accounts
Let’s return to the Windows Service. On Windows, services typically run under one of the following accounts:
- LocalSystem - highly privileged account that can manage the computer; it has a swath of privileges, including SeBackupPrivilege, SeRestorePrivilege (both disabled initially). On the network, the computer authenticates as itself (relevant for Windows AD).
- LocalService - basically a ‘user-level’ account for services. Conceptually, it is similar to a Linux account with
/sbin/nologin shell (ie users cannot login). On the network, the computer acts as an anonymous user (relevant for Windows AD).
- NetworkService - same as LocalService, but on the network the computer authenticates as itself.
(See Service User Accounts)
The above accounts are machine-local. Windows AD also offers managed service accounts (MSA) that are intended for use by services (no interactive logon) and are installed on a Windows machine. Applications/services would use MSA accounts in the same way as regular accounts.
Of course, users can also configure a Windows Service to use a regular account of their choosing.
How do we use the above security model to assign different permissions to Service A and Service B? We use virtual accounts. A virtual account is essentially a sub-account of NetworkService, and can be created on-the-fly. In the Services snap-in:
- Open properties for any service, go to the Logon tab.
- Select This account radio button and enter
NT Service\MyNewAccountName, leave the password field blank, and press OK.
We can then edit resource ACLs to give our service the necessary permissions.
Screenshots in PR#4471 show the application running as
NT Service\Duplicati and that we added
NT Service\Duplicati to the
Backup Operators security group to give it the relevant privileges.
Robust software applications often use the virtual NetworkService accounts. For example, by default the Microsoft SQL Server service runs as
NT Service\MSSQLSERVER, and the installer restricts access to important directories to this user (eg C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA).
On Windows, Duplicati stores configuration in the
%LOCALAPPDATA% directory. When Duplicati runs a logged on user, this is typically
C:\Users\USERNAME\AppData\Local\Duplicati. If we run the Duplicati service as
NT Service\Duplicati, then
%LOCALAPPDATA% will resolve to
What improvements are desired for running Duplicati as a service?
- Duplicati service should (try to) access local files using SeBackupPrivilege/SeRestorePrivilege with the correct file IO semantics (eg Alphaleonis.Win32.Filesystem.File.OpenBackupRead).
- It would be nice to have a simple forms-based UI to manage service install/uninstall (eg add forms to Duplicati.WindowsService.exe).
- By default, the service installation process should configure the Windows Service to logon as
- By default, the service installaiton process should add the service user account to the
Backup Operators security group.
User interface (web GUI)
- GUI should show more prominently the user context under which the application is running (currently visible on System info tab, 17 lines into System properties). On Windows, we should show the full account name in Domain\User format (currently, when service runs as
NT Service\Duplicati, the System properties reads:
UserName : duplicati).
- GUI should show the location of the data folder being used (can be specified using the
--server-datafolder parameter). This is currently not visible at all.
The OP (@jcs1167957 ) also mentioned functionality to detect when USB drives are plugged in and execute relevant jobs. This would be a great feature, but is not related to the Windows service requirement. I suggest a separate discussion about this.