4 — Authentication

[Previous] [Next] [Contents] [Index]

This chapter describes authentication topics and related tasks. It contains the following sections:

4.1 Understanding DCE Authentication
4.2 Managing DCE Authentication
4.3 Managing Invalid Login Handling
4.4 Managing Password Format Policies
4.5 Using the Password Strength Server
4.6 Managing Password Expiration
4.7 Integrated Login
4.8 Login Contexts

For a discussion of Entegrity's Co-Authentication Service (CAS) please refer to the Guide to CAS.

4.1 Understanding DCE Authentication

This section provides some general information on DCE authentication useful to those who need to administer DCE cells.

4.1.1 DCE Authentication Process

The following is a very general description of how DCE authentication works.

When you create or modify an account for a principal, you supply a password for that principal. The security service uses the password to derive an authentication key, which it stores in the registry.

When a principal logs into DCE, the security client on the principal's system uses the password supplied by the principal to derive the principal's authentication key. This key is used by the security service to authenticate the principal (that is, to guarantee the principal's identity) as follows:

1. The security client does the following:
   • Uses the password to derive the principal's authentication key

   • Prepares a login request, and encrypts part of it using the authentication key

   • Forwards the request to the security service

2. The security service does the following:
   • Obtains the registry's copy of the principal's authentication key

   • Attempts to decrypt the login request with this key

If the decryption succeeds, the keys are the same, which means the password supplied by the principal is valid. Authentication succeeds and login is allowed.

If the decryption fails, the keys must be different, which means the password supplied by the principal is invalid. Authentication fails and login is denied.

4.1.2 OSF DCE Version 1.1 Authentication Enhancements

OSF DCE Version 1.1 authentication addresses certain security deficiencies in the Kerberos V5 authentication protocols, which are used as the basis for the DCE authentication protocol in versions previous to OSF DCE Version 1.1. These deficiencies result from:

• The security server responding to client login requests without verifying that the user knows the password

• The use of user passwords, which are notoriously weak, to encrypt plaintext data that is then sent across the network

These practices are subject to attacks in which the attacker obtains network transmissions and proceeds to attack them offline to elicit users' passwords.

OSF DCE Version 1.1 reduces the likelihood of such attacks succeeding by providing for:

• Preauthentication of principals making login requests (that is, by having the security service verify the identity of the requestor before responding to the request)

• The use of strong keys to encrypt all network transmissions involving validation between security clients and servers

Three preauthentication protocols provide three levels of decreasingly strict preauthentication. You can control the minimum level of preauthentication that the security server will accept by attaching an instance of the pre_auth_req ERA (Extended Registry Attribute) to the principal, as described in the following section.

The preauthentication protocols are as follows:

• Third-party protocol - Provides the highest level of security. 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.

  OSF DCE Version 1.1 clients always construct authentication requests with this protocol, except in cases where they are unable to do so because the machine session key, which is required to construct third-party requests, is unavailable (for example, at cell startup).

• Timestamps protocol - Provides an intermediate level of security. The timestamps 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.

  Specify timestamps preauthentication only for principals (such as cell administrators and noninteractive principals) who must be able to operate when the client is unable to construct a third-party authentication request as previously described. In these cases, the client constructs and forwards a timestamps login request.

• OSF DCE Version 1.0 (Kerberos V5) protocol - Authenticates pre-OSF DCE Version 1.1 clients only, and provides no preauthentication security.

  Specify the OSF DCE Version 1.0 protocol only to enable OSF DCE Version 1.1 servers to accept login requests from pre-OSF DCE Version 1.1 clients.

Table 4-1 describes how login requests are handled when OSF DCE Version 1.1 clients and servers interoperate with pre-OSF DCE Version 1.1 clients and servers in a single cell.

Table 4-1: OSF DCE Version 1.1/Pre-OSF DCE Version 1.1 Authentication Interoperation

Login Request Type	Pre-1.1 Server Response	1.1 Server Response
OSF LDCE Version 1.0	Returns OSF DCE Version 1.0 (unpreauthenticated) response.	If no ERA exists, or existing ERA has value=0 (NONE), returns OSF DCE Version 1.0 (unpreauthenticated) response. Otherwise, rejects login request.
From pre-OSF DCE Version 1.1 clients only.
TIMESTAMPS	Server ignores preauthentication data in request and returns pre-OSF DCE Version 1.1 (unpreauthenticated) response.	If no ERA exists, or existing ERA has value=0 (NONE) or value= 1 (TIMESTAMPS), returns OSF DCE Version 1.1 TIMESTAMPS response. If existing ERA has value=2 (THIRD-PARTY), rejects login request.
From OSF DCE Version 1.1 clients only.
THIRD-PARTY	Server ignores preauthentication data in request and returns pre-OSF DCE Version 1.1 (unpreauthenticated) response.	Returns OSF DCE Version 1.1 THIRD-PARTY response.
From OSF DCE Version 1.1 clients only.

4.1.3 Privilege Attributes

After a principal is authenticated, the security service obtains the principal's privilege attributes. Privilege attributes include the principal's network identity, the groups in which the principal is a member, and any extended attributes associated with the principal. Privilege attributes determine the principal's rights to any objects that principal attempts to access.

4.1.4 Ticket-Granting Tickets and Service Tickets

A ticket-granting ticket (TGT) allows a principal to request and receive tickets to DCE services. The tickets that let principals access DCE services are called service tickets.

Both ticket-granting tickets and service tickets have lifetimes that are determined by the settings for individual accounts and registry policies and properties. When a principal's ticket-granting ticket expires, the principal is no longer considered an authenticated user. To remedy this, the principal must reauthenticate by running the kinit command or by logging in again to DCE.

If you flag an account as able to renew service tickets, the principal's service tickets are renewed automatically by the authentication service, requiring no action on the principal's part. Note, however, that the lifetime allocated to a service ticket can never exceed the time remaining on the principal's ticket-granting ticket.

4.2 Managing DCE Authentication

This section describes how to manage a principal's pre-authentication protocol settings and tickets.

4.2.1 Managing Preauthentication Protocols

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 security service should accept, from this principal, login requests using any of the three protocols (including the OSF DCE Version 1.0 protocol.)

  NOTE: 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.

• 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.

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.

4.2.1.1 Creating a Principal with the pre_auth_req ERA

Use the principal create principal -attribute {attribute_list} command to create a principal and attach the pre_auth_req ERA. For example:

dcecp> principal create fillmore -attribute {pre_auth_req 2}

Use the principal show principal -xattrs command to display a principal's ERAs. For example:

dcecp> principal show fillmore -xattrs 
{pre_auth_req 2}

Use the principal modify principal -add {attribute_list} command to attach the pre_auth_req ERA to an existing principal. For example:

dcecp> principal modify cell_admin -add {pre_auth_req 2}

Use the principal modify principal -change {attribute_list} command to change the pre_auth_req value. For example:

dcecp> principal modify fillmore -change {pre_auth_req 2}

This section describes how to manage a principal's pre-authentication protocol settings and tickets.

4.2.2.1 Viewing Privilege Attributes and Tickets

Use the dcecp klist command to display a principal's current tickets and privilege attributes. The klist command displays three types of information:

• Privilege attributes
  
• Expiration information
  
• service ticket information
  

The klist command displays a principal's privilege attributes. This display lists the fully qualified principal name followed by the UUIDs and names of the cell, the principal name, and all the groups of which the principals is a member. For example:

dcecp> klist
DCE Identity Information:
        Global Principal: /.../longwood/fred
        Cell:      004127b0-916c-14bf-a883-00802964ff95 /.../longwood
        Principal: 00000064-916c-24bf-a800-00802964ff95 music/fred
        Group:     0000000c-916d-24bf-a801-00802964ff95 composers

The second part of the klist display shows the dates and time that the principal's ticket-granting ticket, account, and password expire:

• The first line shows the date and time the ticket-granting ticket expires.

• The second line shows when the principal's account expires. If the account expires, the principal will be unable to log into DCE.

• The third line shows the date the principal's password expires. If the password expires, the principal will be unable to log into DCE.

For example:

Identity Info Expires: 2000/02/13:00:56:13
Account Expires:       2000/12/31:12:00:00
Passwd Expires:        2000/06/30:12:00:00

The third part of the klist display shows the principal's ticket information and the name of the principal's ticket cache.

The first three tickets labeled Server are the tickets used after the principal logged in and obtained privilege attributes. The remaining tickets labeled Client show the principal's ticket-granting ticket and service tickets.

In the listing for each ticket after the word Client, the display shows the name of the privilege server, a server that grants privilege attributes after the principal's identity has been authenticated by the security service. The name of the server to which the principal has tickets is shown after the Server entry, and the dates and times these tickets are valid are shown on the following line.

For example, in the following sample display, the last line shows that the principal has a ticket to the server named dce-rgy. The lifetime of this ticket is from 2:56 and 15 seconds p.m. on 2/12/98 to 4:56 and 15 seconds p.m. on 2/12/98. (The time is shown in 24-hour format.)

Kerberos Ticket Information:
Ticket cache: C:/PCDCE32/opt/dcelocal/var/security/creds/dcecred_00f58600
Default principal: fred@longwood
Server: krbtgt/longwood@longwood
        valid 2000/02/12:14:56:13 to 2000/02/13:00:56:13
Server: dce-rgy@longwood
        valid 2000/02/12:14:56:13 to 2000/02/13:00:56:13
Server: dce-ptgt@longwood
        valid 2000/02/12:14:56:15 to 2000/02/12:16:56:15
Client: dce-ptgt@longwood       Server: krbtgt/longwood@longwood
        valid 2000/02/12:14:56:15 to 2000/02/12:16:56:15
Client: dce-ptgt@longwood       Server: dce-rgy@longwood
        valid 2000/02/12:14:56:15 to 2000/02/12:16:56:15

Use the kdestroy command to invalidate the tickets that a principal has acquired.

When the principal logs out, the principal's tickets are not destroyed; they remain valid until they expire. Users may want to use kdestroy just before they log out to ensure that no valid tickets remain.

4.3 Managing Invalid Login Handling

When you specify a preauthentication level of 2 (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.

You do this by attaching instances of two ERAs (max_invalid_attempts and disable_time_interval) to the principal:

• max_invalid_attempts - Number of successive invalid login attempts allowed before the security server disables the account.

• disable_time_interval - Number of seconds the principal's account should be disabled once max_invalid_attempts is exceeded.

If the user's account is disabled due to exceeding the limit set by max_invalid_attempts, the login response the user sees is identical to the response for an invalid password.

4.3.1 Creating a Principal with Attached Invalid Login ERAs

Use the principal create principal -attribute {attribute_list} command to create a principal and attach the invalid login ERAs. For example:

dcecp> principal create fillmore -attribute {{pre_auth_req 2}
{max_invalid_attempts 3} {disable_time_interval 60}}

Use the principal show principal -xattrs command to display a principal's ERAs. For example:

dcecp> principal show fillmore -xattrs
{pre_auth_req 2}
{max_invalid_attempts 3}
{disable_time_interval 60}

Use the principal modify principal -add {attribute_list} command to attach the pre_auth_req ERA to an existing principal. For example:

dcecp> principal modify taylor -add {{pre_auth_req 2}
{max_invalid_attempts 3} {disable_time_interval 60}}

Use the principal modify principal -change {attribute_list} command to change the pre_auth_req value. For example:

dcecp> principal modify cell_admin -change {disable_time_interval 300}

In OSF DCE Version 1.1, the invalid login handling functionality accurately tracks login activity in a cell with one master and no replicas, but does not keep accurate counts in replicated cells. This is because:

• Login attempts in a replicated cell are randomly assigned to either a master or replica.

• There is at present no mechanism for replicas to communicate to the master and, therefore, no way for the master to maintain an accurate count.

You can restrict the formats used for newly created or modified passwords by setting the following policy attributes:

• pwdminlen integer - Minimum password length. A value of 0 specifies no minimum length. The default is 0.

• pwdspaces {yes | no} - Whether or not the password can be all spaces. The default is yes.

• pwdalpha {yes | no} - Whether or not the password can contain only alphanumeric characters. The default is yes.

For a given account, password format policy consists of the combination of the strongest settings from the registry and from the account's primary organization.

The security service enforces the policy when you create or modify a password. Therefore, if you change the policy, existing passwords are not subjected to the change.

You can also use the password strength server to enforce formats for selected accounts. For information on the password strength server, refer to Section 4.5.

4.4.1 Viewing Password Format Settings

To view policy settings, including password formats, for the entire registry, use the registry show registry -policies command. For example:

dcecp> registry show /.:/subsys/dce/sec/master -policies
{acctlife unlimited}
{maxtktlife +1-00:00:00.000I-----}
{maxtktrenew +28-00:00:00.000I-----}
{pwdalpha yes}
{pwdexpdate none}
{pwdlife unlimited}
{pwdminlen 6}
{pwdspaces yes}

To view policy settings for an organization, use the organization show organization -policies command. For example:

dcecp> org show zephyr -policies
{acctlife unlimited}
{pwdalpha no}
{pwdexpdate none}
{pwdlife unlimited}
{pwdminlen 0}
{pwdspaces yes}

To change a policy attribute in the registry, use the dcecp registry modify command. For example, the following command changes the minimum password length to six for the entire registry:

dcecp> registry modify /.:/subsys/dce/sec/master -change {pwdminlen 6}

To change a policy attribute in an organization, use the dcecp organization modify command. For example, the following command forbids the use of passwords consisting of all spaces for organization zephyr:

dcecp> org modify zephyr -change {pwdspaces no}

The password strength server performs the following functions for specified principals:

• Enforcement of password format policy - The password strength server enforces either the existing password policy, as defined by registry and organization attributes (Section 4.4 on page 54), or a separate policy defined by arguments passed to the password strength server at startup time.

• Password generation - The password strength server generates randomized passwords.

You specify which principals are subject to the password strength server by attaching ERAs to the principals specifying the service required of the password strength server and a binding to the server.

4.5.1 Configuring the Password Strength Server

The password strength server is an additional DCE server provided by PC-DCE. You configure the password strength server using the PC-DCE Service Panel. For instructions on configuring a password strength server, refer to the online help associated with the PC-DCE Configuration Panel.

NOTE: To protect password security, and to optimize performance, the password strength server should run on the same machine as the master DCE security server.

Once you configure the password strength server, it runs automatically as part of the PC-DCE service. You can control it using the PC-DCE Service Panel along with the rest of the DCE processes. You can also run it from the command line as described in Section 4.5.3 on page 59.

If you want to modify the password strength server default behavior, the password strength server source code is available from The Open Group. For information, visit http://www.opengroup.org/tech/dce/mall/free_dce.htm.

4.5.2 Configuring Principals to Use the Password Strength Server

To configure a principal to use the password strength server, attach instances of the pwd_val_type and pwd_mgmt_binding ERAs:

• pwd_val_type integer - Specifies password creation options for the principal as follows:

  0 (NONE) - Specifies that the principal's password is subject only to checking by the standard security service. Specifying 0 is equivalent to not attaching an ERA instance to the principal.

  1 (USER_SELECT) - Specifies that the principal must supply a password. The password strength server strength-checks the password (enforces password policy).

  2 (USER_CAN_SELECT) - Specifies that the principal can either supply a password or request a randomized password from the password strength server. The password strength server strength-checks the password (enforces password policy).

  3 (GENERATION_REQUIRED) - Specifies that the principal must obtain a randomized password from the password strength server. The password strength server strength-checks the password (enforces password policy).

• pwd_mgmt_binding - Specify a binding to the password strength server. This ERA uses the binding encoding type (Section 4.5.2.5).

Use the principal create principal -attribute {attribute_list} command to create a principal and attach the pwd_val_type and pwd_mgmt_binding ERAs. For example:

dcecp> principal create fillmore -attribute {{pwd_val_type 2} \
{pwd_mgmt_binding \
{{dce /.:/pwd_strength pktprivacy secret name} \
{/.:/subsys/dce/pwd_mgmt/pwd_strength}}}}

Use the principal show principal -xattrs command to display a principal's ERAs. For example:

dcecp> principal show fillmore -xattrs 
{pwd_val_type 2}
{pwd_mgmt_binding {{dce /.:/pwd_strength pktprivacy secret name} 
{/.:/subsys/dce/pwd_mgmt/pwd_strength}}}

Use the principal modify principal -add {attribute_list} command to attach the pwd_val_type and pwd_mgmt_binding ERAs to an existing principal. For example:

dcecp> principal modify buchanan -add {{pwd_val_type 2} \
{pwd_mgmt_binding \
{{dce /.:/pwd_strength pktprivacy secret name} \
{/.:/subsys/dce/pwd_mgmt/pwd_strength}}}}

Use the principal modify principal -change {attribute_list} command to change pwd_val_type or pwd_mgmt_binding values. For example:

dcecp> principal modify buchanan -change {pwd_val_type 3}

The pwd_mgmt_binding ERA uses the binding encoding type:

{{auth_info} {binding_info}}

which expands to:

{{auth_serv_type name prot_level authentication_service authorization_service} {binding_info}}

Table 4-2 defines the parameters.

Table 4-2: Parameter Definitions for the Binding Encoding Type

Parameter	Values
auth_serv_type	Specifies the authentication type: none - No authentication If you select none, specify no additional parameters except binding_info. dce - Standard DCE authentication
name	Principal name of the server, usually /.:/pwd_strength.
prot_level	Protection level that determines the degree to which authenticated communications between the client and the server are protected by the authentication service: default - Default protection level of pkt. none - No authentication: no tickets are exchanged, no session keys are established, no client EPACs or names are certified, transmissions are in the clear. connect - Authenticates only when client establishes a relationship with server. call - Authenticates only at the beginning of each RPC when server receives the request. This level does not apply to RPCs made over a connection-based protocol sequence (that is, ncacn_ip_tcp). If this level is specified and the binding handle uses a connection-based protocol sequence, the routine uses the pkt protection level instead. (prot_level continued next page)
prot_level (continued)	pkt - Ensures that all data received is from the expected client. pktinteg - Ensures and verifies that none of the data transferred between client and server has been modified. This is the highest protection level that is guaranteed to be present in the RPC runtime. pktprivacy - Authenticates as specified by all of the previous levels and also encrypts each RPC argument value. This is the highest protection level, but it is not guaranteed to be present in the RPC runtime.
authentication_service	Specifies the authentication service. The exact level of protection provided by the authentication service is specified by prot_level. default - DCE shared-secret key. none - No authentication: no tickets are exchanged, no session keys established, client EPACs or names are not transmitted, and transmissions are in the clear. secret - DCE shared-secret key authentication.
authorization_service	Specifies the authorization service. The validity and trustworthiness of authorization data, like any application data, is dependent on the authentication service and protection level specified. The supported authorization services are as follows: none - Server performs no authorization. name - Server performs authorization based on the client principal name. This value cannot be used if the authentication service is none. dce - Server performs authorization by using the client's DCE EPAC sent to the server with each remote procedure call made with this binding. Generally, access is checked against DCE ACLs.
binding_info	Specifies the binding, which can be a string binding, a server entry name, or a list containing one or more string bindings or server entry names. The following example shows a server entry name binding: /.:/hosts/host_name/dce_entity_name The following example shows a string binding in standard syntax: ncadg_udp_ip:130.105.96.3[1234]

4.5.3 Running the Password Strength Server from the Command Line

If you wish, once the password strength server is configured (Section 4.5.1 on page 56), you can run the password strength server from the command line. You might wish to do this to override password policy for those principals that are configured to bind to the password strength server.

If you run the password strength server from the command line, this instance supersedes the instance started by the PC-DCE service. After you end the command line instance, the PC-DCE Service Panel will still show the password strength daemon as running, but its bindings will be unavailable.

pwd_strengthd.exe is located in install_directory\bin. For command line arguments, refer to Section 4.5.3.1.

4.5.3.1 Overriding Policy from the Command Line

By default, the password strength server enforces standard password policy (Section 4.4 on page 54). However, if you run the password strength server from the command line, you can use command line arguments to specify a separate password policy to be used for principals configured to use this server. In addition you can control a few other server options. For descriptions of all command line options, refer to Table 4-3.

If you don't specify an argument to explicitly override policy, the password strength server enforces policy. Be aware that if you specify options that are weaker than policy, the weaker options are used.

Table 4-3: Command Line Arguments for pwd_strengthd.exe

Option	Description
+all	Allows passwords to be all spaces.
-all	Prevents passwords from being all spaces.
+alp	Allows passwords to consist only of alphanumeric characters.
-alp	Prevents passwords from consisting only of alphanumeric characters.
-m pwd_min_len	Specifies the minimum length of the password.
-d	Runs pwd_strengthd in the foreground, which causes log messages to standard output.
-v	Runs in verbose mode.

For example, the following command runs the password strength server with arguments that prevent passwords from being all spaces, and sets the minimum password length to 6:

C:\>dce_login cell_admin mxydkwl

C:\>pwd_strengthd -all -m 6 -v -d
pwd_strengthd 05/06/2000 09:18:29 - Registering rsec_pwd_mgmt interface
pwd_strengthd 05/06/2000 09:18:31 - Setting up server context
pwd_strengthd 05/06/2000 09:18:33 - Listening on rsec_pwd_mgmt interface

A principal configured to use the password strength server with a pwd_val_type ERA having a value of 2 or 3 can (or will be required to) obtain a randomized password when creating or modifying its password. The following example shows how to use dcecp to obtain the password from the password strength server:

dcecp> set p [account generate delilah]
newgenpwd

This command requests a generated password from the password management server, places the new password in the p variable, and prints it to the screen (newgenpwd). Be sure to remember the new password.

Next, pass the value stored in p as the value of new password in an account modify or account create command:

dcecp> account modify delilah -password $p -mycurrentpwd -dce-

Never execute the following dcecp command, since the password will be changed in the account, but the user will not see the new password:

dcecp> acct mod delilah -password [acct gen delilah] -mycurrentpwd -dce-

The password strength server generates passwords according to registry policy only. It ignores the organization policy and any policy you specify using command line switches. For example, if a principal's organization's policy requires passwords to use non-alphanumeric characters, but registry policy does not, the password strength server will generate passwords that use alphanumeric characters only. To work around this restriction, you may need to temporarily change registry policy (Section 4.4 on page 54) when creating or modifying passwords.

4.5.5 Viewing Password Strength Server Log Messages

The log file for the sample password management server resides in install_directory\dcelocal\var\security\pwd_strengthd.log.

If you run the password strength server from the command line (Section 4.5.3), you can supply the -d command line argument to run the process in the foreground, which causes log messages to be directed to standard output.

4.6 Managing Password Expiration

You can cause passwords to expire by setting the following registry and organization policy attributes:

• pwdlife - passwords expire this number of seconds from the account creation time or the last time the password was changed.

• pwdexpdate - time at which all passwords in this domain (registry or organization) expire.

To view policy settings, including password expiration, for the entire registry, use the registry show registry -policies command. For example:

dcecp> registry show /.:/subsys/dce/sec/master -policies
{acctlife unlimited}
{maxtktlife +1-00:00:00.000I-----}
{maxtktrenew +28-00:00:00.000I-----}
{pwdalpha yes}
{pwdexpdate none}
{pwdlife unlimited}
{pwdminlen 6}
{pwdspaces yes}

To view policy settings for an organization, use the organization show organization -policies command. For example:

dcecp> org show zephyr -policies
{acctlife unlimited}
{pwdalpha no}
{pwdexpdate none}
{pwdlife unlimited}
{pwdminlen 0}
{pwdspaces yes}

To change a policy attribute in the registry, use the dcecp registry modify command. For example, the following command changes the pwdlife to 7862400 (3 months) for the entire registry:

dcecp> registry modify /.:/subsys/dce/sec/master -change {pwdlife 7862400}

To change a policy attribute in an organization, use the dcecp organization modify command. For example, the following command sets the pwdexpdate to June 30, 2001 for organization zephyr:

dcecp> org modify zephyr -change {pwdexpdate 2001-06-30-00:00:00}

By default, the security server disables logins for principals whose passwords have expired. There may be cases where you would prefer this not to happen; for instance, you don't want cell_admin to be locked out of the cell because of an expired password.

You can manage password expiration checking for a given principal by attaching an instance of the passwd_override ERA to the principal and specifying one of the following values:

0 (NONE) - Specifies that password expiration checking for the principal should not be overridden (that is, the principal should not be permitted to log in with an expired password.) Specifying 0 (NONE) is equivalent to not attaching an ERA instance to the principal.

1 (OVERRIDE) - Specifies that password expiration checking for the principal should be overridden (that is, the principal should be permitted to log in with an expired password).

NOTE: In OSF DCE Version 1.2.1, the DCE privilege server removes ERAs from credentials requested by foreign cells. As a result, the passwd_override ERA has no effect for logins from foreign cells.

4.6.3.1 Creating a Principal with the passwd_override ERA

Use the principal create principal -attribute {attribute_list} command to create a principal and attach the passwd_override ERA. For example:

dcecp> principal create fillmore -attribute {passwd_override 1}

Use the principal show principal -xattrs command to display a principal's ERAs. For example:

dcecp> principal show fillmore -xattrs 
{passwd_override 1}

Use the principal modify principal -add {attribute_list} command to attach the passwd_override ERA to an existing principal. For example:

dcecp> principal modify cell_admin -add {passwd_override 1}

Use the principal modify principal -change {attribute_list} command to change the passwd_override value. For example:

dcecp> principal modify fillmore -change {passwd_override 0}

Integrated login is a feature of PC-DCE that automatically logs users into DCE whenever they log into Windows. When the user logs out of Windows, integrated login logs the user out of DCE. Additionally, if a user changes his Windows password, the integrated login feature automatically changes the DCE password.

Integrated login is a popular feature on client systems because it provides single sign-on capability, because it enables the user's DCE credentials to be available as soon as the system is done booting, and because it saves the user a login step.

For integrated login to work, it must be enabled through the PC-DCE Control Panel configuration program, and the user's Windows and DCE user names and passwords must be identical, including case. For instructions on configuring integrated login, refer to the PC-DCE Configuration Panel online help system.

You can verify that integrated login is working by logging into Windows and then issuing the klist command from a command prompt. The klist command displays the currently logged in principal name, which should match the Windows user name.

The integrated login function creates a global login context for the user. For more information on login contexts, refer to Section 4.8.

4.8 Login Contexts

A login context is the set of security credentials associated with a user logged into DCE. In UNIX, when a user creates a new process, that process normally inherits the user's login context through an environment variable. However, Windows treats new processes differently than UNIX does. As a consequence, login contexts created in the normal fashion (through the DCE sec_login APIs) are per-process login contexts, and are not inherited by new processes.

PC-DCE includes a feature called the default login context that provides behavior similar to that seen on UNIX. When a user logs into DCE using either integrated login (Section 4.7) or the dce_login command, PC-DCE creates a default login context and stores it in the registry. Any new processes created by the user inherit the default login context.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Portions of this document were derived from materials provided by Compaq Computer Corporation. Copyright © 1998-2003 Compaq Computer Corporation.

Copyright © 2003 Entegrity Solutions Corporation & its subsidiaries.

All rights reserved.