In a given DCE cell many security servers may run. Each one of the security servers manages its own copy of the registry database. A security server and its database are known as a replica. The servers collaborate to keep their copies of the database consistent. Only one of the replicas accepts changes, the master replica. The action of copying a change from one server to another is propagating that change. All of the changes that occur in the master registry database are propagated to all remaining replicas at the granularity of the change. That is, whenever a change is made to the master registry, such as when a new principal is added, that change is then propagated to each replica. The act of propagating changes from the master security server to all other replica security servers is considered replication.
Replication improves the system's reliability and availability. When clients bind to a replica they bind to either a read or update site. The master site is the only update site; all read only sites are called slave replicas. If a slave replica fails to respond to a query the client can then rebind to another replica.
No facility for supporting replication is specified in this document, though implementations would likely provide some sort of service functions for this purpose. Typically they would consist of support for administration and configuration functions for DCE installation.
Replication is done only within a cell. That is, within hierarchical cells or cells connected intercell a change within a cell does not force a change or a replica update in any other cell.
When an update arrives at the master, the master server applies the update to its copy of the database. It then adds the update to its propagation queue. The master then persistently tries to deliver the updates on its propagation queue to all replicas. When an update has been delivered to all replicas, the master then removes the update from its propagation queue.
To maintain the synchronicity between the replicas the master replica maintains a propagation queue. Each entry on the propagation queue needs to be sent to one or more replicas. The entries on the propagation queue remain until all replicas have received them. All entries on the queue are positioned on the queue as they occur, positioned in first-in, first-out order. That is, when an event occurs at the master registry it is put on the queue. During normal propagation events the following list shows the interfaces which perform normal propagation. Each entry made to the propagation queue typically would be checkpointed (or preserved) in some manner (as with the registry and replica list). The technique for doing so is not specified in this document.
The current per-modification propagation interfaces are described in
For more information regarding the individual propagation function
calls, please see the appropriate rs_prop sections in
Each time a modification is made to the registry a corresponding entry is made on the propagation queue. In some instances entries are made to the propagation queue and are not propagated out to the replicas immediately. That is, when an entry is added for propagation the interface has a general argument that places the data on the queue with the specific intention of no propagation. A specific instance for the no propagation flag is during change of master. In this specific case, the sequence of events occurring during a change of master, may cause loss of data.
The propagation queue contains the following information.
The master registry sequence number of the change. This is the coordinating entry within the update and propagation process. When the replicas are communicating their relative up-to-dateness this number is the determining factor. This number is originally generated on the master replica, it is generated when an update occurs. For each change within the master there is a sequence number generated and assigned to that change.
The time when the update happened to the master registry.
The data that is specific to this update. The actual data that was modified in the master.
The replica list contains an entry for each security replica in operation. Each entry within the list contains the replica's UUID, name and tower information. The master replica controls the replica list. That is, in order for a replica to be added or removed from the list, the master controls the process.
Each security server in the cell manages a replica list. Several
entries are common to all replica lists. This basic information on all
security servers' replica lists gives each replica an idea of the
location and status of all the replicas. The entries for the replica list
are outlined here; please see
The cell relative name of the replica. The replica's name (which is not "well-known") falls in the form /.../cell_name/subsys/dce/sec/replica_name, where replica_name represents the name for the replica.
The replica's instance UUID.
The network address(es) for the replica.
There may be multiple addresses. See the data types for
This flag indicates whether the described replica is currently the master replica.
Flag indicating if the replica has been or is marked for deletion.
The server maintains special information to manage propagation of updates to a replica.
Describes the current relative state of the replica. This will determine the method of updates passed from the master replica.
The replica is currently in the process of receiving a database from a replica.
The replica has been scheduled to be deleted.
The replica is currently accepting updates.
If the replica is ready for updates, this is the sequence number of
the last update successfully delivered to the replica.
(This implies, of course, that all previous sequence numbers
have been successfully delivered.)
See the rs_replica_prop_info_t data type definition in
The timestamp of the last update represented by the sequence number.
The communication status of this particular replica. There are currently three levels of communication status. They are the nominal state replica_comm_ok, short term communication interruption replica_comm_short_failure, and long term communication interruption replica_comm_long_failure.
Each security replica has a flag that defines its current state. This state is either known or distributed to other replicas. During certain states the replica is incapable of accepting propagation information or providing database information to clients and other replicas. The complete set of replication information that each replica maintains about itself and about the system is:
As defined in the next section.
The replica's instance UUID.
This UUID may or may not be identical to that of
the Master UUID. If it is, then this replica
is the master replica (otherwise, it is a slave replica).
Its cell-relative name.
The sequence number of the last update provided. This is noted on the master and the client replicas to maintain a cross check of the updates. That is, the master ("thinks" it) has sent a specific number of updates and this number on the client would confirm that number.
The timestamp of the last update represented by the sequence number.
The UUID of the replica that provided the initialization of the replica's registry.
The security replica's network address(es).
This UUID is generated at the initialization of the master registry database when the cell is created. This entry is the same as the cell UUID. It uniquely determines the cell.
The UUID of the current master replica.
The number of the event when this master became the master. This information is only relevant if this is the master replica. The master keeps the sequence number that was current at the time this replica became the master.
The rs_replica_info_t structure in
Because of the variety of changes and situations that a replica can
be in, the necessity of maintaining state information is critical. When a
attempting to communicate with a peer it needs to understand what the
current state of that peer is. The concept of replica state provides
this. If a new replica is going to request a database from a peer it
needs to know whether that particular replica is able to be a
provider. The state generally defines a series of events in the life
of a replica, from initialization, name changes, slave to master
changes or database key changes.
The replica state defines the current condition of the replica.
The data type definition of the replica states can be found
The current state of the replica is unknown to the master.
The replica remains uninitialized while the database is being created. This is generally a temporary state during creation of a replica.
The replica is currently being initialized by another replica.
The replica is currently in service. The replica may either provide information for clients or become the master.
This state is in effect during a renaming of the replica.
This state is active when the database is in the process of being copied to a new replica or a replica that has requested a new database.
The replica is in maintenance mode.
The current master key is in the process of being changed.
When a replica receives the request to become a master, this state is active (on the replica that is in state transition from slave to master).
During the time when a slave replica receives a request to become a master this state is active (on the master that is in state transition from master to slave).
A replica that thinks it is the master has been informed by a slave that the slave believes a different replica to be the legitimate master.
A replica has closed its databases and is in the process of exiting.
The replica has been deleted from the replica list.
The slave replicas maintain both the registry database and replica list in memory and on disk. Each entry is updated when the master replica propagates a change. Each change is applied to the in-memory copy and then pushed to the disk copy. For each update that is propagated from the master replica an entry is made to the update log as well.
The slave replica also maintains a list of all changes that have been made.
In DCE 1.1 a replica is created by configuring the host as a DCE client. In addition, a new ("empty" or skeletal) (security) database is created. Once the new database is created several entries from the current master are required to be cataloged. The database is initialized with the following entries:
The Cell well known security UUID.
The instance UUID of the replica being created. This UUID is (dynamically) created during the process of creating the replica.
The binding towers for the replica being created.
See the rs_replica_twr_vec_p_t data type
The replica name.
This name is of data type rs_replica_item_p_t.
It is supplied by the administrator upon creation of
The master sequence number at the time of creation. This sequence number is of data type rs_update_seqno_t.
The sec_id_t of the entity creating the replica. This id is either supplied by the administrator, or it is the UUID and string name of the local cell on which the replica is created if not given by the administrator. Typically (usually) the (registry) Creator Id is supplied by the administrator.
The sec_id_t of the (local) cell. This Cell Id is initially stored in the registry database when the cell is being created. It consists of the cell's UUID and a string name identifying it. The cell name (string name) is retrieved when necessary (for instance when creating a replica). The method of retrieval is not specified in this document.
The initial keyseed for the database.
The rs_replica_item_t of the master replica (see
The replica name is then created and verified with the CDS
name service. This is done by creating the replica name of the form
The name service is then
checked to verify that the name is acceptable for use with
When the master site is notified of a new replica the master server guides the
initialization of the replica. When the replica is added to the
master's replica list it is marked for initialization using
rs_rep_admin_init_replica(, which sets the replica state to
rs_c_replica_prop_init. The master sends an
initialization request to the replica using rs_rep_mgr_init(. This
request includes a list of other
replicas that the new replica can use to initialize from (see
A replica is deleted in DCE 1.1 under command of (initiated by) the Security Administrator. Typically, installations have a set of commands for security administration-however, they are beyond the scope of this document and are not specified here.
When the replica deletion command is given, a delete replica request is sent to the master server using rs_replist_delete_replica(. The master marks the replica for deletion by setting replica state to rs_c_replica_prop_delete and puts the delete replica update on its propagation queue. The master then propagates the delete replica update to all other replicas sites on its list. These replicas remove the entry for the deleted replica from their respective replica lists. The master then delivers the delete request to the replica being deleted. When the replica server receives the request, it destroys its database and stops running. Upon completion, the master server removes the deleted replica from it's replica list.
Ultimately there is no verification the replica deleted its database and stopped operating. But the other slave replicas and the master replica would refuse communications because it has been marked as deleted.
By issuing the appropriate command (implementation specific items are
beyond the scope of this document), the security administrator can change
a slave to a master. This change is effected through
During the entire master change sequence, from initiation to completion, changes to the master registry are not accepted. If a client is attempting to change the master registry at this time and is not successful, the client attempts resubmitting the change a number of times. The number of attempts permitted is determined by the security administrator.
The slave replica selected to become the new master replica will, upon
receiving the request to become the master,
read the original master's replica list using
Communication between replicas is secure. The master server authenticates to
the slaves as the dce-rgy principal and the slaves authenticate to the
master using the host principal of the machine on which they run. By
default slaves need i, m and I ACL rights to the
replica list (/.:sec/replist)-see
Each replica has a server entry name in CDS. The default is /.:/sec. When binding to a security server, using this default will cause a binding to the cell's master replica. (An installation (cell) can change this default to any of the security server names registered in CDS. This is typically done via installation-supplied functions that set the default (and which are beyond the scope of this document) to a specific replica in /.../cell_name/subsys/dce/sec.)
The /.../cell_name/subsys/dce/sec node maps the replica's name to its location, its replica UUID (replica ID), and the cell's security object UUID (Cell Security ID), for any replicas that have been registered. When a replica server is first created it validates its server entry's information.
The security RPC group name is /.../cell_name/sec.
This name is not "well-known", but by convention it is named
The CDS name /.../cell_name/sec-v1 is an RPC Group designating the master security server. For more information regarding RPC Groups please reference the DCE RPC Specification.
When a client needs to find a security server replica it does so by
looking up a special security service interface UUID in the CDS cell
profile /.../cell_name/cell-profile . This special interface
UUID in the cell profile maps to the
cell's security group name /.../cell_name/sec.
The client binding code tries to bind to one of the servers in the
Each replica maintains its own master key to encrypt the data it
stores on disk. The key is initially generated via system
This key can be changed with the routine
When a database is initially created by the administrator, as part
of the creation process (for both slave and master replicas), the
administrator command usually typically requires the specification of
a keyseed in order to create the key for the database. In DCE 1.1,
if a keyseed is not specified, the administrator is asked to input
one as part of the creation process. This keyseed is a character
string up to 1024 bytes in length that is then used to seed the
random key generator in order to create the master key for the
database being created (master or slave). This master key
is used to encrypt account passwords. Note that each instance
of a replica has its own master key.