Running Deployment Agent with restricted permissions
gius
Posts: 2
For security reasons, I don't want Deployment Agent to run as LOCAL SYSTEM.
I'd rather create a specific user account and run the agent within its context.
This is what I have done so far:
1. Install Deployment Agent
2. Create new user "DeploymentAgent" and make the Red Gate Deployment Agent service run as this user
3. Enable Log on as a service for DeploymentAgent
4. Add permissions to open port 10301 for DeploymentAgent
5. Add read permissions for C:\Program Files (x86)\Red Gate\Deployment Agent\Agent
6. Add write permissions for C:\ProgramData\Red Gate\DeploymentAgent
So far, the agent is able to deploy my applications (despite the fact that DeploymentAgent does not have rights to write to respective folders the apps are deployed to).
The problem comes when the agent needs to be upgraded. It seems that the upgrade process is done via pushing the standard MSI package to the server and running Windows Installer there. But when the service is running under DeploymentAgent user, the Windows Installer does not work:
In installation log, there is the following error:
The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed.
And in Event log, there is following warning for MsiInstaller source:
Failed to connect to server. Error: 0x80070005
So, my question is:
What other rights are needed for Deployment Agent to run (and upgrade) properly?
Moreover, when I ran the MSI package manually, the agent got upgraded, but the service was set to run as LOCAL SYSTEM again. So, is it possible to set the service user through the installation package, or at least leave the service settings untouched?
Has anyone tried the same or am I the only one concerned that the deployment process, including custom PowerShell scripts, usually configurad via Variables, running with Administrator rights?
(and if you want to ask - yes, wrong configuration variable caused my custom script to run in a different path than expected, completely erasing the server's system disk :-(
I'd rather create a specific user account and run the agent within its context.
This is what I have done so far:
1. Install Deployment Agent
2. Create new user "DeploymentAgent" and make the Red Gate Deployment Agent service run as this user
3. Enable Log on as a service for DeploymentAgent
4. Add permissions to open port 10301 for DeploymentAgent
5. Add read permissions for C:\Program Files (x86)\Red Gate\Deployment Agent\Agent
6. Add write permissions for C:\ProgramData\Red Gate\DeploymentAgent
So far, the agent is able to deploy my applications (despite the fact that DeploymentAgent does not have rights to write to respective folders the apps are deployed to).
The problem comes when the agent needs to be upgraded. It seems that the upgrade process is done via pushing the standard MSI package to the server and running Windows Installer there. But when the service is running under DeploymentAgent user, the Windows Installer does not work:
In installation log, there is the following error:
The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed.
And in Event log, there is following warning for MsiInstaller source:
Failed to connect to server. Error: 0x80070005
So, my question is:
What other rights are needed for Deployment Agent to run (and upgrade) properly?
Moreover, when I ran the MSI package manually, the agent got upgraded, but the service was set to run as LOCAL SYSTEM again. So, is it possible to set the service user through the installation package, or at least leave the service settings untouched?
Has anyone tried the same or am I the only one concerned that the deployment process, including custom PowerShell scripts, usually configurad via Variables, running with Administrator rights?
(and if you want to ask - yes, wrong configuration variable caused my custom script to run in a different path than expected, completely erasing the server's system disk :-(
Comments
Unfortunately it's a known limitation that the agent upgrade fails if you've amended the user account it runs as.
It's something the team may investigate, but for now, it's recommended that you change the user back to Local System when you want to upgrade it, then change it back to the account you want it to use afterwards.
Redgate Software