We have developed a backup software for a SQL Server(2019) that runs on a Windows Server 2019 for a customer.
The app (.net Windows Forms) has an interface to configure the backups (e.g. select day's for backup, backup times every day, and so on) and further configuration's (data to SMTP-Server, mail distribution list, and so on). Further the client contains functions to restore database.
The backups are started over a timer.
The App works fine, but has to run 24/7/365.
Problem description:
The app run's on a customer server and the customer don't allow accounts where the password never expire.
Further the server is (at least) rebooted every two weeks automatically.
So… we have to access the server and start our client new at least every two weeks, what is not nice.
Therefore, we think about to "split" the backup App in two parts:
- Windows Client (with deactivated backup and E-Mail functions)
- Windows service (read the config files at startup, do the backups, send E-Mails)
=> Target: The Service to the backup is started automatically after a server reboot (no need to start in manually).
Needs:
The Service need to have access to the local disk (read (.ini) configuration file, store the backups), to the SQL-Server (installed on the same server) and to the SMTP-Server (located on another customer server) to be able to send E-Mails.
As mentioned above, the target is to use a "system account" without password (that has to be changed periodically).
We are developers, not system engineers… therefore the "starter questions":
As far as we know, there are System accounts for "Local System", "Local Service" and "Network Service" (maybe there are more…).
Question:
Has one of the above mentioned accounts all needed rights (or is there another)?
Thanks!
Best Answer
Yes, you absolutely need to have the interactive "configuration" and "service" parts separate. The Service part needs to run all the time, the configuration part only as and when needed.
The idea of having an application running "on the console" of a Windows Server these days is troublesome, at best, and gets harder with each version of Windows. Having produced Windows Services that are still in Production 20 years on, I'm a little surprised you didn't come across this "challenge" during development and testing.
But anyway ...
Given that Windows supports numerous, "system" accounts whose password never expire, this is a strange "Requirement" to have inflicted on your application.
Question: Is this "Requirement" actually relevant?
To use the "configuration" app, you would need to log into the machine, so you'd use whatever credentials you were given for this purpose - those, interactive, User-specific, credentials should expire periodically.
The "service" part should just run and do stuff.
If these system accounts had expiring passwords, the Windows ecosystem would be utterly unusable.
Yes, absolutely.
Any of the "Service" accounts should have this level of access.
Access to anything "off" the box requires a Network-aware account.
Network Service is probably your best bet.
Danger, Will Robinson!
Are you seriously saying that your "backup" utility is taking and storing SQL Server backups on the same machine as the SQL Server instance itself?
This undermines your whole solution.
If you lost the machine on which SQL Server was running, then you'd also lose the backups of your database as well and, since the only reason that backups exist is to guarantee that you can get the database back no matter what goes horribly, horribly wrong, then your "backup solution" is completely compromised.
You absolutely must get the backups off of that server and onto a.n.other machine, well away from the databases that they are protecting.