PreviousNext

Managing User Authentication

You manage preauthentication for a given principal by attaching an instance of the pre_auth_req ERA to the principal and specifying a value to indicate the lowest level protocol the DCE Security Service should accept for the principal, as follows:

0
(NONE) Specifies that the DCE Security Service should accept, from this principal, login requests using any of the three protocols (including the pre-DCE Version 1.1 protocol.) This is the least secure level and is provided only in order to enable DCE Version 1.1 servers to accept login requests from pre-DCE Version 1.1 clients. It is most vulnerable to the type of attack previously described.

Warning: Failing to attach an instance of the pre_auth_req ERA to a principal is equivalent to specifying 0 (NONE).

1
(PADATA-ENC-TIMESTAMPS) Specifies that the DCE Security Service should accept, from this principal, login requests using either the timestamp or third-party protocol. The timestamp protocol protects against attackers masquerading as a security client and attacking replies from the DCE Authentication Service, but is still vulnerable to attacks by processes capable of monitoring the network.

2
(PADATA-ENC-THIRD-PARTY) Specifies that the only login requests the DCE Security Service will accept from this principal are those using the third-party protocol. This is the highest level of DCE preauthentication and provides the most protection against the attacks previously described. With third-party preauthentication, all authentication data sent over the network is encrypted with a "strong'' random key known only to the local machine principal and the DCE Security Service.

3
(PADATA-ENC-PUBLIC-KEY)
Specifies that the only login requests the DCE Security Service will accept from this principal are those using the public key protocol. This is the highest level of DCE preauthentication.

When the authentication service receives a login request for a principal, it always attempts to respond using the same protocol as the request, unless the pre_auth_req ERA value for that principal "forbids'' it to do so. The table entitled DCE Version 1.1/Pre-DCE Version 1.1 Authentication Interoperation provides a matrix describing the actions taken by the authentication service under the various combinations of login (authentication) request type and pre_auth_req ERA value.

For complete information on the details of DCE authentication (including the operation of the preauthentication protocols), see the OSF DCE Application Development Guide - Core Components .

The following is an example of a dcecp command to create a principal and attach a pre_auth_req ERA specifying third-party preauthentication:

dcecp> principal create smitty -attribute {pre_auth_req 2}
dcecp>

For further information on how to use dcecp to attach ERAs to principals, see Creating and Using Extended Registry Attributes.