Hi all, since we updated our on-prem Octo server to 2020.1.8 the ‘sign in with domain account’ on the Octopus login page does not work anymore. We have multiple domains, forested together. Currently if click on this button, users get a 404.
Is this something anyone else picked up after this upgrade or version?!
Thanks for getting in touch.
Sorry to see this bug has hit you:
Unfortunately, there is no fix for this at this moment in time. This issue was caused by upgrading from
.Net Full Framework to
.Net Core 3.1.
We have logged an issue with Microsoft and are still investigating.
There is a workaround which is to type in the credentials manually and use the “SIGN IN” button instead.
Sorry I could not bring you better news.
thank you for the reply, glad to know its nothing on our side. I will await further update on this fix. Thanks.
We are investigating some more leads in relation to this integrated sign-in issue. We would appreciate it if you could provide us with some more information to help us narrow down the problem:
- Are users on the same domain able to use the integrated sign-in?
- What authentication scheme is Octopus Server configured to use?
Thank you and I hope we can resolve this issue with your help.
Thanks for the mail. This is still an issue for us.
We’ve determined that there is an issue with the WWW-Authenticate headers that we are now sending post 2020.1.1. Instead of their value being
negotiate, ntlm we’re now sending
kerberos incorrectly. This is a deviation from how our product used to work, where we’d expect it to use negotiation and then fallback to NTLM if required. We are releasing a patch for it this week.
The other action you might need to perform is to set up a ‘host’ SPN on the windows server that hosts the octopus server application. We have moved to using http.sys for our directory services authentication provider plugin. We needed to do this to support other improvements to this code base. Unfortunately user mode authentication (which we previously relied upon) is not possible using http.sys - it only supports kernel mode authentication. As such, it is necessary to use a ‘host’ SPN.
In my test lab I have an octopus server on a machine called od.domain1.local and its website binding is http://od.domain1.local. This means that the call to
setspn that I needed to set, looks like this:
setspn.exe -S HTTP/od.domain1.local %COMPUTERNAME%
Please note that a server reboot is required after making these configuration changes. We tested this in IE specifically and the latest version of Chrome, Firefox will require some additional configuration listed on this site.
Thank you for your patience, I will let you know when we have released the patch.
Would I need to set this after the patch is releases or can I do this now already?
Please wait for the patch release, we will ship this today/tomorrow.
Good news, we’ve just released 2020.1.16 which should be available for download here: https://octopus.com/downloads - this contains the fix for the headers, however if you’re using kerberos you’ll still need to set the SPN as well.
We have some new documentation on that here, it is based on @frank.lin 's advice above regarding SPNs.
All the best,