System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable

Legacy Uncategorised
1

The LDAP servers in the company I work with appears to fail over frequently and when it happens Octopus Deploy 2.6.5.1010 (when configured to use Domain authentication) gets stuck, apparently because it uses the LOGONSERVER to perform all the authentication operations.

When this happens, the only solution is to restart the server (not the Octopus Deploy windows service) in order to have the machine authenticate against a new logon server.

Are there any solutions to this problem in version 2.6.5.1010? Is this a problem resolved in version 3.1?

See below a sample stack trace for the exception seen:

2015-10-25 06:13:08.6269 209 ERROR The server could not be contacted.
System.DirectoryServices.AccountManagement.PrincipalServerDownException: The server could not be contacted. —> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
at System.DirectoryServices.Protocols.LdapConnection.Connect()
at System.DirectoryServices.Protocols.LdapConnection.SendRequestHelper(DirectoryRequest request, Int32& messageID)
at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
— End of inner exception stack trace —
at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
at System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
at System.DirectoryServices.AccountManagement.PrincipalContext…ctor(ContextType contextType, String name, String container, ContextOptions options, String userName, String password)
at System.DirectoryServices.AccountManagement.SDSCache.GetContext(String name, NetCred credentials, ContextOptions contextOptions)
at System.DirectoryServices.AccountManagement.AuthZSet.get_CurrentAsPrincipal()
at System.DirectoryServices.AccountManagement.FindResultEnumerator1.get_Current() at Octopus.Server.Web.Infrastructure.Authentication.ActiveDirectoryMembership.ReadGroups(IEnumerable1 groupPrincipals, ICollection`1 groups) in y:\work\refs\heads\master\source\Octopus.Server\Web\Infrastructure\Authentication\ActiveDirectoryMembership.cs:line 154
at Octopus.Server.Web.Infrastructure.Authentication.ActiveDirectoryMembership.GetMemberExternalSecurityGroupIds(String username) in y:\work\refs\heads\master\source\Octopus.Server\Web\Infrastructure\Authentication\ActiveDirectoryMembership.cs:line 111

2

Hi!

Thanks for getting in touch. Unfortunately when Active Directory starts misbehaving we can’t do too much about it. The behaviour you’re seeing (need to reboot the server) is interesting. Typically the DNS details for the AD are cached by the .NET DNS cache quite aggressively depending on the DNS configuration, and AD failover isn’t picked up for a LONG time. The typical response is to restart the service and it will re-query DNS for the AD details and get the new server.

You’re right, in Octopus 3.1.4 we’ve implemented a more resilient Active Directory integration at the cost of longer security information caching.

My recommendation would be to try upgrading to the latest Octopus 3.1 release which should work a lot better in environments where Active Directory is unstable.

Hope that helps.
Mike

3

Ever since we upgraded to 3.2.19 this has not been an issue for us, please close this.

4

Hi!

Thanks for getting back and letting us know this has helped! It’s actually best if you close this issue yourself, otherwise it locks you out from adding future comments to this thread.

Happy Deployments!
Mike