##############################################################################
# @(#)30     1.5  src/examples/pwdstren/readme, examples.src, os2dce21.dss, 960602a.1  5/23/96  13:31:16
#
# COMPONENT_NAME:  examples.src
#
# FUNCTIONS: readme file for password strength server example
#
# ORIGINS: 27
#
# (C) COPYRIGHT International Business Machines Corp. 1996
#  All Rights Reserved
#  Licensed Materials - Property of IBM
#
#  US Government Users Restricted Rights - Use, duplication or
#  disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
##############################################################################
-----------------------------------------------------------------------------
opt\dcelocal\examples\pwdstren directory
-----------------------------------------------------------------------------

    DCE Password Strength Server sample "pwdstrn2"
    ----------------------------------------------

The contents of this file attempts to explain the password strength server.
It contains the following sections:

   1.  INTRODUCTION
   2.  OVERVIEW OF PASSWORD MANAGEMENT
   3.  PASSWORD STRENGTH SERVER FILES
   4.  BUILDING PASSWORD STRENGTH SERVER
   5.  SETTING UP THE PASSWORD STRENGTH SERVER
   6.  SETTING UP PASSWORD MANAGMENT ERAS
   7.  STARTING THE PASSWORD STRENGTH SERVER
   8.  USING THE PASSWORD STRENGTH SERVER AND PASSWORD MANAGEMENT ERAS
   9.  PASSWORD STRENGTH SERVER OPTIONS
  10.  HINTS FOR CUSTOMIZING PASSWORD STRENGTH SERVER
  11.  OTHER HELPFUL HINTS


------------------------------------------------------------------------------
1.  INTRODUCTION

The DCE password strength sample is an example of a password management server.
A password management server can enforce password composition rules other
than the rules already enforced by standard DCE policy. The server also
generates user's passwords. This password strength example is to be used
as a basis upon which a customized password strength checker and generation
server is built. The password strength sample code is similar to the
source code used to build the OS/2 DCE Password Strength Server. This
sample password strength server generates passwords and does limited
password strength checking. This strength checking includes rejecting
any password containing the letter z.

------------------------------------------------------------------------------
2.  OVERVIEW OF PASSWORD MANAGEMENT

The Password Managemnet facility is intended to increase the strength
checking of passwords by  providing the tools necessary to develop
customized password management servers. The client password change
programs will utilize these tools.

The Password Management facility include the following:

 *  The DCE Password Management interfaces enable clients to retreive
    a principal's password management ERA values and to request strength-
    checking and generation of passwords. These APIs are:

    sec_pwd_mgmt_setup         -   sets the data required to perform remote
                                   password management calls to the password
                                   management server

    sec_pwd_mgmt_get_val_type  -   get user's password validation type as
                                   specified in the pwd_val_type ERA.

    sec_pwd_mgmt_gen_pwd       -   retreives a set of generated passwords
                                   from a password managerment server

    sec_pwd_mgmt_free_handle   -   frees storage allocated for a password
           management handle

 *  The DCE Password Management network interfaces enable a Password
    Management Server to accept and process password strength checking
    and generation requests. These APIs are:

    rsec_pwd_mgmt_str_chk      -   strength checks the password according
                                   to policy

    rsec_pwd_mgmt_gen_pwd      -   generates a set of passwords for a given
                                   principal


The following figure illustrates the relationship between the security
client, security server and the password strength server.

            ***************************
            *                         *
            *        Client           *-----------------------
            *                         *                      |
            *-------------------------*                      |
            *  sec_pwd_mgmt_*()       *<-----------------    |
            *  sec_rgy_acct_passwd    *                 |    |
            ***************************                 |    |
               |    ^                                   |    V
               |    |                       ***************************
               |    |                       *   rs_pwd_mgmt_setup     *
               |    |        ---------------*   rs_acct_passwd        *
               |    |        |              *-------------------------*
               |    |        |              *                         *
               |    |        |    --------->*     Security Server     *
               |    |        |    |         *                         *
               |    |        |    |         ***************************
               V    |        V    |
            ***************************
            *rsec_pwd_   |rsec_pwd_   *
            *mgmt_gen_pwd|mgmt_str_chk*
            *-------------------------*
            *                         *
            *Password Strength Server *
            *                         *
            ***************************


The password strength server exports two interfaces, rsec_pwd_mgmt_gen_pwd and
rsec_pwd_mgmt_str_chk. The first interface rsec_pwd_mgmt_gen_pwd is invoked
by an DCE client to generate passwords. The second interface
rsec_pwd_mgmt_str_chk is call only by the DCE Security Server to
approve or reject proposed passwords.

The password generation function (rsec_pwd_mgmt_gen_pwd) is used by
programs that perform user's password changes. The DCE programs
dcelogin and rgy_edit are two such programs that perform password changes.
These programs consult ERA settings stored for the user in the DCE Registry
database. These adminstrator-controlled settings determine whether password
generation is relevant for that user (ERA pwd_val_type) and how to contact
the appropriate password strength server (ERA pwd_mgmt_binding). The programs
present the password strength server generated password to the user. If
password generation is required (ERA setting), the user has to accept the
password. If the password generation is optional, the user may choose
the generated password or choose their own. If the ERA setting is not
marked for password generation, the password strength is never contact
for a generated password.

The password composition checking function(rsec_pwd_mgmt_str_chk) is
invoked automatically by the DCE Registry Server whenever an account
password is changed and per the ERA settings. The password strength server
verifies that the password proposed by the user is the same one just
generated or performs simple composition checks  on the proposed
password. This composition checking is based on policy arguments
received from the Registry Server and any overrides specified via
command-line options.

Two new ERAs have been defined to support the password management
functionality. The DCE adminstrators define the password management
ERAs for the user principals. The password management ERAs are defined as:

1) PWD_MGMT_BINDING   -  this ERA attaches to a user principal and
                         defines what password strength server should
                         be used when the user's password is changed.

2) PWD_VAL_TYPE       -  this ERA attaches to a user principal and
                         defines the level of strength checking.
                         The four values are defined as:

                         1.)  0 - NONE
                              no strength checking

                         2.)  1 - USER_SELECT
                              password strength checking is done by the
                              server named in the PWD_MGMT_BINDING ERA

                         3.)  2 - USER_CAN_SELECT
                              password is first generated by the server
                              named in the PWD_MGMT_BINDING ERA, then the
                              user is free to use the generated password
                              or choose his own

                         4.)  3 - GENERATION_REQUIRED
                              the password is generated by the server
                              named in the PWD_MGMT_BINDING ERA. The
                              user is required to supply this password as
                              confirmation.


------------------------------------------------------------------------------
3.  PASSWORD STRENGTH SERVER FILES

The following files are contained in this subdirectory:


  readme           -  this file
  gen.c            -  password generation source code
  gen.h            -  password generation include file
  pwd_cache.c      -  password cache routines source code
  pwd_cache.h      -  password cache include file
  pwd_strengthd.c  -  password strength server source code
  pwdstrn2.def     -  password strength server def file
  makefile.bor     -  makefile for building password strength server
                      with the Borland C++ 2.0 compiler
  makefile.os2     -  makefile for building password strength server
                      with the IBM C/C++ compiler
  makefile.vc3     -  makefile for building password strength server
                      with the Visual Age 3.0 compiler
  makefile.wat     -  makefile for building password strength server
                      with the Watcom C/C++ 10.5 compiler

-------------------------------------------------------------------------------
4.  BUILDING PASSWORD STRENGTH SERVER - PWDSTRN2.EXE

Refer to the main Example readme for compiling and linking instructions.

-------------------------------------------------------------------------------
5.  SETTING UP THE PASSWORD STRENGTH SERVER

Before you can run the password strength server, you must first setup your
DCE cell with the necessary security registry and namespace information
for the password strength server. These tasks consist of the following steps:

  1. Adding the password strength server principal "pwdstrn2" to the
     Security registry.

  2. Creating a CDS namespace entry "/.:/subsys/dce/pwd_mgmt/pwdstrn2"
     for the server to export its binding information to.

  3. Setting up the correct permissions on the namespace entry to allow the
     server to use it (i.e., write to it) correctly.

  4. Creating a keyfile "\opt\dcelocal\krb5\pwdstrn2" to be used by the server.


You can use rgy_edit, dcecp or the DCE Administration GUI to do the setup.
The following steps below is how dcecp can be used to do the setup:

  # Note, you need to change to the drive where the \opt\dcelocal directory
  # resides or add the drive letter to the storage path on the keytab create.
  # start dcecp
  >dcecp

  # logon
  dcecp> login cell_admin

  # create the password strength server id
  dcecp> user create pwdstrn2 -group none -organization none
         -password pwdstrn2 -mypwd -dce-

  # this steps only needs to be done if pwd_mgmt is not already created
  dcecp> directory create /.:/subsys/dce/pwd_mgmt


  # create the namespace for password strength server
  dcecp> object create /.:/subsys/dce/pwd_mgmt/pwdstrn2

  # make sure password strength server id has correct permissions on namespace
  dcecp> acl modify -entry /.:/subsys/dce/pwd_mgmt/pwdstrn2
         -add user:pwdstrn2:rwdt


  # logout. Need to be "self" to create keytab file
  dcecp> logout

  # create keytab file. add drive letter to the storage path if
  # /opt/dcelocal directory is not on the current drive.
  dcecp> keytab create pwdstrn2 -storage {/opt/dcelocal/krb5/pwdstrn2}
         -data {pwdstrn2 plain 1 pwdstrn2}

  dcecp> keytab add pwdstrn2 -random -registry -member pwdstrn2


-------------------------------------------------------------------------------
6.  SETTING UP PASSWORD MANAGMENT ERAS

To direct password checking to this password strength server, the
"PWD_MGMT_BINDING" ERAs need to be established on user's principals.
To setup strength checking and password generation, the PWD_VAL_TYPE
ERA need to be defined for the user's principals.

You can use dcecp or the DCE Administration GUI to setup the ERAs.
The following steps below is how dcecp can be used to setup the ERAs:


  # start dcecp
  >dcecp

  # logon
  dcecp> login cell_admin

  # create the users
  dcecp> user create user0 -group none -organization none
         -password user0 -mypwd -dce-

  dcecp> user create user1 -group none -organization none
         -password user1 -mypwd -dce-

  dcecp> user create user2 -group none -organization none
         -password user2 -mypwd -dce-

  dcecp> user create user3 -group none -organization none
         -password user3 -mypwd -dce-

  # Attach password strength checking and generation ERA to user's principals
  # pwd_val_type = 0 - use standard DCE policy checking and do not use
  # the password strength server. Basically the same as not attaching an
  # ERA to the principal.

  dcecp> principal modify user0 -add {pwd_val_type 0}

  # pwd_val_type = 1 - use password strength server as defined by the
  # pwd_mgmt_binding ERA to do strength checking on user-defined
  # password.

  dcecp> principal modify user1 -add {pwd_val_type 1}

  # pwd_val_type = 2 - user can supply own password or use the
  # password supplied by password strength server specified in the
  # pwd_mgmt_binging ERA. Strength checking is also done by
  # the specified password strength server.

  dcecp> principal modify user2 -add {pwd_val_type 2}

  # pwd_val_type = 3 - user must use password generated by the
  # password strength server specified in the pwd_mgmt_binding ERA.

  dcecp> principal modify user3 -add {pwd_val_type 3}


  # Attach password strength server ERA to users' principals
  # The option "pktprivacy" can be changed to "pkginteg" or "cdmf".
  # The option depends on your encryption level.

  dcecp> principal modify user0 -add {pwd_mgmt_binding {{dce pwdstrn2
         pktprivacy secret name}  /.:/subsys/dce/pwd_mgmt/pwdstrn2}}

  dcecp> principal modify user1 -add {pwd_mgmt_binding {{dce pwdstrn2
         pktprivacy secret name}  /.:/subsys/dce/pwd_mgmt/pwdstrn2}}

  dcecp> principal modify user2 -add {pwd_mgmt_binding {{dce pwdstrn2
         pktprivacy secret name}  /.:/subsys/dce/pwd_mgmt/pwdstrn2}}

  dcecp> principal modify user3 -add {pwd_mgmt_binding {{dce pwdstrn2
         pktprivacy secret name}  /.:/subsys/dce/pwd_mgmt/pwdstrn2}}

-------------------------------------------------------------------------------
7.  STARTING THE PASSWORD STRENGTH SERVER


To see how the password strength server really works, first start the
password strength server and then start changing the user's passwords.
The password server server assumes it's own identity. You do not
have to dcelogin as the server principal before starting the server.

To have the password strength server reject the letter 'z' in passwords
the  environment variable PWD_PORT_TEST needs to be set prior to
invoking the server. This is for example purposes only. The letter 'z'
checking should be replaced with the kind of additional composition
check a real password strength server would perform.

On the machine on which you want to run the server, enter the following:

    > set PWD_PORT_TEST = 1
    > pwdstrn2  -verbose -debug

(Note pwdstrn2 command options are define in section "9.  PASSWORD STRENGTH
SERVER OPTIONS").

The server will display:

pwdstrn2 05/22/96 21:28:36 - Setting up server context
pwdstrn2 05/22/96 21:28:46 - Registering rsec_pwd_mgmt interface
pwdstrn2 05/22/96 21:28:46 - unexporting old rsec_pwd_mgmt info from CDS namespace
pwdstrn2 05/22/96 21:28:55 - exporting new rsec_pwd_mgmt info to CDS namespace
pwdstrn2 05/22/96 21:28:57 - registering endpoints for rsec_pwd_mgmt interface
pwdstrn2 05/22/96 21:28:57 - pwdstrn2 INITIALIZATION COMPLETE


------------------------------------------------------------------------------
8.  USING THE PASSWORD STRENGTH SERVER AND PASSWORD MANAGEMENT ERAS


After you have invoked the server, wait until you get a message similar
to the following:

pwdstrn2 05/22/96 21:28:57 - pwdstrn2 INITIALIZATION COMPLETE

(This is the  "Server ready" message displayed by the example server)

You can now use "dcelogin -n" to login and change your password. The steps
below will illustrate how the password strength server and password management
ERA work together. Go to another window and try the following scenarios:

1. login as user0  and change password to zap.
   You will be successful since user0 is assigned pwd_val_type = 0 ERA
   which means no password strength checking. So password with
   letter 'z' is allowed since the password strength server is not invoked.

   > dcelogin -n  user0 user0

   The output is displayed as follows:

   DCE LOGIN SUCCESSFUL
   Enter New Password:
                enter: zap     --> password does not display
   Re-enter New Password:
                enter: zap     --> password does not display
   PASSWORD SUCCESSFULLY CHANGED

   The pwdstrn2 password strength server will show no activity.

2. login as user1  and change password to zap.
   You will be unsuccessful since user0 is assigned pwd_val_type = 1 ERA
   which means password strength checking is enforced. So password with
   letter 'z' is allowed since the password strength server is not invoked.
   Enter another password that does not contain the letter 'z'.

   > dcelogin -n  user1 user1

   The output is displayed as follows:

   DCE LOGIN SUCCESSFUL
   Enter New Password:
                enter: zap     --> password does not display
   Re-enter New Password:
                enter: zap     --> password does not display
   New password was not valid.  Try again? [y/n] (y)
   Enter New Password:
                enter: -dce-   --> password does not display
   Re-enter New Password:
                enter: -dce-   --> password does not display
   PASSWORD SUCCESSFULLY CHANGED


   The pwdstrn2 password strength server will display:

pwdstrn2 05/23/96 14:24:16 - rsec_pwd_mgmt_str_chk request: princ- user1
pwdstrnd test (rsec_pwd_mgmt_str_chk): success: gen NOT required, and check_plain_pwd OK.
pwdstrnd test (rsec_pwd_mgmt_str_chk): failure: passwords cannot contain z!
pwdstrnd test (rsec_pwd_mgmt_str_chk): good - you passed the no-z test!


3. login as user2  and change password to zap.
   Since user2 is assigned ERA pwd_val_type of 2, you will be supplied
   with a generated password. You may chose the generated password or your
   own password. Strength checking is performed. Passwords containing the
   letter 'z' are not  allowed. The password strength server is invoked for.
   the password generation and the strength checking.

   > dcelogin -n  user2 user2

   The output is displayed as follows:

   DCE LOGIN SUCCESSFUL
   Your generated password is vegderf
   Type this or a password of your own choice.
   Enter New Password:
                enter: zap     --> password does not display
   Re-enter New Password:
                enter: zap     --> password does not display
   New password was not valid.  Try again? [y/n] (y)
   Enter New Password:
                enter: -dce-   --> password does not display
   Re-enter New Password:
                enter: -dce-   --> password does not display
   PASSWORD SUCCESSFULLY CHANGED


   The pwdstrn2 password strength server will display:

pwdstrn2 05/23/96 14:25:14 - rsec_pwd_mgmt_gen_pwd request: princ- user2
pwdstrn2 05/23/96 14:25:14 - rsec_pwd_mgmt_gen_pwd: princ- user2
pwdstrn2 05/23/96 14:25:20 - rsec_pwd_mgmt_str_chk request: princ- user2
pwdstrnd test (rsec_pwd_mgmt_str_chk): success: gen NOT required, and check_plain_pwd OK.
pwdstrnd test (rsec_pwd_mgmt_str_chk): failure: passwords cannot contain z!
pwdstrnd test (rsec_pwd_mgmt_str_chk): good - you passed the no-z test!


4. login as user3  and change password to zap.
   Since user3 is assigned ERA pwd_val_type of 3, you will be supplied
   with a generated password. You must use the generated password.
   You will not be able to successfully change the password unless
   you use the generated password. The password strength server is invoked
   for the password generation.

   > dcelogin -n  user3 user3

   The output is displayed as follows:

   DCE LOGIN SUCCESSFUL
   Your generated password is jocinbya
   Type this as your new password.
   Enter New Password:
                enter: zap     --> password does not display
   Re-enter New Password:
                enter: zap     --> password does not display
   New password was not valid.  Try again? [y/n] (y)
   Enter New Password:
                enter: jocinbya -> password does not display
   Re-enter New Password:
                enter: jocinbya--> password does not display
   PASSWORD SUCCESSFULLY CHANGED


   The pwdstrn2 password strength server will display:


pwdstrn2 05/23/96 14:28:06 - rsec_pwd_mgmt_gen_pwd request: princ- user3
pwdstrn2 05/23/96 14:28:06 - rsec_pwd_mgmt_gen_pwd: princ- user3
pwdstrn2 05/23/96 14:28:14 - rsec_pwd_mgmt_str_chk request: princ- user3
pwdstrnd test (rsec_pwd_mgmt_str_chk): failure: generation_required, and password not found in cache.
pwdstrnd test (rsec_pwd_mgmt_str_chk): success: generation_required, and found in cache.



-------------------------------------------------------------------------------
9.  PASSWORD STRENGTH SERVER OPTIONS

The password strength server is invoked as follows:

  pwdstrn2 [ -d[ebug] ]  [ -v[erbose] ]  [ -t[imeout]  minutes ]
           [ -m[in_len] password_min_length ]  [ -c[ache] size ]
           [ +/- all[_spaces] ]  [ +/- alp[ha_num] ]

where:
       -debug             (optional) Causes the password strength server to
                          send its output to the screen rather than a log.
                          Error messages are sent to stderr and information/
                          warning messages are sent to stdout.
                          Default log pwdstrn2.log can be found in
                          directory \opt\dcelocal\var\security.

       -verbose           (optional) The password strength server generates
                          more messages.

       -timeout minutes   (optional) Defines the number of minutes a generated
                          password is held in the in-memory password generation
                          cache before it is deleted. The default is 30 minutes.

       -min_len password_min_length   (optional) Causes the minimun password length
                           tolerated by the Registry Server to be overridden.

       -cache size        (optional) Defines the number of password records
                          stored in the in-memory password generation cache. The
                          default is 100. Each password record can consist of one
                          or more generated password for a given user).

        +/-all_spaces      (optional) Causes the Registry policy to restrict passwords
                           consisting of all spaces. '+' means password of all
                           spaces are accepted. '-' means password of all spaces
                           are rejected.

        +/-alpha_num       (optional) Causes the Registry policy to restrict passwords
                           consisting of only alphanumeric characters. '+' means
                           only alphanumeric characters passwords are accepted.
                           '-' means any password NOT containing at least ONE
                           non-alphanumeric character will be rejected.




-------------------------------------------------------------------------------
10.  HINTS FOR CUSTOMIZING PASSWORD STRENGTH SERVER


  1)  You will notice a fair amount of conditional compilation within the
      source.  This is because IBM desires to deliver sample source code
      similar to the source code that is used to build the OS2 DCE
      pwdstred.exe module.

      In building an OS/2 DCE version of a strength server, the provided
      makefiles sets the following conditional compilation flags.  You
      should *not* change any of these values:

       IBMOS2 is defined.
       AIX_PROD is *not* defined.
       OS2_EXAMPLE is defined.
       OS2_FATMAP is *not* defined.

      With the flags set in this manner, the module is built such that it
      is dependent only on functions available to DCE customers; namely,
      dependent only on the exported DCE libraries, the compiler libraries,
      and the OS/2 Toolkit libraries.

  2)  You will also notice that with these flag settings, most if not all
      screen output uses message catalog functions.  In this case, the example
      relies on the DCE exported /opt/dcelocal/nls/msg/enus437/dcesad.cat.

      If your enhancements or modifications require additional messages to be
      output, you have a couple of choices:

         - use of printf directly

         - DCE exports the sams.exe program, and provides documentation for
            it in the Application Development reference and the Commands
            Reference.  You can use sams to build a private message catalog
            containing any of your new messages, and continue to rely on
            dcesad.cat for any unmodified messages.  Of course, you must
            enhance the source code to include sams-generated .h files to
            use any new catalog you might be generating.  And, you must
            then place your own .cat file within a directory that is listed
            in the NLSPATH environment variable.

      Fortunately, the source code maintains the original "in English"
      messages (in most cases) via the #else directives; hence you can "see"
      what the existing messages mean.  The DCE-internal source file used
      to generate dcesad.cat is *not* exported to DCE users in /opt/dcelocal.

  3) Near the beginning of pwdstrn2.c, you will see the definitions of
      constants that control basic DCE server parameters.  Search for the
      first occurrence of the string "SERVER_PNAME" to get to this location.
      You can tailor these variable to meet the needs of your particular
      strength server:

       SERVER_PNAME:  DCE service principal name used by this server
       OBJUUID:       All strength servers export the same interface
                      (rsec_pwd_mgmt).  The OS/2 DCE pwsync server also
                      exports this very same idl interface.  Hence, your
                      server must export its own unique object UUID for this
                      interface.  Run uuidgen to get a new UUID for this
                      purpose, and supply within this constant.

       Customers need not uniquely specify, via further source code
       modifications, the keytable file name, the program's log
       file name, or the CDS namespace location.  Rather, these names will
       be a function of the service principal name.  Customers should not
       alter this convention if they wish to configure their server via the
       GUI services that are part of OS/2 DCE.

       Furthermore, the server will be capable of running on either HPFS or
       FAT file systems so long as the service principal name chosen contains
       8 or less characters.  If a longer name are chosen, the server will
       only be capable of running on an HPFS file system.

       If a customer wishes to assign different names to the keytable file,
       the program log file, or CDS namespace location, then they can do so
       by altering the following constants that appear near the beginning
       of the source code:

         KEYTABNAME
         PWD_STRENGTHD_LOG
         CDSPATH

       The example source code assigns values to all of these constants as
       a function of SERVER_PRINC_NAME.  If a customer breaks this convention,
       the DCE Administration GUI services cannot be successfully used to
       perform configuration of the strength server.

  4)  The whole point of a "real" password strength server is to imbed "real"
      password composition checks that go beyond what minimal checks the DCE
      security server makes.  The example server only makes trivial password
      checks, and only if a test environment variable (PWD_PORT_TEST) is set.
      (If so, the example code allows any password unless it contains the
      letter 'z'.  This is sufficient for module testing, but obviously this
      is hardly suitable for "reality".)

      To locate where in pwdstrn2.c you would imbed your own algorithm, search
      for the string "COMPOSITION".  The second occurrence is where you would
      imbed your algorithm.  Comments in the code indicate that you can
      have the minimal checks rendered via the DCE registry policy enforced
      by the strength server itself by also calling "check_plain_pwd".

  5)  The files gen.c and pwd_cache.c support "system generated password",
      and the "caching" of them for some amount of time.  Generally, you
      would leave all of this logic alone, and take "as is".

  6)  Finally, one special note on a change we made to this serve for IBM DCE,
      that differs from the OSF DCE original.  There is within pwdstrn2.c a
      utility routine called check_auth_client.  It is called in a couple of
      places.  When called from rsec_pwd_mgmt_str_chk, the IBM DCE version
      passes a NULL parameter to it rather than the service principal name
      of the DCE security server.  This mod is essential if your password
      strength server is to cooperate in an OS/2 DCE environment with the
      password synchronization server (pwsync).  In general, an OS/2 DCE
      password strength server cannot assume who its "client" is; it can
      either be the DCE security server (secd), or it can be the password
      synchronization server (pwsync).  It depends on how the system is
      configured.


------------------------------------------------------------------------------
11.  OTHER HELPFUL HINTS


  1)  The password strength server generates messages to a log. The
      log file is pwdstrn2.log and can be found in directory
      \opt\dcelocal\var\security. The -debug option or
      redirection of output will override this log file.

  2)  Unlike rgy_edit and dcelogin, the dcecp program does not check
      the value of the pwd_val_type ERA when performing password changes.
      Therefore, if a user's pwd_val_type is 3 (password generation
      required), they will not be able to change their password using
      dcecp. dcecp has offers no way to present the generated password.
      Any proposed password would be rejected since it is not in
      the generated password cache.

  3)  You can not attache ERAs to principals using rgy_edit. ERAs can
      be added to principals using dcecp.

  4)  To view ERA's , use dcecp's principal show user0 -all or
      principal show user0 -xattrs.

------------------------------------------------------------------------------

For fuller information on Password Management functionality, see the IBM DCE
Application Development Guide -- Core Components volume  and the IBM DCE
Administration Guide -- Core Components volume.


