Security in the Cell Directory Environment

In a secure DCE cell operation, a server does not complete a user's request unless the user's identity has been verified through the DCE Authentication Service. So, for example, a CDS server allows a user to create a new directory only if that user's identity has been verified. The process of verifying that users are who they say they are is called authentication. The proof is in the form of a username, or principal name, coupled with a special kind of password.

CDS servers themselves must be authenticated principals for two reasons:

· To prove to clients that they are trustworthy

· To prove to each other that they have the permission to modify and manage the data that they share

The principal name of a CDS server is automatically selected by the configuration program and is placed in a group that contains the names of all CDS servers in the cell. The group is stored as an entry in the DCE Security Service database. After initial contact with a CDS server, the clerk confirms through the Security Service that the server is a valid member of the server group.

Authentication is not an end in itself, but is instead a step in the process of authorization. Once the identity of a principal has been verified, the software must next determine whether that principal has the permissions that are required to perform a requested action. This is called authorization. Therefore, to create a new directory, the user in the previous example must not only be authenticated, but must also have the appropriate permissions.

Servers need to be authenticated to each other because they share and modify replicated data. For example, suppose server A and server B both store a replica of the same directory. Associated with each directory is a list of all the servers authorized to maintain that directory. When a user modifies an entry in the replica at server B, server B must notify server A of the change. Server A does not accept the update unless server B is an authenticated principal and is one of the principals authorized to modify that directory.

The CDS permissions are read, write, insert, delete, test, control, and administer. Each has a slightly different meaning depending on the kind of name it is associated with, but, in general, their meanings are as follows:

· Read permission lets users view data.

· Write permission lets users add or change data.

· Insert permission lets users create entries in a directory.

· Delete permission lets users delete entries.

· Test permission lets users test whether an attribute of a name has a specific value without being able to see any values; that is, without having read permission to the name. The main advantage of this permission is that it gives application programmers a more efficient way to check for a value: rather than reading a whole set of values, the application can test for a particular value.

· Control permission lets users manage the access control list (ACL) of an entry.

· Administer permission lets users manage directory replication.

Note that it is possible to define a special ACL for users who cannot be authenticated or who deliberately request unauthenticated operations. In such a case, the user's identity is not verified, and the ACL entry for unauthenticated users determines whether the user has the permissions to perform the requested action. (See Part 6 of this guide for details on creating ACLs for unauthenticated users.)