OSF DCE Administration Guide--Core Components

OSF DCE Administration Guide—Core Components
30.6.1.2 Preauthentication Interoperability Between DCE Versions
Table 30-2 describes how login requests are handled when DCE Version 1.1
clients/servers interoperate with pre-DCE Version 1.1 clients/servers in a single cell.
TABLE 30-2. DCE Version 1.1/Pre-DCE Version 1.1 Authentication Interoperation
________________________________________________________________________________________
Login Request Type Pre-1.1 Server Response 1.1 Server Response
________________________________________________________________________________________
________________________________________________________________________________________
DCE Version 1.0
From pre-DCE Version
1.1 clients only.
No preauthentication. Returns DCE
Version 1.0 (unpreauthenticated)
response.
Supports preauthentication. Checks
for pre_auth_req ERA instance:
If no ERA exists, or existing ERA
has value=0 (NONE), returns DCE
Version 1.0 (unpreauthenticated)
response. Otherwise, rejects login
request.
________________________________________________________________________________________
TIMESTAMPS
From DCE Version 1.1
clients only.
No preauthentication. Server ignores
preauthentication data in request and
returns pre-DCE Version 1.1
(unpreauthenticated) response.
Supports preauthentication. Checks
for pre_auth_req ERA instance:
If no ERA exists, or existing ERA
has value=0 (NONE)orvalue=1
(PADATA-ENC-TIMESTAMPS),
returns DCE Version 1.1
TIMESTAMPS response. If
existing ERA has value=2
(PADATA-ENC-THIRD-PARTY),
rejects login request.
________________________________________________________________________________________
THIRD-PARTY
From DCE Version 1.1
clients only.
No preauthentication. Server ignores
preauthentication data in request and
returns pre-DCE Version 1.1
(unpreauthenticated) response.
Supports preauthentication.
Returns DCE Version 1.1 THIRD-
PARTY response.
________________________________________________________________________________________
30.6.2 Managing Invalid Login Handling
When you specify a preauthentication level of 2 ( PADATA-ENC-THIRD-PARTY) for
a principal, the security server is able to detect and track invalid login attempts for that
principal. This makes it possible for administrators to limit the possible impact of
password guessing attacks by
• Setting a limit to the number of successive invalid login attempts before the
principal’s account is disabled. (A successful login resets the counter.)
• Specifying the period of time the principal’s account will be disabled once that limit
is reached.
30 − 10 Tandem Computers Incorporated 124243