Migrating on-prem server to cloud VM - LDAP error

Legacy Authentication
1

Tried to add this to the “migrations” forum - no permissions :frowning:

We are migrating from our on-prem octopus instance an an Azure VM and have followed the steps here:

This fails on the new server because the old server had AD authentication but the new server will not. We get an error on the install script:

Error: ===============================================================================
Error: The server could not be contacted.
Error: System.DirectoryServices.AccountManagement.PrincipalServerDownException
Error: at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
Error: at System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
Error: at System.DirectoryServices.AccountManagement.PrincipalContext…ctor(ContextType contextType, String name, String container, ContextOptions options, String userName, String password)
Error: at System.DirectoryServices.AccountManagement.PrincipalContext…ctor(ContextType contextType, String name, String container)
Error: at Octopus.Node.Extensibility.Authentication.DirectoryServices.DirectoryServices.DirectoryServicesContextProvider.GetContext(String domain)
Error: at Octopus.Node.Extensibility.Authentication.DirectoryServices.DirectoryServices.UserMatcher.Match(String name, CancellationToken cancellationToken)
Error: at System.Linq.Enumerable.WhereSelectArrayIterator2.MoveNext() Error: at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 source, Func2 predicate) Error: at Octopus.Server.Commands.AdminCommand.AddAdminUser(IRelationalTransaction transaction, CancellationToken cancellationToken) Error: at Octopus.Server.Commands.AdminCommand.Start() Error: at Octopus.Shared.Startup.AbstractCommand.Start(String[] commandLineArguments, ICommandRuntime commandRuntime, OptionSet commonOptions) Error: at Octopus.Shared.Startup.ConsoleHost.Run(Action1 start, Action shutdown)
Error: at Octopus.Shared.Startup.OctopusProgram.Run()
Error:
Error: --Inner Exception–
Error: The LDAP server is unavailable.
Error: System.DirectoryServices.Protocols.LdapException
Error: at System.DirectoryServices.Protocols.LdapConnection.Connect()
Error: at System.DirectoryServices.Protocols.LdapConnection.SendRequestHelper(DirectoryRequest request, Int32& messageID)
Error: at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
Error: at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
Error: -------------------------------------------------------------------------------

I guess this is because the new server cannot see the on-prem AD controller.

What’s the recommended way to work around this? Remove AD authentication first? We’re a little unsure of the implications of this and the impact on our current octopus AD backed users. Since this is our live system we don’t want to mess up any security credentials that we cannot revert if the migration goes wrong.

Is there a way to remove LDAP authentication during the migration step?

Octopus Deploy version 2018.6.12

3

To answer my own question:

You need to enable Octopus built-in authentication first and you can then disable AD authentication in Octopus Deploy first via the setting option in the main app. You then need to change the password of every user as it’s likely that in-built octopus credentials will not have these.

As a test, try to login with the old AD user (e.g. user@domain.com) and the reset password. If this works correctly then you are running in Octopus built-in authentication. Backup the DB, restore on the new server, and LDAP integration will not be enabled so it should work ok this time.

4

Hi @g.bunce,

Adding to the conversation: When you change authentication providers in Octopus, it will do its best to match the new incoming identities with existing Octopus Users. The exact matching algorithm will depend on the new authentication provider you are planning to use.

For Google Auth, Azure AD, and other OpenIDConnect-based providers, email is the matching key.
For Active Directory, the key is the best possible combination of SamAccoutName, UPN, and email.
If you are moving to the built-in username/password provider, you will need to get each of your Octopus Users to create their own username/password combination before switching off the old provider.

Here is some more information on matching incoming identities with existing users.

Here is a new section I wrote describing how to change authentication providers.

Hope that helps!
Mike