Browse Prior Art Database

A DCE Directory/Security Structure for the Intranet/Enterprise

IP.com Disclosure Number: IPCOM000123005D
Original Publication Date: 1998-Apr-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 98K

Publishing Venue

IBM

Related People

Stokes, EJ: AUTHOR

Abstract

The method describes how to transition the use of multiple directories as related to security in the DCE such that the base for a distributed computing infrastructure could be developed that would be applicable to both the Intranet and Enterprise.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

A DCE Directory/Security Structure for the Intranet/Enterprise

      The method describes how to transition the use of multiple
directories as related to security in the DCE such that the base for
a distributed computing infrastructure could be developed that would
be applicable to both the Intranet and Enterprise.

      The directory related information in the DCE security server
is moved into the directory thereby allowing the DCE security server
to function as a security server.  The DCE security server now is (1)
the DCE/vanilla Kerberos server and does only authentication via
Kerberos (DCE or vanilla v5), (2) a ticket granting service, and (3)
a generator of EPACs (Extended Privilege Attribute Certificates).  By
letting the DCE security server do only security functions  allows
the distributed infrastructure to be restructured such that directory
and security components are pluggable, so the customer can choose the
services that best fit his needs.  For example, DCE with its services
as defined today may meet the requirements of an enterprise.  But,
for the customer whose environment is the Internet (or intranet) may
find that he requires Public Key Infrastructure (PKI) security
services and has no need for Kerberos.  Both customers should be able
to deploy exactly what meets his requirements.

      Moving the directory information out of the DCE security server
requires some thought because the directory information consists of
typical directory info such as person object information (names,
address, telephone number, userid, etc) and security related
information necessary  for the security server to maintain itself and
its replicas as well as  security policy information for the cell.
These two types of information  must be structured properly in the
directory service so that each is secure, that is, person info can be
modified by the person whose information it is, and security related
information can be modified by  the administrator (and not by just
anybody).  This is accomplished by the use of access control lists
(ACLs).

      There are 4 types of attributes classes that contain directory
information in the DCE security server for a given cell:
  o  registry attributes - apply to Principal, Group,
      Organization, Account (PGOA)
  o  registry-wide attributes - apply to Organization, Account)
  o  synch attributes (R/O) - maintained by each replica about
      itself
  o  replica specific attributes (R/O) - kept by master for each
      slave

      Most attributes are security related attributes, except for
those explicitly about PGOA (intersection with person and group
objects, for example).

      The DCE security server (registry) also associates this
'directory information' with a c...