第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．1ADSI的用途
這里有兩個相關的問題。前面講過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 Access 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示例對象的屬性幾其值
屬性名屬性值
CNSimon Robinson
AdsPathLDAP：//CN= Simon Robinson，CN=Users，DC=TopOfThePops，DC=Frame，DC=com
SAMAccountNameSimon
Description一段注釋,可用adsvw.exe設置
MailSimon@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中都可見。
類決定了對象擁有什么樣的屬性，特別是它決定了必有的和可選的屬性。必有屬性（MANDATORYPROPERTIE）是某類中所有對象都必須有值的屬性，可選屬性（OPTIONALPROPERTIE）的值可能有但不是必須有。一個對象通常除了具有類所定義的必有屬性和可選屬性之外，再無其他屬性。
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所示的屏幕截圖..