Directory services for Windows have finally arrived. Three and a half years in the making, Microsoft’s Active Directory aims to solve the problem of finding and managing people, organizations, and computing resources over a multidomain, multiplatform network. Active Directory, a key service of Windows 2000 Server, is the primary distributed-storage mechanism for security objects, such as user accounts, user groups, and network domains. Prior to Windows 2000, these objects were accessible only via the Windows registry and proprietary, nonscalable network interfaces.

Now, Active Directory securely presents this information to both Windows and non-Windows clients with the Lightweight Directory Access Protocol (LDAP). LDAP has been widely accepted as the standard for cross-platform directory access, and as of V4R3, IBM has provided its Directory Services LDAP server for the AS/400. The promise of a unified directory access mechanism such as LDAP is integrated security and namespace management over both the Windows and the AS/400 domains. However, Active Directory is much more than a simple LDAP server: It also takes on the problems of network security and management in a Windows environment. Another exciting feature is Active Directory’s programming interface, which provides simplified access to the directory database.

Meet Directory Services

Administrators of enterprise computing environments must be able to centrally manage great numbers of users, groups, and machines. Otherwise, this management effort will be duplicated for each computing domain (for example, adding a new user once for the Windows domain and then adding the same user in the AS/400 domain). Directory services provide a logically centralized data store that can be added to, deleted from, modified, and queried by network users and applications. Using distributed techniques, this data store can be replicated on several nodes throughout the network to provide a hierarchical structure and decrease local query response time. LDAP is an open-standard protocol that implements directory services based on the X.500 directory standard. With LDAP, you can create aggregated directories from otherwise-disparate systems. Directory services supporting LDAP are nothing new (Novell’s NDS and Banyan’s StreetTalk are full- featured LDAP servers, and Lotus Notes and Microsoft Exchange both have directory service functions), but the introduction of Active Directory may mark the beginning of their widespread use.

Although it is not a database management system, a directory service stores information about an organization that is, generally, accessed frequently and updated infrequently. For example, an enterprise email address book is a resource that is best used and managed online by a directory service. User account details, network printers, and file servers are all resources that can be located and managed effectively using a directory service. Additionally, you can organize the data managed by a directory service hierarchically, allowing attribute inheritance, which is important in managing groups of objects, such as computer user accounts. Using attribute inheritance, a system administrator can assign the availability of certain computer resources to a group of users rather than to each user individually.

With the directory services infrastructure in place, next-generation directory-enabled applications are possible. For example, Cisco Systems has integrated its solutions for controlling network bandwidth and quality of service with Active Directory features, allowing administrators to assign those resources to groups of users.

Active Directory and Windows 2000

Active Directory is not an empty directory services framework. Actually, Windows 2000 itself is a directory-enabled application, and its security infrastructure relies on Active Directory to distribute information regarding the domain to Windows clients. When a Windows 2000 Server is designated as a domain controller, the objects (e.g., machines, profiles, and groups) associated with that domain are published as entries in the Windows domain schema of the directory. This schema has attributes for managing various hierarchical elements, ranging from the Windows desktop settings of individual users to
“trees” and “forests” containing multiple Windows computer domains. In addition, the Active Directory schema is extensible, allowing new classes of objects and new attributes for existing objects.

The treelike structure of Active Directory reflects its hierarchical organization. At the top of the tree is a container (or, using X.500 parlance, an organizational unit). This top- level container reflects the top-level organization; generally, this would represent a company with resources to be described and managed with Active Directory. Beneath the top-level container is a set of containers modeling network object organizations, such as users, machines, and applications. These containers have certain attributes and either contain directory entries for network objects or hold other containers representing subclassifications of network objects. The entries in the directory are protected with Windows NT access control lists (ACLs), which prevent unauthorized users from accessing directory information. Figure 1 shows an example directory structure, with
users’ accounts, servers, applications, and printers classified and managed by their containers.

Because most large companies will have several locations and, therefore, several network domains, Active Directory supports a form of directory replication called multimaster replication. Rather than store directory information in one physical machine and location, Active Directory supports replication of directory information among all Windows 2000 domain controllers, thereby allowing faster query responses, reducing network traffic, and providing a degree of fault tolerance. Note that if a network segment (for example, a WAN) becomes disconnected, the local domain controller’s replica of the directory may still provide valid information. When the network connection is restored, directory changes made at one site will be efficiently propagated to the directory replicas on all sites. This propagation of changes in Active Directory is optimized with the multimaster scheme. Active Directory knows the difference between WAN and LAN linked sites and attempts to minimize WAN traffic by updating only a single domain controller across a WAN segment. The updated local-site domain controller will propagate the update to all other domain controllers on the LAN segment. To further reduce the bandwidth required, updates are compressed. This replication scheme operates independently of the Windows

2000 domain organization, so the physical location of a domain controller need not have any relation to its logical presence in the network. In fact, you can synchronize two domain controllers (even if there is no continuous network connection between them) by using the Simple Mail Transfer Protocol (SMTP).

As illustrated in Figure 1, the hierarchical nature of Active Directory simplifies many management tasks. Administrators can control access to the directory entries of a subunit or group within an organization: a process known as delegation. For example, the senior administrator might assign the administrator of the marketing department authority to manage the marketing users’ accounts and assign the administrator of the research department authority over the research department users. Likewise, Windows applications may be assigned to particular departments. For example, if you are a member of a group that has been assigned a network application (which is registered in the directory), you will have that application available on your desktop when you log into the network. If your group is not assigned the application, then you won’t have access to it. The benefit of this feature to administrators is that network applications don’t have to be explicitly installed on a user’s desktop. By adding or deleting a user from a particular group, that user gains or loses access to a set of applications assigned to that group. You can make similar assignments for the hardware components of the network, such as printers and shared folders.

Active Directory brings users in mixed-computing environments a step closer to single-logon simplicity. UNIX and other systems supporting Kerberos security can both provide authentication for Windows 2000 clients and obtain authentication from Windows 2000 domain controllers. Other Active Directory features may be linked to Kerberos
“realms” by setting up trust relationships with Windows domains. Alternatively, you can use the Active Directory network and programming interfaces to create custom applications that merge directory information provided by other operating systems (including OS/400) and applications. Third-party products have already emerged that allow cross-platform user management with Active Directory tools. It is unfortunate that Active Directory cannot supply this functionality right out of the box.

Using Active Directory

Windows 2000 users have several ways to access Active Directory information. As seen in Figure 2, you can use the Search option on the Start menu to enter simple queries for information about users in the organization. Also, the new My Network Places icon on the Windows 2000 desktop allows you to query machine and application information contained in Active Directory. Finally, a management console snap-in applet, Active Directory Users and Computers, provides administrators and privileged users access to many Active Directory details in an Explorer-like tree interface. This application lets administrators configure Active Directory shared folders, printers, and user accounts. Other snap-in applets available on the Administrative Tools menu of Windows 2000 Server are Active Directory Domains and Trusts and Active Directory Sites and Services. A fourth snap-in, Active Directory Schema, allows a developer to view and change the database schema of the directory when creating Active Directory applications.

Service Interfaces

There are many ways to programmatically interface with Active Directory. Microsoft wants you to use its Active Directory Service Interfaces (ADSI) for new Windows applications that use Active Directory. ADSI is a Component Object Model (COM) API that can be used in any COM-aware programming language. Microsoft recommends you use ADSI when adding new containers, objects, and/or attributes to the directory. Why would you want to do this? Perhaps you want to add more detailed attributes to the description of your users or other network objects. Or you might want to publish and query metadata related to a new

systems application. Another reason for using ADSI is that it simplifies directory queries in your applications.

Because LDAP is the underlying protocol ADSI uses, the look and feel of the API is similar to LDAP and X.500 standards. In fact, you can use ADSI to access non-Active Directory LDAP servers, such as the AS/400’s Directory Services server. Directory servers and contents are described using LDAP URLs. Suppose you want to access information on a particular object in Active Directory. You can make a simple connection to the server by using Visual Basic (VB) syntax as follows:

Set s = GetObject(“LDAP:”)

In this case, ADSI and Active Directory will determine the best available domain controller to use as the Active Directory server and connect to it. You may also connect to a specific server or domain by using the LDAP://myserver or LDAP://mycompany.com URLs instead. The object returned by GetObject is actually a representation of the top-level domain component container in the directory. Accessing directory objects with ADSI is a matter of binding; the directory object returned is represented as a COM object with an interface expressing the information contained by the object. To access a user account object, you could use the following:

Set user = GetObject( “LDAP://CN=walter, CN=users,
DC=midrangecomputing, DC=com” )

This URL specifies the distinguished name (DN), or object path, for a directory entry representing a particular user. This DN is composed of four relative distinguished names (RDNs), or object names. An RDN is an attribute/value pair, in which the attribute is to the left of the symbol “=” and the value of the attribute is to the right. The directory hierarchy is traversed from the bottom up as RDNs are read from left to right in this URL. At the bottom of the hierarchy, in the Users container, is an object representing the user
“walter.” Users is a default container in which domain users are placed when an NT 4.0 domain is migrated to Active Directory. The two rightmost RDNs represent the domain container (containing “users”). The domain container names the top-level organization, midrangecomputing.com.

Given a DN resolved by ADSI to a directory object, you can determine some attribute values of that object using the Get method as follows:

Debug.Print user.Get “Name”
Debug.Print user.Get “TelephoneNumber”

The Get method returns the value of the specified attribute for the entry being referenced. Searching for one or more objects with ADSI is somewhat trickier. ADSI includes an OLE DB provider, which permits access to the directory with the common OLE DB interfaces. In case you are unfamiliar with these, OLE DB is Microsoft’s strategic set of COM interfaces that provide uniform access to data stored in diverse information sources, one of which is Active Directory. Visual Basic and similar programming environments use the ActiveX Data Object (ADO) interfaces for OLE DB provider access. So, to do more complex searching with VB, you would probably use ADO. The example shown in Figure 3 is a search for the telephone numbers of all users in the domain.

This example first creates an ADO connection and command objects. The connection is opened by using the ADSI OLE DB provider, ADsDSOObject, as assigned to the Provider property. This connection is assigned to the command object’s ActiveConnection property. You specify the text for the query command by using the LDAP Version 3 (RFC 2254) query format. This format specifies four items (separated by semicolons in the command string): the directory container to search (in this example, the

top-level container), an expression each found entry must satisfy, the attributes to be returned by the query, and the scope of the search. The fourth item, scope, can be one of the following: base, onelevel, or subtree. Base indicates that only the container is searched; onelevel specifies a search of the container and its entries; and subtree indicates that all subcontainers be searched. Alternatively, ADSI accepts an SQL-style query. You could use the SQL format and achieve identical results as follows:

cmd.CommandText = “select telephoneNumber from
‘LDAP://DC=midrangecomputing, DC=com’ WHERE objectClass = ‘user’”

The method you choose is a matter of preference, but the near-standard LDAP method may be more portable than the SQL method. If you are truly concerned about portability, however, you probably should use an interface other than ADSI.

For users with portability concerns, Microsoft provides the standard LDAP programming interface for Active Directory access. This is a C-language API that is implemented by all LDAP-supporting platforms, including OS/400. You might not use it as intuitively as you would the COM-based ADSI interfaces, but this API is the basis for ADSI remote directory access. Custom applications that require access to both AS/400 and Windows directory services would best be designed around the LDAP interfaces. You may face difficulty using these with Windows languages other than C or C++, but you can use the LDAP interfaces in any ILE language on the AS/400.

Get Active

Active Directory is a major step forward in the enterprise for Microsoft. Its embrace of LDAP and scalable directory services is welcome though incomplete. Hopefully, third parties will provide the middleware necessary for realizing Active Directory’s full potential in mixed-computing environments. The programming interfaces provided by Active Directory will, no doubt, spur those efforts.

Information about Active Directory, ADSI, and LDAP abounds on the Web. In particular, the Microsoft Developer Network (MSDN) site (msdn.microsoft.com) and the Windows 2000 Server site (www.microsoft.com/windows/server/Overview/intro/default.asp) contain everything you need to know about Active Directory. For background information, check out the University of Michigan birthplace of LDAP at www.umich.edu/~dirsvcs/ldap/ldap.html. Also, the AS/400 Directory Services LDAP server is detailed on the IBM Web site at www.as400.ibm.com/ldap. However, the best place to start learning everything about Active Directory is Microsoft’s Exploring Active Directory Web site at www.microsoft.com/windows/server/Overview/ exploring/directory.asp.

Company

Servers Applications Printers, etc. Users

Personnel Sales Research

Figure 1: The treelike structure of Active Directory information promotes object inheritance and delegation of management tasks.

Figure 2: The Find People applet is one way Windows 2000 users can query Active Directory contents.

‘Create ADO connection and command object Set con = CreateObject( “ADODB.Connection” ) Set cmd = CreateObject( “ADODB.Command” )

‘ Open the connection, and associate it with the query command con.Provider = “ADsDSOObject”
con.Open “Active Directory Provider” Set cmd.ActiveConnection = con

‘Compose the query command cmd.CommandText = “; objectClass=user ; telephoneNumber; subTree”

‘ Execute the query and print the record set contents Set rs = cmd.Execute
While Not rs.EOF

Debug.Print rs.Fields(“telephoneNumber”) rs.MoveNext
Wend

Figure 3: You can access Active Directory like any other OLE DB data source by using the ADO interfaces. This VB fragment displays all telephoneNumber fields of users in the directory.

Also Read

RPG Academy - Database Modernization: Entity Relationship Diagrams

RPG Academy - Database Modernization: A Bit of Database Theory

Talking About Modernization Isn’t Good Enough