Configuring Octopus Deploy with Active Directory Authentication with Multiple domains

Hi Team,

We’ve been doing some testing on a setup that we want to run but we’re hitting a couple of issues, so I have a couple of questions.

To describe the environment;
We have at least 3 domains

  • Contoso
  • Customer1
  • Customer2

Customer1 & Customer2 has a one-way trust to Contoso , ie they trust accounts from Contoso . We want to be able to deploy applications to our customers using an Octopus Server that’s placed in the domain Contoso , which we can solve relatively easy, however, we’re having issues with allowing Customer1 & Customer2 to authenticate with the Octopus Server in the domain Contoso with their own user accounts located in Contoso.

With a setting of the command “Octopus.Server.exe configure --activeDirectoryContainer “CN=Users,DC=Customer1,DC=COM”” we’re able to search for accounts in the given directory even against the trust direction from the Octopus Server which is located in Contoso domain, however, while trying to login with added account we receive the following error

2019-10-17 10:26:04.5743 4104 38 WARN Principal ‘test2’ (Domain: ‘cust1’) could not be logged on via WIN32: 0x000006FB.

System.ComponentModel.Win32Exception (0x80004005): The security database on the server does not have a computer account for this workstation trust relationship

2019-10-17 10:26:09.4181 4104 36 WARN Principal ‘Test2@customer1.com’ (Domain: ‘’) could not be logged on via WIN32: 0x000006FB.

System.ComponentModel.Win32Exception (0x80004005): The security database on the server does not have a computer account for this workstation trust relationship

However, running your troubleshoot script from the server where Octopus Server is installed and as the service account returns no errors and shows the groups where the test account is a member in. To be clear, the Octopus Server is located in Domain Contoso & runs using service account CONTOSO\octo-svc

[System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.AccountManagement")
[System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices")
[System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.ActiveDirectory")

# Only uncomment the remainder of this line if Octopus is scoped to a specific container.
$principalContext = new-object -TypeName System.DirectoryServices.AccountManagement.PrincipalContext "Domain", "acme.local"#, "CN=Users, DC=acme, DC=local"

$principal = [System.DirectoryServices.AccountManagement.UserPrincipal]::FindByIdentity($principalContext, "ExampleUser")
# Get Authorized Users Groups. This reads inherited groups but fails in some situations based on security and configuration
$groups = $principal.GetAuthorizationGroups()
Write-Output $groups
# Try Number two. Reads just the groups they are a member of - more reliable but not ideal
$groups = $principal.GetGroups()
Write-Output $groups
$principalContext.Dispose()


So given all this, is there any way to make this work or is having a 2-way required in this scenario?

Hi There,

Thanks for getting in touch with us.

In your scenario, you would need a 2-way trust for this to work successfully. We have a section in our documentation that explains how you can use Trusted Domains and you can see this on https://octopus.com/docs/administration/authentication/active-directory-authentication#ActiveDirectoryauthentication-TrustedDomains.

If you compare the configurations, you could run the Octopus Service account as a service account from Customer1 OR Customer2 domain, but with your scenario, it needs to trust more than a single domain meaning you will be limited to using a 2 way trust for both domains with the service account needing to be run from your Contoso domain. The recommendation here would be to run the service account from Contoso and set up 2-way trusts for Customer1 and Customer2. You could then run the account under your CONTOSO\octo-svc and as 2-way trusts are in place, both Customer1 and Customer2 domains would trust inbound and outbound to Contoso but not with each other.

Another approach here would be to use a different authentication method for the users in your Customer1 and Customer2 domains and map these to local accounts in Octopus. For instance, you could use Google Apps for one customer and an Active Directory trust for another. You can see the full list of authentication providers on https://octopus.com/docs/administration/authentication.

Please let us know what you think and if we can help you further.

Thanks