Asp.Net登录控制与非可信AD域的初始连接速度非常慢

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.

ASP.NET登录控制在向与Web服务器所属的域不同的域进行身份验证时,与AD建立初始连接的速度非常慢。 IIS服务器以及与Visual Studio的内置Web服务器一起使用时出现问题。

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.

尝试使用控件连接另一个域时,第一次大约需要30秒。 Web服务器的域和其他域之间没有信任关系(尝试连接到多个不同的域)。后续连接快速执行,直到连接超时。

Using Systernals Process Monitor to troubleshoot, there are two OpenQuery operations right before the delay to "C:\WINDOWS\asembly\GAC_MSIL\System.DirectoryServices\2.0.0.0_b03f5f7f11d50a3a\Netapi32.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.

使用Systernals Process Monitor进行故障排除,在延迟到“C:\ WINDOWS \ asembly \ GAC_MSIL \ System.DirectoryServices \ 2.0.0.0_b03f5f7f11d50a3a \ Netapi32.dll并且结果名称未找到”之前有两个OpenQuery操作,紧接着TCP Send和TCP Recieves指示30秒延迟指示与AD服务器通信。

Things we have tried:

我们尝试过的事情:

Impersonating an administrator on the web server in the web.config;

在web.config中模拟Web服务器上的管理员;

Granting permissions to the CryptoKeys to the NetworkService and ASPNET;

授予CryptoKeys对NetworkService和ASPNET的权限;

Specifying by IP instead of DNS name;

通过IP而不是DNS名称指定;

Multiple variations of specifying the name and ldap server with domains and OU's;

使用域和OU指定名称和ldap服务器的多种变体;

Local host entries;

本地主机条目;

Looked for ports being blocked (SYN_SENT) with netstat -an.

查找被netstat -an阻塞的端口(SYN_SENT)。

Nslookup resolves all the domains and systems involved correectly.

Nslookup可以解决所有涉及的域和系统。

TraceRt shows the Correct routes

TraceRt显示正确的路线

Any Idea or hints are greately appreicated.

任何想法或提示都是非常适用的。

3 个解决方案

#1

we finaly fixed it with

我们最终修复它

connectionProtection="None"

To turn off all attmepts to connetc on the secure port and only use 389.

要关闭安全端口上connetc的所有attmec并仅使用389。

We also had to specify the Connection username like "ad/bob" instead of just "bob" after the connetionProtection change.

在connetionProtection更改后,我们还必须指定连接用户名,例如“ad / bob”而不是“bob”。

Thanks,

Eric-

#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:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' Sorts the issue.

我们有一个自定义用户作为app pool用户运行,为用户提供对此目录的读取权限'C:\ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys'排序问题。

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

如果您安装了.NET 2.0 SP1,只需将以下内容添加到machine.config中(当然所有站点都不会再检查verisign)

<runtime>
   <generatePublisherEvidence enabled="false"/>
</runtime>

http://forums.asp.net/t/968778.aspx

#1