You should simply be able to define the ldap servers as ldaps://server:636 and it should encrypt the connection from MWG to LDAP.
If you want to enforce the certificate verification for this connection import the LDAP server's Cert into a list and select that list.
I tried that again -- still doesn't work. We get this message with a test user that works fine with [ip]:389
Error: Authentication failed
How is your certificate signed? Its very important that how you specify the LDAP server in the definition list that it match what you have on the certificate...
I doubt that the certificate was issued by IP address.
Check out my hints here:
Yes it is possible to use LDAPS without kerberos. LDAP is just another form of verifing a user has the correct credentials.
Previous versions of MWG only had abilities to pull group membership for kerberos authentications via LDAP, so it was necessary to setup a rule to pull the groups after Kerberos authentication using LDAP.
You would setup LDAP authentication just like you do any other method (kerberos, ntlm, ntlm-agent) see screenshot below, the example uses direct proxy auth as the example:
Hope this helps,
Cool. Thanks for the link. That's the guide we had been looking at -- we weren't sure if those LDAPS settings applied to "LDAP" instead of "Kerberos" in the User Database.
You're right -- we need to go back and look at some stuff with the cert.
To clarify -- We have authentication working with NTLM with no browser prompt for credentials. So that user experience is good.
Our MS sysadmins would prefer we use LDAPS, though, instead of NTLM. Before we mess around with the certs, we're testing with pure LDAP (port 389). That pure LDAP also works, but the browser prompts the user for credentials.
Is there anyway to get LDAP to work without the user / password prompt? In other words it somehow picks up the credentials from the PC? We're running XP and 7.
Any form of pure LDAP authentication directly to the browser WILL prompt for credentials.
Only NTLM and kerberos will not, as well as an SSL encrypted logon web form.
The LDAPS componenet we are speaking of in this thread is strictly for the encryption of lookups from the MWG to the DC itself. Not from the client to the MWG.
This is a function of how browsers work, not how MWG works. Browser only support NTLM and Digest (kerberos) for promptless and everything else is basicAuth (prompted and in the clear).
We have NTLM setup for the Authentication method and we've enabled "integrated authentication".
We've rolled out to a small test group -- about a dozen users. I'm noticing a lot of entries in the access.log with 407 status codes -- just over 20,000 so far today. About a quarter of the log is just 407 line entries.
407 is a proxy authentication status code -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Just about an hour ago I enabled (checked) the NTLM cache and set it to 100 seconds, but that hasn't stopped the entries or their frequency.
We're not experiencing any usage hiccups, but this doesn't seem like preferred behavior.
Is this normal, or is there something I should be tweaking?
1 of 1 people found this helpful
This is normal behavior.
Proxy auth operates as such:
1 (client) GET
2 (proxy) 407 (with methods supported: basic, NTLM, negociate)
3. (client) GET (with chosen method, lets say NTLM, NTLM [blah........token........blah], this is the negotiate step "type 1")
4. (proxy) 407 (with Challenge included for NTLM protocol, type 2)
5. (client) GET (with Authenticate step, type 3)
6. (proxy) 200 OK
NTLM authentication occurs in three steps (negociate, challenge, authenticate).
Hope this helps make sense of the logs.