Class Notes; DCE Secure Core and DFS System Administration

Version 1.2

This is a set of notes for a class taught in Fall 1994 for the University of Pennsylvania's DCE Task Force and interested parties.

This course is based on a pair of courses taught by Transarc Corporation in August 1994 and their help is appreciated.

Course Outline

The course will cover:

Overview of the DCE Secure Core and DFS (weeks 1 and 2)
Working with DCE and DFS (weeks 2 and 3)
Administering the Secure Core (weeks 4 and 5)
Installing the Secure Core (week 5)
Administering DFS (weeks 6 and 7)
Installing DFS (week 8)

All week numbers are subject to change, possibly dramatically and without warning. I am trying to present 35-40 hours of course materials in 8 hours, which will either be impossible or impressive. :-) The class itself is subject to cancellation if nobody is interested.

DCE Overview

1.	Cells
2.	RPCs: Remote Procedure Calls
3.	Threads
4.	Security
	a.	Registry Service
	b.	UUIDs
	c.	Authentication Service
	d.	Privilege Service
5.	Naming
	a.	CDS: the Cell Directory Service
	b.	Global Naming: X.500 and DNS
	c.	Intercell Communications and the GDA
	d.	RPC End-Point Database
6.	Time Service
7.	DFS: Distributed File Service
	a.	Clients
	b.	Servers
	c.	Files
	d.	Data Protection
	e.	Filesets and the File Location Data Base (FLDB)
8.	Putting it all together in a hypothetical UPenn Cell

1. Cells

What is a cell?

Cell: self-contained organization-based collection of users, systems, and network resources, with a common set of services and common administration.

What this means at Penn is not clear, primarily due to the expected arrival of

Hierarchical Cells: set of cells under the same Internet domain name space, with some (as yet unknown) facilities for creating symbolic links between entries in the common Cell Directory Service.

Cells are independent of the number and types of machines and networks.

2. RPCs : Remote Procedure Calls

Remote Procedure Calls: RPCs are system calls for DCE inter-process communications that are used extensively by all DCE services

3. Threads

Threads: Lightweight sub-processes that allow programmers to divide a process into parallel, independent processes that execute independently.

In other words, clients and servers can talk and listen with multiple mouths and ears all at the same time, or carry on multiple independent conversations.

4. Security

Registry Service

Definitions:

Principal:: a DCE person, computer, server process, or cell
Group:: a set of principals -- used to control access. Principals can belong to multiple groups simultaneously, and usually do.
Organization:: a set of principals -- used to control password policy, e.g., how often passwords must be changed.

Note: Organizations and Groups are conceptually peers -- neither contains the other, even though their names might imply that groups are subsets of organizations.

Account:: information used when a principal logs in, e.g., password, group, organization, account expiration date, and home directory.

Security Registry: the cell's database of DCE principals, groups, organizations, and accounts. This is separate from member systems' /etc/passwd and /etc/group files.

While we will probably want to deploy unified DCE and Unix system logins eventually, it may make sense for us to test and pilot services with the two logins separated. In the separate case, the Unix identity is obtained from /bin/login, and the DCE identity from dce_login.

DCE vendors will the two to be combined, which would require system administrators to synchronize Unix and DCE users, groups and accounts.

DCE administrators will still require multiple identities.

UUIDs

128-bit Universal Unique ID for cells, principals, groups, organizations, RPC interfaces, and just about everything else in the DCE.

Derived from network MAC address (e.g., Ethernet), process id, a time stamp, and additional bits for uniqueness.

They look like this:

65fa1425-a243-ca11-f59a-02608c0ffe49,
65FA1425-A243-CA11-F59A-02608C0FFE49, or
65fa1425a243ca11f59a02608c0ffe49.
obsolete form: 65FA1425A243.CA.11.F5.9A.02.60.8C.0F.FE.49

(If the examples above were really supposed to be different forms of the same UUID, they shouldn't look quite as much alike as they do, because the different forms have different pairwise byte orderings or some such fiddle faddle.)

Authentication Service

Authenticate: to determine a principal's identity via a shared secret.

Since everything is a principal, everything can authenticate itself, and the authentication service provides for mutual authentication.

Privilege Service

Privilege: permission to operate on a particular object in specific ways.

Authorization: determination of an authenticated principal's privileges.

DCE Access Control Lists (DCE ACLs): extension to POSIX ACLs, in which each DCE object has an ACL that determines which principals and groups can operate on it and how. This is a generalization of UNIX mode bits, applying to more than just files, describing classes of users beyond owner, owning group, and all others, and controlling more than just read, write and execute operations.

5. Naming

CDS: the Cell Directory Service

CDS is a name to location lookup service that answers questions about what named resources are available where in this cell. E.g., "where are the machines in this cell that are file servers?"

CDS databases are called clearinghouses.

The DCE Namespace is structured as a hierarchical directory tree.

/... is the root of the tree.

/.../upenn.edu will be the root of Penn's DCE namespace.

/.../upenn.edu/printers/seas/pserv-1 could end up being the name of a print service in SEAS at Penn.

/.: is shorthand for the root of the local cell, e.g., /.../upenn.edu, in which case the printer above could also be referenced as /.:/printers/seas/pserv-1

/: is shorthand for the file system, which is really /.../upenn.edu/fs.

Note: because we haven't figured out how Hierarchical Cells will work for us yet, these examples are hypothetical at best.

The big news here is that clients don't have to know where things are, CDS knows and can tell them.

CDS Junctions

CDS maintains information about RPC (i.e., CDS knows servers). In addition, some RPC servers, DFS and Security in particular, maintain their own name spaces.

A CDS Junction is the interface to the non-CDS part of the DCE namespace. Junctions are to the CDS namespace as special device "files" are to the Unix file system.

/.:/sec is the security junction and it contains entries like: /.:/sec/principal/shull

note that /.:/sec is the CDS part that allows us to find the security service, and principal/shull is meaningful only to the security service.

Similarly, /.:/fs is the file system junction, which might contain /.:/fs/usr/shull/.cshrc. DCE names are not file names unless they are under /.:/fs (aka /:).

(insert picture here.)

Global Naming: X.500 and DNS

Global Naming: how to locate other, foreign cells, allowing clients in one cell to use servers in other cells

There are two technologies that can be used for global naming, GDS and BIND.

GDS: DCE's Global Directory Service, an implementation of X.500, which features cell names like C=US/O=UPENN.
BIND: Berkeley Internet Name Domain service, is not part of DCE, but an implementation of DNS, the standard Internet Domain Name Service, offering cell names like upenn.edu.

Bottom line: Global Naming is necessary to resolve the names of foreign cells, but it doesn't go into the CDS.

Intercell Communications and the GDA

The Global Directory Agent (or GDA) links the local and remote name services, requiring registration of participating cells.

For example, say we wanted to access a foreign server at MIT, say /.../mit.edu/fs/ftp/pub/emacs/emacs-20.gz

GDA uses DNS to lookup /.../mit.edu,
DNS tells us to talk to MIT's CDS,
MIT's CDS tells us were to find /.../mit.edu/fs,
which is the file system junction (not a CDS object), so,
the file system is then used to serve the requested file.

RPC End-Point Database

Separate endpoint databases are maintained on each machine.

An RPC client that only knows the server name needs to obtain a network address for the machine, and a port number for the service. Thus

If the server is in a foreign cell, the local GDA and either BIND or GDS find the foreign cell's CDS,

The server's CDS passes the client the server's network address,

The server's endpoint database then tells the client which port the service is on, and

the client can then communicate directly with the server.

6. Time Service

System clocks must be synchronized in a DCE to support Kerberos, DFS, and even applications like make in Unix.

DTS is DCE's Distributed Time Service, which guarantees that all DCE machines within acceptable margins of error with respect to the current time.

The Internet standard NTP (Network Time Protocol) can also be used. DTS is simply a means of making sure clocks are synchronized so other components of the DCE work.

7. DFS: Distributed File Service

DFS Clients

Must be DCE Clients

Must run the DFS Cache Manager process and a modified kernel!

If not in secure environment, local disk space is used only for swap and cache, i.e., user files, data and binaries are kept on secure servers.

DFS Servers

Again, must be DCE Clients.

Store DFS files, directories, and ACLs

Fast machines with plenty of disk space.

Disk partitions are exported to make them visible.

DFS server processes actually serve the files to the clients.

Usually DFS Servers should also be DFS Clients so tools and utilities are accessible.

Minimization of server complexity is also desirable, because it increases server stability, e.g., don't run Motif and allow only two logins on your servers.

DFS Files

DFS filenames look similar to other DCE names (actually, DCE names all look like file names). :-)

But, all DFS files, including directories, are stored under the DFS junction /.../upenn.edu/fs (aka /.:/fs and /:).

The following are equivalent within the hypothetical upenn.edu cell:

/.../upenn.edu/fs/usr/shull/.cshrc

/.:/fs/usr/shull/.cshrc

/:/usr/shull/.cshrc

WARNING: Colons are dangerous! Beware /etc/passwd and path entries that use ":" as a delimiter. The shorthands above cause both loud and silent "hurls" in these cases.

DFS Data Protection

Access Control Lists (ACLs) protect DFS files and directories.

ACLs specify lists of users and/or groups and the permission or permissions each has for an object.

ACLs are a generalization of Unix mode fits, able to specify more users, groups, classes of users, and permissions. Users and groups can even be from foreign cells, but this requires mutual trust on the part of the cell administrators.

ACLs are even backward compatible with standard Unix mode bits.

Filesets and the File Location Data Base (FLDB)

Fileset:: a subtree of DFS files and directories.

Filesets are the basic unit for backup, restore, move and quota allocation, e.g., quota for and location of filesets can easily be changed by system administrator.

As of November release of DFS, frequently read, but infrequently changed files, such as system and application binaries, can be replicated on multiple DFS servers to:

1) increase availability through redundancy, and therefore perceived reliability, and

2) balance load for improved performance

Over-subscription of disk quotas is supported

(insert picture here.)

Aggregates:: DFS disk partitions.

Aggregates contain one or more filesets

Are of fixed size on most systems -- compared to filesets which routinely grow and shrink based on usage.

(insert picture here.)

Mount Points:: analogous to Unix mounts; a mechanism for joining filesets to form a single, logical filesystem.

If /:/usr/fred is a mount point for the fileset user.fred, then the root directory of the tree contained in user.fred is accessible via /:/usr/fred. (see picture above.)

Similarly, the destination of /: is a mount point for the cell's root.dfs fileset.

(insert picture here.)

File Location Database -- FLDB

FLDB contains the 1) Fileset name, 2) Numeric ID, and 3) Location (or locations for replicated filesets) for each fileset in the local cell.

Cache managers contact the File Location (FL) Server to figure out where to find a needed fileset. This is necessary because DFS mount points store only the names of filesets, not their locations. DFS Clients cache fileset location information.

(insert picture here.)

FLDBs are replicated to provide load balancing and greater availability.

They should really be run on three (3) stable, secure, DFS servers.

FLDB replicas are not the same as fileset replicas.

8. Putting it all together in a UPenn Cell (as yet hypothetical)

Working with DCE and DFS

1.	Encryption and Decryption
2.	Kerberos for Mutual Authentication
	a.	Ticket Types
	b.	Ticket Expiration
3.	Authentication Commands
	a.	dce_login
	b.	klist
	c.	kinit
	d.	kdestroy
	e.	Unix su
	f.	How DFS Handles Authentication

4.	DCE ACLs
	a.	ACL Structure
	b.	Entry types
	c.	Permission types
	d.	Evaluation
	e.	Default ACLs
	f.	acl_edit
	g.	ACL Managers
	h.	DFS ACLs and Unix Mode Bits
5.	Special Principals and Groups
6.	Basic End-User Troubleshooting
	a.	Checking DCE credentials
	b.	cdscp (CDS Control Program)
	c.	DFS Command Parser
	d.	cm Command Suite
	e.	Troubleshooting checklist

1. Encryption and Decryption

Encryption:: scrambling text with a key so it can only be returned to an understandable form (decrypted) if you have that key in the case of private key encryption systems, or the complementary key, in the case of public key systems.

DES is the private key, Data Encryption Standard promulgated by the government, which is used in Kerberos today.

Some folks are experimenting with the use of RSA, public key technology as a more secure replacement for DES.

We will assume DES-based Kerberos for this class.

Example:

Encrypting "Oh rose, thou art sick," with the key "snafu" might generate the string "dcba3l9kflds7j09sqsldkda".

Decrypting "dcba3l9kflds7j09sqsldkda" with the key "snafu" would then generate "Oh rose, thou art sick,".

However, without the key, even with the right algorithm, figuring out that "dcba3l9kflds7j09sqsldkda" means "Oh rose, thou art sick," would be so computational difficult as to be impractical for almost everyone.

2. Kerberos for Mutual Authentication

Recall that Authentication is the determination of a principal's identity via a shared secret known only by the principal and the security service.

The shared secret for human principals is typically a login password the user types in, but it could also be from a magnetic card, a voice print, a hand-telemetry reader, a challenge/response card, or a smart ID card.

For non-interactive principals, the shared secret is the server key, which is stored in a keytab file on the server's disk. The term key is commonly used for the shared secrets of both users and servers.

Kerberos authenticates the identity of DCE principals, which may have to be distinct from their Unix identities, e.g., the cell-admin.

Kerberos provides mutual authentication of principals -- users to servers and back again.

Password is used only for encryption and decryption, and is therefore not passed over the network.

Kerberos Ticket Types

Ticket-Granting Ticket: the TGT is the user's proof of identity obtained by dce_login, encrypted with key known only to the authentication server,
Privilege Ticket-Granting Ticket: the PTGT is a list of groups to which the user belongs, again obtained by dce_login, and again encrypted with a key known only to the authentication server.
Server Ticket: the Server Ticket is a permit for a user to talk to a specific server, that details the client's identity, is encrypted with the target server's key, and is obtained automatically if a TGT is valid.

(insert picture here.)

Kerberos Ticket Expiration

All tickets expire, according to administrator determined ticket lifetimes.

An unexpired TGT lets a client system automatically refresh other tickets when they expire.

But, when the TGT expires, the client must re-authenticate himself or herself, by resubmitting a password.

When PTGTs expire, systems can automatically refresh it using the keytab file.

Expiration times are inside the encrypted tickets, so clients cannot modify them.

As a rule, the life of server tickets should be less than that of PTGTs, which should, in turn, be less than that of TGTs.

3. Authentication Commands

a. dce_login

b. klist

c. kinit

d. kdestroy

e. Unix su

f. How DFS Handles Authentication

4. DCE ACLs

a. ACL Structure

b. Entry types

c. Permission types

d. Evaluation

e. Default ACLs

f. acl_edit

g. ACL Managers

h. DFS ACLs and Unix Mode Bits

5. Special Principals and Groups

6. Basic End-User Troubleshooting

a. Checking DCE credentials

b. cdscp (CDS Control Program)

c. DFS Command Parser

d. cm Command Suite

e. Troubleshooting checklist

Ba, da, ba, da, ba, da, dat's all Folks!

For now.