1 2 Previous Next 10 Replies Latest reply on Aug 23, 2012 2:34 PM by 0range

    SLDAP without Kerberos

    0range

      We're setting up our first appliance.  It's running 7.2.  In the Authentication Engine (User Database), we have LDAP setup on port 389 .  Some test users are showing as OK.  But we'd like to use secure LDAP instead.

       

      We have other apps on other devices using SLDAP (port 636) successfully.  The only guides I've found to do this on the MWG are to use Kerberos, which we don't do.

       

      So is it possible to do SLDAP without Kerberos?

        • 1. Re: SLDAP without Kerberos

          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.

          • 2. Re: SLDAP without Kerberos
            0range

            I tried that again -- still doesn't work.  We get this message with a test user that works fine with [ip]:389

             

            I tried

             

            ldaps://[ip]:636

            and [ip]:636

             

            Authentication:

            Error: Authentication failed

            • 3. Re: SLDAP without Kerberos
              Jon Scholten

              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:

              https://community.mcafee.com/docs/DOC-2682#Hints_on_using_LDAPS

               

              ~jon

              • 4. Re: SLDAP without Kerberos
                Jon Scholten

                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:

                 

                ldapauth.png

                 

                Hope this helps,

                jon

                • 5. Re: SLDAP without Kerberos
                  0range

                  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. 

                  • 6. Re: SLDAP without Kerberos
                    0range

                    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.

                     

                    Thanks.

                    • 7. Re: SLDAP without Kerberos

                      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).

                      • 8. Re: SLDAP without Kerberos
                        0range

                        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?

                         

                        Thanks.

                        • 9. Re: SLDAP without Kerberos
                          Jon Scholten

                          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.

                          ~jon

                          1 of 1 people found this helpful
                          1 2 Previous Next