Our company purchased and password management tool. It will change service account passwords once a day.
We deploy webapps and Windows services that use service accounts. How do we integrate with CyberArk?
We were thinking of retrieving the passwords at runtime from CyberArk but our company did not purchase the CyberArk API. Is there a way to ingest the password into an Octopus variable when the password is changed at CyberArk?
Thanks for getting in touch. This should be possible assuming you can trigger a script or command after CyberArk does a password update and that you store your usernames and passwords in Octopus variables. If these assumptions are true, then you should be able to script updates to variables (either at the project level or variable set level) using the Octopus API. The two most common ways to integrate w/ Octopus is to use our Octopus.Client NuGet package or via our REST API. The following documentation pages cover each of these approaches.
Hope this helps!
Thanks for the reply. That should work for us.
I have a follow up question. I seem to remember reading from you documentation that if you deploy to existing Windows service or WebApp it will continue to use the Windows/IIS settings. However, this only seems to work with Windows services. Am I doing something wrong? See below for further explanation.
I tested Octopus Deploy with existing Windows Services and IIS WebApps that use a domain user service account and these are my findings:
· Windows Service
o I can configure the Octopus deployment scripts to not provide a username/password and the Windows service will continue to use the existing credential after deployment. No issues here.
· IIS Web App
o I am required to pass a username/password parameter in my deployment script. If I remove the username/password from the script then Octopus will default to one of four choices: Application Pool Identity, Local Service, Local System, or Network Service. This is an issue.
Thanks for the reply. I can understand why this is important in your environment but I have to note that the fact that this works for windows services is more of a side affect than something intentional. That said, I do think you have a couple other options for web apps. You could take advantage of the ‘IIS6+ home directory’ package step feature which simply updates an IIS website to point to the new package location. This should leave the other settings as is. The other option is to explore our library of step templates at http://library.octopusdeploy.com/ and customise one if needed.
Hope this helps.