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 ...
The app run's on a customer server and the customer don't allow accounts where the password never expire.
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.
The Service need to have access to the local disk (read (.ini) configuration file, store the backups) ...
Yes, absolutely.
Any of the "Service" accounts should have this level of access.
... and to the SMTP-Server ... to be able to send E-Mails.
Access to anything "off" the box requires a Network-aware account.
Network Service is probably your best bet.
... to the SQL-Server (installed on the same server) ...
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.
