Issue binding password to custom windows service identity

Rob_Sanders · 22 January 2015 05:28

I’ve attempted to bind an environment variable from an variable set as the password for a domain user, set as a Windows Service credential, attempting to support different passwords for different environments (see screenshot).

The configuration appears to bind to the value, but when deploying it errors (cannot start service) due to invalid password (setting the correct password directly in the config works).

Vanessa_Love · 22 January 2015 05:36

Hi Rob,

Thanks for getting in touch! The general culprits are things like scope, variable availability and variables being added but an existing release deployed where the variable was not part of the snapshot.
When these all appear right the next step is to print the variables to the logs and see if they are available:
http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables

Let me know how that goes.
Vanessa

Rob_Sanders · 4 February 2015 23:14

Finally found some time to go back over the deployment - it seems to be working now. I’m not sure what is different now (than before), but it’s working!

Rob_Sanders · 6 March 2015 02:56

HI Vanessa,

Sorry for the late, late reply. We’re still getting this issue. I’ve enabled the printing of variables, and reverted to storing the password as non-sensitive. Unfortunately, the log doesn’t help much as it still obfuscates the password:

Running PowerShell script: C:\Octopus\Applications.SQ-PWCBRSBUS31-06BAE891\Octopus.Tentacle\2.6.0.778\Scripts\Octopus.Features.WindowsService_BeforePostDeploy.ps1
Info 13:45:43
The MassTransit.RuntimeServices service already exists. It will be stopped and reconfigured.
Stopping the MassTransit.RuntimeServices service
sc.exe config MassTransit.RuntimeServices binPath= “D:\Services\MassTransit\MassTransit.RuntimeServices.exe” DisplayName= “MassTransit Runtime Services” depend= / start= delayed-auto obj= svc_mt_consumer@production..au password= “************”
[SC] ChangeServiceConfig SUCCESS
Updating the service description
[SC] ChangeServiceConfig2 SUCCESS
Starting the MassTransit.RuntimeServices service
Error 13:46:12
Start-Service : Service ‘MassTransit Runtime Services
Error 13:46:12
(MassTransit.RuntimeServices)’ cannot be started due to the following error:
Error 13:46:13
Cannot start service MassTransit.RuntimeServices on computer ‘.’.
Error 13:46:13
At C:\Octopus\Applications.SQ-PWCBRSBUS31-06BAE891\Octopus.Tentacle\2.6.0.778
Error 13:46:13
Scripts\Octopus.Features.WindowsService_BeforePostDeploy.ps1:141 char:2
Error 13:46:13

```
Start-Service $ServiceName
```

Error 13:46:13

```
~~~~~~~~~~~~~~~~~~~~~~~~~~
```

Error 13:46:13
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceControl
Error 13:46:13
ler:ServiceController) [Start-Service], ServiceCommandException
Error 13:46:13
+ FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Comman
Error 13:46:13
ds.StartServiceCommand
Fatal 13:46:13
PowerShell script returned a non-zero exit code: 1
Tentacle version 2.6.0.778

Rob_Sanders · 6 March 2015 02:59

Forgot to add the variables scoped in the log file:

The following variables are available:

[EnvironmentName] = ‘production.tga.gov.au’
[EnvironmentNameBasic] = ‘Production’
[MassTransit] = ********
[MassTransit.InstallDir] = ‘D:\Services\MassTransit’
[MT.Service.Dependency.Name] = ‘MassTransit.RuntimeServices’
[MT.Service.Identity.Password] = ‘********’
[MT.Service.Identity.Username] = ‘svc_mt_consumer’
[Octopus.Action.EnabledFeatures] = ‘Octopus.Features.CustomDirectory,Octopus.Features.ConfigurationVariables,Octopus.Features.ConfigurationTransforms,Octopus.Features.WindowsService’
[Octopus.Action.Id] = ‘96ab8f23-df2c-4ae0-a647-c82d6ea63f35’
[Octopus.Action.IsTentacleDeployment] = ‘True’
[Octopus.Action.Name] = ‘MassTransit.RuntimeServices’
[Octopus.Action.Package.AutomaticallyRunConfigurationTransformationFiles] = ‘True’
[Octopus.Action.Package.AutomaticallyUpdateAppSettingsAndConnectionStrings] = ‘True’
[Octopus.Action.Package.CustomInstallationDirectory] = ‘#{MassTransit.InstallDir}’
[Octopus.Action.Package.DownloadOnTentacle] = ‘False’
[Octopus.Action.Package.NuGetFeedId] = ‘feeds-builtin’
[Octopus.Action.Package.NuGetPackageId] = ‘MassTransit.RuntimeServices’
[Octopus.Action.Package.NuGetPackageVersion] = ‘1.0.0.397’

Paul_Stovell · 9 March 2015 00:30

Hi Rob,

We found and fixed a few bugs related to passing passwords to sc.exe that have characters like #, $, { or " in them, which will be in the Octopus 2.6.4 release coming soon. For now, assuming your password has those kinds of characters, you might have to change the password.

Paul

Rob_Sanders · 9 March 2015 22:04

Hi Paul,

I had to “hard code” the password into the Process item and use the same pwd in all environments (obviously not ideal). Will look for the new version, but the problem is temporarily resolved in the meantime.

Cheers,

Rob

maurociaccio · 2 April 2015 14:31

Hi,
Thank goodness that I found this post as I could not understand what the problem was.

Can you please confirm which version of OctopusDeployServer this was fixed in?

Cheers
Mauro

maurociaccio · 2 April 2015 14:53

Hi,
Sorry, just to clarify, I ask about the version because in this other post Vanessa said that no fix would be put in place.

http://help.octopusdeploy.com/discussions/problems/24111-special-characters-in-custom-account-password-seems-to-pass-invalid-characters

Thanks

Paul_Stovell · 6 April 2015 21:20

Hi,

I believe a couple of fixes were made, in 2.5.12 and 2.6.0. The latest 2.6.4 release will include the fixes.

Paul

bcall · 24 November 2015 04:10

We have no special characters in our password but are running into issues with the variable binding for a custom service password. It works fine in one environment but in another it does not. All the other scoped variables work fine and everything from the logs we can see looks like it should be grabbing the right password but is not. Any suggestions on what we should do? For the moment we had to make the password the same across multiple environments which is not ideal.

We are running 3.0.18.2471. Is this a known issue that has been fixed?

henrik · 24 November 2015 06:51

Hi,

We have the following bug that is related to IIS App Pools and passwords with special characters causing issues for customers. I’ll make a note in there to also look at your scenario.

Thank you and kind regards,
Henrik

bcall · 24 November 2015 07:31

If I were to guess what is happening it appears that maybe the password for a custom user on a service gets evaluated and stored for the first environment you deploy to and it doesn’t get reevaluated when you promote to another environment even though you have a different variable scoped for that environment.

I don’t presume to know your code or if that is possible, it is just what it appears to be doing.

I’m new enough to Octopus to think maybe I’m doing something wrong but every other context specific variable I’ve setup works flawlessly except for in this one case. So I’d really like to confirm if it is a bug or not. If there is anything I can do to help or more info you’d like let me know. Thanks!!!

henrik · 25 November 2015 03:53

Hi,

We’ve done a few fixes to password fields, sensitive variables and custom expression for Windows Services and IIS App pools that may correct this issue for you, so if you are in a position to upgrade to 3.0.24 or later this issue may be resolved.

Thank you and kind regards,
Henrik

Jon_Hughes · 1 December 2015 03:40

Hi Henrik,

We are running into this issue with a create scheduled task step (from the community library). We have a variable containing the password that is scoped to each environment, and the password configured for the step is bound to that variable (custom expression #{MyPasswordVariable}). After deploying to the first environment, each subsequent deployment to other environments uses the password from the first environment, but all the other scoped variables are changed correctly. We are already running 3.0.24. I have checked the release notes up to the current version and it doesn’t appear that this issue has been fixed?

henrik · 2 December 2015 05:17

Hi Jon,

Thanks for reporting the issues you are having, I’ve added it to #2169 to be investigated.

Thank you and best regards,
Henrik

stellerm · 6 July 2016 12:48

I’m having the same issue. I’m running 3.2.1. I am using a variable for the password since it is different per environment. My variable values are only upper and lower case letters and numbers. I am using the “IIS App Pool - Create” step template found in the Octopus Deploy Library. I keep getting the 503 Service Unavailable error after a deploy. I remote into the servers and reenter the password for the account and it works as expected. Has there been any movement on this issue item?

henrik · 7 July 2016 02:41

Hi,

We made some significant changes to how we work with sensitive variables in version 3.3.0, are you in a position where you can upgrade to this version (or later) to see if your issue has been resolved?

Thank you and best regards,
Henrik

stellerm · 7 July 2016 12:31

I just talked with our server group and they are going to upgrade to version 3.3.0. I will attempt the deployment again once this has finished.

Thanks for your reply. Hope this alleviates my problem.

ben_bedard · 25 October 2016 12:28

I am also encountering an issue with a password that I am using to install a windows service as a custom user. Here are my details.

Octopus Version: 3.3.27
Octopus deploy package step, with Windows Service feature selected under ‘Configure Features’.
Password entered in a prompt variable, marked sensitive & required.
I’ve ticked the custom binding checkbox beside the “Custom account password” field and entered my password variable reference as `#{Password}
Password has been scrubbed of potential special characters that may be causing the issue reported by other people with similar symptoms It’s alphanumeric, mixed case.

The service installs as expected, and while monitoring things as it gets deployed I notice the timestamps on the files change, I notice the service stop, but then Octopus exits with an error. I then test starting up the service manually after Octopus has completed attempting to deploy and start it up. It fails with this error in the event log “Logon failure: unknown user name or bad password.” I then paste the same password into the service Log On tab and the service starts successfully.

Below is the error message. To prove that my variables are available in this scope, I have a second variable for the user domain that you can see in the error below as obj="[REDACTED][REDACTED]". This domain variable is populated within the original error message.

The [REDACTED] service already exists, it will be reconfigured.
14:24:17Info
sc.exe config "[REDACTED]" binPath= C:\Program Files (x86)\[REDACTED].exe DisplayName= "[REDACTED]" depend= "/" start= "auto" obj= "[REDACTED]\[REDACTED] password= "************"
14:24:20Info
[SC] ChangeServiceConfig FAILED 1057:
14:24:20Info
The account name is invalid or does not exist, or the password is invalid for the account name specified.
14:24:20Error
sc.exe config failed with exit code: 1057
14:24:20Error
At C:\Program Files (x86)\[REDACTED]
14:24:20Error
\Octopus.Features.WindowsService_BeforePostDeploy.ps1:132 char:3
14:24:20Error
+         throw "sc.exe config failed with exit code: $LastExitCode"
14:24:20Error

14:24:20Error
    + CategoryInfo          : OperationStopped: (sc.exe config f...exit code:  
14:24:20Error
   1057:String) [], RuntimeException
14:24:20Error
    + FullyQualifiedErrorId : sc.exe config failed with exit code: 1057

![WindowsServiceUserCredsIssue.JPG](upload://qaIrm0WVFrdoOj69eg9pkbthWka.JPG)