Hi
I am using the Octopus VM Extension as part of my VM Deployment in Azure.
I have automated the deploy of the VM , interfaces etc and the extension from an ARM template in Octopus. The problem that I have, is that once the VM is deployed and activated and running, I cannot deploy my next Octopus steps in the project as they require an elevated permission, and the Octopus tentacle is running under a local service account on the VM in Azure.
So my question is:
Can we change the service account that the tentacle is deployed under via automation, or is there a way to specify a different remote credential (different to the service account that the tentacle is running under) for the steps in the process of the project in Octopus?
I have been reading about DSC, but it does not seem to allow you to specify the service account of the tentacle.
Thanks
Francois
Hi Francois
Thanks for getting in touch!
Can you clarify what you mean when you say “they require elevated permission”? The Tentacle runs under Local Service, which should give you admin permissions to the local machine? The only scenario I can think of where it doesn’t give you full permissions is when you require NetworkService and permissions to go out across the network?
Unfortunately, there is no way to specify the service account to use via the VM Extension, nor via the DSC. (There there has been a discussion about a community contribution to do this, but it is not available as yet).
One potential option is once the Extension is installed, you could use a Script Extension to change the service account.
If you went down the DSC route, you could also do the same with a service resource and set the credentials that way.
Another option could be to try using the special variables Octopus.Action.PowerShell.Username
and Octopus.Action.PowerShell.Password
. While not explicitly designed for this scenario, that may work to set the powershell credentials to use when running your script.
Hope that helps!
Regards,
Matt
Hi Matt
Thanks for the great reply (and excellent support and documentation in general).
The elevated permissions that I required in this case, was to create the Integration Services catalog post deploy of my .dacpac from Octopus.
This requires sysadmin privileges which the service account of the tentacle did not have.
The way I did it in this case, was to have a powershell step in the process that assigned the SQL SysAdmin privilege to the local service by executing a SQL statement using a SQL server Login that had permission.
This obviously required mixed authentication to be enabled in the ARM template, which was fine for me.
Thanks
Francois
Hi Francois
Glad to hear you’ve managed to resolve it - thanks for letting us know.
Happy deployments!
Regards,
Matt