LDAP Auth backend breaks on v0.8.3 for some configurations

[hugespoon]

Environment:

• Vault Version: v0.8.3
• Operating System/Architecture:
  Ubuntu 16.04 x86_64

Expected Behavior:
LDAP Auth backend should authenticate correctly.

Actual Behavior:

# vault auth -method=ldap username=myuser
Password (will be hidden):
Error making API request.

URL: PUT https://vault.mydomain.com/v1/auth/ldap/login/myuser
Code: 400. Errors:

* LDAP bind (service) failed: unable to read LDAP response packet: unexpected EOF

Steps to Reproduce:
Configure LDAP as follows:

Key            	Value
---            	-----
binddn         	CN=Admin,CN=Users,DC=mydomain,DC=com
bindpass       	BINDPASS
certificate
deny_null_bind 	true
discoverdn     	false
groupattr      	memberOf
groupdn        	OU=SSO,DC=mydomain,DC=com
groupfilter    	(|(memberUid={{.Username}})(member={{.UserDN}})(uniqueMember={{.UserDN}}))
insecure_tls   	false
starttls       	false
tls_max_version	tls12
tls_min_version	tls11
upndomain
url            	ldap://ldap.mydomain.com
userattr       	samaccountname
userdn         	OU=SSO,DC=mydomain,DC=com

Important Factoids:
I've been unable to reproduce this issue on v0.7.3 through v0.8.2. Only v0.8.3 seems to be at issue.

References:
This is the only recent LDAP related issue that I could find.
#3293

[jefferai]

Presumably your bind password is not empty? (as in, you're doing authenticated binds?)

[hugespoon]

Yes, I just redacted the bindpass.

[jefferai]

Any chance you can build from current master? We're not seeing reports from any other user on 0.8.3 and I looked at the updates to the underlying library and there isn't anything obvious, but there have been more updates between the version in 0.8.3 and now.

[snesbittsea]

FWIW, I am seeing this error as well on Vault version 8.2 while attempting to authenticate against a Samba 4.3.11 ActiveDirectory instance in an Ubuntu 16.04 x86_64 environment.

[jefferai]

I am relatively positive that this is a duplicate of #3656. Closing as there is more debugging happening there, but I believe this should be fixed in 0.9.1. If you are able to test the branch referenced in that issue that would be great!