Directory service
A directory service organizes computerized content and runs on a directory server computer. It is not to be confused with the directory itself, which is the database that holds the information about objects that are to be managed by the directory service. The directory service is the interface to the directory and provides access to the data that is contained in that directory. It acts as a central authority that can securely authenticate resources and manage identities and relationships between them.
A directory service is highly optimised for reads and provides advanced search on the many different attributes that can be associated with objects in a directory. The data that is stored in the directory is defined by an extendable and modifiable schema. Directory services use a distributed model for storing their information and that information is usually replicated between directory servers. domain name service, the user doesn't have to remember the physical address of a network resource; providing a name helps locate the resource. Each resource on the network is considered as an object on the directory server. Information about a particular resource is stored as attributes of that object. Information within objects can be made secure so that only users with the available permissions are able to access it.
A directory service defines the namespace for the network. A namespace is a set of rules that determine how network resources are named and identified. The rules specify that the names be unique and unambiguous. In LDAP the name is called the distinguished name (DN) and is used to refer to a collection of attributes which make up a directory entry.
| Contents |
Comparison with relational databases
There is a number of things that distinguishes a directory service from a relational database
- In a directory, the information is generally read more often than it is written. Hence the usual database features of transactions and rollback are not implemented in a directory. Data may be made redundant, but the objective is to get a faster response time during searches.
- Data is organized in a strictly hierarchical manner. In terms of cardinality, directories do not have many-to-many relations. Instead, such relations must be maintained explicitly using lists of distinguished names.
- Attributes are defined as stand-alone schema entities. That is: they exist without being part of an object and have a fixed type.
- An objectClass has:
- Must-attributes that each of its instances must have
- May-attributes that can be defined for an instance, but could also be omitted when the object is created. The lack of a certain attribute is somewhat like a NULL in relational databases
- Attributes are often multi-valued in directories whereas this is seen in relational database design as a denormalized state of the database schema.
- Attributes and objectClasses are standardized throughout the industry and formally registered with the IANA for their object ID. Therefore directory applications seek to reuse much of the standard classes and attributes to maximize the benefit of existing directory server software.
- Object instances are slotted into namespaces. That is, each objectClass inherits from its parent objectClass (and ultimately from the root of the hierarchy) adding attributes to the must/may list.
- Directory services are often a central component in the security design of an IT system and have a correspondingly fine granularity regarding access control: who may operate in which manner on what information. Also see: ACLs
Directory design, compared to relational databases, therefore feels much more like customizing an industry-standard rather than a conceptualization of a real-life situation. Different rules apply regarding data modeling and the access scenarios are different.
Implementations of Directory Services
Directory services were part of an Open Systems Interconnect (OSI) initiative to get everyone in the industry to agree to common network standards to provide multi-vendor interoperability. In the 1980s the ITU and ISO came up with a set of standards - X.500, for directory services, initially to support the requirements of inter-carrier electronic messaging and network name lookup. The Lightweight Directory Access Protocol, LDAP, is based on the services of X.500, but uses the TCP/IP stack, giving it more relevance on the Internet.
There have been numerous forms of directory service implementations from different vendors. Among them are:
- NIS: The Network Information Service (NIS) protocol, originally named Yellow Pages (YP) was Sun Microsystems implementation of a directory service for Unix network environments. (Sun has, in the early 2000s, merged its iPlanet alliance Netscape and developed its LDAP-based directory service to become part of Sun ONE, now called Sun Java Enterprise.)
- NDS: Novell's implementation of directory services NDS supports multiple architectures among them Windows, Netware, several flavours of Unix, AS/400 and Linux and has long been used for user administration, configuration management, and software management. NDS has evolved into a central component in a broader range of Identity management products. NDS was renamed into eDirectory upon this occasion.
- Fedora Directory Server: Red Hat released the directory service that it acquired from Netscape Security Solutions under the name The Fedora Directory Server.
- Active Directory: Microsoft's directory service is the Active Directory which is included in the Windows 2000 and Windows Server 2003 operating system versions.
There are also plenty of open-source tools to create directory services, including OpenLDAP and the Kerberos (protocol), and Samba software which can act as a Domain Controller with Kerberos and LDAP back-ends.
Notes
- ^ Carter, Gerald (2003) "LDAP System Administration". O'Reilley pp 3–4
References
- Carter, Gerald (2003) "LDAP System Administration". O'Reilley. ISBN 1-565592-491-6.