# Presentation: 045960

## Preliminary NIH Directory Architecture Review: Discussion Slides

- Prepared by The Burton Group
- for NIH
- July 15, 1998
- Daniel Blum, Senior Vice President
- dblum@tbg.com
- www.tbg.com

## NIH Directory Discussion

- Initial Feedback:
- Logical and physical architecture seem well-defined as do NIH directory object schemas
- Proposed “Hybrid-Flat” DIT design should be validated
- Inventory of directories/databases needed
- Requirements input needed from application development, other groups
- Proof of Concept Directory recommended before Pilot
- Pilot Definition must be refined to validate timeline

## NIH Directory Discussion

**Agenda**
- Naming Issues
- Proof of Concept
- Directory Pilot

## Naming Issues

- General Objectives
- Identify the name structure alternatives
- Recommend a name structure plan for the enterprise directory hierarchy
- Get the top level name structure right, because it is hard to change later
- Prerequisites (from inventory)
- Enterprise organizational and geographic topology (including how users perceive the organization)
- Security requirements
- What structural data is available
- How information will be maintained in the enterprise directory (centrally, distributed, or a combination of the two)

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- General Approaches
- LDAP/X.500 Top Level Approach
- Multinational organizational
- Country/Organization approach (one tree)
- Country/Organization approach (multiple trees)
- DNS and X.500 Top Level approach
- Map to existing Intranet domain components (DCs)
- Structure within an organization or domain
- Organizational unit breakdown (OUs named after functions)
- Region or Site breakdown (OUs named after sites)
- Flat namespace (just users)

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- O=NIH

- C=US

- National Organization, One Tree
- Conventional LDAP/X.500 naming
- Acceptable for NIH top level naming

***Directory Information Base***

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- Organizational Unit

- Organizational Unit

- Organization

- Cost Center

- Organization

- Cost Center

- OU=People

- OU=Applications

- Organizational naming examples inside the tree

***Note: Within the enterprise directory, should the IC internal structure vary among IC, or always be the same?***

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- Region

- Organization

- Site

- Country

- Site

- Inside the tree, geographical naming

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- OU=“A”

- Organization

- OU=“AA”

- Flat Namespace

- Organization

- Organizational Unit

- Organizational Unit

- Flat Namespace

- Flat Namespace

- Inside the tree, flat naming
- Hybrid flat naming with aliases

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- General decision factors
- Ease of use:  Supports end user friendly structures for navigation and searching
- Feasibility:  Can you get the desired structural information out of a facility list or HR organizational database?
- Stability:  How often does the structure change?
- Performance: Does the naming structure allow information to be distributed properly?
- Access control granularity:  Need different privileges per container?
- Administration: Supports centralized or distributed updating, with necessary access control granularity?
- Development: How much configuration or programming (if any) to build the structure?

**I   n  -  d   e   p   t   h       t   e   c   h   n   o   l   o   g   y       a   n   a   l   y   s   i   s       f   o   r       n   e   t   w   o   r   k       p   l   a   n   n   e   r   s**
**Copyright © 1998, The Burton Group.  All Rights Reserved**

## Naming Issues

- NIH data points
- SAC codes available to model organizational structure
- SAC codes fairly “real” and “stable”
- Some administration will be done centrally by “UID”, “Telecom”, “Parking”, “Badge” groups
- Some data will be imported from HRDB, PH, NDS, and other systems, and will continue to be administered from within those systems by cross-functional support groups
- Some data needs to be updated by ICs
- NIH does want to store X.509 Certificates in the user entries
- NIH does want to maintain and propagate unique user identifiers (UIDs)
- Lots of “temps” need to be stored in the directory

## Naming Issues

- NIH Schema Alternatives
- Flat namespace
- Organizational Namespace based on SAC code
- Hybrid flat namespace
- Flat namespace contains all the people data
- Organizational namespace contains aliases that point into the flat namespace
- Note:  Each alternative is equally “searchable” and all have problems representing people working in multiple OUs

## Naming Issues

- Flat namespace
- Advantage:  Stable distinguished names used in X.509 certificates, roles, and other references
- Advantage:  Readily accommodates people other than NIH employees
- Advantage:  No risk of duplicating, or need for aliasing, users working in multiple organizations
- Disadvantage: Does not allow structural browsing (can only store org. attributes in people entries)
- Disadvantage: No container granularity of access control for centralized lookups or updates to meta-directory
- Disadvantage: No container granularity for replication or collective attributes
- Disadvantage: Cumbersome to represent org. role objects

## Naming Issues

- Organizational namespace
- Advantage:  No development/administration to maintain aliases
- Advantage:  Users can browse NIH by organization structure
- Advantage:  Can include Role objects in organizational view, helps accommodate people in multiple organizations
- Advantage:  Container granularity available for access control, replication, and collective attributes
- Disadvantage: Occasional structural changes may lead to bulk Certificate revocation, bulk referential attribute updates
- Disadvantage: Tools must be developed to manage the structure
- Disadvantage:  May still need aliases for users working in multiple organizations.  Possibility of duplication.

## Naming Issues

- Hybrid Flat + Organizational namespace
- Advantage:  In some respects, best of both worlds
- Users can browse NIH by organization structure
- Can include Role objects in organizational view, helps accommodate people in multiple organizations
- DNs and references are stable
- Certs last as long as you want
- Advantage:  Organizational attributes can be listed in organizational entries (though not using collective attributes)
- Advantage:  Easily extended to add other views (geographic)
- Disadvantage: Possible performance impact of following aliases on all directory operations
- (continued)

## Naming Issues

- Hybrid Flat + Organizational namespace
- Disadvantage: Granular access control, replication and collectives are probably not available with the off the shelf directory using this hybrid configuration (though an inhouse developed update tool could key off the secondary organizational structure to implement access control in a custom manner).

## NIH Directory Discussion

**Agenda**
- Naming Issues
- Proof of Concept
- Directory Pilot

## NIH Directory Proof of Concept

- What is a Directory proof of concept?
- Take a logical design and see if it will work
-  What is a Directory pilot?
- Now, take a substantial group of real end users and see if they can live with it
- Proof of Concepts recommended when
- It’s a question of emerging technologies (LDAP directory + PKI)
- A proposed implementation of a mature technology is unusual or complex (NIH hybrid flat naming, use of roles, custom objects)
- When the spec HAS to be right the first time or contract changes will cost a lot of money (The NIH Pilot)

## NIH Directory Proof of Concept

- What would it involve?
- A reasonably powerful server
- Evaluation license for directory with 200K or more entries
- Some test files from the directories you want to model
- A few inhouse power user developers for a few weeks
- Some vendor or contractor support
- Try to involve the Technical Lead person from the same contractor you’ll use for the pilot
- All the ducks are lined up when the vendor/contractor comes over

## NIH Directory Proof of Concept

- What questions does it answer?
- Do you have the right directory data collected to load an initial O=NIH?
- Can you create the hybrid flat structure?
- Can you create the custom NIH objects?
- Do the custom objects in a hybrid flat structure look okay and perform well from LDAP clients such as IE, Navigator, Notes, etc.?
- What were your access control options?
- Are you better off with RDN of CN?  RDN of UID? Or RDN of CN and UID?
- (Continued)

## NIH Directory Proof of Concept

- What questions does it answer?
- How clean are the DBs and databases we're connecting?  How much effort is involved in associating UIDs and joining them?
- What are the lessons learned?
- And many others...

## NIH Directory Discussion

**Agenda**
- Naming Issues
- Proof of Concept
- Directory Pilot

## NIH Directory Pilot

- Typical Directory Pilot Methodology
- Pick an application(s) for which your Pilot Directory will be needed by users
- Develop tools and procedures to load and refresh the Pilot Directory
- Select a group of pilot users (50-500)
- Select a pilot administrator(s)
- Develop an operational plan to support the Directory Pilot (or you’ll lose your users fast)
- Line up dedicated technical support (at least 2)
- Line up technical writers to document, survey, and report on lessons learned
- Hold orientation sessions.  Then Begin.

## NIH Directory Pilot

- Example Pilot Scenario (not NIH specific)
- Select 200 R&D users in at least 2 sites employing POP3 clients such as Outlook Express, Eudora, Netscape
- Load email, HR, and phone data into the meta-directory, and test procedures for daily update from existing production sources.
- Note: If UIDs are not pre-propagated to these entire databases, the data should be a “clean subset” that can be merged repeatedly
- Orient administrators (by meeting) and users (by email)
- Administrators set up clients to access directory, or encourage users to do so.  Now the fun begins.
- For Extra Credit: Add some Certificates, more directories, custom applications, etc.

## NIH Pilot Directory

- Need to refine the actual NIH Pilot
- Who are the users?
- What are they doing with the directory?
- How will IT support the Pilot?
- How, where, and when does the UID database and UID propagation to existing directories figure into the pilot timeline?
- What is the phasing for the directory/database integration (can’t do them all at once...)?
- And many others...

## NIH Directory Discussion

***THE END***

## This slide intentionally blank

## This slide intentionally blank