Installing Tentacle under workgroup user or domain account

Legacy Uncategorised
1

What additional permissions or setup steps would a user require to run the Tentacle service if it was not installed under the network service.

Have found “System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL” errors when I changed the service account but there are work arounds for those.

2

Hi Nikolai,

Tentacle would need to run under a user account that can:

  • Host the WCF service (http registrations will be part of that as you have discovered)
  • Read/write to the C:/Octopus folder
  • Run as a service
  • Start/stop Windows Services
  • Modify IIS settings
  • Anything your custom PowerShell scripts need to do

That’s a pretty broad set of permissions - if you can do all that to a system, you can do almost anything anyway, so my assumption has been that running as Local System would be acceptable. Since the product is still in development I haven’t captured a full list of all the necessary permissions though, so let me know if you have any problems!

Thanks,

Paul

3

Thanks, I have resorted to the bad behaviour of adding the user to local admin, I am doing BizTalk deployments and require some pretty agressive permissions given the services being deployed and restarted.

In a production setting the Tentacle user will need to be a domain user as there are domain groups it would need to be a member of.

4
  • Create a user to run the tentacle service as. In this example xUser.
  • Create a group called xGroup and add xUser to it. Remove xUser from default users group.
  • Where possible, assign permissions to the group.

Run as a service

  • Change the tentacle service to logon as xUser.
  • Windows automatically granted xUser permission to run as service

Host WCF Service:

  • netsh http add urlacl url=http://*:8202/ user=xGroup
  • Replace 8202 with the port your tentacle should listen on

Read/Write to C:\Octopus

  • Pretty easy, just grant modify permissions to xGroup

Modify IIS Settings

  • Goto C:\Windows\System32\inetsrv\config
  • Grant xGroup read permissions to administration.config, and redirection.config
  • Grant xGroup read/write permissins to applicationHost.config

Start/Stop Windows Services

PowerShell Scripts and Other

  • Not doing much here yet. I will have to do some database stuff for sure, but that should be limited to granting xGroup access to specific databases.

I’m still debating if the extra work to set this up is worth it. I like running everything with as few permissions as possible, if only to see if it can be done. The microsoft documentation on the IIS config directory says not to change permissions so that’s about the only thing I’m a little concerned with.