directory services

IV.1

Directory Services

IV.2

Distributed Directory Services: requirements

Requirements to the name structure:

• multi-stage names („[email protected]“)

• attribute names („host_x:CPU=Pentium, PRT=Ipr, LOC=rz“)

• group names („Arbeitsgruppe_1“ => „meier, müller, schmidt“)

Requirements to the Directory Service:

• distributed, decentralized name management (for example, one server per department of a company)

• replication of name tables (efficiency, fault tolerance)

• transparent distributed handling of name queries /name interpretation (internal forwarding between the servers)

IV.3

Distributed Directory Services: requirements

Examples of name usage:

• selection of a printer server via logical name

• search for e-mail-address of a colleague via name or company/department

• selection of a computer node with special CPU-capacity (attribute)

==> mapping of logical names or attributes to the addresses necessary

==> special system support required

=> distributed Directory Services

IV.4Distributed Directory Services: requirements

Example of some name structure:

Document-Editor

PrinterServer 1

#134

PrinterServer 2

#137Directory Service

Printer #137

Plotter #358

Host_X #377

SelectServer(„Printer“)=> #137

IV.5

Name management: basic terms

Address: explicit, „physical“ object notation („#346“)

Name: logical object notation, mostly location independent („printer“)

Interpretation: name mapping to an address

Context: area/scope/space of interpretation of a component of some multi-stage name (for instance, set of computer names for „schill@host_X“)

Name area/space: set of contexts (for instance,

„<user>@<computer-node>“)

Relative names: interpretation depends on outgoing (issuance) context (for instance, interpretation of „schill“ otherwise by context „host_X“

than by „host_Y“)

Absolute names: context independent

IV.6Types of name areas/scopesHierarchy name space:

Example (Unix, NFS):„usr/src/file.c“

Context: „root“

Context: „usr“

Context: „bin“ Context: „src“

Routing-oriented name space:

Context„computer names“

Context„host1, route1“




Flat name area/scope:

Context„user names“

Example (local operating system): „schill“

IV.7

Context and name interpretation

Example: interpretation of the name „schill@host_X“

„schill@host_X“

Context R (computer name)

Address ofhost_X

Context B „schill“

User identification

Context B (user names in the space of host_X)

host_X

IV.8

Context and name interpretation

Approach to interpretation:

• interpretation of each name component via related context

• Result: mapping of components on an address + a new context

• assignment of separate contexts to different name servers possible

==> decentralized, distributed interpretation

IV.9

Directory Service: implementation

Basic conceptions:

• hierarchical names spaces

• assignment of one or several contexts to each name server

• each name server knows the sub-ordinate and super-ordinate servers

• distributed interaction of the name servers for processing of a name interpretation

– no expensive broadcast necessary

– name servers are relatively autonomous

IV.10Directory Service: implementation

Example of a name area with related name servers:

Name Server S1:Context „Firm_Names“

Name Server S2:Context „Dept_Firm_A“

Name Server S3:Context „Dept_Firm_B“

Name Server S4:Context „Design_

Firm_A“

Name Server S5:Context „Fabrication_

Firm_A“


Firm_B“

Queries processing: „Firm_A : Fabrication : Meier“• In Firm_A: S4 -> S2 -> S5 or directly via S5• In Firm_B: S6 -> S3 -> S1 -> S2 -> S5

IV.11

Optimization: Caching

Goals and approaches:• Performance improvement via re-use of precedent query results • Caching via clients of the Directory Service:

– parts of an interpreted name and address of the interpreting name server of subordinate level

– example of a cache-record: („Firm_A:Fabrication“, „S5“)– then direct querying of the lowest subordinate server possible

(here „S5“)• Caching via name server directly:

– records: name context and addresses of all servers on the same level

– thereby, reduction of one level

IV.12

Caching: example

Name Server S1:Context „Firm_names“

Name Server S2:Context „Dept_Firm_A“

Name Server S3:Context „Dept_Firm_B“


Firm_A“


Firm_A“


Firm_B“

Clients Cache:„Firm_A : Fabrication“, „S5“

Server Cache:„Firm_A“, „S2“

Server Cache:„Firm_B“, „S3“

IV.13

Context replication

Goal: Fault tolerance and locality of queries

Approach:

• Implementation of a context via several name servers

• Selection of an alternative server after termination of a timeout by a query

• Estimation of the alternative servers via simple cost function => optimization

• Change management of the Name Directories via a special replication method(relatively expensive but robust in comparison with error cases)

• Use of replication, especially in very error-critical environments (CIM etc.)

IV.14

Replication: example

Name Server S1:Context „Firm_ names“

Name Server S2:Contexts

„Dept_Firm_A“„Dept_Firm_B“

Name Server S3:Contexts

„ Dept_Firm_B“„Dept_Firm_A“


Firm_A“


Firm_A“


Firm_B“

IV.15Internal tasks: details

• Mapping of names onto the name records,i.e. onto computer addresses or other data

• Name structure: hierarchical (for large systems)(for instance, “iioploc://www.firm_x.de/Department_1/WS_5/printserver”)

• Name records: Attributes and attribute values(for instance, <Address, 130.13.3.56>; <Phone, 0351/463-38261>)

• Query operations:According to name and partially also according to attributes

• In any case several distributed Directory Servers (fault tolerance)

IV.16

• Caching:

• Replication:

Storage of query results for later re-use Efficiency

Redundant storage of names on several servers Fault tolerance, efficiency

Administration area

/

/Dept1

/Dept1/WS_1/...

/Dept2/..

Server 1

/

/Dept1

/Dept1/WS_1/...

/Dept1/WS_5/...

Server 3

/

/Dept2/..

Server 2

Internal implementation techniques

IV.17

• Relatively extensive administration tasks

• Tools

• Installation of server processes• Definition of name space structure• Setting of access control mechanisms• Replication control of name records• Re-configuration of name spaces

• Examples

• Simple command interface• Vendor-specific tools (also Remote Management)

create replica /hosts clearinghouse /t500m0_ch

set directory /hosts Convergence = high

System administration

IV.18

Existing systems

• Novell Directory Service

• Microsoft Active Directory

• Domain Name System

• DCE Cell Directory Service

• X.500 - Products

IV.19Name and address mapping in ISO/OSI

Principle:

• 7-layer-Structure, mapping layer-wise

• logical, hierarchical names only on layer 7

• Skipping of layers for the mapping

Layer 1

Layer 2

Layer 3a,b

Layer 3c

Layer 4

Layer 5-7

Physical transmission

Physical address

Address of the channel layer

Subnet route (Computer 1, Computer 2, ...)

Subnet address

Inter-network route (Gateway 1, Gateway 2, ...)

Network addressTransport address

Application-Level name

IV.20

ISO/OSI – name structure

Basic concepts:

• Hierarchical name area

• Attributed names

Standards:

• ISO-9594 respectively CCITT X.500

• Detail aspects: ISO-9594-1 up to 9594-8 respectively CCITT X.500 up to X.521

Name attributes:

• Standard attributes: country code, organizational unit, department, person, postal address etc.

• Additionally freely defined attributes

• Multi-valued attributes => group names

• Optional attributes

• Inheritance hierarchy of attributes

IV.21

ISO/OSI – name interpretation

Basic concepts:

• Mapping of contexts on distributed name servers

• Decentralized name interpretation

Alternative interpretation approach:

• Hierarchical processing (according to the precedent examples)

• Multicast-queries for different name servers (for instance, relevant for Ethernet)

• Interpretation via a sequence of RPCs for servers with decreasing accuracy of contexts

Communication protocols:

• Directory System Protocol (DSP) between servers

• Directory Access Protocol (DAP) between client and server

IV.22

Lightweight Directory Access Protocol (LDAP)

• de Facto-Standard for access to Directory Services, wide spread vendor support

• Simplified variant of X.500 Directory Access Protocol (DAP), implementation over TCP/IP

• Front-End for heterogeneous Directory Servers (for instance, X.500, NIS, MS Active Directory, CDS, Novell NDS etc.)

• Typical operations for name search and name manipulation:

-> Search, Compare, Add, Delete, Modify

IV.23

LDAP: Directory Structure

root

de fruk

dfn tu-dresden

informatik mathnat

yyyxxx

Country (C)

Organisation (O)

Organisational Unit (OU)

Individuals

Replication and Distribution possible

IV.24

Special properties of LDAP

• Simplified protocol elements in comparison to X.500

• Optimization of access functions

• Automatic forwarding of queries between Directory Servers with distributed information repositories („referral“ without involving of client application)

• Improvements regarding to authentication, encryption, and integrity for Directory Accesses

IV.25

Novell Directory Service (NDS)

• widely used system decision

• relatively scalable (name properties managed)

• distributed architecture

• support of X.500 and LDAP

• integrated security functions

• integrated programming interfaces for applications (for instance, Java)

• however proprietary administration functions

• Platforms: Windows, Linux, Solaris, OS/390 among others

IV.26

NDS: security functions and trustiness

• Central authentication for each administration area, based on RSA

• Authorizing of Directory access

• Rights awarding also on the basis of partial Directory-trees as well as in reference to user groups

• Record replication -> fault tolerance

• Automatic re-configuration mechanisms in error case

IV.27

NDS: scalability and performance optimization

• Replication of name records -> local authentication and local resource access frequently possible

• Load distribution of queries on numerous different servers

• Implementation of multi-threaded servers

=> parallelism

• Flexible adaptation of Directory Server configuration to actual query and update profiles possible

IV.28Internet Directory Services

Name structure:

• Hierarchical names

• Allowed components on the highest hierarchy level– in USA: .com/ .edu/ .gov/ .net etc.– otherwise: country identifier (.de etc.)

• generally 3-4 name components

Address structure:

• Internet-addresses with length of 4 Bytes

• Example: 129.13.3.57

• Different address classes:– Class A for large organizations: 24 bit for sub-networks and hosts– Class B for medium organizations: 16 bit for sub-networks and hosts– Class C for small organizations: 8 bit for sub-networks and hosts

IV.29

Name interpretation in the Internet

Principle:• Distribution of contexts on the name servers• Replication of contexts on the superior levels of the name space• Each name server knows at least one server from superior

levels

=> direct forwarding of queries• Interpretation of relative names possible

Optimizations:• Caching of query results via clients as well as via servers of the

lower levels• Automatic deletion of Cache-records after expiration of a

timeout (so called „time to live“, „TTL“)

IV.30Summary

Distributed Directory Services:• Mapping of names on addresses• Structured name areas• Multi-level mapping of names• Implementation via distributed name servers

Important Standards and Quasi-Standards:• ISO/OSI 9594 / CCITT X.500• OSF Distributed Computing Environment• Internet Domain Name System• CORBA Naming Service• Novell Directory Service• Microsoft Active Directory

directory services

Documents