directory services best practices ed reed, technologist novell, inc. [email protected]
TRANSCRIPT
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 Changeavoid lots of regular changescapacity 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 DataTight consistency implies Single
MasterLoose consistency provides better
availability of manageability and data
Directories are designed for fairly static dataStable 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 topologyAlso, limit the number of replicas of each partitionReplication is just one method to reduce the cost of
availability of data. Use it wisely.
See Data Design / Reuse in Synergy, followingdon’t hard-code names in your applications
Read and cache configuration at startupdon’t poll for changes, register for change notification
Do what makes sense for your applicationdon’t force fit everything to use loose consistencydon’t expect robust, failure resistant systems with single
master - that’s what SFT-III and TPMs are foruse High Confidence bit to force single master behavior
Scalability Enablers
Let the customer define the namespace, if possible
Avoid flat namespacesAvoid huge #s of objects per containerUse Catalog Services to provide flat
viewsUse hierarchy to enable partitioning,
right-sizing local storage, and delegation of authority
Assume a global namespaceDon’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 scientificDon’t impose your bias on your customer
NDS is tuned for fast lookup and read operationsNewDB will dramatically increase this limitCatalogs server as centralized indexes for search
Failure to plan ahead is guaranteed to hurt you laterLDAP effectively gives us federated namespacesSee the note on Naming, above
Synergy Across Products
Data / Design Re-use:defined schema elements, where
possibledefined relationships, where possible
Create new schema whennew data elements/attributes are
needednew semantics are neededuse auxiliary classes, when available
Use DN syntax to create relationshipsUse Groups & Roles to grant rights
Meansless development time for GUI, Installation, Testmore synergy with existing customer dataless duplicated effort by administratorsless complexity for administratorsfewer things for administrators to rememberfewer 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 harmship secure productslet the customer relax security if they
like
Let the customer decidehow much interoperability with other
vendors they wanthow much trust they have in various
authentication & security tools
Let the customer managewho they trust to do whatdifferentiate 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 understandsecurity policy information must be
inspect-able & understandableservices behavior must be audit-able
Novell can’t say it’s sorry fast enough if we screw upor empower our customers to be screwed up without
their help
It’s a heterogeneous world out theremany 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 installEasy to manageEasy to use
Help the customer develop an intuitionConsistency breeds loyaltyLook-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
installationconfigurationstartupin-serviceshutdownde-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.
