只打了这么多：（，顺便送给【豆豆】

第21章 ADSI和AD介绍
本章讨论活动目录服务接口（Active Directory Service Interface，ADSI）和活动目录（Active Directory，AD），以及怎样用ASP访问目录服务器和使用它们所包含的信息。这里的目录服务实际上是指一种特定的数据库，该数据库能够有效的查找网络资源目录的一类信息。AD是一种网络资源目录，而ADSI是能够访问任何目录的Microsoft技术。其他公司也有类似的的技术，例如Sun公司的JNDI，但因本书的是针对Windows的，所以在此只讨论ADSI。
不要混淆ADSI和AD，它们是两种截然不同的技术。尽管如此，因为这两种技术确实是密切的相互作用,我们还是将他们放在同一章里讨论。AD是随着Windows 2000诞生的大而新的目录，包含了所有的安全性和管理本地的网域所需要的其他信息。另一方面，ADSI是一套Microsoft作为访问任何目录的方法而推出的COM接口，这意味着ADSI也是访问AD的通常方法。尽管AD只存在于Windows 2000 Server和Windows 2000 Advanced Server中，ADSI却适用于所有的32位操作系统：Windows 2000 Professional、NT 4.0和Windows 9x。
本章的目的是使读者掌握怎样使用ASP语言简单而又容易的访问目录，因此本章的重点是ADSI，但由于AD的重要性，本章也接触到AD的一些相关功能。
21．1  ADSI的用途
这里有两个相关的问题。前面讲过ADO，在技术上ADO符合Microsoft的UDA规范，本书第二部分里已深入讨论过。ADO能访问任何有OLE DB提供者的数据源。目录是另一种类型的数据源，为了使用目录，必须使用一种不同的技术——ADSI。为了理解为什么要使用ADSI，需要理解是什么使目录不同于一般的数据源，以及ADSI能做哪些ADO不能做的事。
ADO的确是一种通用的技术。原理上，Microsoft的目录是让ADO可以访问任何数据源，而不管这种数据源的内部结构。但又在本质上重视关系型的数据源。这没什么错，但着也确实意味着如果想访问分层结构的数据源，ADO可能不总是最有效的办法。因此引入ADSI，因为ADSI正是专门分层结构数据源而设计的。精心设计的ADSI使用户在浏览树状结构时感到比较容易，而ADO就没那么轻松。
上面提到的分层结构的数据源和目录，它们是一回事么？它们相似，但不完全相同。下面先讨论相同点，即它们都是树状结构，再讨论目录区别于数据库和数据源的特征。
分层结构的数据源是按树状结构组织起来的，对象包含着其他对象，与Windows的文件系统中的文件夹包含文件和文件夹一样，而多数目录也是这样的结构。
事实上，体会这一点最简单的方法是快速浏览AD的结构。图21-1是从adscw.exe中截取的, adscw.exe是一个通用目录浏览器，可用于任何基于ADSI的目录（包括AD）。adscw.exe是由ADSI某种原因SDK提供的。
图21-1中有很多我们将研究的内容，我们在后面在回来讲述，如果现在不能全看懂也不必担心。请注意左边点击树状结构，它是一个标准的树控件，清楚的显示了AD中数据的分层排列。以CN=Simon Robinson为例，这是作者在局域网上的帐号，它的父级CN=User。在目录用语里，父子关系称为包含关系。CN=User称为一个容器，包含了CN=Simon Robinson对象。在这个AD中，CN=User实际上包含了此域中所有的用户帐号，不过实际情况不总是这种。
同样，用户容器也被代表域的对象DC=TopOfThePops包含这。DC=TopOfThePops容易让人误解，因为域的全名是DC=TopOfThePops，DC=Frame，DC=com，对应于一个虚拟的URL：TopOfThePops.Fame.com（Windows 2000支持这样的域名，而任何NT4.0的机器只能识别第一部分的TopOfThePops）。不要为这些名字的格式而担心，这是AD专用的，你很快就会适应，CN代表普通名（Common Name），而DC代表域组件（Domain Component）。
最后，树中的域节点被LDAP对象包含。LDAP代表轻量目录访问协议（Lightweight Directory Aclearcase/" target="_blank" >ccess Protocol），这是一个访问目录的工业标准协议，该协议的引入表明了AD是与LDAP相联系的。后面将进一步讨论LDAP。
迄今为止，所做的工作指出我们正在存储大量的对象信息，并正在以分层方式管理这些信息。顺便提一下，这里所说的对象是通常意思下的，不是技术上的，在这里不指COM对象。AD提供了一个非常好的例子，展示了ADSI所能访问的目录的结构。下面将探讨AD的细节，并演示目录的典型结构。然后就可以学习如何用ADSI去得到和修改目录中的信息。
但首先，来看一下如何获得所需软件。
21．2     必需的软件
在这一节中，由于ADSI和AD需要的软件不同，我们将分别讨论它们。
Windows 2000集成了AD。如果你的计算机运行在Windows 2000下，并将其作为域控制器，则已经安装了AD，反之则不会。关键在于是否把Windows 2000作为域控制器。如果在一个域内的Windows 2000工作站，由一个NT4.0的主域控制器控制，也不会有AD。
ADSI也是Windows 2000操作系统中的一部分，但能够从Microsoft的Web站点上下载用于NT4。0和Windows 9x的ADSI。另外，可能需要ADSI SDK 来开发软件。无论正在用什么操作系统。都需要下载这个SDK。它包含了各种各样的头文件很文档。尽管编写ASP程序时，它不如用VB或C++编程时那么必须，但它包含了图21-1中使用的adsvw.exe实用程序。
下面将使用adsvw.exe进一步研究AD。adsvw.exe也叫做活动目录浏览器，这名字有些误导作用。这是一个通用的目录浏览器，可以检测任何ADSI兼容的目录，而不止是AD。活动目录浏览器是一个好工具，因为其本身使用ADSI搜集信息，并显示给我们。因此，我们看到的信息的格式恰恰就是用ADSI编程时所需要的。
正如前面提到的，adsvw.exe是ADSI SDK的一部分，可以从微软的WEB站点上下载。如果没有的话，我们建议下载一个拷贝，你会发现对于研究目录，它是非常有用的。
21．3     AD的内部结构
AD包含了一个域控制器管理一个域所需的全部信息。从这个意义上讲，它与NT4。0服务器中的域目录（domain directory）是一样的。所不同的是它符合LDAP标准。因为LDAP是工业标准，所以很容易编写用标准的API函数（包括ADSI）来访问AD的客户程序。相比之下，NT4。0上相应的数据库却是微软专用的，通过Windows API函数只能得到少得可怜的信息。实际上，根本不能把该数据库用作集中管理网络资源的目录，但AD可以。
另外，AD远比原有的NT4。0域目录强大。它连同WINDOWS 2000一起，支持下列概念：把域本身排列成域树（domain tree），或允许很多独立的树共享配置数据，形成一个域林（domain forest）。还允许把个人信息象操作系统使用的资料一样存储进去。
就AD中存储的信息而言，实际上有两个部分。缺省情况下，AD包含了管理一个域所需要的全部信息，如：计算机、用户和工作组帐号，以及相应的安全权限。另一方面，AD被设计成通用的目录，这意味着任何其他系统管理员认为有用的内容都可以存入AD。所以像用户帐号这样的信息也可能出现在薪金明细和公司组织结构下面。AD还有一套非常完善点击安全系统，由管理员分配细致的等级，决定谁具有对各式各样信息的读或写的权利。
但是，令我们感兴趣的还是AD的整体结构，我们将给出一个一般的目录例子。
21．3．1  目录里的对象和属性
需要理解的第一件事是：关系型数据库把数据存储在表的行和列里，而在目录里一个很重要的概念是对象，对象含有需要存放的信息。在图21-1的屏幕截图中，我们就选了一个用户帐号的对象。AD中的其他对象包括计算机、域和工作组等。稍后，当我们讨论WINNT决定ADSI提供者时将要碰到其他目录里面的对象，如服务对象和打印队列对象等。
不要把目录中的对象与COM对象（组件）相混淆，目录里的对象与COM毫不相干。它们有属性，但通常不具有方法。
实际上目录中通常除了对象没有别的，对象被排成层状。对象可以被认为是由许多属性组成的。
注意在这里我们不是在讨论COM自动化属性，仅仅是在讨论一条条的信息。一个属性包括属性和属性值。例如，上例中在AD中的用户帐号的属性如表21-1所示。
表21-1  示例对象的属性几其值
属性名    属性值
CN    Simon Robinson
AdsPath    LDAP：//CN= Simon Robinson，CN=Users，DC=TopOfThePops，DC=Frame，DC=com
SAMAccountName    Simon
Description    一段注释,可用adsvw.exe设置
Mail    Simon@Robinson.com
以上这些属性大部分是不言而喻的。CN代表普通名（common name），是访问对象时的通常名字。AdsPath是使用ADSI访问目录时，可唯一确定该对象的名字，很象一个文件的完整路径名，包含了该对象本身和目录树中所有在其上面的对象的名字。SAMAccountName是用户在域中用这个帐号注册时的提供名字。
表21-1展示的一个重要的概念，就是一个属性有两个部分：名字（如CN）和值（如Simon Robinson）。更准确的说是一个名字和一个或者一个以上的值，因为有些属性是多值的。可把多值性想象成一个值的数组。
顺便说一下，表21-1只是属性中的一小部分，如果安装了AD，在查看你自己的用户帐号时，将发现数量巨大的属性，其中许多还没有值，只是为某些系统管理员偶尔的需要而准备的。
当使用adsvw.exe时，可用屏幕右边的Properties列表框查看不同属性（见图21-1）。选中一个值的属性，他的值就在旁边的文本框中显示出来。如果想改变这个值，就在文本框中输入一个新值并单击列表框下面的CHANGE按钮。再点击APPLY按钮确认。
21．3．2  对象的类
到目前为止，我们已使用adsvw.exe查看了用户帐号对象，别忘了还有其他类的对象，例如专门针对计算机的对象。从这种意义上，一个用户和一个计算机（对象）的不同之处就是它们属性的数目和类型的不同。例如，选中图21-2所示的这个对象。
这是描述作者所在的域的域控制器的对象，这是一台名叫BIGGYBIGGY的计算机。它表示一台计算机，如果要检查它的属性，就会发现它的很多属性与用户对象一样，当然还有其他一些属性，这些舒心包含只属于计算机的信息。
对象的类型称作类。例如，在AD里，用户是对象类，计算机也是对象类。因用户和计算机是两个不同的类，所以它们能拥有的属性就不一样，在adsvw.exe里，选中的对象的类显示在右边顶上的信息中，在图21-1和图21-2中都可见。
类决定了对象拥有什么样的属性，特别是它决定了必有的和可选的属性。必有属性（MANDATORY  PROPERTIE）是某类中所有对象都必须有值的属性，可选属性（OPTIONAL  PROPERTIE）的值可能有但不是必须有。一个对象通常除了具有类所定义的必有属性和可选属性之外，再无其他属性。
21．3．3  容器和叶
前面已提到，目录树中可作为其他对象的父对象的是容器。而不能这么做的则是叶（LEAF）。一个对象是容器还是叶决定于它所属的类。一些类定义为容器而另一些则定义为叶。例如，在AD里，用户和计算机都是容器。图21-1和21-2中的信息中的两行说明了这一点。CONTAINER行说明它是不是一个容器，CONTAINMENT行说明它可成为哪些对象的父对象。
这类事情在大多数目录中被定义得很仔细，以确保用户在修改目录的内容时不会破坏目录树的结构。如果往目录中添加新的对象，必须把它放在规定的地方，符合目录规则，即哪些类的对象能包含哪些类的对象。当然还有其他的检查，如是否有足够的安全权限！
事实上一个对象是容器并不是说他必须包含其他对象，而仅仅从原则上允许这么做而已。例如，在AD里，所有用户帐号从技术上说都是容器，但在作者的用户帐号里，恰巧什么也不包含。
同样，你可能已经注意到目录结构和WINDOWS的文件系统很类似。它们都是同一种层式结构，文件夹在WINDOWS里有时候也称为目录（这种称呼是从UNIX系统移植而来的）。按照这钟相似性，文件系统的文件夹对应目录里的容器，而文件系统里的文件对应目录里的叶对象。但当心不要把这种相似性推得太广。在文件系统中，文件夹的作用仅仅是文件的容器，除了WINDOWS自动赋予的特定系统属性（如创建日期等）和关于谁能访问他们的安全信息外，并不真正拥有自己的数据。不能像网文件里存东西那样往文件夹里存大量的文本。相反在目录里，容器本身也是目录对象，有自己的一套属性。容器与叶唯一的不同之处就是容器可以包含其他对象。
21．3．4  模式
上面已看到了如何通过类来定义对象，以及怎样确定一个对象能拥有什么样的属性和是否是一个容器。这些规则连同其他相关信息，如属性的数据类型（例如，普通名是一个字符串并是单值的），以及其他任何关于值的范围的限制，并称为模式（SCHEMA）。需要说明的是，模式本身就存储在目录中。可能认为模式是目录的内部细节，且它的实现是目录的事。从某种程度上说这是对的。但有标准的途径去访问模式，这需要模式本身作为目录的一部分存储。
在AD里，模式被存储在ADSPATH为LDAP：//CN=SCHEMA，CN=CONFIGUATION，<DOMAIN NAME>的容器中,这里的DOMAIN NAME 是用AD的格式表示的用户的域名(见图21-2所示的屏幕截图).如果检测这个容器,将看到图21-3所示的屏幕截图..

原文转自：http://www.ltesting.net