Last post Nov 15, 2009 11:54 PM by luke.sampson
Nov 18, 2008 06:50 AM|bgs264|LINK
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
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?
Jan 16, 2009 12:22 PM|caladin|LINK
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.
Jul 08, 2009 06:54 PM|caladin|LINK
Answer for my Issue:
Nov 15, 2009 11:54 PM|luke.sampson|LINK
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.