Why might LdapConnection.Bind() be slow? RRS feed

  • Question

  • User-916962509 posted


    I'm using the System.DirectoryServices.Protocols namespace (LdapConnection class) to bind to a Windows AD server. I'm using SSL (.SecureSocketLayer = true) and binding to port 636 on the AD server.

    On my development machine, I'm having no problems. The .Bind() method takes only a fraction of a second to bind to the server, and everything is well.

    However, when I deploy the application (it's a web application) to a server, the .Bind() method is slow. My code is like this:

                        HttpContext.Current.Trace.Write("Authenticate LDAP User point 3")
                        HttpContext.Current.Trace.Write("Authenticate LDAP User point 4")

    When I look in the trace file, it takes 13.x seconds to get between point 3 and 4. The x varies, but the time is always between 13 to 13.5 seconds.


    So, any ideas why the binding would be so slow from a server, but so fast from my dev machine? I'd appreciate some things I could check, like

    • Any components that may be on one PC but not another
    • Any configuration I may need to make on the AD server
    • Anything more detailed tracing I can run to find out which bit of LdapConnection.Bind() is so slow


    UPDATE: I have found that adding impersonation into the web.config and impersonating a domain user "solves" this problem and makes it very quick to bind, just like on my development machine. I'm still curious why this solves the problem though..  Is it something to do with the machine already having bound to AD to validate the impersonation credentials?



    Tuesday, November 18, 2008 6:50 AM

All replies

  • User-1254684073 posted

    I experienced a similar issue connecting to our Ad server, using the Forms Authetications stuff in asp.net.

    First Connection slow, then fast till it times out. 

    One thing I was told to do was to specify the ldapserver by IP instead of name incase it's a dns issue.

    It didn't help me, but might be worth trying. Currently I'm calling a function to connect to the server beforehand

    so it's ready for login, sounds pretty similar to your trick.




    Friday, January 16, 2009 12:22 PM
  • User-1254684073 posted

     Answer for my Issue:


    Wednesday, July 8, 2009 6:54 PM
  • User15393796 posted

    I was having the same problems as you bgs264 - the solution that worked for me is here:


    It seems enabling impersonation works because the IIS USR account has already access to this file, whereas the NETWORK SERVICE account doesn't by default.

    Sunday, November 15, 2009 11:54 PM