通过访问活动目录覆盖

2021-09-06 来源：延安租房网

rectoryServices 使用户能够通过访问一些基本的用户管理功能。本文首先回顾了活动目录（AD）的有关概念，然后简要地讨论了实际的 rectoryServices名字空间本身，最后给出了可供我们在实际应用程序中使用的代码。

活动目录是什么？

在目前的络环境下，能够方便地控制对各个络设备的访问是非常关健的。在控制谁在何时有访问何种设备的权限时，需要有一整套方法，这些设备包括打印机、文件以及其他的局域或分布式络资源。AD能够提供这些功能，由于与操作系统的整合非常紧密，这意味着AD能够在非常低的级别上提供支持。

AD的工作原理

单地说，AD就是一个内容为所有络资源、分层次、面向对象的数据库。最顶层的对象一般是Organization (O)，在该组织单元（OU）之下是容器，最后是包含实际资源的对象。这种分层次的格式为系统管理人员创建了一种熟悉和易于管理的“树”。例如，如果指定一个OU访问一个实际的资源，这一权限也将被赋予包含在其中的对象。

如何创建AD？

在.NET Framework中，微软为我们提供了rectoryServices名字空间，它又使用了活动目录服务接口（ADSI）。

DSI是通过编程与许多不同的目录服务提供者交互的方式，也就是一种编程接口。

rectoryServices空间中的类能够与如下所示的活动目录服务提供者配合使用：

表1.1 AD服务提供者

在rectoryServices名字空间内，有二个主要的类： rectoryEntry和 rectorySearcher类。本篇文章不涉及这二个类的细节，需要注意的是， DirectorySearcher只能与LDAP提供者一起使用。

在使用DirectoryEntry对象时，每个对象都有一个模式。模型是对象条目的类型。例如，如果有一个User模式的DirectoryEntry对象，它就代表是一个用户。

在本篇文章中，我们使用了Windows 2000提供者(

用户管理

在本篇文章的例子中，我们使用rectoryServices名字空间创建一个数据访问层（DAL），执行一些非常基础的用户管理任务。DAL是对执行数据访问的真实的复杂性进行抽象的一种方法。例如，如果我们要编写一个访问Access数据库的DAL，就可以在对象中隐藏所有与有关的任务。当开发人员需要与数据库打交道时，只需要简单地使用这些对象，而无需关心特定的实现细节。开发者根本无需为操心，即使是以后决定升级到SQL Server，也只是需要改变DAL，使之适合新的数据库即可，其他的东西无需改变。

用户对象

我们建立的第一个对象用来表示任何给定用户的当前状态，该对象对User模式的DirectoryEntry类进行抽象。为了清楚起见，它看起来更象一个实际的User对象。

namespace DSHelper {

public class DSUser {

public DSUser(rectoryEntry user) {

mainName=th;

ername=;

ssword=ssword;

try {

llName=String(voke(\"Get\", new object[]

{\"FullName\"}));

scription=String(voke(\"Get\", new object[]