LDAP, Open/Closed Tom Jackiewicz, tom@sun4c

1. LDAP, Open/Closed Tom Jackiewicz, tom@sun4c.net Tacos are totally, like, yummy

2. Ok, here we go… • Good topics: OpenLDAP, iPlanet/Netscape, Meta directories, “single sign on”, Integration NIS/Kerb/*anything* • Bad topics: Microsoft in any detail, slashdot trolls, too much web integration

3. Origins • Directories have long existed. Common: NIS/NIS+, DNS, Yellow Pages. • 1989, Quipu (1st X.500 software) released. • The first X.500 standard was published in 1990. (haha).

4. Origins • 1992, UMICH. • 1993, RFC 1487 detailed specifications. • 1998, Netscape shipped first commercial LDAP v3 diretory server. • 1998, OpenLDAP 1.0 released.

5. LDAP Overview • X.500 “heavy” and complicated. • Too much structure in schema. • Lightweight version of DAP over TCP • Basic schema provided • Great flexibility in extending data types

6. LDAP Overview • Thus here’s our problem:- Not enough initial guidelines given to LDAP deployments. - Initially, system administrators with focus on a single environment configured these systems, thus there was minimal planning and no future integration needs were seen.

7. LDAP Overview • RFC’s for LDAP starting creating more structured environments. Was it too late? By the time these were coming together, some of the damage was already done. • RFC’s for X.500 were trying to take over the IT space. The scope was too large.

8. Surveying Your Environment • Look at what is out there before you deploy and start planning out basic design elements. • Many companies currently have information in many databases and directories.

9. Surveying Your Environment • Look at existing data sources for the authoritative sources of:- Logins / Account names- Phone information- Legal names / Preferred Names- System access / Roles- What else do you need?

10. Surveying Your Environment • Customize your script or use a meta directory to consolidate information. • Identify “primary keys” in your other environments to match data. • If possible, keep information consistent and easy to generate based on values and not filters.

11. Surveying Your Environment • Most packaged/commercial meta directories rely on reading “legacy changelog” formats (cn=changelog). • OpenLDAP doesn’t support this as it is not a defined standard. • Come up with your own set of scripts/tools/libraries for accessing information.

12. DIT • The Directory Information Tree is key to having a working environment. • Once set, you will not want to change your DIT. • Be careful when planning to make sure that all future goals of the company are met.

13. DIT • Your organization name (Base DN, I.e. dc=sun4c,dc=net) is at the top of the tree. • OrganizationalUnits should be based on Region, DataCenter or relatively static information. • Organizational Units should NOT be based on function.

14. Schema • Base Schema works for storing basic identity information. Great if you are deploying an LDAP phone book. • Current schema provided for NIS and other information is ugly and often relies on a new container for each type of data. • Don’t do this! Relationships do not belong in LDAP

15. Schema • RFC 2307 - an approach for using LDAP as a network information service. • Guidelines provided within this RFC. • PADL and other packages love these suggestions. • Linux loves these suggestions. • They’re only suggestions.

16. Types of Integration - TRUE • True integration: This is having a product sit on top of LDAP, utilize it for storage, and have the data available via LDAP itself. i.e. a messaging system integrated with LDAP that is also used as a phone directory. • My guidelines for “True integration” involve having LDAP as part of planning.

17. Types of Integration - TRUE • True integration of LDAP also allows you to keep on using LDAP. That is, do not just have LDAP there as a storage for your data (and only your data) but ensure that your LDAP system is available for use (read/write/whatever) by other applications.

18. Types of Integration – TRUE • As a guideline, ask yourself if integration of a system can be done with an already existing LDAP directory. • iPlanet, because of their reliance on LDAP, usually offers a good level of true integration. • Netegrity (for SSO) and IronPort are other vendors/products that allow their product to interface well with LDAP.

19. Types of Integration - Marketing • Marketing integration. • That is, a product puts LDAP on its roadmap because everyone demands it, but the integration is weak. • For example, some vendors would initially use Oracle and then just port data over into LDAP and say they support LDAP.

20. Types of Integration - Marketing • The result is a badly structure LDAP system that is unusable by other products. • Other vendors even shut off all access so only their product can utilize LDAP. • The end result is having multiple LDAP instances in your environment – none talking to each other or sharing any data.

21. Types of Integration – sync • Some product integrate with LDAP using a synchronization. • That is, they store information in their own custom database (or even their own LDAP system) but gather information from your “other” LDAP system. Daily, every few hours, whenever. • How does this differ from a perl script?

22. Types of Integration – on top • It is possible to extend the role of LDAP in your environment by utilizing it as a back end system on which other products sit. • For example, SSO. • For example, additional auth methods.

23. Meta • Meta directory integration. • Critical Path, Sun, Microsoft, etc.

24. NIS • Old LDAP tools for NIS integration relied on synchronization. • NIS tables were retained and old tools were still somewhat usable.

25. NIS • New NIS integration relies on direct (or via module) access to LDAP directory. • PAM is popular.

26. NIS • NIS integration. • Migration tools from www.padl.com conform to RFC 2307 for addressing of traditional network services information.

27. User Management • Users should have a single DN in the directory. A DN per service is a bad idea as the directory grows per service and not per user. • Default management tools enforce their own standards. Make them comply to yours instead.

28. User Management • Centralized user management is good. • By “Centralized” I mean centralized application or centralized guidelines. • Defining an owner of the data is necessary. Providing multiple methods to modify information in the directory creates problems.

29. Replication • Master should be isolated. • Master should have fewer indexes.

30. Replication • Consumers should have more indexes and be optimized for read. • Consider a content switch.

31. Replication • If you need to support multiple applications with different sets of requirements, consider multiple sets of replicas with their own sets of indexes. • Keep the rest of the data consistent.

32. Replication • Master or Masters at top. • If more than 10 consumers, consider replica heads. • Each data center or location should have at least 2 consumers for read and a fail over. • Needs depend on what you want to store and how often it is accessed.

33. (NIS - COEXIST) • During transition? How to coexist? • Migration of yp commands • 1000’s of clients • how to make scale

34. Kerberos • Kerberos is a network authentication protocol designed to prove strong authentication for client-server applications by using secret key cryptography. • MIT created Kerberos as a solution to network security problems.

35. Kerberos • GSSAPI (Generic Security Services Application Programming Interface)+ • SASL (Simple Authentication and Security Layer)= • Support for Kerberos within OpenLDAP

36. Kerberos • To use the GSSAPI mechanism with slapd, you must create a service key with a principal Sasl-realm configuration

37. Kerberos • Compile to include Berkeley DB, SASL. • OpenLDAP/SASL needs to connect to the Kerberos domain. • UserPassword: {KERBEROS}

38. Kerberos • Kerberos packages will have full rights to your LDAP system.

39. SSO • Netegrity, Sun ONE/DSAME, Oblix

40. Commercial LDAP • Commercial LDAP has an advantage. • iPlanet has taken the lead. • Offers direct integration and has innovated in the LDAP world.

41. Limitations of OpenLDAP • OpenLDAP is a standards based system. This is good in an idealistic world. • The commercial vendors of LDAP integration tools and implementations are evil. • Commercial tools that will make it worthwhile to implement LDAP require proprietary features.

42. Limitations of OpenLDAP • Netscape / iPlanet has taken the lead of LDAP *innovation* • OpenLDAP community has not advanced LDAP and has been focused more on integration of useful tools. • Useful tools don’t move heads of your managers.

43. Limitations of OpenLDAP • Meta Directories are a big thing now. • iPlanet provides class of service (objectclass=costemplate) to store mappings. • For example, everyone in your company that has a location of US has the language preference set to English. COS lets you set this as a dynamic mapping.

44. Limitations of OpenLDAP • However, because COS is not a standard, OpenLDAP does not support it. • Directory 10,000 users = (10,000 attributes pointing to English) = 10,000 changes. • COS allows you to make a single change and SHAZAM.

45. Limitations of OpenLDAP • Roles, relying on class of service, extend the group infrastructure and let you extend the usability of your system. • Once again, these aren’t standards so they don’t really exist in OpenLDAP

46. Limitations of OpenLDAP • The good is that OpenLDAP supports standards. • The bad is that these standards don’t scale well. • The good is that commercial vendors are creating new features based on this. • The bad is that they *require* you use them.

47. What now? • Found out what really cool features the commercial packages have. • Agree on a standard. • Implement them based on your standard. • Tell the vendors to pound sand.

48. Contact • Tom Jackiewicz • www.sun4c.net • tom@sun4c.net • Deploying OpenLDAP from Author’s Press