# Presentation: 499244

## NIH Architecture Review

- Second Briefing
- Results of Hybrid Flat-Deep RFI
*Prepared by The Burton Group*
*August 5, 1998*

## Requirements

- NIH has a large population of "organizationally mobile" People in its directory, including temporary staff such as Visiting Scientists, Contractors, and Exchange Students in addition to employees.
- NIH believes that a high degree of stability in directory Distinguished Names (DNs) is necessary in order to maintain referential integrity, and to avoid frequent revocation of Certificates due to DN changes.
- At the same, time NIH has rich organizational data available in its HR systems. NIH wishes to use this rich organizational data to search for and organize People and Role objects.

## Desired Solution

- Flat Namespace

- O=NIH

- Organizational Unit

- Organizational Unit

- Aliases or copies

- C=US

- O=NIH

- C=US

- Master Entries

***Proposed Hybrid Flat+Deep***

***DIT Design***

## RFI was sent to

- CDS
- IBM and Telstra
- ISOCOR
- Netscape
- Siemens/Nixdorf
- Zoomit

## Summary of Answers

**CDS:** Can do flat+deep through a customized solution using its Global User Agent.   Defers most issues to a consulting process.  Granular access control would be costly.
**IBM and Telstra:**  Does not recommend flat+deep structure.  Could do it and guarantee referential integrity, but not granular access control.
**ISOCOR:**  Does not recommend flat+deep, but could do it once their Meta-Connect product is available.
**Netscape:**  Does not recommend flat+deep.  Recommends flat structure with OU attributes in entries.  Can provide granular access control.
**Siemens/Nixdorf:**  Has not done flat+deep in the past, but could do it.  Might have performance issues.
**Zoomit:**  Could do flat+deep.  Recommends storing master data in the deep DIT.

## Additional Notes

**Certificates:**  Deep trees do cause certificate revocation concerns.  While browsers look for the “subjAltName” field of the Certificate to contain an email address and ignore the Cert’s DN, other applications may require the DN to be valid.
**Aliases:**  Microsoft and Netscape do not or will not support aliases in their LDAP server products.  Browser support for aliases is uncertain.

## Backup Slides

## Control Data Contact

- Mark Heckhaus at 301-738-5575 or Cecilia Williams 301-738-5547.

## Control Data Process

- Control Data’s experienced designers work with customers in defining the X.500 Directory schema and tree structure, as well as specifying an enterprise name space design.  Directory mappings for bi-directional directory synchronization or meta-directory integration must be carefully planned.  This is a goal-oriented consulting service...
*In accommodating the hybrid flat+deep DIT, Control Data would examine the feasibility of adapting the Global User Administration solution to automatically construct the deep-side of the DIT.*

## More Control Data Input

- Control Data does not consider establishing the directory and loading entries to be a large task.  Upon completion of loading the directory, users would have the ability to search the directory and access information via web browsers and LDAP clients.
- Basic administrative functions (add/delete/modify) could also be demonstrated using a single administrator for the entire DIT.  *However, customizing the existing administration tools to establish access control across multiple administrators in the hybrid flat+deep DIT would require further planning and development time.*

## IBM and Telstra

- We have customers that have built and piloted similar directories to the approach suggested by NIH.    The design models applied have always been to start small and build upon successes.   Building an “initial” developmental DIT is not a large task.  Some of the C/C++ and Perl scripts developed on other projects would be reusable.
*The flat+deep structure should be avoided if possible.*  Referential integrity is not a concern; our View500 DSA "DN Tracking" feature synchronizes an entry's DN with references to it.  The necessity of the "flat + deep" structure is dependent only on the envisaged usage of the certificates.

## IBM and Telstra

- Providing access control over the "deep" part of the DIT is okay. However any access controls specified in the "deep" part will not apply to the "flat" part. This is entirely due to the way in which X.500 access control works (i.e. it is product independent). *The only way to get access control onto the "flat" part is by assigning it on a per entry basis.* This would seem to be a major drawback to the "flat + deep" scheme.

## ISOCOR

- The use of aliases to build the organizational structure (a la US Defense Messaging System DIT design) can be fraught with administrative issues.  It is fine as long as the DIT is not distributed across multiple DSAs, however any attempt to distribute can be a disaster.
- We do not have any major accounts that have implemented this approach, although we have validated it internally.
- The MetaConnect Controller (soon to enter beta) could easily be used to maintain a copy of the flat tree information in an organizational hierarchy, or vise-versa.  This would be recommended rather than maintaining aliases for performance reasons.
- Not a large task, but would have to involve our professional services organization to scope the project.

## ISOCOR Notes(corroborated from other sources)

- Browser clients offer a simple search interface only and will display the DN (which may not be attractive if you are using the UID).  They also will probably have trouble with multi-valued RDNs.  The search interface will not provide a strong indication of the organizational structure in the way that a browse interface would
- In the future, it may not be necessary to put DNs in Certs.  Already today, browser clients are mainly looking at an email address stored in the “subjectAltName” field. DN is still mandatory in certs, however, and some applications may require that it be valid.  The PKIX working group at the IETF is deliberating decoupling certs and DNs, but no consensus.

## Netscape

- Rich Pfautz
- 301 571 3943
- _rickp@netscape.com_

## Netscape Response

- Netscape Directory Server supports a pluggable interface that would allow the server to be customized in such a way that it would simultaneously maintain the deep and flat structure.
- Netscape recommends a more cost effective, lower maintenance solution involves using just a flat structure with rich organizational data stored as attributes in a person's entry.

## Netscape Recommended Structure

- uid=123456789, ou=People, o=nih.org
- Netscape's internal directory deployment as well as those of nearly all Netscape customer deployments use this
- To represent the rich organizational structure available from NIH HR databases, Netscape recommends adding one or more additional attributes to the user records.
- Applications will find it easier to query for roles and organizational affiliations because they can simply issue queries such as (ou=Consulting Physicians) without needing to understand the "deep" structure of the DIT

## Netscape Example

-    ou: Consulting Physicians ou: Student Evaluation Committee location: Bethesda role: surgeon role: Department Head status: permanent status: non-exempt manager: uid=123456709, ou=People, o=NIH, c=US secretary: uid=123456719, ou=People, o=NIH, c=US

## Netscape Access Control

- Using the ACL, permissions can be set for:
- the entire directory,
- a particular subtree of the directory,
- specific entries in the directory,
- a specific set of entry attributes,
- any entry that matches a given LDAP search filter.
- In addition, permissions can be set for a specific user, all users belonging to a specific group, or for all users of the directory. Finally, access can be defined based upon a network location such as an IP address or a DNS name.

## Siemens/Nixdorf

*Siemens Nixdorf does not have any references, which implemented a hybrid flat+deep DIT.*  We do have customers with a very deep DIT structure.
*The command-line DAP client dirxcp can be used to create and maintain the hybrid flat+deep DIT.* The client dirxcp is Tcl based, which allows the creation of the necessary environment of the automated construction and maintenance of the DIT. We believe that one week would be enough for the proof of concept.

## Siemens/Nixdorf

*The introduction of copied entries is always not a very good idea*, since administrators have to deal with the consistency of the original and the copied data.  Unfortunately, we do not have experiences with such a large amount of alias entries. It will definitely impact the performance. *As long as the aliases and the original data reside on the same DSA the performance impact should not be critical.* If the aliases reside on a different DSA, we do not have the possibility to check the consistency of the alias-relationships, which is done with a single DSA implementation.  LDAP client behavior when encountering aliases is somewhat unknown.

## Siemens/Nixdorf

*Access controls would be valid for both parts of the DIT.* Access controls would be managed with the GUI DirXmanage or with dirxcp. DirXmanage would have some performance-issues with the flat tree, since it would read all the entries at once, but these will be solved with the paged results feature in the next release.
- When you work with copies you always will encounter consistency issues. You will have a performance impact when you access the aliases. In our case the read operations should not decrease by more than 10% - 20%, in case of read operations. *We can not make any comments regarding updating operations. They have to be measured.*

## Zoomit

- We believe it would be difficult to pinpoint many customers who have implemented this approach to solve the same business problem you are trying to solve. However, Zoomit Corporation feels that a hybrid flat+deep DIT is the correct solution.  We have recently recommended a variation of this solution to Prudential Insurance of America.

## Zoomit

- Zoomit VIA has the capability of automatically generating a hybrid flat+deep DIT structure to solve the business problem presented. In addition, Zoomit VIA's Metadirectory capabilities will allow for the automated construction and maintenance of the proposed DIT from NIH's underlying NOS, e-mail, and HR database systems. Since Zoomit VIA can generate the deep DIT portion of the tree most easily from these various systems, we produce the flat part of the tree as alias entries pointing back to the master entries in the deep DIT.

## Zoomit

- Zoomit recommends that the master entries be stored in the deep DIT portion of the namespace while the aliases are stored in the flat portion of the tree. This would enable OU level shadowing or distribution of data to any LDAP/DSA, which could be an important consideration depending on the size and geographic distribution of the NIH. Also, Zoomit VIA's future implementation of cryptologistics will "tie" encryption certificates to the "unchanging" DN in the flat namespace and will "tie" the signature certificates to the "changing" DN in the deep DIT.
- The use of aliases is recommended because referential integrity is inherently maintained. However, Zoomit VIA 2.0 implements LDAP "push" technology so that a copy of a record would be automatically updated by the master server. So, depending on the results of the pilot or further investigation, it would be possible to choose either method with a minimal impact on performance.