I have two AD domains in my environment - we’ll call them A and B for the purposes of this post. There is a trust relationship between A and B. The Octopus server lives in B and all the developers workstations are in domain A. When a user logs in, they are using the AD creds from there workstation (domain A) and clicking the link “sign in with your Microsoft Windows domain account” - they do not enter a username / password. I am the admin and I set up the server a few months ago.
Up until today, there have not been any issues. But today, my domain creds for domain A were expiring and I changed my password. Since that point, NO USERS using domain A creds can log in. We can however, logon using domain B creds - if we specify them in the username/password field. But this creates a new user in Octopus and I don’t want to have to manage that.
So, my question is - was Octopus somehow using my domain A creds to connect and query AD? So that now that I have changed my password, it can no longer query domain A? I’m looking for some help trying to figure this out. I already looked at the troubleshooting guide here - http://docs.octopusdeploy.com/display/OD/Troubleshooting+Active+Directory+integration. It works when using domain B creds, but fails when using domain A. The error is: Exception calling “FindByIdentity” with “2” argument(s): "A referral was returned from the server.
Thanks for getting in touch. Octopus uses the credentials of the user account that the server service is running as when querying AD, so to answer your question, it would be using your credentials if the service has been configured to run as you. If this is the case, and you’ve changed your password, restarting the service would fail.
Would you be able to send some details of the network traffic during one of the failing login attempts? You can get this from the Network tab in the Developer tools section of either Chrome or IE. We’re not after complete network traces, just trying to confirm which URLs it’s trying to hit and exactly which one is failing.
Other customers have also reported issues when crossing domain boundaries (https://github.com/OctopusDeploy/Issues/issues/2335, https://github.com/OctopusDeploy/Issues/issues/1601, https://github.com/OctopusDeploy/Issues/issues/1000 are some examples). We’ve got some updates to authentication coming in the imminent 3.5 release, at which point the AD implementation will also be Open Source, and we’re currently setting up an AD environment with multiple domains to try to reproduce the issue and then find and prove a fix. In 3.5, if the user records in Octopus have been assigned an email address it will use that as a secondary check in case the UPN/username has changed, to prevent it from creating new users in that case. This was primarily to handle the case where domains are being migrated to the cloud and scenarios like that where UPNs change, but would also help in the scenario you’ve described.
So sorry we don’t have a solution yet, but we are actively working on it.