Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
Michael Wojcik wrote: > very real risk of password compromise. (sspi is particularly bad > because it requires use of the user's domain password; compromise > exposes the user entirely. If pserver and sserver are used with That's completely incorrect. sspi uses the preexisting windows authentication token. In any modern configuration that's passing kerberos tokens (and encrypted SSPI is fully encrypted kerberos which is basically uncrackable). Even NTLMv2 is pretty nontrivial to crack over the wire.. (unlike NTLMv1 which is subject to dictionary attacks, but hardly anyone uses that). For sserver by default it uses self signed certificates which is perfectly fine for the purpose (which is to stop the trivially encrypted pserver passwords going over the wire in readable form). You can enable strict checking on the client but if you do that you must have a proper signed certificate on the server recognised by a CA listed in ca.pem (which you can replace with your own if you like). That's an advanced configuration - most people don't do that. Tony