I realize there is information in the Octopusdeploy docs for the subject matter; however, I am not able to get any of those to work properly. We were on 3.4.4 until yesterday morning when I attempted to upgrade to 3.7.8 and then 3.7.9. Because of another issue involving a bug in Calamari, we were forced to rollback to 3.4.4. Unfortunately, during this process, we lost the ability to sign in with our Microsoft Windows domain account. When we select the “sign in with your Microsoft Windows domain account” link, it opens a Windows Security dialog box. Entering our domain account credentials on this dialog box and selecting OK brings up a page with no content displayed. If we reload the page (it is now a URL like this: http://machinename/integrated-challenge?redirectTo=http://machinename/app), it once again presents the Windows Security dialog box.
If I enter the original URL for our Octopus site and enter my credentials in the format domain\username with the appropriate password, I am able to get in; however, we really want to have the “Sign in with your Microsoft Windows domain account” functionality restored. Any thoughts?
Thanks for getting in touch! Sorry to hear you’re having trouble with the integrated login. To help with troubleshooting and getting you back up and running as quick as possible, I’ll need a little more information on a couple of things.
When you did the rollback did you restore the database as well as reinstall the earlier version?
Could I get you to double check that the Octopus Deploy server service is running as the correct domain account? We’ve had some reports that the account can sometimes revert to running as Local System during downgrades. I’d expect this to impact the forms login as well as the integrated login, but is worth checking.
Related to this, are the users in AD in the same domain as the server and it’s service account? The challenge dialog you are seeing is usually typical of issues with the service account not having access to the correct domain.
Thank you, Shannon, for the quick response. As for our process of rolling back, we performed the steps located here: http://docs.octopusdeploy.com/display/OD/Upgrading+from+Octopus+3.x (please note the instructions are near the bottom of the page). So, yes, we did restore the backup of the database as instructed.
OctopusDeploy is still running as the service account we originally setup for this application. It did NOT revert back to Local System.
The users in AD are on the same domain (there is one user who is the exception; however, we have continually instructed him to log in with his credentials from the proper domain).
Is there anything else I can provide to help diagnose this issue?
Do you know if you had custom values for the webAuthenticationScheme or activeDirectoryContainer?
In 3.5+ some of the server settings get moved from the config file into the database (which was part of some fixes for config issues with HA environments and includes those 2 values). If you had custom values for the webAuthenticationScheme or activeDirectoryContainer they would have been moved to the database and the config file needs to be restored to it’s previous state as part of the downgrade. I’ve just realised this wasn’t documented on the upgrading page you linked to and have just updated it.