Directory Services

1. Directory Services

2. Distributed Directory Services: requirements • Requirements to the name structure: • multi-stage names („schill@inf.tu-dresden.de“) • 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)

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

4. Distributed Directory Services: requirements Example of some name structure: Document-Editor PrinterServer 1#134 SelectServer(„Printer“)=> #137 Printer Server 2#137 Directory Service

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

6. Context: „root“ Context: „usr“ Context: „bin“ Context: „src“ Context„host2, route1“ Context„host1, route1“ Context„computer names“ Context„host2, route2“ Context„host1, route2“ Types of name areas/scopes Hierarchy name space: Example (Unix, NFS):„usr/src/file.c“ Routing-oriented name space: Flat name area/scope: Example (local operating system): „schill“ Context„user names“

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“ host_X Context B (user names in the space of host_X) User identification

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

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

10. Directory Service: implementation Name Server S1: Context „Firm_Names“ • Example of a name area with related name servers: Name Server S2: Context „Dept_Firm_A“ Name Server S3: Context „Dept_Firm_B“ Name Server S6: Context „Fabrication_Firm_B“ Name Server S5: Context „Fabrication_Firm_A“ Name Server S4: Context „Design_Firm_A“ • Queries processing: „Firm_A : Fabrication : Meier“ • In Firm_A: S4 -> S2 -> S5 or directly via S5 • In Firm_B: S6 -> S3 -> S1 -> S2 -> S5

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

12. Caching: example Name Server S1: Context „Firm_names“ Server Cache:„Firm_B“, „S3“ Server Cache:„Firm_A“, „S2“ Name Server S2: Context „Dept_Firm_A“ Name Server S3: Context „Dept_Firm_B“ Name Server S6: Context „Fabrication_Firm_B“ Name Server S5: Context „Fabrication_Firm_A“ Name Server S4: Context „Design_Firm_A“ Clients Cache:„Firm_A : Fabrication“, „S5“

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.)

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“ Name Server S6: Context „Fabrication_Firm_B“ Name Server S5: Context „Fabrication_Firm_A“ Name Server S4: Context „Design_Firm_A“

15. Internal 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)

16. Server 1 Server 2 Server 3 / /Dept1 /Dept1/WS_1/... /Dept2/.. / /Dept2/.. / /Dept1 /Dept1/WS_1/... /Dept1/WS_5/... Internal implementation techniques • Caching: Storage of query results for later re-use Efficiency • Replication: Redundant storage of names on several servers Fault tolerance, efficiency Administration area

17. System administration • Relatively extensive administration tasks • Installation of server processes • Definition of name space structure • Setting of access control mechanisms • Replication control of name records • Re-configuration of name spaces • Tools • Simple command interface • Vendor-specific tools (also Remote Management) • Examples create replica /hosts clearinghouse /t500m0_ch set directory /hosts Convergence = high

18. Existing systems • Novell Directory Service • Microsoft Active Directory • Domain Name System • DCE Cell Directory Service • X.500 - Products

19. Name 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 Application-Level name Layer 5-7 Transport address Network address Layer 4 Inter-network route (Gateway 1, Gateway 2, ...) Layer 3c Subnet address Subnet route (Computer 1, Computer 2, ...) Layer 3a,b Address of the channel layer Physical address Layer 2 Layer 1 Physical transmission

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

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

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

23. LDAP: Directory Structure root de Country (C) fr uk Organisation (O) dfn tu-dresden mathnat informatik Organisational Unit (OU) yyy Individuals xxx Replication and Distribution possible

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

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

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

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

28. Internet 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

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“)

30. Summary • 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