NT users experience a steadily growing interlocking of their local computer and resources which can be reached only via the Internet. Microsoft puts emphasis on integrating the NT-desktop into their web browsers. The Internet Explorer 4.0 (which will be included into NT 5.0) realises a hybrid "browser-desktop" where Internet and intranet resources become indistinguishable.
A directory containing all relevant information is required in order to locate, manage and use these remote resources easily and fast. A number of such directory services already exist: Novell NDS, Microsoft NTDS, Banyan StreetTalk, DNS and X.500 to name a few. Access to each of these services is gained by special interfaces. Enabling applications to use the directory services therefore becomes a bit clumsy. The developer has to understand a number of concepts and interfaces, because every directory service has to be supported explicitly. The end-user as well likes to have one standardized access to his data. Therefore a single view upon the numerous directory services is desirable.
Microsoft calls its solution ADS (Active Directory Services). ADS offers this single view by encapsulating existing directory services and providing access to them through one well-defined interface. A so-called provider exists for each directory service which should be available via ADS. This provider implements the actual access to the data by returning an interface through which the selected directory object can be accessed. Providers are implemented as DCOM-objects.
For example, an ADS-enabled client wants to use a printer, of which only the fact is known that it is capable of printing PostScript-documents, is situated somewhere on the third floor of the building and is integrated into an NT domain. (For more information about the new domain concept in NT see below.) The program uses the ADS interface to query the appropriate directory service. The directory service calls the specified provider (in this case WinNT) which searches for the printer and returns a DCOM-object which contains an interface to the printer. The query has been processed without the client having to know details about the implementation and location of the directory service. (Fig. 1)
|
Fig. 1: The client on the right-hand side has to cope with a number of different directory interfaces; the left-hand side client uses ADSI and therefore sees only one interface. |
Like ADS a number of other recently released directory services are based upon X.500 [1]. X.500 has been specified by the CCITT in 1988 in order to provide "a collection of open systems which cooperate to hold a logical data base of information about a set of objects in the real world". Essentially, three core protocols have been defined: DAP (Directory Access Protocol), which is used to access the database from outside; DSP (Directory Service Protocol), which is used for inter-server-communication and DISP (Directory Information Shadowing Protocol). However, X.500 bases on a complete ISO/OSI-stack which kept it from being really successful.
In 1995 the Lightweight DAP (LDAP) was designed by Yeong, Howes and Kille [2] in order to "remove some of the burden of X.500 access from directory clients, making the directory available to a wider variety of machines and applications". LDAP implements complete directory access using a TCP/IP-stack, therefore simplifying the access to an X.500 directory. Only a subset of X.500 functions has been reused in LDAP. However, these functions can emulate the complete X.500 DAP functionality.
An LDAP directory contains one or more entries which consist of a number of attributes. Each attribute has a type (which is denoted by the name of the attribute) and one ore more values. For example, valid attribute types could be: "Name", "eMail" or "Favourite seats in the meeting room". The appropriate values are: Foo; foo@bar.co.uk; 1,2,5. Note that "Name" and "eMail" only have one value asserted, whereas "Favourite seats in the meeting room" has three values. Each entry has a special attribute called "objectClass", which designates the type of the entry itself. For example, "objectClass" could have the values "person", "organization" or "country". It is possible to define a scheme for each object class which contains all mandatory and optional attributes.
Every entry contains a distinguished name (DN), written in X.500 notation. The DN identifies an entry unequivocally; in the above example it would be something like "cn=Foo, o=bar, c=uk". Each particle of a DN is called RDN (relative DN) and denotes an entry in the actual directory node. "cn=Foo" denotes the example entry relatively to the directory node "o=bar, c=uk". The resulting tree structure, in which all entries can be found, is called DIT (Directory Information Tree).
LDAP implements a number of functions: add, delete, modify (modifies attributes and values), modifyRDN (renames entries) and search. Search is used to emulate functions which are defined in DAP but have not been taken over into LDAP. In order to narrow a search it is possible to use search filters. Both unencrypted and more sophisticated Kerberos authentification is supported. LDAP realises a lightweight and easy access to directories and is therefore the better choice for an Internet environment. Nowadays, LDAP does not only stand for an access protocol but for a whole lightweight, fast and scalable directory service.
A number of important software manufacturers regard LDAP as the core technology for their directory services: Banyan StreetTalk uses LDAP, Netscape Directory Server does and Microsoft ADS bases on LDAP as well [3]. Novell, too, offers a kind of LDAP-plugin for their directory server NDS; with the next release of IntranetWare LDAP will be completely integrated. Netscape Directory Server offers a complete LDAPv2 support, besides that Netscape is contributing to the specification of LDAPv3. In order to do so, Netscape hired Tim Howes, one of the fathers of LDAP. For the future, Netscape plans to integrate NT-domains into the Directory Server. Microsoft is engaged in the specification of LDAPv3, too. LDAP is used as a multi-purpose directory access protocol in the Active Directory Services which will ship together with NT 5.0. Because Microsoft wants to enable so-called "multi-vendor-solutions", not only a service provider for LDAP will be included, with which accesses on a high-level abstraction become possible, but also the standard C-API.
Microsoft ADS uses a data modell [4] which is very similar to the data modell used in LDAP: an entry is described by a number of attributes (which are called "properties" in ADS). As a nameservice a kind of DNS is used; Microsoft says that ADS "combines the best of DNS and X.500". Communication with other directory services is done via LDAP. This again points out that LDAP is regarded as "killer technology" by the big players in the directory game.
With the introduction of ADS the NT namespace will change completely. The concept of flat domains will be given up in favour of a hierarchical domain tree. By doing so, Microsoft ensures an increased scalability of the namespace. By treating all objects contained in a domain (users, computers, printers, disks, abstract resources) as entries in a directory, the domain itself becomes structured as a tree. The Primary Domain Controller will be replaced by a Directrory Server which provides access to all objects in the domain. The "tree-domains" are comprised in a "domain-tree"; an ADS namespace actually is a tree of trees (Fig. 2).
|
Fig. 2: Domain tree: NT 5.0 will implement a hierarchical domain concept |
LDAP is used both for the internal communication within this directory structure and any outside communication. Therefore the NT domain tree provides different views to different types of clients: an NT client sees an NT domain structure, an LDAP-enabled client sees an LDAP directory which can be browsed just like a usual DIT.
Each provider defines a hierarchy of objects which represents its structure and the respective namespace. Fig. 3 shows the WinNT hierarchy as an example. Within the hierarchy each object has a unique path, the so-called ADsPath. There are two notational formats: the DCOM format, which is required in order to maintain compatibility, and the URL format. It looks like <NamespaceID>://<ProviderPath>. For example, accessing a user in a domain called DOMAIN would be done with the following URL: WinNT://DOMAIN/User.
|
Fig. 3: The hierarchy of objects in the NT namespace |
Putting the domain tree, which is only a logical structure, onto the physical computer topology results in a strict separation of physical and logical network structure. This simplifies changing the physical structure, because all changes are transparent to the user.
For fast and efficiently searching for remote resources the so-called "Global Catalog" (GC) is used. The GC is similar to the "Directory Assistance" used in Banyan StreetTalk: every object which is located somewhere in the domain tree is registered with the GC, therefore enabling users finding objects in remote domains fast and easily by querying the GC instead of the remote directory. Since the GC is optimized for speed, Microsoft expects a significantly improved performance.
Another performance improvement is achieved by replicating the data contained in the directory. Provided that a very large number (around 99 %) of all operations performed on the directory are read operations, the average response time can be reduced by replication. Microsoft uses an optimistic strategy of server replication in ADS: updates of data are done by using any server where the data can be found; the directory service automatically performs the propagation to other servers which hold a copy of the data. Similar solutions can be found in distributed file systems like Ficus [7] or Coda [[lit.html 8]].
For guaranteeing the consistence of the data ADS does not use time stamps in order to avoid synchronization problems. Instead of this every object contains an Update Sequence Number (USN) which is similar to the LSID concept of Coda. The USN ensures that only the actual version of an object is replicated. Additionally, this method allows the detection of collisions.
Reintegration of changed objects takes place at the basis of their properties.
Objects will not be written in one pass, but divided in their properties and then written. This method reduces the probability of a collision. The following example should clarify this: an object possessing properties A and B will be changed by two users at the same time. User 1 change's property A and user 2 change's property B. When checking in the objects at a per object basis there would be a collision. By using properties when checking in, the collision could be avoided. Only when both users change the same property at the same time a collision would occur. ADS does not implement a collision resolution; the last change will overwrite all prior changes. Microsoft motivates this with the low collision probability in directory services. In fact, research done on Ficus and Coda has proven this to be true. If such a strategy is also efficient in practice has to be shown.
A further important change focuses on trust management. Today an administrator must explicitly build the relationship between Windows NT domains. In ADS every domain in a domain tree is automatically trustable. If one domain in a tree should not be trusted, this must be done by pointing it as not trustable. At one hand, this reduces administration overhead, on the other hand this could lead to security holes.
For further reducing administration overhead, administrative work could be decentralized. This relates to either the administration of security information and the administration of user databases. The tree structure of the new NT domain allows to make profiles for the whole tree, but allows additionally the administration of a domain by itself. A new feature in this context is the ability to make access rights on a per object and per property basis. For example, a user could be allowed to ask for the toner level at a printer but not for the paper level - if this should make any sense at all.
Especially when administrating users, this concept seems to be promising. It is possible to give a user who is responsible for the administration of parts of the system read and write access to the relevant user attributes without given him full administration rights. With upcoming NT 5.0 scripting languages like VBScript will be integrated in the operating system. By using the ADS Interface (ADSI) - and the easy access to all objects in a domain tree - many administration tasks could be automated.
ADSI is based upon Microsoft's Distributed Component Object Model (see DCOM box). ADSI divides objects in Active Directory Objects and so called Dependent Objects - both of course of the DCOM object type.
Dependent object contain functionality for their host objects; host objects are always Active Directory Objects. This way dependent objects divide and hide the functionality of Active Directory Objects. Additionaly, Active Directory Objects themselves are devided in two groups: Directory Leaf Objects and Directory Service Container Objects. As one can easily imagine Container Objects could contain other Active Directory Objects, while Leaf Objects are the leafs of the Active Directory Tree (see Fig. 3). Both, Leaf- and Container-Objects represent persistent objects of the underlying directory service.
ADSI defines the two basis interfaces IADs and IADsContainer as well as standard interfaces for the directory services named IADs<objectname>. These standard interfaces must be implemented by the provider of a directory service.
To get access to the features of DCOM all interfaces must be derived directly or indirectly from IDispatch. Additionally, Container- and Leaf Objects must support the IADs interface and Container Objects the IADsContainer interface.
This interface allows three access methods: direct call of an object method when the name of the method is known at design time. This calling method is named early binding.
Often the name of a directory object method is not known at design time because of the unknown structure of the directory service. Therefore Microsoft introduces a dynamic, name binding method for function name binding a runtime. For this method the basic interfaces "Put" and "Get" are defined. There is also a way to query methods from an unknown object; we will explain this later in this article. The third method to access functions at runtime uses OLE/DCOM and the IDispatch Interface. Using IDispatch with the name of the function returns a pointer to the function.
ADSI defines some important objects which are derived from these basic objects. Important object containers cover name spaces, localisation and organisation, domain and organisational units like computers and file services. Pre-defined leaf objects are users, groups, aliases, services, printers, ressources and file shares. Dependent objects for Active Directory Objects are collection- and membership objects for the enumeration of sets (e.g. users of a group), bytestream objects and objects for access control.
ADSI should enhance flexiblity when accessing directory services. Especially clients th at are not aware of the structure of the required namespace should be able to access objects and interfaces of such unknown objects. Therefore Microsoft enhances every object with a so called shema, through which a program could ask for properties, methods and their syntax at runtime. This way, sets of objects could be made available without knowledge of the underlying structure of the directory tree or the implementation of the service.
Imagine a common browser program: This program could traverse the name space beginning with the first object of the name space and read and change all objects and their properties. On the other hand, this technique allows a directory service provider to introduce new functions and properties not yet defiend by Microsoft in their standard objects. A small glimpse of the possiblities of script programming with ADSI with the help of Visual Basic could be found in the box.
Microsoft offers ADSI 1.0 [5] as an supplement for NT 4.0 integrating the providers LDAP, NDS, Netware 3.x and NT. Microsoft announces that ADSI will be integrated in NT 5.0 as; anyway, today's versions have left the beta stadium behind.
ADSI provides an easy way to access and to change system parameters. Nonetheless, is is not only useful for administrators. Using the common look at all system objects including computers, domains and networks, a user has an easy and comprehensible view at his computer environment.
Developers of Windows programs will profit most from the ADSI technology - with one method objects could be accessed from everywhere, no matter if they are NT, Novell or LDAP ones. It is easily to imagine that this advantage will be taken up by program developers soon and this will speed up distribution of ADSI.
Literature
[1] ADSI, Microsoft Corp. (http://www.microsoft.com/win32dev/netwrk/adsi.htm), 1997
[2] Component Object Model Specification (http://www.microsoft.com/intdev/com/comdocs.htm), Microsoft Corp., 1996
[3] The Directory: Overview of Concepts, Models and Service. CCCITT Recommendation X.500, 1988
[4] Lightweight Directory Access Protocol, RFC 1777, 1995
[5] Migrating to the Active Directory (http://www.microsoft.com/devnews/JanFeb97/nt4lead.htm), Microsoft Corp., 1997
[6] MS Strategy for Lightweight Directory Access Protocol, Microsoft TechNet May 1997
[7] R. G. Guy, G. Popek et al.; Implementation of the Ficus Replicated File System USENIX Conference Proceedings, Juni 1990
[8] M. Satyanarayanan et. al.; Coda: A Highly Available File System for a Distributed Workstation Environment; IEEE Transactions on Computers, Vol. 39, No. 4, April 1990
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 08/1997 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
