1 / 27

Directory Services

Directory Services. DIT Design Jim Rommel Perot Systems Corporation. Jim Rommel. Sr. Directory Specialist: Perot Systems Incorporated 4 years experience with X.500/LDAP Directory Services at Texas Instruments and Perot Systems Prior experience with Object Repository Technology

echo-branch
Download Presentation

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.

E N D

Presentation Transcript

  1. Directory Services DIT Design Jim Rommel Perot Systems Corporation

  2. Jim Rommel • Sr. Directory Specialist: Perot Systems Incorporated • 4 years experience with X.500/LDAP Directory Services at Texas Instruments and Perot Systems • Prior experience with Object Repository Technology • X.500/LDAP Experience includes: • Schema and DIT Design • Directory Infrastructure Integration • Directory Synchronization • LDAP Development • Client DUA Development • X.500/LDAP Vendor evaluations • Installation and Maintennance of 4 several X.500/LDAP products

  3. DIT Design What is a DIT? • Directory Information Tree • The logical hierarchical structure and categorization of directory information • Different naming attributes within the tree: • c : country • o : organization • ou : organizational unit • l : locality • cn : common name • DIT Structure rules determine which naming attributes must preceed others in the hierarchy • Each entry in a Directory must have a unique Distinguished Name (DN)

  4. DIT Design: People By Department c=US o=Acme ou=R&D ou=Sales ou=Engineering ou=Accounting ou=Mfg. cn=Mike Smith

  5. DIT Design: Types of People c=US o=Acme ou=Employees ou=Contractors ou=Customers ou=Others cn=Mike Smith

  6. DIT Design: By Location c=US o=Acme l=Headquarters l=New York l=Dallas l=Chicago l=Los Angeles cn=Mike Smith

  7. DIT Design: Deep Tree By Department c=US o=Acme ou=People l=Asia l=North America l=Europe l=New York l=Dallas l=Japan l=Los Angeles l=Singapore l=London l=Munich l=Paris cn=Mike Smith

  8. DIT Design: Deep Tree c=US o=Acme ou=People l=Asia l=North America cn=Joe Boss ou=Sales ou=Engineering cn=Clara Jordan ou=Engineering ou=MFG ou=R&D l=LA l=NYC cn=Mike Smith l=DFW cn=Mike Smith cn=Soopy Sales

  9. DIT Design: Flat Tree c=US o=Acme ou=People cn=Mike Smith

  10. DIT Design: Flat Tree c=US o=Acme ou=People cn=Mike Smith #1 cn=Mike Smith #2

  11. DIT Design: Perot Systems DIT c=US o=Acme ou=People cn =SmithET cn =AikmanTA cn =SandersDJ cn = GonzalesJ cn =ModanoMW

  12. DIT Design: Perot Systems DIT c=US o=Acme ou=Groups ou=People ou=Locations ou=Apps ou=Systems ou=Schema cn =SmithET site=TX-SD cn=Directory User cn =AikmanTA site=TX-RI cn=Mail Admin cn =SandersDJ cn=Medical Admin site=SW-BK cn = GonzalesJ cn=Medical User site=NY-AA cn =ModanoMW ou=Medical ou=Resumes ou=Web Sites

  13. DIT Design: Deep -vs- Flat Trees Deep Trees: • Can result in long Distinguished Names (DN) • May reflect your actual corporate structure • Can result in administrative problems if your organization is constantly changing • Better chance of having unique names within a subtree • Works well if you want to distribute the data across multiple DSAs and do multi-mastering

  14. DIT Design: Deep -vs- Flat Trees Flat Trees: • No need to categorize people • Short Distinguished Names, easy to remember and type • DIT is very stable: not affected by organizational changes, and easy to administer • Higher chance of name collisions • Not well suited for Browsing • Can result in longer load times or startup times, depending on the Directory Product you use

  15. DIT Design: Selecting a Distinguished Name c=US - DN Changes if a female marries - DN Changes if I change my nickname - Name may not be unique. o=Perot Systems ou=People cn = Mike Smith cn=Mike Smith, ou=People, o=Perot Systems, c=US

  16. DIT Design: Selecting a Distinguished Name c=US + DN Guaranteed to be unique + DN Never Changes + More robust searching using name components o=Perot Systems -Browser shows useless information -Microsoft and Netscape mail clients expected a real name in the commonName (cn) field. ou=People cn = 0175387 givenName = Michael nickname = Mike surname = Smith cn=0175387, ou=People, o=Perot Systems, c=US

  17. DIT Design: Selecting a Distinguished Name c=US + DN Guaranteed to be unique + DN Never Changes + More robust searching using name components - Browser shows useless information o=Perot Systems +commonName (cn) field contains a real name to work well with other LDAP applications. ou=People uid = 0175387 cn = Mike Smith givenName = Michael nickname = Mike surname = Smith uid=0175387, ou=People, o=Perot Systems, c=US

  18. DIT Design: Selecting a Distinguished Name c=US + DN Guaranteed to be unique + More robust searching using name components + commonName (cn) field contains a real name o=Perot Systems +Browser shows more useful information (although not as ideal as a full name) +Directly maps to a user’s logon ID (can be used for single signon) ou=People -DN has the potential to change if the name or UID changes -Entrust product requires the commonName (cn) to be part of the DN. uid = smithMJ cn = Mike Smith givenName = Michael nickname = Mike surname = Smith uid=smithMJ, ou=People, o=Perot Systems, c=US

  19. DIT Design: Selecting a Distinguished Name + DN Guaranteed to be unique + More robust searching using name components + Directly maps to a user’s logon ID (can be used for single signon) + commonName (cn) field contains a real name +commonName (cn) is part of the DN - DN has the potential to change c=US o=Perot Systems ou=People -Very hokey way of achieving uniqueness -Complicated DN syntax -More complicated Directory Logon procedures -This syntax may not be accepted as standard in the future. cn = Mike Smith + uid = smithMJ givenName = Michael nickname = Mike surname = Smith cn=Mike Smith + uid=smithMJ, ou=People, o=Perot Systems, c=US

  20. DIT Design: Selecting a Distinguished Name c=US + DN Guaranteed to be unique + More robust searching using name components + Directly maps to a user’s logon ID (can be used for single signon) + commonName (cn) field contains a real name + commonName (cn) is part of the DN - DN has the potential to change o=Perot Systems ou=People cn = smithMJ cn = Mike Smith givenName = Michael nickname = Mike surname = Smith uid = smithMJ - Data is duplicated in several areas (uid and cn) - Value displayed for commonName may vary. cn=smithMJ, ou=People, o=Perot Systems, c=US

  21. DIT Design: Selecting a Distinguished Name + DN Guaranteed to be unique + More robust searching using name components + Directly maps to a user’s logon ID (can be used for single signon) + commonName (cn) field contains a real name +commonName (cn) is part of the DN c=US o=Perot Systems ou=People ou=Certificates cn = smithMJ ALIAS POINTER uid = smithMJ cn = Mike Smith givenName = Michael nickname = Mike surname = Smith - DN has the potential to change -Problems with X.500 aliases: -no built-in referential integrity-will LDAPv3 support them? cn=smithMJ, ou=People, o=Perot Systems, c=US uid=smithMJ, ou=Certificates, o=Perot Systems, c=US

  22. DIT Design: An IETF DIT Naming Proposal http://www.imc.org/draft-ietf-ids-dirnaming “The X.500 approach to naming has become an obstacle to the wide deployment of directory-enabled applications on the Internet.”

  23. DIT Design: An IETF DIT Naming Proposal http://www.imc.org/draft-ietf-ids-dirnaming • The dc named attribute stands for domain component • The idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com) dc=com dc=acme

  24. DIT Design: An IETF DIT Naming Proposal http://www.imc.org/draft-ietf-ids-dirnaming • The dc named attribute stands for domain component • The idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com) dc=com dc=acme • Lower levels of the tree will also use the dc named attribute dc=Corporate dc=Customers

  25. DIT Design: An IETF DIT Naming Proposal http://www.imc.org/draft-ietf-ids-dirnaming • The dc named attribute stands for domain component • The idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com) • Lower levels of the tree will also use the dc named attribute dc=com dc=acme dc=Corporate dc=DalSite • Each user is identified with the uid named attribute containing the email address. uid = mike.smith@acme.com cn = Mike Smith givenName = Michael surname = Smith uid = jane.doe@acme.com cn = Jane Doe givenName = Jane surname = Doe

  26. DIT Design Conclusion • Robust DIT Naming and design standards are not in place yet • There is currently no single “right way” to design your DIT that applies to everyone • Take into consideration your organization • the organizational structure • the organization’s tendency to change • the organization’s current size and potential to grow • Take into consideration the how you want to use the directory • what information will be stored in the directory • who will own what data and how will be be mastered • what what other systems in the infrastructure will be using/storing the data • how and what applications will be accessing the data

  27. Questions??? Jim RommelPerot Systems Corporation email: jim.rommel@ps.netphone: 972-461-3689fax: 972-461-3030

More Related