Ability to specify which domain AD should use for login


We’ve been trying to get AD to work since we bought an Enterprise license last week.
Our setup has 2 domain with trust enabled.
It seems that octopus always assumes the domain on which it is installed.
Using different approaches user@domain, domain\user, yeilds no results.
We can perform a login if we use a user from the same domain as octopus is installed on, but that is not good enough.
Therefore we would like the ability for force octopus to use a specific domain.
Commandline support as were available in one of the RC, should be enough I suspect.

Hi Christian - thanks for getting in touch. There are a few related things that can cause trouble here, to help narrow it down can you please let me know:

  • Are you upgrading from a 1.6 instance? and
  • Is the login problem primarily exhibited when trying to access the admin account?

It is possible you’re impacted by: https://github.com/OctopusDeploy/Issues/issues/597 - we’ve fixed this but haven’t yet made a build available. If it sounds like a possible cause, there’s a workaround described in http://help.octopusdeploy.com/discussions/problems/14705-administrator-login-with-domain-authentication-does-not-work#comment_31332567 that may help you forward.

Just a note, in multiple-domain scenarios with Octopus, DOMAIN\user logins are the required format - user@DOMAIN won’t apply.


Ive tried following those, using every combination.
Please note the following:

  1. I can install with the Manager setting an admin for either DOMAIN1.LOCAL or DOMAIN2.LOCAL without any problems.

  2. Octopus is installed on DOMAIN1.LOCAL.

Ive been switching back and forth between AD/UNP trying to get this to work.
Ive set the service to run as a dedicated AD user.
Only thing I have achieved, which indicates something is working corretly, is locking the user from DOMAIN1.LOCAL out of the AD, this user was configured to be the admin using the console swith you referred to.
I have not seen this behaviour when setting a user from DOMAIN2.LOCAL as admin.

My needs are very specific. Only users on DOMAIN2.LOCAL should be able to login.

I sense this has something to do with Octopus being on DOMAIN1.LOCAL, but thats just a guess, so its rather frustrating.

Stuff that got locked up but looked like something was right:

2014-02-05 14:44:49.9363   WARN  Principal 'octopus' (Domain: 'prod.local') could not be logged on via WIN32: 0x0000052E.
System.ComponentModel.Win32Exception (0x80004005): Logon failure: unknown user name or bad password
2014-02-05 14:44:56.5574   WARN  Principal 'octopus' (Domain: 'prod') could not be logged on via WIN32: 0x0000052E.
System.ComponentModel.Win32Exception (0x80004005): Logon failure: unknown user name or bad password
2014-02-05 14:46:00.8308   WARN  Principal 'octopus@prod.local' (Domain: '') could not be logged on via WIN32: 0x0000052E.
System.ComponentModel.Win32Exception (0x80004005): Logon failure: unknown user name or bad password
2014-02-05 14:46:05.1707   WARN  Principal 'octopus@prod.local' (Domain: '') could not be logged on via WIN32: 0x00000775.
System.ComponentModel.Win32Exception (0x80004005): The referenced account is currently locked out and may not be logged on to
2014-02-05 14:46:11.6472   WARN  Principal 'octopus' (Domain: 'PROD') could not be logged on via WIN32: 0x00000775.
System.ComponentModel.Win32Exception (0x80004005): The referenced account is currently locked out and may not be logged on to

Users from DOMAIN2.LOCAL simply get an exception of pricipal not found error and i have tried all combos XXXX\chmi, XXXX.local\chmi…:

2014-02-05 14:48:30.4832   INFO  A principal identifiable by 'chmi' was not found in 'pdc01.prod.local'
2014-02-05 14:48:43.2293   INFO  A principal identifiable by 'chmi@xxxx' was not found in 'pdc01.prod.local'
2014-02-05 14:48:57.1707   INFO  A principal identifiable by 'chmi@xxxx.local' was not found in 'pdc01.prod.local'

2014-02-05 14:47:54.1355  ERROR  Unhandled error on request: http://localhost/api/users/login : Logon failure: unknown user name or bad password.

System.Runtime.InteropServices.COMException (0x8007052E): Logon failure: unknown user name or bad password.

   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer()
   at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit()
   at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize()
   at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx()
   at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate)
   at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, String identityValue)
   at Octopus.Server.Web.Infrastructure.Authentication.ActiveDirectoryMembership.ValidateCredentials(String username, String password) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Server\Web\Infrastructure\Authentication\ActiveDirectoryMembership.cs:line 35
   at Octopus.Server.Web.Api.Actions.UserLoginAction.Execute() in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Server\Web\Api\Actions\UserLoginAction.cs:line 39
   at Octopus.Platform.Web.Api.Responder`1.Respond(TDescriptor options, NancyContext context) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Platform.Web\Api\Responder.cs:line 163
   at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
   at CallSite.Target(Closure , CallSite , Object , Object , NancyContext )
   at Octopus.Server.Web.Api.OctopusRestApiModule.<>c__DisplayClass5.<.ctor>b__2(Object o) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Server\Web\Api\OctopusRestApiModule.cs:line 47
   at CallSite.Target(Closure , CallSite , Func`2 , Object )
   at Nancy.Routing.Route.<>c__DisplayClass4.<Wrap>b__3(Object parameters, CancellationToken context)

I’d really hate setting users up manually and reinstalling Octopus as im allready deploying away.
Do you have any idea when the AD fix will be ready to test OR if you will allow us to force a specific domain using the console?

Hi Christian,

Using DOMAIN\user logins force the domain to be DOMAIN, since internally we parse out the domain and use this for both the principal lookup and the log-in function.

The AD fix currently due to be released only affects the admin command-line generated by the Octopus Manager app, so may not help here.

Running over the output you’ve provided, it looks like users from prod.local (Octopus being the example in the log) should have no problem logging in. Is there a non-service-account in this domain that you can test with, and send results?

For the pdc01.prod.local domain, using pdc01.prod.local\user is the correct format, the others won’t work in this case. For the logon to be successful, the domain has to be trusted by the domain of the server machine, and the account the Octopus server is running under will need to have permission to look up users in the target domain.

As a starting point, can users in the pdc01 domain log in interactively on the Octopus server machine?


Hi Nicholas

You’re right. I tried with another PROD domain user (PROD\username) and it can login.
By the way pdc01.prod.local is not a domain, its 1 of 2 servers where the AD stuff happens, pdc00 being the other one.
But i still cannot login with DOMAIN2\username.

However there might be an answer, where do you perform the authentication? On the server or client side?

You see, I CAN login to servers in the PROD domain using DOMAIN2\username, BUT i have to jump via another server. This is a deliberate security “feature” :S, to which im so accustomed that I forgot to mention it :frowning: , sry.
So there is trust, but you have to go via another server, which is restricted to specific users.
So if you guys perform client side authentication, then that might explain why I cannot login using DOMAIN2\username.

Any thoughts?

Kind regards
Christian Mikkelsen

Hi Christian,

We perform the authentication on the Octopus server (your credentials are sent to the server, and the server then tries to authenticate with AD, and returns a HTTP response with the result). Hope that helps,


So after a lot of detectives work by some of our brilliant ops people which went through all sorts of experiments checking logs, AD settings, server setup, firewall, fns etc, we ended up simply moving the server to DOMAIN2.
Its in no way ideal, but it will work since Octopus only communicates through 1 port as opposed to having open for remote powershell etc, so security wise its acceptable.
They claim the logs points to an issue related to the way Octopus authenticate to the second domain. They could see the request coming in but something was amist with the passwords / connection so the AD would reject it. This would not happen if the request came from first domain (in which Octopus was installed).
Im sorry I don’t have anything more specific, but it might be worth looking into. It could still also be a network thing, but then again, they verified that request WAS received by the AD…
Anyways, we are finally running with AD which makes me happy :).

Excellent, really glad to hear you’re up and running, thanks for providing all the info you could!


I’m having a similar situation. We have two domains. Let’s call them DomainA and DomainB. DomainA is what I’d like to authenticate on. Octopus Deploy Server is running on a server on DomainB.

When I turn on Active Directory authentication, I am presented with the link to “Sign in with your Microsoft Windows domain account”. When I click that link, I prompted by a basic authentication type prompt. When I provide my domain credentials with “DomainA\Jon.Doe” it acts like it is thinking for a bit, then redirects back to the login screen with no success or error message. Subsequent attempts at clicking the “Sign in with your Microsoft Windows domain account” link result in no prompt for credentials and an immediate redirect back to the login page.

I can provide a screencast of this if someone can email me about the problem. I might can also get logs from Active Directory from IT, but that might be difficult; they’re stingy.

In troubleshooting this, I launched the RavenDB interface in the same browser and was able to login with my DomainA credentials when prompted and view the Octopus Deploy data successfully. So I don’t think it’s something like AD is blocking this kind of communication.

Troubleshooting further… I was reading through this discussion:


And noticed someone said to run the server service as a domain account. So, I tried just running the server from command line as my domain user Octopus.Server.exe run and sure enough, domain authentication was working as expected.

Is this the only way to get it to work? Ideally I could run the server service as the local system account? …

Hi Donnie,

Thanks for getting in touch. I really wish I had a great answer that would fix this, but I don’t. The fact is, how AD trusts and authentication work is really dependent on your environment. It might be that Local System (which Octopus runs under) can authenticate against one domain, but doesn’t have permission to query role assignments in another domain, while you do. One thing we’ve learned supporting so many different AD setups is that there just isn’t a step-by-step guide we can give that will make Octopus work with every possible AD configuration.

It’s great that running as your user account works. Perhaps the next step would be to create a specific domain account that can be used by Octopus for authentication.


Thanks for the reply, Paul!

So I have a couple of questions:

  1. RavenDB’s AD authentication works from the same browser. It’s also running as the Local System, right? Why does it work, but Octopus Deploy doesn’t?

  2. I saw in 2.5.11 release notes: “1140 - Ability to specify an Active Directory container”. What’s this? Is that something I could use?

Hi Donnie,

I’ll start by saying we still don’t have a solution to this, but it’s something that’s on the list. The reason it works for Raven and not Octopus Deploy looks like a limitation in the way we handle AD authentication. As for the the feature “Ability to specify an Active Directory container” this addresses an issue when authenticating with AD containers are not in default locations and permissions prevent queries as a result. The container is the AD container on the store to use as the root of the context. All queries are performed under this root which can be useful in a more restricted environment.