Directory service

From Wikipedia, the free encyclopedia
Jump to: navigation, search

A directory service or name service maps the names of network resources to their respective network addresses. When using a directory service, a user does not have to remember the physical address of a network resource, because providing a name locates the resource. A directory server is a server which provides such a service. Each resource on the network is considered an object by the directory server. Information about a particular resource is stored as a collection of attributes that are associated with that resource or object. In some directory services, this information can be made secure, so that only users with certain permissions, such as administrators, can access it.

A directory service defines a namespace for the network. The namespace is used to assign a "name," or unique identifier, to each of the objects. Directories typically have a set of rules that determine how network resources are named and identified, which usually includes a requirement that the identifiers be both unique and unambiguous.

A directory service is a shared information infrastructure for locating, managing, administering, and organizing everyday items and network resources, which can include volumes, folders, files, printers, users, groups, devices, telephone numbers, and other objects. A directory service is a critical component of a network operating system.

Comparison with relational databases[edit]

Several things generally distinguish a directory service from a relational database:

  • directory information is read more often than it is written; this makes features related to transactions and rollback less important.[citation needed]
  • data can be redundant[clarification needed] if it helps performance.

Directory schemas are defined as object classes, attributes, name bindings and knowledge (namespaces), where an object class has:

  • Must - attributes that each of its instances must have
  • May - attributes that can be defined for an instance, but can be omitted with the absence treated somewhat like NULL in a relational database
  • Attributes are sometimes multi-valued allowing multiple naming attributes at one level such as machine type and serial number concatenated or multiple phone numbers for "work phone".
  • Attributes and object classes 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 object class inherits from its parent object class (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

Replication and distribution[edit]

Replication and distribution have very distinct meanings in the design and management of a directory service. The term replication is used to indicate that the same directory namespace (the same objects) are copied to another directory server for redundancy and throughput reasons. The replicated namespace is governed by the same authority. The term distribution is used to indicate that multiple directory servers that hold different namespaces are interconnected to form a distributed directory service. Each distinct namespace can be governed by different authorities.

Implementations of directory services[edit]

Directory services were part of an Open Systems Interconnection (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 directory information services of X.500, but uses the TCP/IP stack and a string encoding scheme of the X.500 Directory Access Protocol (DAP), giving it more relevance on the Internet.

There have been numerous forms of directory service implementations from different vendors. Systems developed before the advent of X.500 include:

  • Domain Name System: (DNS), the first directory service on the Internet, which is still used everywhere today.
  • Hesiod: was based on DNS and used at MIT's Project Athena.
  • Network Information Service: (NIS), originally named Yellow Pages (YP), was Sun Microsystems' implementation of a directory service for Unix network environments. It served a similar role as Hesiod.
  • NetInfo: was developed by NeXT in the late 1980s for NEXTSTEP. After being acquired by Apple, it was released as open source and used as the directory service for Mac OS X before being deprecated for the LDAP-based Open Directory. Support for NetInfo was completely removed with the release of 10.5 Leopard.
  • Banyan VINES: was the first scalable directory services offering.
  • NT Domains: was developed by Microsoft to provide directory services for Windows machines before the release of the LDAP-based Active Directory in Windows 2000. Windows Vista continues to support NT Domains, but only after relaxing the minimum authentication protocols it supports.

LDAP implementations[edit]

Among the LDAP/X.500 based implementations are:

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 Windows Domain Controller with Kerberos and LDAP backends. The administration is done using GOsa or Samba provided SWAT.

Using name services[edit]

Unix OSs[edit]

Name services on Unix systems are typically configured through nsswitch.conf. Information from name services can be retrieved using getent.

See also[edit]

Notes[edit]

  1. ^ [1] Archived October 15, 2007, at the Wayback Machine.
  2. ^ "Oracle and Sun". Sun.com. 2010-09-07. Retrieved 2012-01-09. 
  3. ^ "Java.net". Opends.dev.java.net. Retrieved 2012-01-09. 

References[edit]