Directory Services Best Practices Ed Reed, Technologist Novell, Inc.

Why Best Practices? Synchronization Scalability Synergy Security General Make effective use of NDS replication for your applications. Don’t try to make it do things it doesn’t do. Make effective use of namespace design to ensure flexibility and scalability of your applications. Make your application look like it belongs! Leverage your customer’s investment in training, education, and experience to bring them back for more. Avoiding surprises for our customers requires planning in our design. Preserving and empowering customer choice will gain us customers in today’s world. We’re in business to make money, and so are our customers. Our commitment to help customers manage their business is what pays our bills.

Synchronization Suggestions Velocity of Change < 4 changes / hour per value (approx) store configuration, not state Capacity for Change avoid lots of regular changes capacity planning includes configuration, topology, replica placement, number of copies, bandwidth, cpu, … the more change expected, the fewer replicas you should expect Object name changes - they happen! Moves, reorganizations, mergers Change notification to subordinate resource managers Consistency of Data Tight consistency implies Single Master Loose consistency provides better availability of manageability and data Directories are designed for fairly static data Stable status information may be ok, if it’s subject to “flutter” Use SNMP or other protocols to query for real-time status directly, rather than via directory Use Transitive Synch in NDS5.0 To tailor the replication topology Also, limit the number of replicas of each partition Replication is just one method to reduce the cost of availability of data. Use it wisely. See Data Design / Reuse in Synergy, following don’t hard-code names in your applications Read and cache configuration at startup don’t poll for changes, register for change notification Do what makes sense for your application don’t force fit everything to use loose consistency don’t expect robust, failure resistant systems with single master - that’s what SFT-III and TPMs are for use High Confidence bit to force single master behavior

Scalability Enablers Let the customer define the namespace, if possible Avoid flat namespaces Avoid huge #s of objects per container Use Catalog Services to provide flat views Use hierarchy to enable partitioning, right-sizing local storage, and delegation of authority Assume a global namespace Don’t assume anything about what is in [ROOT] Assume many organizations and authorities share the same namespace Place policy near, but below, the organization or organizational unit to which it applies Naming is more political than scientific Don’t impose your bias on your customer NDS is tuned for fast lookup and read operations NewDB will dramatically increase this limit Catalogs server as centralized indexes for search Failure to plan ahead is guaranteed to hurt you later LDAP effectively gives us federated namespaces See the note on Naming, above

Synergy Across Products Data / Design Re-use: defined schema elements, where possible defined relationships, where possible Create new schema when new data elements/attributes are needed new semantics are needed use auxiliary classes, when available Use DN syntax to create relationships Use Groups & Roles to grant rights Means less development time for GUI, Installation, Test more synergy with existing customer data less duplicated effort by administrators less complexity for administrators fewer things for administrators to remember fewer errors by administrators Applications can customize the directory as needed NDS will maintain relationships between objects, groups, and roles, even if object names change this is one of the biggest values of NDS over competitors

Security Principles First, do no harm ship secure products let the customer relax security if they like Let the customer decide how much interoperability with other vendors they want how much trust they have in various authentication & security tools Let the customer manage who they trust to do what differentiate policy based on who and what they trust not all tools are created equal - don’t make customers treat them as if they were Let the customer understand security policy information must be inspect-able & understandable services behavior must be audit-able Novell can’t say it’s sorry fast enough if we screw up or empower our customers to be screwed up without their help It’s a heterogeneous world out there many choices brings complexity and chaos We can help customers manage that complexity And provide them reason to continue buying from us

General Advice Design solutions that work out-of-the-box Easy to install Easy to manage Easy to use Help the customer develop an intuition Consistency breeds loyalty Look-and-feel is an important part of brand identity and recognition Use the directory to provide persistent storage and default policy information for services throughout the service instance life-cycle installation configuration startup in-service shutdown de-installation Technology doesn’t sell, Products sell Data design, object reuse, relationship reuse, common install, common GUI metaphor, consistent APIs, etc. define Novell in our customer’s eyes It’s not a transactional database. Don’t try to make it one. There are lots of applications that traditional databases can’t support. Use the directory for many of them.