# Presentation: 658828

## “Strawperson” NIH Directory Service Architecture

- NIH AMG Technical Subcommittee

- DRAFT 2

## Requirements

- Support access via LDAP v2 (v3 future)
- Support access via ANSI SQL and ODBC
- Support an X.500 directory information model
- Provide high availability via server replication and automatic failover

- DRAFT 2

## Requirements (continued)

- Provide mutual authentication
- Provide for hierarchical management

- DRAFT 2

## Components

- Client Web browsers and other applications
- Directory update Web application service
- NOS and server OS security registries
- Relational DBMS
- Directory servers

- DRAFT 2

## Central Update Architecture

- Directory **queries** performed directly by LDAP clients
- Directory **updates** performed by centrally-managed Web application server

- DRAFT 2

## Directory Architecture Diagram

**RDBMSs**

**OS & NOS**
**Security**
**Registries**

**Directory Servers**

**Browsers**
**and other**
**Web apps**

**Directory Update**
**Service: Business**
**Rules + Workflow**

**HTTPS,LDAP, RPC**
**updates**

**LDAP Queries**

**LDAP**
**updates**

**ODBC/SQL**
**updates**

**LDAP, RPC, e-mail**
**updates**

- DRAFT 2

## Directory Update Service

- Multiple interfaces: HTTPS, LDAP, IIOP, RPC, ...
- Client authentication and privacy
- Automate business process
- Enforce business rules
- Perform workflow
- Maintain audit information
- Synchronize directory with other DBs

- DRAFT 2

## Central Update Rationale

- Simplicity
- Many key data sources are already centralized:
- Organization structure (HRDB)
- Organizational affiliation (HRDB)
- Telephone and FAX(?) numbers

- DRAFT 2

## Central Update Rationale (cont.) 

- Many key data sources are already centralized (cont.):
- Badge numbers (NIH UID)
- Other?
- To ensure interoperability and security, desirable to **enforce** and **automate** **NIH-wide** directory update **business process** (e.g. change phone #)

- DRAFT 2

## Central Update Rationale (cont.)

- Need to update other data repositories in sync with directory:
- RDBMSs (examples?)
- Add/update/delete users/groups/ACLs  in Server OS and NOS security registries:
- Windows NT
- Novell Netware
- UNIX/DCE,NIS
- MVS/RACF

- DRAFT 2

## Central Update Problems

- ICD updates of **decentralized** data sources:
- Office address(?)
- Mail stop?
- Other?
- ICD control of additional directory attributes, entries for non-NIH employees (e.g. grantees)

- DRAFT 2

## Central Update Problems

- Direct employee update of:
- E-mail address?
- Other?
- Can directory update service be replicated?

- DRAFT 2

## Solutions?

- Hierarchical business rules
- Delegation of authorization to ICDs via ACLs on directory entries
- Decentralized update of ICD-specific directory objects

- DRAFT 2

## Physical Implementation

- Replicated, homogeneous, geographically separated servers
- at least 3 on Bethesda campus
- at least 1 each in RTP and Frederick
- Load balancing and failover
- Per site administration and monitoring
- Sync protocol: DISP, LDIF, proprietary
- Note: LDIF **not** part of LDAP standard

- DRAFT 2

## Directory Hierarchy

- o=NIH, c=US

**uniqueIdentifier=0010062400**
-   cn=Robert M. Malick
-   mail=rm14e@nih.gov
-   c=US
-   o=NIH
-   ou=DCRT
-   userCertificate=...
-   ...

**ou=DCRT**
-   manager=“uniqueIdentifier=0010006301,
- 	o=NIH,c=US”
-   sac=HNU

**cn=Rob Malick**

**ou=OCRS**
-   sac=HNU3

**cn=NIH CA**
**  **cACertificate=...
-   CRL=...

**cn=printers**

**cn=pslaser**
-   ip=128.231.128.243
-   device=HP Laser II
-   ...

- alias

**cn=ROJ**
-   person=“uniqueIdentifier=0010000019,o=NIH,c=US”
-   account=ZNNZ
-   ...

**cn=MVS**

**ou=CFB**
-   sac=HNU33

**ou=DSS**
-   sac=HNU333

- customized objectclass

**ou=contractors**

**ou=grantees**

**ou=groups**

**ou=employees**

- DRAFT 2

## Directory Hierarchy

- All persons with UIDs represented at topmost directory level using Lightweight Internet Person Schema with ICD specified as “ou” attribute
- Distinguished name form of NIH UID persons in directory *“uniqueIdentifier=nnnnnnnnnN,o=National Institutes of Health, c=US”*
- ICDs represented at topmost directory level
- Other branches and sections represented within ICD namespaces
- Aliases to top level UID entries used in other levels of hierarchy for ICD namespace referencing purposes (e.g., allows lookup of *“cn=Rob Malick, ou=DCRT, o=National Institutes of Health, c=US”)*
- ICD namespaces organized based on “NIH Organization Handbook”

- DRAFT 2

## Directory Hierarchy- Pros

- Stresses uniqueness of UIDs (not more than one “uniqueIdentifier=.., o=NIH, C=US” allowed)
- Organizations may or may not be represented in topmost directory level based on need
- Potential of administratively partitioned hierarchy
- Partitioning of information in namespaces allows ICD-specific uses of directory services (e.g., customized objectClasses)
- Aliases help transition of legacy namespaces into NIH UID namespace

- DRAFT 2

## Directory Hierarchy - Cons

- Information synchronization for alias entries and attribute indirect references (handled by directory update service)
- Requires centralized o=NIH, C=US name space administration and authority including ou naming scheme and creation authority
- Topmost directory level distinguished names do not contain common name. Distinguished names will be of little help for user identification without additional lookups (application specific). Could be problematic when doing directory maintenance.
- Full organization affiliation of person not represented. Define naming scheme for person’s “ou” attribute?
- Some CA software does not support relative distinguished names of “uniqueIdentifier” (e.g., Netscape CA 1.x)

- DRAFT 2

## Directory Hierarchy Issues

- How is directory going to be accessed most frequently? Is hierarchy optimized for this?
- Non-NIH personnel (grantees, ...). Have separate namespace at top level (e.g., cn=grantee, o=NIH, c=US)? Some particular defining entry attribute?
- Centrally managed directories and fixed objectclass and attribute schema facilitate directory server upgrades and reconfigurations
- Use any schema or recommendations of the Center for Electronic Messaging Technologies Gov’t Electronic Directory (ou=Department of Health and Human Services, o=U.S. Government, c=US)?

- DRAFT 2

## Directory Information Schema

- Lightweight Internet Person Schema (LIPS) - 37 common attributes (general, personal, organization, security,ancillary).
- Reference http://www2.netapps.org/netapps/lipschemafinal.html
- Co-sponsored by Network Applications Consortium (NAC), Microsoft, Netscape, Lotus, Banyan, Worldtalk, Zoomit.

- DRAFT 2

## Directory Information Schema - Issues

- LIPS makes sense only for person entries. Other objectclasses need to be defined as NIH standards.
- LIPS not a standard but being currently implemented by vendors (e.g., Netscape 3.x directory server)
- Administration of NIH and customized objectclasses and their attributes (additions, deletions, definitions). Defining objectclasses of all optional attributes with parent of objectclass “top” can be centrally managed and can be included in any DIT objectclass.
- Access control over entries, objectclasses, and attributes.
- Any additional person attributes needed in person UID entries? Additional NIH objectclasses? Person UID entry access controls.

- DRAFT 2

## Directory Information Schema - Issues

- Attribute formats need to be consistent (e.g., (555) 123-4567 or +1 555 123-4567 or 1 555 123 4567). Effects LDAP client searches and server replication.
- Synchronization of customized objectclasses, attributes and attribute formats
- What will directory be used for (objectclasses determined: devices, persons, machines, groups, etc.)?
- Data planning and enterprise data surveys
- what data does NIH keep
- what needs to go into directory
- will private info be included? Privacy Act ramifications.
- identify master copies of info (e.g., home address master copy in HRDB?)
- identify data ownership
- what groups need to be created for management

- DRAFT 2