Secure flag broken

[edermi]

When authenticating to a Domain Controller that enforces ldaps, windapsearch throws the following error:

./windapsearch -u 'user@dom' -d 'dom' --dc dc.dom -m computers
Password for [user@dom]: 
FATAL[2020-09-29T18:16:57+02:00] LDAP Result Code 8 "Strong Auth Required": 00002028: LdapErr: DSID-0C09027F, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839  package=windapsearch

Appending the --secure flag is supposed to fix this, but unfortunately it brings up a less helpful error message:

./windapsearch -u 'user@dom' -d 'dom' --dc dc.dom -m computers --secure
Password for [user@dom]: 
FATAL[2020-09-29T18:17:08+02:00] unable to read LDAP response packet: read tcp 192.*.*.*:43528->10.*.*.*:636: read: connection reset by peer  package=windapsearch

Taking a look on the wire, I noticed that --secure sends the data unencrypted (which is pretty bad):

Since the DC won't allow this, the connection is resetted. I took a look into the problem and decided to stop when I got to the point where go-ldap does the handshake on its own.

Currently, go-windapsearch is broken for scenarios where the DC enforces a secure connection, which is a real pity. In order to fix the issue, I'd like to propose to establish the tlsconnection using go's standard library before handing the connection over to the ldap library. I'll submit a pull request, but please note that I didn't do extensive testing. It works with DCs enforcing TLS now, and I'm still getting the error to use TLS in case of a missing --secure switch (so everything works as it is supposed to), but I did not perform any other tests, so you might want to try it on your own first.

[edermi]

Here you go: #9

[edermi]

Fixed