Managed Service Accounts

Legacy Uncategorised
1

Since the introduction of Windows Server 2008 R2, the company I work for has moved toward Managed Service Accounts for software that runs as a service. The latest version of Octopus doesn’t seem to support this.

2

Hi Julian,

Thanks for getting in touch! I don’t have a lot of experience working with MSA’s, but I will do my best to help. The short answer is Octopus doesn’t currently support MSA’s as a first-class citizen, but there are easy workarounds for that which you can use in the meantime.

MSA for the Octopus Server

We don’t have built-in support for choosing an MSA for the principal that runs the Octopus Windows Service. There is an easy workaround for this based on this similar issue.

  1. Set up OD as per usual
  2. Use the built-in Windows dialogs to choose a Managed Service Account instead

MSA for deployed Windows Services

Again, it looks like we don’t have built-in support for choosing an MSA when deploying a Windows Service. As a workaround, you should be able to deploy the Windows Service using the normal process, and add a custom script to re-configure the service principal.

  1. Configure a Windows Service step making sure:
    a. Set the Startup type to Manual
    b. Set the account to one of the built-in accounts like Network Service
  2. Add a post-deploy custom script to reconfigure and start the Windows Service
    a. sc.exe config "myservice" obj= "domain\username$"
    b. Start-Service "myservice"

Note the following excerpt regarding the username and security policy:

There must be a dollar sign ($) at the end of the account name in the Services snap-in console. When you use the Services snap-in console, the SeServiceLogonRight logon right is automatically assigned to the account. If you use the Sc.exe tool or APIs to configure the account, the account has to be explicitly granted this right by using tools such as the Security Policy snap-in, Secedit.exe, or NTRights.exe.

You can see more about the scripts we use to deploy Windows Services here: Calamari/source/Calamari/Scripts at master · OctopusDeploy/Calamari · GitHub

Hope that helps!
Mike

3

Hi Julian,

I’ve just done some more testing and wanted to get back to you with the results.

MSA for deployed Windows Services

You can use the Deploy Windows Service step in its current form without any custom scripting. You just need to configure the step so it uses a Custom Account and make sure the Password will be omitted by binding it to nothing.

747×384

Sample output from our demo server:

The OctoFXRateServiceDevelopment service already exists, it will be reconfigured.
November 10th 2016 11:09:52Info
sc.exe config "OctoFXRateServiceDevelopment" binPath= C:\Octopus\Applications\DWebApp01\Development\OctoFX.RateService\3.2.54161\OctoFX.RateService.exe DisplayName= "OctoFX Rate Service Development" depend= "LanmanWorkstation/TCPIP" start= "demand" obj= "DOMAIN\username$"

Note you will still need to grant the SeServiceLogonRight to that MSA.

Hope that helps!
Mike

4

Hi Julian,

Just wanted to drop you a line and let you know I’ve updated our documentation based on our conversation to date.

Let me know if you have success, or any problems, and I’ll make sure we take care of things on our end. :slight_smile:

Hope that helps!
Mike

5

I just realized that I may not have been clear regarding the MSA though I’m excited to know that I will be able to deploy Windows services using managed service accounts with Octopus. My current problem is getting the Octopus Server to run using a Managed Service Account. I did go into the service control manager and update the service to use my managed account and gave the service account the “Log on as a Service” rights. The service starts but immediately stops with the “The HTTP server could not start because namespace reservations have not been made” error. I have run the netsh commands with the service account listed. However, it still fails to start with the same error message. During troubleshooting, I added the service account to the local Administrators group and restarted the service and it was able to start but returned a 503 HTTP error code via a web browser. I removed the service account from the Administrators group and the “namespace reservations” error returned… I rather not run my services as a local administrator on the box so I’m not sure what else to try at this point.

–
Julian

_WRD000.jpg

6

Apparently, the 503 only occurs when I’m running with SSL using the FQDN name of the server that Octopus is running… When I also add “localhost” endpoints, I can browse it from the server (along with the “name mismatch” certificate warning) using https://localhost/

7

Hi Julian,

Thanks for getting back to me. If you are willing, I’d like to get to the bottom of this one. The error you see when running as the MSA is because Windows is refusing to let the Octopus Server process running as the MSA create an HttpListener binding to that URL/port/etc. Octopus will attempt to create all the correct ACLs on your behalf, but in your case the MSA doesn’t have the permissions to do so. It looks like other people have had success doing the same kind of thing with similar applications, so I can’t see any fundamental reason why this can’t work for you too: http://www.ryanmelena.com/2014/05/29/tfs-2013-build-agent-group-managed-service-account/

We might be chasing our tails a bit, so I think it would be good to check a few fundamentals.

Firstly, could you stop the Octopus Server and:

  1. Delete any existing URL ACLs for the octopus server URLs you tried binding to? That would include any localhost:port bindings and FQDN:port bindings: netsh http delete urlacl ...
  2. Delete any SSL certificate bindings for Octopus: netsh http delete sslcert ...
  3. Check and make sure there are no more URL ACLs nor SSL cert bindings left over.

Now configure the Octopus Server to use the MSA and:

  1. Configure a single URL ACL for http://localhost:8065: netsh http add urlacl http://+:8065 user=DOMAIN\User$

Now run the Octopus Server Manager and:

  1. Delete all bindings
  2. Configure a binding for http://localhost:8065
  3. Finish the wizard and Octopus Server should get configured to use that single binding

This should enable the Octopus Server to bind an HttpListener to that port.

If this works as we hope, you should be able to build on top of this by changing the bindings and URL ACLs.

To enable SSL you will need to configure the SSL Certificate binding also:

http add sslcert ipport=0.0.0.0:<port> appid={E2096A4C-2391-4BE1-9F17-E353F930E7F1} certhash=<certificateThumbprint> where <port> will usually be 443.

Regarding the 503 Service Unavailable error - do you have any other servers running on this machine? Like IIS or another application?

If you are still experiencing problems I’d be happy to organise a screen share at a time that suits us both. :slight_smile:

Hope that helps!
Mike