Standard sign-on dialog

The standard sign-on dialog is always performed when the following two conditions are met:

1. Automatic KDCSIGN (= automatic sign-on check) is not generated for the terminal (see "Automatic KDCSIGN").

2. No sign-on service is generated for the standard application name (generated in MAX APPLINAME) under which the user signed on (see "Sign-on process with sign-on services").

In the standard sign-on dialog, openUTM carries out a sign-on check (system access control). The sign-on dialog cannot be modified.

Different levels of freedom can be defined for the sign-on check. An overview of all options can be found in the diagram in the section "Scenarios for the UTM sign-on check".

openUTM conducts the sign-on check interactively with the user if the -S switch was specified at the start of the corresponding dialog terminal process. In this case, openUTM requests the login and, if generated, requires that you specify a password.

If the -S switch is not specified, openUTM performs the sign-on check with the system login under which the user signed on to Unix or Linux systems. In this case, a password may also be generated for the login in the UTM application, and the user will be asked to enter this password during the sign-on check.

Please note, however, that a user cannot work simultaneously with several dialog terminal processes under one login.

Entering the password

If a password is generated for the user id (KDCDEF statement USER...,PASS=password[, DARK]), the password is always entered in a field without blanking.

With every sign-on to the UTM application, the user has the option of entering a new password to replace the previous one, provided the minimum validity period allows the password to be changed at this time. The new password must then be entered once in a field without blanking. openUTM checks the old password entered and, if necessary, the new password. If the old password is incorrect, a UTM message is output to inform the user and request again to enter a user ID.

Validity period of the password

When generating the user ID, you can define a maximum and minimum validity period for the password:

USER ...,PROTECT-PW=(...,maxtime,mintime).

The minimum validity period means that the user cannot change his or her password until this period has expired. The maximum validity period means that the user must change the password within the specified period.

If the password will become invalid within the 14 days following the sign-on procedure, openUTM warns the user in a K-message as long as a change is allowed at this time according to the minimum validity period for the password. A password can be changed as described under “Entering the password”.
To prevent users that have not worked with the application for a long time from forgetting to change their password and then consulting the system administrator, the UTM application can be configured such that these users may sign on one more time after their password has expired, see section “Grace sign-on” below.

When the password is changed, openUTM checks the following:

• when a maximum validity period is specified, whether the new password differs from the old one.
  If a password history is generated (SIGNON ...,PW-HISTORY=n), the new password is also checked against the last n passwords.

• whether the new password corresponds to the level of complexity generated for the user ID (USER ...,PROTECT-PW=).

• whether the length of the password is greater than or equal to the generated minimum length (USER ...,PROTECT-PW=).

If the new password fulfils all of these conditions, openUTM changes the password. The validity period of the new password again corresponds to the generated value.
If the new password does not satisfy one of these conditions, the following UTM message is output to ask the user to reenter the KDCSIGN information using the old password:

K097 Input for new password cannot be used - please sign on

If the validity period of the password has already expired when the sign-on attempt is made and if no grace sign-on is generated, the sign-on attempt is rejected with the following UTM message:

K120 Password expired - please sign on

It is then not possible to sign on again to the UTM application under this user ID until the UTM administrator has assigned a new password to the user ID.

Grace sign-on

If the validity of the password has already expired when the user attempts to sign on and if the application is generated with grace sign-on (SIGNON ...,GRACE=YES), a K message informs the user that his or her password is no longer valid. The user is also asked to enter the old password and a new password.

Scenarios for the UTM sign-on check

The following diagram shows the possible variants of the UTM-sign-on check, depending on the KDCDEF generation. If incorrect data is entered, openUTM outputs a specific UTM message and asks the user to reenter the information. If several unsuccessful sign-on attempts are made in succession from a particular terminal or under a particular user ID, openUTM outputs UTM message K094 with the standard destination SYSLOG (system log file). The maximum permitted number of unsuccessful sign-on attempts before UTM message K094 is initiated can be defined in the UTM generation with the KDCDEF statement SIGNON ... SILENT-ALARM=. A MSGTAC program unit can respond to this UTM message.

Figure 3: Sign-on check scenarios for applications with logins (part1)

Figure 4: Sign-on check scenarios for applications with logins (part 2)

Figure 5: Sign-on check scenarios for applications with logins (part 3)