ASP.NET Login control is very slow making the initial connection to AD when authenticating to a different domain than the domain the web server is a member of. Problem occurs for the IIS server and when using with the Visual Studio’s built in web server.
It takes about 30 seconds the first time when attempting to use the control to connect against another domain. There is no trust relationship bewteen the web server’s domain and the other domains (attempted connecting to several different domains). Subsequent connections execute quickly until the connection times out.
Using Systernals Process Monitor to troubleshoot, there are two OpenQuery operations right before the delay to “C:WINDOWSasemblyGAC_MSILSystem.DirectoryServices2.0.0.0_b03f5f7f11d50a3aNetapi32.dll with a result NAME NOT FOUND” and right after the 30 second delay the TCP Send and TCP Recieves indicate communication begins with the AD server.
Things we have tried:
- Impersonating an administrator on the web server in the web.config;
- Granting permissions to the CryptoKeys to the NetworkService and ASPNET;
- Specifying by IP instead of DNS name;
- Multiple variations of specifying the name and ldap server with domains and OU’s;
- Local host entries;
- Looked for ports being blocked (SYN_SENT) with netstat -an.
- Nslookup resolves all the domains and systems involved correectly.
- TraceRt shows the Correct routes
Any Idea or hints are greately appreicated.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
we finaly fixed it with
connectionProtection=”None”
To turn off all attmepts to connetc on the secure port and only use 389.
We also had to specify the Connection username like “ad/bob” instead of just “bob” after the connetionProtection change.
Thanks,
Eric-
Method 2
I had the same issue. Following this advice seems to have sorted it.
https://elgg.leeds.ac.uk/webteam/weblog/15385.html
We had a custom user running as the app pool user, giving the user read access to this directory ‘C:ProgramDataMicrosoftCryptoRSAMachineKeys’ Sorts the issue.
Method 3
If you have the .NET 2.0 SP1 installed
just add the following to the
machine.config (of course all sites
will not check verisign any longer)
<runtime> <generatePublisherEvidence enabled="false"/> </runtime>
http://forums.asp.net/t/968778.aspx
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0