1 / 30

Directory Services

Directory Services. 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“)

Télécharger la présentation

Directory Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  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,>; <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: • 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

More Related