When connecting to an LDAP server, there are three ways to connect:
1. Insecurely through port 389 (LDAP).
2. Securely through port 696 (LDAPS).
3. Insecurely through port 389 then negotiate TLS (StartTLS).
This PR adds support for the 3rd flow, letting dex connect to the
standard LDAP port then negotiating TLS through the LDAP protocol
itself.
See a writeup here:
http://www.openldap.org/faq/data/cache/185.html
Now that LDAP supports an `insecureSkipVerify` option, clarify that
`insecureNoTLS` is an extremely bad choice and as such we may drop
support for 389 in the future.
However, since we send plain text passwords from our frontend to our
backend, this probably gets us into a bigger conversation about dex's
TLS story. For example when terminiation is approporate. cc'ing
@dghubble for thoughts on how that might apply to our internal uses.
We probably want an overaching security doc at some point, but that
can be another PR.
Specify "DN" as attribute name to return, but will only work if not present in ldap.Entry.Attributes
Use when full DN is stored in groupSearch's userAttr
