Directory services within networked computing environments are not a new concept. Many organizations have implemented white pages to make basic information available to all employees. E-mail applications have used directories as address books. Within the network operating systems, directory services show that it is possible to simplify network management tasks by storing all information in a centralized directory. With today’s network operating systems, directory services must be capable in the following roles:
-
User and Network Resource Management by providing a scalable, hierarchical information repository to simplify tasks such as delegating administrative privileges and locating network resources such as printers.
-
Security Authentication and Authorization Services by providing flexible authentication and consistent authorization services that protect data and minimize barriers to doing business over the Internet.
-
Directory Consolidation by reducing the number of directories companies need to improve sharing and enable common management of users, computers, applications, and devices.
-
Directory-enabled Infrastructure by enabling elements such as networking hardware and shared file systems to offer enhanced service quality and greater functionality through access to information about users (and their roles), machines, network elements, and policies stored in the directory.
-
Directory-enabled Applications by enabling simplified application configuration and management and greater functionality and synergy with other directory-enabled components of the network-computing environment.
However, without a solid technical foundation, no network operating system will be capable of performing the aforementioned roles. As such, the following technical criteria must be considered when evaluating a network operating system based on directory services:
-
Scalability – The various roles that directory services play require the storage and replication of millions of objects efficiently and cannot require complex configuration of servers. A directory partition (or division) must scale to hold at least 1,000,000 objects. And objects should be easily queried and located within the directory. Catalog services should be provided to expedite object search and retrieval; latency should be low.
-
Internet Standards – Given the wide range of ways that directory services will be used, often from across corporate and geographic boundaries, directories must locate and access objects completely via Internet standards such as the Domain Name Service (DNS) and the Lightweight Directory Access Protocol (LDAP). All directory services, not just a subset, should be totally exposed via LDAP and DNS to achieve true standards compliance.
-
Flexible and Simple Security – Along with the desire to increase access to directories is the need to protect corporate resources without placing design restrictions on networks or increasing management complexity. Access rights via catalog services and LDAP should not be computed differently than when the directory is accessed natively. Full group support should be provided and no performance implications should be imposed on creating groups that span multiple directory partitions.
-
Consolidation – Because most organizations will not be able to eliminate all of the application-specific directories that they use today, multi-purpose directories must enable consolidation and provide synchronization facilities to minimize duplicated administrative efforts. Additionally, scalability should ensure that bringing large numbers of objects into the directory raises no significant performance issues.
-
Application Development Environment – To attract software developers, directories must be full-featured, easy to use, with exposed APIs, and platforms that provide a comprehensive and simple-to-use development environment.
Solaris 7 Implementation Details
The primary name resolution service supported by Solaris 7 is Sun Directory Services 3.1. Sun Directory Services is a complete multi-protocol directory for storing user, resource and configuration information. Directory data information is object-based and stored in a directory tree structure. Classes of objects can be accessed in the directory through the hierarchy provided by the directory tree. For example, you could use the directory to look up the email address of a user at the Seattle office even though you are in the London office. This information could be accessed through LDAP or via the Web/LDAP gateway service. Sun Directory Service also supports RADIUS for remote authentication and NIS for applications that use NIS naming services.
Information in the directory is organized according to a predefined directory schema. This schema can be modified, which allows you to customize the directory environment. Access to information in the directory is controlled through access control lists which provide five basic modes:
-
None – No access
-
Compare – Allows comparisons of values but doesn’t grant read access.
-
Search – Allows searching of the directory by reading distinguished names (DNs).
-
Read – Provides read access to the directory.
-
Write – Provides write access to the directory.
These controls are similar though less elaborate to the controls available in Windows 2000. Directory data can be managed through any Web-enabled browser or by running the management applications, which include Administration Console for local and remote administration and Deja for updating the directory.
Directory Architecture
Sun Directory Services supports LDAP v3 as defined in RFC 2251 and LDAP servers are a core part of the directory architecture. Directory information is replicated throughout the network using an LDAP replication service. Data can be replicated at the subtree, object or property level. Two replication daemons are provided. The dspushd daemon pushes updates from a master server to a slave server and in this way, the master server manages the replication schedule. The dspulld daemon allows a slave server to pull updates from a master and in this way secondary servers manage the replication schedule.
The master-slave replication model is also referred to as the single master replication model. There are many problems inherent in this model. The biggest problems is that outdated data may be retrieved by client applications. Another major problem is that a single server is responsible for processing and replicating changes, which provides a single point of failure and places a heavy burden on the master server. In contrast, the multimaster model used in Windows 2000 gives all servers equal responsibility—any server can process and replicate changes.
Sun Directory Services also supports NIS replication. This type of replication ensures NIS information is maintained and updated throughout the network. NIS services and replication are handled by NIS servers, which are another component of this architecture. With a maximum table size of 50-60,000 entries, NIS servers are not designed to handle large networks or large information loads. NIS support is primarily made available for legacy systems.
NIS services are handled by the dsservd daemon, which can act as an NIS master or an NIS slave. In the role of a master server, dsservd propagates NIS tables to a slave NIS server. In the role of a slave server, dsservd receives propagation requests. Replication between an integrated LDAP/NIS server and a legacy NIS server is handled through a proxy daemon, dsypxfrd.
The final server component in this model is a RADIUS server. Remote Access Dialup User Service (RADIUS) is used to authenticate remote users. The RADIUS server functions are handled by the dsradiusd daemon.
Directory Management
Sun Directory Services also includes the following Java tools that you can run as applets in any Java-enabled Web browser, or as applications:
-
Administration Console for local or remote configuration and administration.
-
Java Directory Editor (Deja) for updating the directory database.
Two SNMP agents are available for obtaining management statistics. The dsnmpserv agent supports the Mail And Directory MANagement (MADMAN) standard specified in RFC 1565 and RFC 1567. The dsnmprad agent supports the RADIUS Accounting Server Management Information Base (MIB).
Directory service security is handled through LDAP, RADIUS and password encryption techniques. The LDAP server component supports Simple Authentication Security Layer (SASL) and Secure Socket Layer (SSL). However, SSL security is available only if SSL and Sun Certificate Manager are installed on the directory server. The RADIUS server component uses MD5XORing shared secret keys to authenticate remote users. Directory entries can also be protected and password encrypted. In this case, the standard crypt (3) encryption algorithm is used.
Windows NT Server 4.0 Implementation Details
Because Widows NT Directory Services (NTDS) is not a hierarchical directory, the concept of partitioning a portion of the directory, as such, does not exist on this platform. Instead, flat user account databases (domains) are used – which scale well up to 25,000 users (including a user account and machine account for each user – 50,000 objects total). Typically, customers of Windows NT Server 4.0 running NTDS use multiple domains with trust relationships to divide their network and provide roughly similar functionality to partitioning at a high level.
Windows NT Directory Services (NTDS) does not provide an implementation of directory catalog services. Nor does Windows NT Server 4.0 support the Lightweight Directory Access Protocol (LDAP) as part of the base operating system. Support for the Domain Name Service (DNS) is provided, but no real integration with Windows NT Directory Services (NTDS) exists, leaving customers of Windows NT Server 4.0 with no Internet-standards based directory access. Other features of the Windows NT directory service implementation follow.
Security Services -
Authentication – Windows NT Server 4.0 provides integrated LAN Manager authentication, providing challenge/response authentication and single network sign-on. Once a user has authenticated to Windows NT Directory Services (NTDS), authorization is performed in a consistent fashion across files, applications, and other resources.
-
Inheritance – Windows NT Server 4.0 implements traditional static inheritance of access control behaviors. Under this model, access control behaviors are computed and attached directly to the child object when some access right to a parent object is changed. An administrator does not necessarily have to make explicit changes to each child object when an access right of a parent object is changed.
-
Groups –Windows NT Server 4.0 fully supports the creation of groups within NTDS. As with the Active Directory implementation found in Windows 2000 Server, there are no significant performance implications from the creation of groups whose memberships span multiple domains.
Synchronization and Consolidation
Windows NT Directory Services (NTDS) provides no synchronization features as part of its implementation. As such, users cannot perform such tasks as request change lists, making it a poor choice on which to build replication-sensitive directory-enabled applications.
Windows NT Directory Services (NTDS) on the Windows NT Server 4.0 platform is a non-extensible directory. Customized objects cannot be created within Windows NT Domains. Only user and group data can be stored in NTDS. As such, Windows NT Server 4.0 is not a solution capable of providing a consolidation platform for corporate information.
Development Environment
Windows NT Server 4.0 exposes an API set allowing developers to build solutions that leverage the Windows NT Directory Services (NTDS) for authentication and security. Because Windows NT Server 4.0 can support a large number of users per domain (partition), it is a good solution for building applications that use NTDS solely for the purpose of authentication. However, as the directory is not extensible and cannot store customized information, it is not a platform on which sophisticated directory-enabled applications can be constructed.
Through its multimaster domain structure, Windows 2000 provides the most robust directory service. With multimaster, any domain controller can process and replicate directory information. Unlike Sun Directory Services, replication of the directory is automatic. You don’t need to configure replication manually, but can optimize replication using bridgehead servers. Bridgehead servers are designated to handle replication between sites, which places the bulk of the intersite replication burden on a specific server rather than on any available server in a site.
Directory Organization
The Active Directory service organizes directory information using a directory tree, which is an object-based hierarchy of information. To ensure data is organized and accessible, Active Directory provides both physical and logical structures for network components. Sites are used to map the physical structures of the network. Site mappings are independent from logical domain structures and because of this there is no necessary relationship between a network's physical structure and its logical domain structure. Logical structures are organized into domains, domain forests, and domain trees. A domain is a group of computers that share a common directory; domain trees are groups of domains that share a contiguous namespace; domain forests are groups of domain trees that share common directory information.
The boundary of a partition within Active Directory is a Windows 2000 Domain. All of the entities within the domain that have associated Active Directory objects will be accessible within a single partition. Because Active Directory supports multimaster replication, a full read/write replica of the partition will be available on all domain servers in the domain, even when the domain spans multiple physical sites.
Active Directory partitions use an efficient indexed data store, which holds information about all entities in a domain. As such, domains can easily contain millions of users and machines. Replication is highly optimized, featuring advanced techniques such as data compression and automatic use of bridgehead servers to reduce the need to create domain boundaries on a physical location basis due to the restricted availability of network bandwidth. Bridgehead servers ensure that replication traffic between sites and across lower network links is performed efficiently. Updates travel once between bridgehead servers, which then propagate the updates to other domain controllers in the site.
Directory Structure
Active Directory on Windows 2000 Server provides a mechanism called a Global Catalog to enable administrators to build a specialized directory containing a subset of object attributes that are of interest beyond a single domain. The Global Catalog builds off of the concept of trees and forests of related domains in Windows 2000 Server to determine how domains participate in the Global Catalog process.
In particular, Active Directory enables administrators to specify which domain controllers in a given domain should hold global catalog information in their Active Directory partitions. Then, administrators specify which object attributes should be replicated to the Global Catalog using the Active Directory Schema Manager. When any object in the tree or forest is added or updated, information about the update is propagated automatically, using the same replication technologies as within a domain, to all domain controllers that are configured to hold Global Catalog information.
Global Catalogs are updated simultaneously with other replication cycles to ensure that catalogs stay consistent with their underlying domain-based objects. Additionally, they are kept within Active Directory partitions themselves to enable a single, unified way of accessing all Active Directory objects. Finally, objects and attributes in the Global Catalog retain their original access control lists to ensure that catalog operations do not compromise security.
Internet Standards Support
Microsoft designed Active Directory from the outset as a native Lightweight Directory Access Protocol (LDAP) Version 3 server. As such, LDAP-based requests are processed directly without translation against the Active Directory data store. Active Directory also exposes all of its functionality via LDAP interfaces. For example, Active Directory provides LDAP-based support for schema management, change history, and query scoping. More importantly, because of Active Directory’s inherent scalability, it is well suited in environments where large numbers of objects are hosted via a single partition – commonly used in such scenarios as corporate address books or product catalogs. Active Directory is easily capable of hosting over one million objects in a single, fully indexed partition.
Likewise, Microsoft designed the Active Directory name space around the Internet standard for name resolution – the Domain Name Service (DNS). Active Directory domain names are the same as DNS domain names. Because domains have a one-to-one relationship with Active Directory partitions, Active Directory name spaces can be located natively via DNS. Furthermore, an Active Directory object’s fully distinguished name contains the DNS name of its partition, is globally unique, and completely describes how to find the object in a company’s intranet or across the entire Internet.
Security Services -
Authentication – Active Directory supports multiple security authentication protocols including LAN Manager (NTLM), Kerberos, and X.509 certificates. Support for Internet-based standards such as X.509 and Kerberos allow Windows 2000 Server to function well in Internet-connected environments and scenarios. Active Directory uses a modular approach to authentication, making it easy to add additional authentication protocol support. Once a user has authenticated to Active Directory, authorization is performed in a consistent fashion across files, applications, and other resources.
-
Inheritance – The Active Directory service in Windows 2000 Server implements a sophisticated form of static inheritance. Each child object has an access control list attached that contains the summary of all access rights that are either specifically assigned to the object or inherited from its parent. Active Directory recomputes child access rights automatically when a parent object’s rights are changed. Then, only the change to the parent object is replicated between domain controllers and global catalogs. The child access rights are then recomputed on each domain controller – a fast and local operation.
-
Active Directory inheritance has been implemented in this fashion because directories must be optimized for read (versus write) behavior. Active Directory pays the price of recomputing access control behaviors once (at the time a parent object is changed) rather than on every read operation. The net effect to the user of true dynamic inheritance and the way Active Directory implements inheritance is the same. However, the net effect to organizations deploying Active Directory is faster access to information stored in the directory for their network users.
-
Groups – Active Directory implements security groups in such a way that it is possible (and efficient) to create groups that span organizational units within a partition and across domains that are part of a forest or a tree. This makes it easy for administrators to create groups that include members regardless of their location in a partition or the domain to which they belong.
Synchronization and Consolidation
Active Directory provides synchronization features that enable companies to use it immediately as their focal point for centralized management and single sign-on infrastructures, while transitioning away from existing directories. In particular, Active Directory includes an LDAP-based interface for requesting lists of all object additions and updates since a given point in time. These interfaces make it easy for applications to synchronize objects in different directories without resorting to inefficient techniques such as tree walking or monitoring replication traffic. Additionally, after the release of Windows 2000 Server, Microsoft expects to offer an additional product that will use Active Directory change notification mechanisms to synchronize Active Directory objects with corresponding objects in other directory services.
As previously mentioned, Active Directory provides scalability up to millions of objects in a single partition. This enables it to be easily utilized as a consolidation point for other application-specific directory services and object stores including:
-
Microsoft Exchange Server.
-
Microsoft Message Queuing Services.
-
Microsoft Commercial Internet Services.
-
Other third-party meta-directory vendors.
Development Environments
Developers have two different sets of interfaces for building directory-enabled applications based on Active Directory. These include:
-
Lightweight Directory Access Protocol (LDAP) – Active Directory has been designed as a ‘native’ LDAP server. LDAP-based requests are processed directly without translation against the Active Directory data store. Active Directory also exposes all of its functionality via LDAP interfaces.
-
Active Directory Services Interfaces (ADSI) – To make it easier to write directory-enabled applications that access Active Directory and other LDAP-enabled directories, Microsoft developed ADSI. ADSI is a set of extensible, easy-to-use programming interfaces based on Microsoft Component Object Model (COM) that can be used to write applications to access and manage Active Directory and other LDAP-based directories. ADSI abstracts the capabilities of directory services from different network providers to present a single set of directory service interfaces for managing network resources. This greatly simplifies the development of distributed applications, as well as the administration of distributed systems. Developers and administrators use this single set of directory service interfaces to enumerate and manage the resources in a directory service, no matter which network environment contains the resource. Thus, ADSI makes it easier to perform common administrative tasks, such as adding new users, managing printers, and locating resources through the distributed computing environment. Combining the wealth of tools that support COM, ADSI makes it easy for developers to directory-enable their applications using any language that supports COM.
Beyond ADSI, Active Directory provides developers with the comprehensive feature-set they need to build powerful directory-enabled applications that deliver great functionality and enable lower TCO. Some of the features included with Active Directory include the following:
-
Group Policy Integration – Group policy features enable administrators to define sets of applications, including specific configurations, that users should have available based on their role in the company, the domain of which they are a member, and the security groups to which they belong. When a user is moved into an organization or added to a Windows NT security group, applications can be installed and configured automatically – helping to lower installation and configuration costs dramatically.
-
Service Publication – Active Directory enables applications to publish the names and locations of service they provide so that clients can locate and use services dynamically. This allows administrators to reconfigure servers for optimal response times and higher availability without having to update clients.
-
Directory Object Extension – Active Directory provides the ability for applications to add new types of objects and to extend existing objects with new attributes. Thus, Active Directory can be a consolidation point for reducing the number of directories that companies have. Benefits include improved information sharing and common management of users, computers, applications, and directory-enabled devices.
-
ADSI Extension Model – ADSI provides a feature called the ADSI Extension Model that allows application developers to associate COM-based business rules with objects stored in Active Directory. This provides a consistent and simple way for developers and administrators to interact with an application and its objects. The Extension Model also makes it easy to invoke methods across groups of objects to simplify administration.
-
Active Directory Class Store – The Active Directory provides a section of the directory tree called the Class Store to store the names and locations of COM objects installed on the network. COM uses the Class Store to locate and install the COM objects that users are allowed to use on their machines automatically. This can lower the total cost of ownership of COM-based applications by simplifying client configuration and administration.
Directory Services Summary
Active Directory is a feature-complete and scalable directory services implementation. Scalability is excellent – up to one million objects per domain (partition). Partitions use indexed data store for fast object retrieval, ensuring excellent performance. Replication between sites and over slow network links is optimized, ensuring that Wide Area Network (WAN) bandwidth will be available in Active Directory environments. Catalog services are provided in the form of the Global Catalog. The Global Catalog is updated simultaneously with other replication cycles, ensuring low latency. A single data store and set of access methods is used for both the partitions and catalogs, ensuring that information from the directory is always consistent and up-to-date.
Full support for the Lightweight Directory Access Protocol (LDAP) is provided because Active Directory was designed from the outset as a native LDAP implementation. No request translation services are necessary and access control rights are consistently implemented via both LDAP and native directory access. LDAP-based access is present for all services. Domain Name Service (DNS) support is equally integrated, as Active Directory uses DNS natively as its name space solution for object location and access. The Global Catalog enforces complete object- and attribute-level security, meaning that it is an excellent choice when used as a reference for authentication. Full group support is provided and there are no performance implications of defining security groups that span domains (partitions).
Because of its inherent scalability and superior catalog performance for queries, Active Directory is an excellent solution on which to consolidate large directories without administrative complexity. Integrated LDAP-based change history facilitates the Active Directory use as a meta-directory platform. As such, today it is being utilized as the basis for the information/object stores in several new Microsoft products including the next releases of Exchange, Message Queuing Services, and the Microsoft Commercial Internet Services (MCIS) package. Active Directory is also easily extensible, providing the COM-based Active Directory Services Interface (ADS) for simplified development. LDAP also exposes access to all Active Directory features, making it an excellent choice on which to develop Internet standards-based solutions. Finally, its inherent scalability allows the development and deployment of large-scale directory-enabled applications that can store, access, and manage millions of objects without application-level complexity.
Sun Directory Services 3.1 adds a fully LDAP-enabled directory service implementation to the Solaris 7 package. The service provides support for standards such as LDAP and RADIUS, but lacks true integration with the operating system. Some directory maintenance is possible via the Java based directory editor. Otherwise management is done via the command line. A Web interface to the directory is also provided, but not recommended for maintenance or configuration uses.
Of the three solutions evaluated, Windows NT Directory Services (NTDS) on the Windows NT Server 4.0 platform is the most dated directory services solution. Because it is not even a hierarchical and extensible directory, it is not fair to compare it directly against Active Directory in Windows 2000 Server and Sun Directory Services in Solaris 7. Its strongest point is its centralized store for user and group management; allowing customers to provide single sign on services across enterprise networks and applications. In all other areas, it simply cannot be directly compared, as it does not offer functionality similar to that present in NDS and Active Directory because of the fundamental architectural differences.
|
