Large Scale LDAP Deployment

Tips and tricks to deploy a large scale open source LDAP environment.
(LinuxCon 2011)

Transcript

1. Large Scale LDAP Deployment Luiz Viana, luiz.viana@locaweb.com.br Locaweb Systems Administrator / Nov 17, 2011
2. Directory Services • Stores and organizes information in a directory • Provide any organized set of records • Directory is a map between names and values • Looks like a dictionary • A name may be associated with multiple pieces of data
3. Origin and Influences LDAP is an outgrowth of the x.500 standard • Data access protocol • Incorporated into the Open Systems Interconnection • Too complex to support
4. What's LDAP Lightweight Directory Access Protocol Q: Is this a database? A: Not really ➔ Optimized for lookups ➔ Not designed to show complex relationships
5. Protocol Overview • Client starts a connection with the Directory System Agent • Client sends an operation request to the server • Server sends responses in return Common behavior: • Client doesn't need to wait response to send a new request • Server may send the responses in any order
6. • StartTLS (LDAP v3) • Bind • Unbind • Search • Compare Client Request Operations • Add entry • Delete entry • Modify entry • Extended Operations • Abandon
7. Directory Structure • A directory is a tree of directory entries • An entry consists of a set of attributes • Attributes must have names • Entries have a unique identifier (DN = Distinguished Name) Relative Distinguished Name (RDN) RDN is constructed from some attributes in the entry, followed by the parent entry's DN: uid=lviana,ou=People,dc=locaweb,dc=com,dc=br
8. Directory Entries version: 1 dn: uid=jose.cuervo,ou=People,dc=locaweb,dc=com,dc=br objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: top cn: José Cuervo sn: Cuervo givenName: José mail: nobody@locaweb.com.br uid: jose.cuervo UserPassword: 9bGZ1eW0vVHAxVEdsREV1T3dFbnBaL0pWWnM1UGVTa0p Tip: DN's can be changed, but each entry have a unique identifier (UUID)
9. Defining Directory Needs ✔ What should be put in the directory today? ✔ What immediate problem is solved by deploying a directory? ✔ What are your application needs on the directory? ✔ What information will be on the directory now? ✔ What information will be on the directory in the near future? Tip: Perform a site survey before defining the schema!
10. Data Ownership By definition, it refers to the person or organization responsible for making sure the data is up-to-date. Common data ownership strategies: • Read-only global with Read-write restricted to some groups • Individuals have their own read-write subsets • Roles that give groups of people read or write access • Access restricted just to directory managers
11. Object Classes • Each directory entry belongs to at least one object class • Used to group related information • Typically represents a real object • Standard object classes are sufficient for most environments • Can be extended and used with the standard ones
12. Object Class Definition Object class definitions contain the following information: • A unique name • An object identifier that names the object (OID) • A set of mandatory attributes • A set of allowed attributes (optional attributes) objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top MUST (objectclass $ sn $ cn $ userPassword) MAY (description $ seeAlso $ telephoneNumber) X­ORIGIN 'RFC 2252' )
13. Customizing the Schema Good practices when customizing the schema: • Keep everything as simple as possible • Reuse existing elements whenever possible • Avoid using too many mandatory attributes • Do not modify existing definitions of attributes
14. Assigning Object Identifiers Don't forget: Each LDAP object class or attribute must be assigned a unique name and object identifier (OID) 1.Obtain an OID from Internet Assigned Numbers Authority (IANA) 2.Create an OID registry to track OID assignments 3.Create branches in the OID tree accommodating elements Tip: Create at least 2 branches on the directory schema, using OID.1 for attributes and OID.2 for object classes. Define custom rules or controls adding new branches.
15. Maintaining Consistent Schema ✔ Ensure that attributes conform to the schema rules ✔ Use syntax validation in attribute values ✔ Select and apply a consistent data format ✔ Use encryption when needed Attention when using replicated schemas! Do not: ✗ Modify the schema on a read-only replica ✗ Use too many useless ACI's ✗ Create same name attributes that use different syntaxes
16. Directory Tree Be sure to define the directory tree before deployment! ➔ Simplified directory data ➔ Flexibility in creating replication policies ➔ Directory data according to the access controls ➔ Support for the client applications ➔ Simplified navigation for the directory
17. Designing Directory Tree • Allign suffix (Base DN) with a Internet domain name • Globally unique and static • Short and easy to remember • Branch the directory according to your organization • Use common objects to define the initial tree • Identify branch points • Define organizational entries needed • Define RDN's for your entries • Naming group entries • Static groups – Few members defined • Dynamic groups – Search filter / Subtree
18. Open Source LDAP Servers Most popular open source directory servers: • 389 / Red Hat Directory Server • Apache Directory Server • OpenLDAP Server • Sun OpenDS / OpenDJ
19. Red Hat Directory Server Full featured directory service, very fast, stable, supports multi-master replication and have extensive documentation. ✔ Multi-master native replication ✔ Active Directory user and group synchronization ✔ Secure authentication and transport (SSLv3, TLSv1, and SASL) ✔ Online, zero downtime, LDAP based schema update and ACI's ✔ Compatible with Linux, Solaris and HP-UX ✗ Lack of administration tools (Java Desktop Client) ✗ Too complex for simple environments
20. Apache Directory Server Full featured directory service, fast, stable, extensible, multi- platform and have a flexible back end administration. ✔ Standards compliant and very extensible (Java) ✔ Front end is completely separable from its back end ✔ Complete administration tool (complete front-end) ✔ Administration via a special system back end (LDAP based) ✔ Ability to handle large amounts of concurrency ✗ Too simple multi master architecture ✗ Lack of documentation
21. OpenLDAP Stable, fast, fully featured and well known open source LDAP server available on most Unix / Linux distributions. ✔ Multi-platform server (C / C++) ✔ Complete libraries ✔ Available natively on most Linux distributions ✔ Multiple back ends and multi-master support ✔ Modular structure ✗ No administration interface ✗ Non native multi-master replication (syncrepl)
22. Sun OpenDS / OpenDJ Stable, fast, extensible, fully featured and well documented standards compliant LDAP v3 server. ✔ Extensible multi-platform server (Entirely Java) ✔ Complete administration tools (GUI / CLI) ✔ Native multi-master replication ✔ Wide choice of deployment configurations ✔ Easy to install, extend, configure and manage ✗ Previous Java knowledge required ✗ Restricted back end support
23. Replication Scenarios Most common replication topologies: • Single master replication • Multi master replication • Cascading replication • Multiple data center replication
24. Single Master Topology Copyright Red Hat Inc.
25. Multi Master Topology Copyright Red Hat Inc.
26. Cascading Topology Copyright Red Hat Inc.
27. Multiple Data Center Topology Copyright Sun Microsystems
28. Fractional Schema Replication Native support on Red Hat Directory Server Q: Does any external replicator provide this feature? A: Yes! LSC Project (LDAP Synchronization Connector)
29. LSC Project • Synchronize entities to LDAP from any data source • Identity management functions included • XML based configuration file (Fully configurable) • Open source project written in Java • Support for SSL / TLS and LDAP v3 extensions • Database support using native JDBC, and Microsoft Active Directory compatible!
30. SDK's and Libraries • Mozilla Directory SDK Project (C, Java, Perl) • OpenLDAP SDK (C++) • Python Library (python-ldap) • Ruby Library (ruby-ldap) • PHP Library (php-ldap) • Erlang Library (eldap) • .NET Library (Novell Directory) ...
31. Python Example #Python simple authentication handler import ldap try: username = "uid=jovem,ou=people,dc=anydomain,dc=com" password = "mypass" conn = ldap.open("127.0.0.1") conn.protocol_version = ldap.VERSION3 conn.simple_bind(username, password) except ldap.LDAPError, e: print e # You can handle the error however you like :)
32. Erlang Example #Erlang simple authentication handler {_,S} = eldap:open(["127.0.0.1"], []). DN = "uid=jovem,ou=people,dc=anydomain,dc=com". eldap:simple_bind(S, DN, "mypass").
33. High Availability Environment Is your directory working in a distributed topology? Yes! So, you have high availability right? No! Applications, systems and services must consume data from more than one directory server!
34. And finally... Questions? :) Presentation available on: http://include.io/talks @luizxx, luiz@include.io
35. Reference • http://en.wikipedia.org/wiki/LDAP • http://docs.redhat.com/docs • http://directory.apache.org • http://opendj.forgerock.org/ • http://directory.fedoraproject.org/ • http://lsc-project.org • https://www.opends.org/wiki/