How Identities Represented by Accounts Are Authenticated
When principals log into the DCE, the security client uses the password they supply (or that is supplied for them in the case of a server or machine principal) to derive the principal's authentication key. A copy of the principal's authentication key exists also in the registry database, having been stored there when the principal's account was created (or when the password was changed.) It is thus available to the authentication service.
This key is used by the authentication service to authenticate the principal (that is, to guarantee the principal's identity) as follows:
1. The security client does the following:
a. Queries the user for the password and uses it to derive the principal's authentication key
b. Prepares a login request, part of which is encrypted using the authentication key
c. Forwards the request to the authentication service
2. The authentication service does the following:
a. Receives the login request
b. Obtains the registry's copy of the principal's authentication key
c. Attempts to decrypt the login request with this key
If the decryption succeeds, the keys are the same; the principal is therefore authenticated and the login is successful.
If the decryption fails, then the password supplied by the principal and used by the security client to derive its version of the principal's authentication key is invalid (that is, different from the password used to derive the registry's copy of the principal's authentication key), and login is denied.
This is a very general introductory description; see the OSF DCE Application Development Guide - Core Components for a detailed discussion of principal authentication.
More:
Ticket-Granting Tickets and Tickets to Services
Displaying Privilege Attributes and Tickets
Destroying a Principal's Tickets