ldap, open/closed tom jackiewicz, [email protected] tacos are totally, like, yummy
TRANSCRIPT
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
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).
Origins
1992, UMICH.1993, RFC 1487 detailed
specifications.1998, Netscape shipped first
commercial LDAP v3 diretory server.1998, OpenLDAP 1.0 released.
LDAP Overview
X.500 “heavy” and complicated.Too much structure in schema.Lightweight version of DAP over TCPBasic schema providedGreat flexibility in extending data
types
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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?
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.
Meta
Meta directory integration.Critical Path, Sun, Microsoft, etc.
NIS
Old LDAP tools for NIS integration relied on synchronization.
NIS tables were retained and old tools were still somewhat usable.
NIS
New NIS integration relies on direct (or via module) access to LDAP directory.
PAM is popular.
NIS
NIS integration.Migration tools from www.padl.com
conform to RFC 2307 for addressing of traditional network services information.
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.
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.
Replication
Master should be isolated.Master should have fewer indexes.
Replication
Consumers should have more indexes and be optimized for read.
Consider a content switch.
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.
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.
(NIS - COEXIST)
During transition? How to coexist?Migration of yp commands1000’s of clientshow to make scale
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.
Kerberos
GSSAPI (Generic Security Services Application Programming Interface)+
SASL (Simple Authentication and Security Layer)=
Support for Kerberos within OpenLDAP
Kerberos
To use the GSSAPI mechanism with slapd, you must create a service key with a principal Sasl-realm configuration
Kerberos
Compile to include Berkeley DB, SASL.
OpenLDAP/SASL needs to connect to the Kerberos domain.
UserPassword: {KERBEROS}
Kerberos
Kerberos packages will have full rights to your LDAP system.
SSO
Netegrity, Sun ONE/DSAME, Oblix
Commercial LDAP
Commercial LDAP has an advantage.iPlanet has taken the lead. Offers direct integration and has
innovated in the LDAP world.
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.
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.
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.
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.
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
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.
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.
