We’re running Octopus Deploy 2020.1.12 in a HA configuration in Azure. The Octopus Deploy service runs under a gMSA account. We would like to enable Azure Active Directory Authentication in our connection string to the Octopus database. This is to avoid having the connection password stored in clear text in the Octopus configuration file.
We are following Microsoft documentation which requires us to use the “authentication” keyword in the connection string.
When we try this it appears Octopus cannot support this keyword.
The provided connection string is not valid: Invalid value for key 'authentication’
We have tried both Authentication=‘Active Directory Integrated’ and Authentication=‘ActiveDirectoryIntegrated’
The adal.dll file was installed by the latest version of SSMS on the machine.
Please can you advise if this is a limitation in the current version of Octopus or if there is a way to get around this issue? If it is not supported are there any plans to support in the near future?
Unfortunately I believe that this is a limitation of Octopus Deploy right now and I’m not able to give a good workaround for securing the password, beyond hardening the octopus server itself. I can appreciate why you would want to eliminate any clear text credentials in your environment to prevent any potential for lateral movement etc in the event of a compromised server.
I’m currently exploring the latest .NET Core SQL Client to see if it supports AAD Integrated authentication, I know as at
2.2 they still hadn’t implemented it. Will keep you up to date with what I find.
All the best,
Following up, I can see that we’re a couple of patch versions behind the latest in the SQL client (we’re using
1.1.0 at the moment), but no movement from microsoft on supporting this feature.
Based on what I’m seeing of their project board and issues, integrated authentication still hasn’t been implemented yet. They have made a start on Interactive authentication, however I don’t think this would be a viable workaround in this case.
I’m sorry I don’t have better answers at this time, but as soon as the SQL Client version that we use supports it, I think we’ll have a better story for you here.
There has been some internal talk of supporting Azure Key Vault as a potential way to load credentials at runtime, but we’re still a way to go before we can commit to that also.
I hope this helps,
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.