Master Thesis in Computer Engineering. Mälardalens Högskola. Integrating ABB Aspect Directory with. Microsoft Active Directory

Master Thesis in Computer Engineering Mälardalens Högskola Integrating ABB Aspect Directory with Microsoft Active Directory Henrik Steen<henrik.steen@linux.nu> Chen Yang <chen.yang@linux.nu> FILENAME: Thesis-010312-final.doc SAVEDATE: 2001-03-18 16:07 PRINTDATE: 2001-03-18 16:08

Summary With the introduction of Microsoft Windows 2000 Server edition, Microsoft delivers a directory service called Active Directory. According to Microsoft, Active Directory provides a powerful and easy-to-use directory service. Many Microsoft s products will support Active Directory in the future and Microsoft helps other software companies to develop products that support Active Directory. ABB has a vision called Industrial IT. Industrial IT is an attempt to use standard Information Technology together with their traditional industrial process expertise. To realize Industrial IT, ABB uses a concept called Aspect Object. To implement Aspect Objects, ABB has a special purpose directory service called Aspect Directory. Aspect Directory is developed by ABB and is the heart and soul of the ABB Industrial IT delivery. The purpose of this thesis is to examine the functionality of ABB Aspect Directory, Microsoft Active Directory and the possibility to integrate ABB Aspect Directory with Microsoft Active Directory. The emphasis of the thesis will be on integration at the API level. Our study is divided into two parts: an analysis and a prototype implementation. We have studied available books about Microsoft Active Directory and articles from the Internet. The documentation about Aspect Directory consists of internal documentation and documentation delivered together with the Aspect Directory software. The prototype tests how to integrate Aspect Directory with Active Directory by using Active Directory Service Interfaces (ADSI). It is integration at the API level. The prototype is written at ABB with COM technology in C++. We have studied several integrations strategies, Multi-directory Access, Synchronization Connectors, Join, LDAP proxy interfaces, Hub and Spoke, and Directory Consolidation. From our analyses, we think that all techniques dealing with information synchronization are inappropriate. Directory Consolidation is an attractive approach if the software is in its early stage of development. This leaves us with only one choice, Multi-directory Access. Our prototype implements Multi-directory Access. It is a proof of concept that an ADSI provider for Aspect Directory can be written without too much effort.

Table of Contents INTRODUCTION...2 OUTLINE OF THE REPORT...3 1 DIRECTORY SERVICES...4 1.1 What are directories and what are directory services?...4 1.2 Why do we need Directory Services?...4 1.3 Directory vs. Database?...5 1.3.1 Different problems with different services...6 1.3.2 Overlapping...6 2 ACTIVE DIRECTORY...7 2.1 Benefits of Active Directory...8 2.2 How does Active Directory work?...8 2.2.1 Domains and Domain Controllers...9 2.2.2 DNS Integration...9 2.2.3 Organizing Domains: Trees and Forests...10 2.2.4 Information model...10 2.2.5 Uniquely identifying objects (Naming Active Directory Objects)...11 2.2.6 Active Directory Schema overview...12 2.2.7 Finding information: Indexing and Global Catalog...13 2.2.8 Multi-Master Replication...14 2.3 The Active Directory API...14 2.3.1 ADSI (Active Directory Services Interface)...15 2.3.2 Lightweight Directory Access Protocol (LDAP) and LDAP API...19 2.4 Drawbacks of Active Directory...21 3 ASPECT DIRECTORY...22 3.1 Benefits from using Aspect Directory...23 3.2 How does Aspect Directory work?...24 3.2.1 Servers and Clients...24 3.2.2 Information model...25 3.2.3 Uniquely identifying objects...28 3.2.4 Object Types and Aspect Categories...30 3.2.5 Aspect Object Lifetime Management...33 3.3 The Aspect Directory C++ API...34 3.3.1 Object Manager...35 3.3.2 Object...36 3.3.3 Aspect...36 3.3.4 Aspect System Object...37 3.3.5 Implementation Binding...37 3.3.6 OPC properties...38 3.3.7 Interaction Hooks...38

3.3.8 Enumerators and Trackers...39 3.4 ABB Automation Model...41 3.5 Drawbacks of Aspect Directory...43 4 DIRECTORY INTEGRATION...44 4.1 Integration problems...44 4.2 Integration alternatives...45 4.2.1 Multi-directory Access...45 4.2.2 Synchronization...47 4.2.3 Meta-directory technologies...50 4.2.4 Information brokering...52 4.2.5 Directory Consolidation...55 4.3 Integration Summary...58 5 PROTOTYPE...59 5.1 Prototype Requirements...59 5.2 Prototype implementation...60 6 CONCLUSION...66 REFERENCES:...67 APPENDIX A, APPENDIX B, GLOSSARY...69 THESIS DESCRIPTION...72

Preface This report is the result of our thesis for a Master degree in Computer Engineering. With the introduction of Microsoft Windows 2000 Server edition, Microsoft delivers a directory service called Active Directory. When we first heard of Active Directory we immediately became interested in finding out more. Partly because of the way the market is dominated by Microsoft, Microsoft products are regarded as the norm, as the standard, and partly because we believe, that Microsoft has delivered interesting products lately. ABB has a vision called Industrial IT. Industrial IT is an attempt to use standard Information Technology together with traditional industrial process expertise. To realize Industrial IT, ABB uses a concept called Aspect Object. Aspect Object is described in detail later in the report. The basic idea is that you have two kinds of entities, Aspects and Objects. Objects are empty in terms of functionality, and act as containers of aspects. Aspects are plug-ins of functionality that can be added to an object. To implement Aspect Objects, ABB has a special purpose directory service called Aspect Directory. Aspect Directory is developed by ABB and is the heart and soul of the ABB Industrial IT delivery. ABB is the market leader (we are told) and Aspect Directory is the heart of the next generation system. We want to take a close look of Aspect Directory and compare it with the Microsoft Active Directory. It is also a fact that large APIs can be a nuisance for developers. What if the API used for Active Directory could also be used to interface with Aspect Directory? That would be a great benefit. Developers familiar with the Microsoft Active Directory API such as external computer consultants and third party system integrators could immediately interface with the system and be productive. In this report, we first examine the functionalities of ABB Aspect Directory and Microsoft Active Directory. Then we analyze the pros and cons of different methods to integrate ABB Aspect Directory with Microsoft Active Directory. The project also includes a small prototype to test how to integrate Aspect Directory with Active Directory by using Active Directory Service Interfaces (ADSI). It is integration at the API level. We would like to thank the following people for their help and support during out work: Administrative Supervisor: Mr. Ivica Crnkovic Professor in Software Engineering at Mälardalen University, IDt Email: <ivica.crnkovic@mdh.se> Technical Supervisor: Mr. Lennart Myrehed Senior System Engineer at ABB Automation Products, LAWF Email: <lennart.l.myrehed@se.abb.com> H.O.S. C.Y. 1

Introduction "We have an immense amount to do in graphics, in video, and in bringing a unified object approach to browsing and storing data. It s a deep problem in computer science. A deep, deep problem. We have too many stores of data today. We have file systems, message systems, directory systems, database systems and all sorts of different software that optimizes all those things. That is not going to cut it...users are going to need one integrated thing that hides all those differences. Bill Gates 1997 (Giants, ISBN 0-07-032934-6) The situation described by Bill Gates is about API mess and confusion involved in using all these different kinds of systems. The same problem is also applicable on directories. These are some examples of directories available today: Microsoft Windows 2000 s Active Directory Microsoft Windows NT Microsoft Exchange Novell NetWare 3.x Novell NDS SUN Solaris NIS The list is long, yet these directories are more or less based on standards such as LDAP (the Lightweight Directory Access Protocol). Some directories are developed for specific needs, like Aspect Directory, which was developed to support ABB Aspect Objects. These kinds of directories often have their own proprietary APIs and access protocols. Theoretically, the simplest solution to the problem (of having multiple Directories and APIs) is to have a single enterprise directory that holds all information about users, machines, network, and applications in the company. For many reasons, including political boundaries, this goal will not be achieved quickly if ever at most companies [16]. Today, most enterprises have one or more directories that are working just fine, and as we all know, If it isn t broken, then don t fix it!. Having one large directory that can accomplish everything is unrealistic, until that will happen the existing directory services and applications must be linked together to provide a consistent way to store, access, and manage their information. The purpose of this thesis is to examine the functionalities of ABB Aspect Directory, Microsoft Active Directory and the possibility to integrate ABB Aspect Directory with Microsoft Active Directory. Because this thesis should be done in 20 weeks, the emphasis of our work will be on integration at the API level. Our study can be divided into two parts: literature study and prototype implementation. Microsoft Active Directory is a new technology; therefore, there are not many books about it yet. During these 20 weeks, we studied many articles from the Internet. The prototype is written at ABB with COM technology in C++. 2

Outline of the Report The report is divided into the following main chapters: Directory Services This chapter describes directories and directory services in general. Active Directory In this chapter, we examine Microsoft Active Directory and the Active Directory API: o Active Directory Service Interfaces (ADSI). o Lightweight Directory Access Protocol (LDAP). The main purpose of this chapter is to understand the expected features of a standard-based directory. Aspect Directory This chapter introduces ABB Aspect Directory, Aspect Object, Industrial IT, and the Aspect Object Model. The main purpose of this chapter is to get understanding of ABB s concepts around Aspect Object as well as the features of the ABB Aspect Directory. Directory Integration Here we introduce different methods to integrate Aspect Directory with Active Directory. Prototype This chapter contains design and construction notes for a simple prototype, implementing the Active Directory Service Interfaces (ADSI) API. Conclusion This chapter presents the conclusion. Appendix Appendix contains all kinds of documents that are related but not directly necessary for the report. 3

1 Directory Services Before going into the detail about Aspect Directory and Active Directory, let s look at directory and directory services in general. 1.1 What are directories and what are directory services? Directory services can be many things. A phone book for example, can be considered as a directory service. Most databases in some form might be considered a directory. There are several definitions about what a directory is and what a directory service is [26]: According to the International Standards Organization (ISO) Recommendation X.500 The Directory Service : The Directory is a collection of open systems which cooperate to hold a logical database of information about a set of objects in the real world. In 1998, Netscape gave the definition of directory services as follows: A directory service is a service that provides information about people and resources to a client requesting information. Information may be a name, telephone number, e-mail address, application preferences, etc. The client may be a person or an application. Also, in Microsoft TechNet s Planning for a Global Directory Service (1998): Directory services are defined as repositories for information about network-based entities such as applications, files, printers, and people. Directory services are important because they provide a consistent way to name, describe, locate, access, manage, and secure information about these resources. Finally, Alan Lloyd defines directory services in his work, OpenDirectory (1998): The directory acts as a knowledge base and acts like a phone book for computing networks in which objects have user-friendly names. To summarize all these definitions, a directory can be considered as a place where information about people and resources are gathered, an information source to store information about interesting objects [20]; and a directory service can be considered as potentially a number of systems offering a means to easily locate information about people, place, and things in a distributed environment. People (employees, consultants, partners, etc), places (buildings, offices, etc) and things (computers, networks, documents, printers, etc) are the core of directory services [26]. A directory service differs from a directory in that it is both the directory information source and the services making the information available and usable to the users [20]. Directories generally have two main parts: a database to hold the information and one or more protocols that allow users to access the stored data. The database is typically distributed across more than one machine, and follows a set of rules called a schema that defines what kind of information it can store [4]. 1.2 Why do we need Directory Services? Using directory services brings many advantages to the enterprises, some of them are [2][20]: Simplifying management. Directory services provide a single and consistent point of management for users, applications and devices. Strengthening security. Directory services provide administrator with powerful and consistent tools to keep information safe from intruders. 4

Information distributing. Directory services distribute a directory across many computers in a network. Information replicating. Directory services replicate a directory to make it available to more users and resistant to failure. Scalability. Directory services partition a directory into multiple stores to allow the storage of a very large numbers of objects. A directory service is both a management tool and an end-user tool. As the number of objects in a network grows, the directory service becomes essential. The directory service is the hub around which a large distributed system turns [2]. 1.3 Directory vs. Database? Is a Directory a Database? Directories and databases have many things in common such as the same central theme of allowing access to stored data. However, directories have special requirements that differentiate them from databases. One of them is that directories are designed to be read-mostly [29]. The most used database today is the Relational Database. The following part is a short comparison between Relational Database Management Servers (RDBMS) and directories. There are enough differences between a database and a directory that they cannot be managed in the same way. The key characteristics of a database are [26][30]: Centralized. Centralized administration and storage. In some cases, there is limited replication to give copies of the entire database. Transactional. Relation databases support sophisticated transaction-based updates. Objects have a complex data relationship to each other. Relational, not hierarchical. Application or user-defined schema; no global requirements. Queries can be based on complex relationship between objects and this is the key benefit of the database, especially for relational systems. A directory cannot provide such services. With a relational database, you can also generate a report based on queries [30]. The common features of a directory are the following [26][30]: Centralized and/or distributed administration. It can be provided in a highly distributed manner. Objects are essentially independent in the directory, and linked into a hierarchy. There is a fixed core schema for naming basic types of objects and managing them in a hierarchy. The schema for separate objects in the directory is highly flexible and extensible. Easily replicated. Distributed administration is the key benefit of a directory, which cannot be provided by a relational database [30]. A directory is generally distributed across more servers than a database. This feature enables the directory to be made available anywhere on the network and supports the need for accessibility, performance, and availability [26]. This nature of directories also makes them inherently better at read requests as opposed to frequent updates [29]. Another important aspect in directories is the enforcement of a standard schema. Not all the directories have schemas, but most of them do. This enforcement enables the directory to be easily replicated and distributed, but it also is one of the most important focal points of any directory implementation. Despite this fact, the schema 5

can be easily extended without causing undue compatibility issues with other directory servers [26]. In addition, directories are designed to contain data that is concise and strictly relevant to the directory object. By contrast, databases are designed to hold large amounts of data per object that may or may not be directly relevant to the object. For this reason, directories don t usually implement the transaction or rollback schemes that regular databases require. If they are permitted at all, directory updates are typically simple all-or-nothing changes. Directories are turned to respond quickly to high-volume lookup or search operation [23]. 1.3.1 Different problems with different services Whenever there is a need to perform sophisticated analysis on data, and the relationship between elements of data is non-trivial, a relational database is a good choice. A directory would not work [30]. Examples: Accounting System Enterprise Resource Planning System There are two kinds of situation, where a directory is suitable and a relational database is not. The first is where distributed provision is essential. The second is where the open access to directory using open protocol and a core common schema enables integration of clients from multiple vendors around a common directory core [30]. 1.3.2 Overlapping Some problems can be solved with either a relational database or a directory, for example, when we want to store information about people. This kind of information can be stored in either a database or a directory. Problems with overlap occur where an enterprise has requirements to use both technologies simultaneously. For example, information about employees may need to be in both directories and relational database systems. However, how can we ensure consistency of both systems when updating? A simple solution is to run both services independently and duplicate data and management. The major problem with this is duplication of effort to correctly maintain the data, and operational inconsistencies that will arise [30]. A very interesting option is to produce a system that will do both. However, how should it be integrated? That s an interesting problem. Unfortunately, we didn t find much information about this problem. In chapter 4, when we examine integration between different directories, there are also some suggestions about integration between directories and database. However, this is not our focus. Therefore, we leave it up to the readers. If you have any suggestions, please contact us. All possible suggestions are welcome. 6

2 Active Directory Active Directory is the directory service for the Windows 2000 Server operating system. It stores information about objects on the network and makes this information available for administrators and users to find and use [1]. Many vendors build specialized repositories or directory services into their operating system and applications to enable the specific functionality their customers require. For instance, e-mail products include directory services that enable users to look up user e-mail addresses, and server operating systems use directory services for storing user account information, such as names and passwords, or configuration information for applications. Because these directory services are targeted narrowly at the needs of the application or operating system, and often lack standard-based interfaces, most companies have found that they are responsible for many different directories that cannot be managed centrally or interoperate easily with each other [8]. In a distributed environment, this problem is especially obvious, it is a problem for both end-users and administrators [19]. Microsoft believes that instead of multiple directories a better approach to manage different resources would be to have one directory service that everybody can use. A common directory service provides one place to store information, a common schema and naming conventions for that information, and a single point of administration [4]. According to Microsoft, Active Directory is created to meet all these challenges. Figure 1. Active Directory provides a single point of management for Windows -based user accounts, clients, servers, and applications [2]. Active Directory is an essential and inseparable part of the Windows 2000 network architecture that improves the domain architecture of the Windows NT 4.0 operating system to provide a directory service designed for distributed networking environments [2]. It is used in many different ways in Windows 2000 Server. The operating system itself uses it to store information about user accounts, printers, machines in the network, and much more. Windows Management Architecture relies heavily on Active Directory to locate server machines that contain application components and more [4]. Active Directory acts as the central authority for network security and as an integration point for bringing systems together and consolidating management tasks. 7

2.1 Benefits of Active Directory Microsoft believes that the introduction of Active Directory in the Windows 2000 Server operating system will provide many benefits for the enterprise s system. The following points are just some of them: Information security Security is fully integrated with Active Directory [1]. Active Directory centralizes authentication. Access control can be defined not only on each object in the directory, but also on each property of each object. In addition, Active Directory provides both the store and the scope of application for security policies [18]. Integration with DNS Active Directory uses the Domain Name System (DNS) as its locator service. DNS is an Internet standard service that translates human-readable computer names, such as seapr.abb.se, to the computer-readable numeric Internet Protocol (IP) address. This lets processes running on computers on TCP/IP networks identify and connect to one another [18]. Extensibility Active Directory is extensible [1], which means that administrators can add new classes of objects to the schema and add new attributes to existing classes of objects. The schema contains a definition of each object class, and each object class s attributes, that can be stored in the directory. Scalability Active Directory domains are hierarchical and virtually without resource limitation. This means that administrators can delegate authority within a smaller number of more manageable domains [14]. Active Directory includes one or more domains, each with one or more domain controllers, enabling you to scale the directory to meet any network requirements. Multiple domains can be combined into a domain tree structure; a singledomain network is simultaneously a single tree and a single forest [18]. Replication of information Active Directory uses multi master replication, which lets you update the directory at any domain controller. Deploying multiple domain controllers in one domain provides fault tolerance and load balancing [18]. Because each controller contains all the data for the domain, Active Directory access will continue even if one domain controller fails [14]. Interoperability with other directory services Because Active Directory is based on LDAP and other standards, it is possible to integrate Active Directory with other directory services and for third-party vendors to integrate their components with Active Directory [14]. Global catalog To facilitate efficient searching of Active Directory, all the objects and their frequently used attributes are stored in a partial replica of each Windows 2000 domain in a directory. This is the Global catalog, and it is built automatically during Active Directory replication [14]. 2.2 How does Active Directory work? Active Directory s directory service uses a structured data store as the basis for a logical, hierarchical organization of directory information [1]. Active Directory lets organizations store information in a hierarchical structure. This structure is made up of two types of objects: containers and leaves. Each container may contain leaves or further containers. A leaf, however, may not contain any other object. Active Directory also stores information in an object-oriented fashion [4]. Network elements are represented as objects. These objects can be assigned attributes, which describe specific characteristics about the object. This lets companies store a wide range of information in the directory and tightly control access to it. 8

2.2.1 Domains and Domain Controllers Windows 2000 s logical structure is built around the concept of domains introduced by earlier versions of the Windows operating system. But unlike earlier Windows versions, the term domain has been updated somewhat [4][31]: Windows 2000 Server requires each domain to have a Domain Name System (DNS) name. In Windows 2000, a domain defines both an administrative boundary and a security boundary for a collection of objects that are relevant to a specific group of users on a network. Domains can be organized into parent-child relationships to form a hierarchy. Active Directory is made up of one or more domains. Each domain must have one or (usually) more machines acting as domain controllers. Each domain controller contains a complete copy of that domain s Active Directory database. In Windows 2000, every domain controller can receive changes, and the changes are replicated to all other domain controllers. There are some operations, however, that are not performed as multi master operations because they must occur at only one place and time [31]. Active Directory uses a database system called the Extended Storage Engine (ESE) [4], and it relies on two different protocols to let clients find and access information in this database. To locate a domain controller, a client uses the protocol defined by DNS. To access the data stored in a domain controller s Active Directory database, a client uses the Lightweight Directory Access Protocol (LDAP). 2.2.2 DNS Integration Active Directory is tightly integrated with the Domain Name System (DNS). DNS domains and Active Directory domains use identical domain names for different namespaces [18]. The differences between them are [1][18]: DNS is a name resolution service DNS clients send DNS name to their configured DNS server. The DNS server receives the name query and either resolves the name query through locally stored files or consults another DNS server for resolution. DNS does not require Active Directory to function. Active Directory is a directory service Active Directory resolves domain object names to object records through requests received by domain controllers as LDAP searches or modifies requests to the Active Directory database. Active Directory clients send queries to Active Directory servers using LDAP. In order to locate an Active Directory server, an Active Directory client queries DNS. Active Directory uses DNS as a locator service, resolving Active Directory domain, site, and service names to an IP address. Active Directory requires DNS to function. Active Directory is integrated with DNS in the following ways [18]: Active Directory domains and DNS domains have the same hierarchical structure. DNS zones can be stored in Active Directory. Active Directory clients use DNS to locate domain controllers. In order for Active Directory to function properly, DNS servers must provide support for Service Location (SRV) resource records 1. The SRV RR is a DNS record used to map the name of a service to the address of a server offering that service [20]. The name of a SRV RR is in this form: <service>.<protocol>.<domain> Figure 2. Name form for a SRV RR. 1 SRV RR is described in RFC 2052, A DNS RR for specifying the location of services (DNS SRV). 9

In Active Directory, the LDAP service in each Windows 2000 domain is represented by an SRV record in DNS. That record contains the DNS name of a domain controller for that domain, which an Active Directory client can use to look up that machine s IP address. Once it s found the right machine, the client can use LDAP to access the Active Directory data stored on that machine [4]. Windows 2000 Server also supports Dynamic DNS (DDNS) 2 [20]. DDNS is an addition to the DNS standard. It defines a protocol for updating a DNS server with new or changed values dynamically. 2.2.3 Organizing Domains: Trees and Forests Domains with contiguous DNS names can be grouped into a domain tree. In a domain tree, domains are organized in a hierarchical structure. Every domain in a particular domain tree must share a common schema, and their DNS names must form a hierarchy [4]. Each domain tree is called by the name given to the root of the tree; hence, the tree in the figure below is known as the abb.com tree. Domains are subdivided into organizational units (OUs) for administrative purposes. This is also illustrated in the figure below. OUs are containers that can hold other objects. They form a hierarchical structure inside an Active Directory domain [14]. abb.com decrc.abb.com seapr.abb.com xxx.seapr.abb.com Figure 3. The abb.com domain tree. Multiple domain trees can form a forest. The domain trees in a forest do not form a contiguous namespace. They form a noncontiguous namespace that is based on different DNS root domain names. However, all trees in a forest share a common schema, configuration, and Global Catalog. The forest root domain is the first domain created in the forest. The root domains of all domain trees in the forest establish transitive trust relationship with the forest root domain. This sharing of common schema and configuration data, in addition to trust relationship between their roots, distinguishes a forest from a set of unrelated trees. Using both domain trees and forests provides developers with the flexibility of both contiguous and noncontiguous naming conventions. This can be useful in, for example, companies with independent divisions that maintain their own DNS names [1]. 2.2.4 Information model Like a number of other directory services (Netscape s Directory Server, Novel s NDS, Banyan s StreetTalk, etc.), Active Directory information model is based on Lightweight Directory Access Protocol (LDAP) standard [13]. Like DNS, LDAP is a standard defined by the Internet Engineering Task Force (IETF), in RFC 1777, and it s derived from the X.500 directory service. Active Directory supports both version 2 and version 3 of the LDAP protocol. LDAP is a communication protocol designed for use on TCP/IP networks. LDAP defines how a directory client can access a directory server and how the client can perform directory operations and share directory data [1]. Therefore, LDAP also defines the key characteristic of the information exposed using that protocol which implicitly defines the directory information model [13]. For more information about LDAP, see section 2.3.2. 2 DDNS is described in RFC 2136, Observations on the use of Components of the Class, Address Space within the Internet. 10

The Active Directory information model is based on the LDAP information model; therefore, in Active Directory data is organized in a hierarchy. Each node in the hierarchy (called an entry or an object) can be either a container or a leaf. An Active Directory object is a distinct, named set of attributes that represents something concrete, such as a user, a printer, or an application [23]. The attributes hold data describing the thing that is identified by the directory object. The kind of information that can be stored in a particular Active Directory database depends on the schema defined for that database. An Active Directory schema defines what object classes and attribute types that directory can contain. Microsoft defines a standard schema, but users and software vendors can also add new object classes and attribute types [4]. For more information about schema, see section 2.2.6. Some of the more interesting Active Directory object classes are [4][13]: Domain, representing a domain of Windows 2000 computers or servers. Organizational Unit (OU), specifying a sub-division of a particular domain. Its most important attribute is Organizational-Unit-Name. Computer, representing a machine in a domain. User, identifying a particular user within a domain. Its attributes can include Common- Name, User-Principle-Name, Address, Telephone-Number and many more. 2.2.5 Uniquely identifying objects (Naming Active Directory Objects) When storing millions of objects in Active Directory, the most important thing is to be able to find a particular one, which means that each object has to be uniquely locatable and identifiable. Every object in Active Directory has a Globally Unique Identifier (GUID), a 128-bit number assigned by the system at creation. The GUID, which is stored in an attribute, objectguid, is guaranteed to be unique and never changes even if the object is moved or renamed. However, there is another way to reference an object: The name. Every Windows 2000 domain has a DNS name, but DNS names aren t used to name individual objects in an Active Directory database. Instead, names defined by LDAP must be used [4]. In Active Directory, there are two kinds of names, which are used to identify each object. A Distinguished Name (DN) is the name used to uniquely reference an object in an entire Directory Information Tree (DIT). A Relative Distinguished Name is the name used to uniquely reference an object within its parent container in a DIT [14]. One of each object s attributes is chosen to describe that object s RDN, this attribute is called naming attribute. Different objects can use different attributes as the naming attributes. For example, an object of the object class User can use Common-Name attribute to identify itself, like CN=Per Person, while an object of the object class Organizational Unit uses Organizational Unit Name attribute, like OU=LAWF. 11

Since RDN uniquely identifies an object only within the parent s name scope, to access objects in LDAP namespace clients are required to provide DN. The DN is just a series of RDN that specify the complete path through the container hierarchy by which the object is reached. The figure below illustrates the components that make up the distinguished name of the user object Per Person in the dasuan.sw.seapr.abb.com domain. dc=dasuan,dc=sw,dc=seapr,dc=abb,dc=se ou=lawf cn=per Person cn=ann Annsdotter LDAP://cn=Per Person,ou=LAWF,dc=dasuan,dc=sw,dc=seapr,dc=abb,dc=se Figure 4. Distinguished Name and the complete path for the User Object Per Person. Active Directory organizes the information into directory objects (also called entries), which are organized into single hierarchy called directory information tree (DIT). Objects in Active Directory can be managed by using Active Directory Users and Computers. In Active Directory Users and Computers, objects are showed in a flat structure, which means an object belongs to the folder where it is created. For example, user Peter Peterson is created in OU Users. Then he can be added to group Manager in OU Sales. However, in folder Sales, under group Manager, you cannot directly see Peter Peterson, only when you see properties to group Manager. This makes it impossible to delete user Peter Peterson from OU Sales. This object can only be deleted from OU Users. 2.2.6 Active Directory Schema overview Active Directory Schema is the set of definitions for all classes, attributes, and syntaxes that can potentially be stored in Active Directory [18]. The Schema is stored in Active Directory. Schema definitions are themselves also stored as objects Class Schema objects (classschema) and Attribute Schema objects (attributeschema). This lets Active Directory manage class and attribute objects in the same way that it manages other directory objects. A classschema object Figure 5. Schema definitions are also stored as objects. An attributeschema object 12

To summarize the Schema implementation [23]: Instances of the classschema class are used to define every object class supported by Active Directory. An object class represents a category of objects, such as users, or printers. The definition for each object class contains a list of attributes that can be used to describe instances of the object class. User and Computer are examples of object classes in Active Directory. Per Person and Ann Annsdotter in Figure 4 are two objects in the directory that are instances of the object class User. Instances of the attributeschema class are used to define every attribute supported by Active Directory. For example, the User class might have an attribute called phonenumber. The Syntax defines the type of data that can be placed into an attribute. If an attribute is defined to be of the type Boolean, then it can store a value that is either True or False. Instances of attributeschema class and classschema class are stored in the Schema container. The Windows 2000 Server operating system provides a default set of object classes and attributes. It was understood that any good schema would never meet all the needs of different organizations. Active Directory schema is designed to be extensible. Administrators and applications can extend the schema by adding new classes and attributes or by modifying existing ones. The Active Directory schema can be updated dynamically. That is, an application can extend the schema with new attributes and classes and use the extension immediately. Schema updates are accomplished by creating or modifying the schema objects stored in the directory [20]. When changing schema, remember the following points [1][18]: Schema changes are global through the forest because the entire forest shares a common schema. Schema extensions are not reversible (although you can modify some attributes). Once a new class or attribute has been added to the schema, it cannot be removed. It can be deactivated. Disabling a class or attribute does not affect existing instances of the class or attribute, but it prevents new instances of that class or attribute from being created. You cannot disable an attribute if it is included in a class that is not disabled. The recommended way to extend the Active Directory schema is programmatically, through the Active Directory Service Interfaces (ADSI) [1]. 2.2.7 Finding information: Indexing and Global Catalog Active Directory can consist of many partitions or naming contexts. The DN of each object includes enough information to access the object using LDAP. Nevertheless, many times, the client does not know the DN of the object, or even worse; the client might not even know which domain that contains the object. To solve this problem, Active Directory supports attribute indexing and Global Catalog (GC). Attributes can be indexed that is, a certain attribute or combination of attributes can be used to uniquely identify a record. Attribute indexing decreases the time required to locate a record in a large database and hence makes searching on common attributes in a given domain more efficient [31]. By default, attributes that are searched often, such as cn, surname and so on, are indexed. Users and applications can also select other attributes for indexing. The Global Catalog (GC) is a catalog of a selection of the properties from every object in Active Directory that can be useful in global searches [14]. All domains in a domain tree or forest share a single GC, and the GC contains a partial replica of every object in those domains. The cache of an object in the GC includes only a subset of attributes in original objects the ones that are likely to be of forest-wide interest. The information about which attributes are cacheable in GC is configurable [13]. Microsoft defines various standard attributes as cacheable, but administrators and application developers can associate the same feature with other existing and/or any newly defined attribute. 13

2.2.8 Multi-Master Replication In order to improve data performance and availability, Active Directory supports data replicating. Unlike many other directories, which use master-slave model, Active Directory uses multi-master replication. Every domain controller has a read/write copy of the entire domain database. A client can update any copy of the information, and that change will be propagated to all other copies in all other domain controllers in this domain [4]. To resolve collisions resulting from simultaneous updates of the same content in two or more replicas, Active Directory uses a 64-bit value called Update Sequence Numbers (USN) instead of simple time-stamps. Sites Replication can also improve data performance. This is built on concept sites. Windows 2000 uses the term site to mean a collection of machines (servers, workstations, or both) that coexist on a fast network, i.e. a physical network in a particular location with good connectivity between all sections of that network [14]. Active Directory allows administrators to divide a single domain into different sites. Between sites, the network connection is slower. For example, a group of connected Ethernet networks might be a good candidate for a site. When a client finds a domain controller via DNS, that domain controller determines whether it s in the same site as the client. If it is not, it refers the client to a domain controller in the client s own site. Sites impact replication. In a typical scenario, replication will occur more frequently among the machines within a site than among machines in different sites. Administrators can control how frequently replication occurs, but since links between sites are typically lower bandwidth than those within a site, inter-site replication will almost certainly occur less often. In addition, to further improve performance, data replicated between sites is compressed so that fewer bytes need to be moved across slower inter-site links [4]. Active Directory uses the following replication protocols [1]: SMTP replication SMTP (Simple Mail Transfer Protocol) is only used for replication over site links (inter-site), and not for replication within a site (intra-site). IP replication IP (Internet Protocol) replication uses remote procedure calls (RPC) for replication over site links (inter-site) and within a site (intra-site). 2.3 The Active Directory API As discussed so far, Active Directory provides many services, but to be useful, there must be a way for applications to access those services. To allow this, Active Directory provides several application programming interfaces (APIs). This encourages the development of applications and tools that make use of the directory s services. Active Directory includes three major API sets [19][31]: MAPI Messaging Application Programming Interface (MAPI) is a messing API that is supported for compatibility with Microsoft Exchange Client and Outlook Address Book client applications. ADSI Active Directory Service Interfaces (ADSI) is a set of Component Object Model (COM) interfaces for manipulating and querying multiple directory services. ADSI supports multiple programming languages, including VB, C++, and C. ADSI also can be accessed by using Windows Script Host (WSH). LDAP C API The LDAP v3 protocol is described in RFC 1823. The LDAP API is a C language API to the LDAP network protocol. Because the MAPI is designed specifically for compatibility with Microsoft Exchange Client and Outlook Address Book client applications, we will focus on the more generic APIs, ADSI and LDAP. 14

2.3.1 ADSI (Active Directory Services Interface) ADSI is a set of generic interfaces to access and manipulate different directory services. ADSI allows developers using almost any language to access and manipulate objects on a server or in a directory service. Contrary to its name, it was written to be generic and extensible rather than specific to one operating system or directory. This means that developers can write code to access a variety of objects on various directories without the need to know vendor-specific library routines [14]. Why ADSI? Why is it necessary with a generic directory interface? Today it is common with a variety of different directories deployed within a single organization. Figure 6. The directory challenge [17]. Since it is difficult to change from multiple directories to an All-In-One directory, most companies have to live with that. Multiple directories in the organization pose complex challenges to users, administrators, and developers. End-users face multiple logons and a variety of interfaces to information across multiple directories. Administrators face the complexity of managing multiple directories. Each directory offers unique application interfaces. Shall developers choose a specific directory implementation or support multiple versions of their application? ADSI helps to solve these problems. ADSI is Open Directory Service Interface (ODSI), a component of Windows Open Service Architecture (WOSA). It is a set of COM programming interfaces intended to provide applications ability to access and manage multiple directory services using a single set of well-defined interfaces. This is accomplished by an open set of interfaces. Applications that are written for the ADSI API, can work with any directory service that offers an ADSI provider [17][13]. NetWare Bindery X.500 Notes NDS NTS DS SP SP SP ADSI SP SP Clients & Server The ODSI Solution Figure 7. The open solution [17]. ADSI object and ADSI provider The ADSI object model consists of ADSI objects and dependent objects. Clients manipulate objects with interfaces. ADSI providers implement the ADSI objects and their interfaces [17]. 15

The ADSI objects are COM objects that represents any item within a directory. An ADSI object is manipulated using one or more COM interfaces. Because COM interfaces are a logically connected set of properties and methods, each interface can be granted as a handle to the object that allows clients access to only one set of logical functions at a time. As illustrated in the figure below, the clients are concerned only with getting and using interfaces on an object, and not with the details of where and how the software of an object is implemented [23]. As the figure below shows there are two groups of ADSI objects: leaf objects and container objects. A container object encapsulates the container directory object and can contain other ADSI objects. A leaf object cannot container other objects; it encapsulates leaf directory objects and provides generic interfaces for accessing properties contained in the object. Active Directory Service Interfaces COM Object Container Object Client Applicaiton COM Object ADSI Objects Active Directory Leaf Object Figure 8. ADSI provider architecture. Clients are concerned only with getting and using interfaces on an object. In ADSI, the fundamental interfaces are [23]: IADs Object identification. As the fundamental interface required for all ADSI objects, IADs supplies access to properties that describe the object itself. It also provides access to the properties and methods that manage the object s data in the property cache. IADsContainer Object lifetime management and detection. ADSI container objects require this interface to manage object creation, deletion, copying and moving, binding, and enumeration. IADsPropertyList Object property management. The IADsPropertyList interface is used to modify, read, and update a list of property objects in the property cache of an object. You can use the enumeration method of this interface to find out all the initialized properties. This interface optimizes management of an object s data in the property cache. IADsClass The IADsClass interface is designed for managing schema class objects that provide class definitions for any ADSI object. IADsProperty The IADsProperty interface is designed to manage a single attribute definition for a schema class object. IADsSyntax The IADsSyntax interface specifies methods to identify and modify the available Automation data types used to represent its data. ADSI defines a standard set of syntax objects that can be used uniformly across multiple directory service implementations. 16

IDirectoryObject This interface provides direct access to directory service objects for non-automation clients. The interface enables access by means of a direct on-the-wire protocol, rather than through the ADSI property cache. Using the on-the-wire protocol helps to optimize performance. In place of the properties supported by the IADs interface, IDirectoryObject provides methods that support a subset of an object's properties and provide access to its attributes. Automation clients cannot use IDirectoryObject. Instead, they should use the IADs interface. IUnknown Basic COM object management. All COM objects must implement IUnknown. IDispatch Type library information and method invocation. This interface is required for all Automation objects. The following figure shows a piece of VBScript code, which uses the ADSI interfaces to create a user in organizational unit Agent and set the new user s Description. Dim adsagentou Dim adsmyagent Set adsagentou = _ GetObject( LDAP://ou=Agent,dc=secrete,dc=mycomp,dc=com ) Set adsmyagent = adsagentou.create( user, James Bonde ) adsmyagent.put Description, Agent 007, license to kill! Update some other properties adsmyagent.setinfo Figure 9. Create a user in Organizational Unit Agent and set the new user s description. In this example, Organizational unit Agent is a container. The variable adsagentou is bound with the OU object Agent in the directory structure by using VBScript GetObject. To create a new user in the container, the IADsContainer::Create method is used. The IADs::Put method is used to set a description for the user object adsmyagent. All modifications are performed on the property cache, when finished updating properties IADs::SetInfo is used to save the cached property values to the directory store. The following figure shows a piece of VB code that displays all Agent 007 s properties in a list field by using schema class definition. Dim adsobj as IADs Dim adscls as IADsClass Dim prop as Variant Active Directory object ADSI class object Set adsobj = _ GetObj( LDAP://cn=Agent 007,ou=Agent,dc=secrete,dc=com ) adsobj.getinfo Set adscls = GetObject(adsObj.Schema) Inspecting mandatory and optional properties For Each prop In adscls.mandatoryproperties List1.AddItem prop Next For Each prop In adscls.optionalproperties List1.AddItem prop Next Figure 10. Walking the property cache using the schema class definition 17