ASP.NET中启用Windows集成验证,怎样在调用System.DirectoryServices下的组件时传递安全上下文,也就是说当前用户凭据,来实现权限管理-优快云博客

本文链接：https://blog.youkuaiyun.com/sinsel/article/details/1524004

在ASP.NET中, 启用Windows集成验证,这样我们就有了登陆网页的用户名和密码的哈希版本，但是我们是不能直接使用的，因为是密码的哈希版本，而不是密码本身。

比如：

System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(

" LDAP://22.11.21.232:389/OU=ou0000_team,OU=ou0000_unit,OU=ou0000_division,DC=bocadtest,DC=com " ,

" administrator " , " admin " ,System.DirectoryServices.AuthenticationTypes.Secure);

我们不能使用此构造函数来传入用户名和密码，所以只能把此ASP.NET运行线程的安全上下文传递过去，这样的话，我们需要在Web.config中，加入下面的标记：

这样的话，就可以把安全上下文传递下去了，使用下面的构造函数：

System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(

" LDAP://22.11.21.232:389/OU=ou0000_team,OU=ou0000_unit,OU=ou0000_division,DC=bocadtest,DC=com " );

这样就可以用用户的权限来操作active directory了。当然如果使用带用户名密码的构造函数也可以，因为用户名和密码已经不起作用。

资料：http://support.microsoft.com/kb/329986/zh-cn

如何在 ASP.NET 中使用 System.DirectoryServices 名称空间

察看本文应用于的产品

文章编号	:	329986
最后修改	:	2006年2月20日
修订	:	5.0

概要

介绍

本文解决了在以下情况下发生的问题：在 Visual Studio .NET 中使用 System.DirectoryServices 名称空间编写的应用程序能够在基于 Windows 的应用程序或命令行应用程序中正常工作，但是在 ASP.NET 中却不能成功运行。如果您遇到此症状，则表明问题与安全性有关。 System.DirectoryServices 名称空间使用 Active Directory 服务接口 (ADSI) 通过不同的 ADSI 提供程序与各个目录服务进行联系。

本文假定您作为应用程序设计人员，想要在 ASP.NET Web 用户的安全上下文下与目录进行联系。如果您不想这么做，或者您不想执行本文中列出的解决方案，则可以通过使用类构造函数向您的 DirectoryServices 代码传递凭据来变通解决这些问题，或者通过使用 Username 和 Password 属性来变通解决这些问题。

回到顶端

更多信息

什么是主令牌？

Active Directory (AD) 依赖于 Windows 2000 服务器的安全机制。要访问 AD 中的大多数信息，您必须在请求 AD 信息时向 Windows 2000 服务器提供凭据。您所提供的凭据必须位于主令牌中，主令牌仅表示 IIS 服务器有一个密码（而不只是该密码的哈希）要传递给 AD。

双跃点问题

双跃点问题是指 ASPX 页尝试使用位于 ISS 服务器以外的其他服务器上的资源时出现的问题。对于我们来说，第一个“跃点”是从 Web 浏览器客户端到 IIS ASPX 页；第二个跃点是到 AD。AD 要求主令牌。因此，IIS 服务器必须知道密码，客户端才可向 AD 传递主令牌。如果 IIS 服务器具有一个辅助令牌，则将使用 NTAUTHORITY/ANONYMOUS 帐户凭据。该帐户不是域帐户，它对 AD 的访问受到很多限制。

例如，当浏览器客户端使用 NTLM 验证向 ISS ASPX 页进行验证时，将出现使用辅助令牌的双跃点。在本例中，IIS 服务器由于使用 NTLM 而具有了密码的哈希版本。如果 IIS 转向 AD 并将凭据传递给 AD，则此时 IIS 所传递的是哈希密码。AD 将无法验证该密码，因此将改而使用 NTAUTHORITY/ANONYMOUS LOGON 进行身份验证。

另一方面，如果您的浏览器客户端使用基本身份验证向 IIS ASPX 页进行验证，IIS 服务器将具有客户端密码并可以生成一个主令牌以传递给 AD。AD 可以验证该密码并作为域用户进行身份验证。
有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

264921 (http://support.microsoft.com/kb/264921/) IIS 如何验证浏览器客户端

如何获得主令牌

如果 IIS 服务器有一个要传递的主令牌，则 IIS 服务器可以代表请求 ASPX 页的客户端向 AD 传递一个主令牌。要使用 ASPX 来获取主令牌，可以使用以下方法之一。

方法 A

当 Web.config 文件被设置为 identity impersonate="true"/ 和 authentication mode="Windows" 时，请使用具有下列设置的“匿名”帐户：

•	在 ASPX 页上，将安全机制设置为“仅匿名”。
•	清除“允许 IIS 控制密码”复选框。
•	将“匿名”帐户设置为域用户。

方法 B

当 Web.config 和 Machine.config 具有以下设置时：

•

Web.config 被设置为 identity impersonate="false"/ 和 authentication mode="Windows"

•

Machine.config 被设置为 processModel username=Domain/username,password=secret

•	如果 `identity impersonate="false"/` 位于 Web.config 文件中，将使用基本进程的凭据。当您提供域用户和密码时，IIS 就可以向 AD 传递主令牌。

没有主令牌时可能出现的错误

如果当您从开发计算机（Web 服务器）浏览代码时代码可以正常工作，但是当其他 Web 客户端访问页面时这些代码不能正常工作，则您可能会收到类似于以下内容之一的错误消息：

"Failed:System.Runtime.InteropServices.COMException (0x80005000):Unknown error (0x80005000) at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)"

"The specified directory service attribute or value does not exist"

解决双跃点问题

您可以使用以下方法之一来解决双跃点问题。

快速测试

要快速确定是否为权限问题，请按照下列步骤操作：

1.	将 ASPX 页安全机制设置为使用仅基本。
2.	使用一个客户端浏览到 ASPX 页，然后在得到提示时提供域凭据。如果一切正常，则可以得出可能是双跃点问题的结论。

测试代码

另一个适用于所有访问 AD 时出现的 IIS ASPX 问题的高效故障排除测试是：将 ASPX 代码从 ISS 环境中导出，然后将其作为一个脚本文件在 IIS 服务器上运行。按照下列步骤操作：

1.	使用您的浏览器尝试使用的域帐户登录到 IIS 服务器，然后运行这些代码。此测试将 IIS 服务器从环境中删除，有助于缩小问题的范围。
2.	要确定是否为双跃点问题，请为目录服务对象打开审核功能。有关如何对 Active Directory 执行此操作的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 232714 (http://support.microsoft.com/kb/232714/) 如何启用目录服务访问的审核功能打开日志记录功能后，将向安全事件日志中写入事件。

如果这是您的问题，您可以在安全事件日志中找到类似于以下内容的事件：

类型:成功审核
来源:安全
类别:Directory Service Access
事件 ID: 565
日期:3/27/2002
时间:3:21:41 PM
用户:NT AUTHORITY/ANONYMOUS LOGON
计算机:TESTDC
描述:
打开的对象:
对象服务器:DS
对象类型:user
对象名称:CN=Users,DC=corp,DC=com
新句柄 ID: 0
操作 ID: {0,68019232}
进程 ID: 264
主要用户名:TESTDC$
主要域:TESTDOM
主要登录 ID:(0x0,0x3E7)
客户端用户名:ANONYMOUS LOGON
客户端域:NT AUTHORITY
客户端登录 ID:(0x0,0x40DE417)
访问次数  READ_CONTROL 
   
特权  -
 
属性:

注意：已作为匿名用户与目录服务进行联系。这是因为 Web 用户的凭据不能正确地传递给目录服务。有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

264921 (http://support.microsoft.com/kb/264921/) IIS 如何验证浏览器客户端

283201 (http://support.microsoft.com/kb/283201/) 如何在 Windows 2000 中通过 COM+ 使用委派

有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

317012 (http://support.microsoft.com/kb/317012/) ASP.NET 中的进程和请求标识

回到顶端

ASP.NET 基本帐户

默认情况下，所有 ASP.NET 应用程序都在基本进程帐户 MACHINENAME/ASPNET 下运行。这是一个本地帐户，该帐户不能访问 Active Directory 中的对象。要使用传递给 IIS 的凭据访问 Active Directory，必须将 Web.config 文件修改为包含参数标识 impersonate="true" 和 authentication mode="Windows"。这两个参数的存在会导致 ASP.NET 在 IIS 传递给它的凭据下运行代码。

注意：这与经典 ASP 的当前工作方式非常类似。“高度隔离”或“进程外”(OOP) 应用程序实际上是在单独的 DllHost 进程中运行。DllHost 的基本进程是 IWAM_machinename。对此 OOP 进行调用时，它将模拟 ISS 对其进行身份验证的用户。对于 ASP.NET，页面也将在单独的进程中运行，该进程为 Aspnet_wp.exe。通过使用 identity impersonate 标记，应用程序设计人员可以控制是否执行模拟。有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

317012 (http://support.microsoft.com/kb/317012/) ASP.NET 中的进程和请求标识

在没有正确设置 ASP.NET 基本帐户时可能出现的错误

如果没有正确地设置 ASP.NET 基本帐户，则可能会收到以下错误消息之一：

Cannot contact the specified domain or domain does not exist

Logon Failure:Unknown Username or bad password

对没有正确设置 ASP.NET 基本帐户的错误进行故障排除

•

如果已将 Web.config 文件修改为使用模拟，但是您的 DirectoryServices 代码不能成功运行并且您收到同样的错误（请参见本文前面部分中提到的错误），则问题可能是由 IIS 中的默认行为造成的。默认情况下，IIS 中新的虚拟目录设置打开了“匿名身份验证”。要解决此问题，请打开 Internet 服务管理器并修改虚拟目录的身份验证方法，以清除“匿名身份验证”复选框。

•

尽管您是在基本 ADSI 接口上调用 SetPassword（或其他公开的方法）的 DirectoryEntry.Invoke()，您仍会收到以下错误消息，且返回的错误号不是 0x8000500D：

The Active Directory property cannot be found in the cache

预期的行为是随此说明一起返回错误号 0x8000500D。

例如：

COMException (0x80020006):The Active Directory property cannot be found in the cache

令人困惑的是此错误的原因（如错误号所表示的）可能与错误说明不对应。此错误的原因应由错误号来标识，而不是由说明来标识。一般情况下，应当使用错误号而不是说明来确定问题的解决方案。在本例中，错误号对应于 DISP_E_UNKNOWNNAME。

回到顶端

•

如果您的 IIS 服务器运行在域控制器或备份域控制器上，则默认的基本帐户可能无法正常工作，并且可能会出现错误。要获得更多信息以及这些错误消息的说明，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

315158 (http://support.microsoft.com/kb/315158/) FIX：ASP.NET 在域控制器上使用默认 ASPNET 帐户不能正常运行

•

如果您的基本 IIS 服务器没有在根网站进行读取、执行和列举的权限，则当您浏览网页时将收到一条错误消息。有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

316721 (http://support.microsoft.com/kb/316721/) PRB：浏览 ASP.NET 页时出现“Failed to Start Monitoring Directory Changes”（未能开始监视对目录的更改）错误消息

ADSI 架构缓存

ADSI 试图缓存 AD 中的架构。架构缓存可用于确定如何从属性缓存中读取属性。如果 ADSI 无法缓存该架构，它将使用该架构的 V2 版本。该架构的 V2 版本包含一组很少的属性。有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

251189 (http://support.microsoft.com/kb/251189/) INFO：查找由 ADSI 缓存的 LDAP 服务器架构

ADSI 将试图为每个进程仅缓存一次架构。在 Windows 2000 中，ASP.NET 在单个 aspnet_wp.exe 进程下运行。这意味着在关闭并重新启动 IIS 服务之前，不会再次缓存架构。

随后的架构缓存访问可能要依赖于满足以下条件的用户的用户权限：该用户第一个运行使用该服务器上的 ADSI 的 ASP.NET 页。

通常情况下，管理员会注意到应用程序可以通过在本地启动 Web 浏览器来正常工作。然后，网站将处于活动状态，并运行一段时间，直到服务器被重新启动或者 Web 服务被重新启动为止。

此时，ASP.NET 应用程序将停止工作，因为 ADSI 未能正确地缓存架构。当访问该网站的第一个用户不能建立用来正确缓存架构的凭据时，可能会发生这种问题。当用户遇到本文前面部分中所述的双跃点问题时，很可能会发生这种情况。您可能不会很快意识到已出现这种问题，因为您看不到以下任一错误消息：

Permission Denied

Property not Found in Cache

这可能是由安装 Active Directory 时所使用的方法造成的。提升域中的第一个域控制器时，DCPromo 向导会询问该域是否应与 Windows NT 4 兼容，或者仅与 Windows 2000 兼容。如果您接受“Compatible permissions with NT4”（与 NT4 兼容的权限）的默认值，则会向“Pre-Windows 2000 Compatible Access”（Windows 2000 之前的兼容访问权限）内置组中添加安全主体“所有人”。这一点很重要，因为在默认情况下，“Pre-Windows 2000 Compatible Access”（Windows 2000 之前的兼容访问权限）组对目录中的许多对象都具有“列出内容和读取所有属性”权限。由于匿名用户将作为“所有人”访问目录服务，因此匿名用户将在一个查询中返回许多个属性并将其加载到属性缓存中。

ADSI 所使用的架构存储在 schema 名称空间中的 cn=Aggregate 对象中。“Pre-Windows 2000 Compatible Access”（Windows 2000 之前的兼容访问权限）内置组和“所有人”主题都没有访问此聚合对象的权限。因此，架构信息是不可访问的。结果，在从服务器检索的属性缓存中有一个 ADSI 无法理解的属性。由于 ADSI 不能确定数据类型，您将收到在本文下一段中将要提到的错误。

ADSI 架构缓存不可用时可能出现的错误

您可能会收到错误。在重新启动服务器后，Web 应用程序不响应，并且您可能还会收到以下错误消息：

0x8000500C, "The property in cache cannot be converted from native datatype"

对 ADSI 架构缓存进行故障排除

如果您收到上一段中所提及的错误，则表明 ADSI 未能正确缓存 Active Directory 架构。要获得更多信息并要验证是否生成了该注册表项以及是否按照另一篇文章中所描述的内容写入该文件，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

251189 (http://support.microsoft.com/kb/251189/) INFO：查找由 ADSI 缓存的 LDAP 服务器架构

注册表项和解决问题的方法

•	如果这些注册表项存在，请删除它们，停止然后重新启动 IIS，然后浏览到该网页。
•	如果没有创建该注册表项或者没有写入该文件，则表明您没有从服务器下载架构缓存的权限，或者没有写入该文件和创建该注册表项的权限。如果它们被写入，则该页在下一次重新启动 IIS 之前应当可以正常工作。要解决此问题，必须解决双跃点问题。

回到顶端