10.3 Configuration Statements

This section describes the following platform configuration file statements:

10.3.1 ACF2.DISABLE Statement

The ACF2.DISABLE statement specifies the handling for ACF2* users who have the Login Disabled attribute set in their corresponding eDirectory™ User objects.

Syntax:

ACF2.DISABLE Action

Action must be either suspend or cancel. Specifying either one causes the corresponding CA ACF2 logonid attribute to be set.

If no ACF2.DISABLE statement is present, the default Action is suspend.

Example:

ACF2.DISABLE cancel

10.3.2 ACF2.EXPIREWARN Statement

The ACF2.EXPIREWARN statement specifies the number of days before a User object password in eDirectory expires that Platform Services begins to warn the ACF2 user.

Syntax:

ACF2.EXPIREWARN Days

Days specifies the number of days that warning messages appear before password expiration.

If no ACF2.EXPIREWARN statement is present, the default is 5 days.

Example:

ACF2.EXPIREWARN 14

10.3.3 ADMINPASSWORD Statement

The ADMINPASSWORD statement specifies the password of the administrative user specified by the ADMINUSER statement. If there is no ADMINPASSWORD statement, you are prompted to enter the password when obtaining a platform security certificate.

Syntax:

ADMINPASSWORD Pswd

Pswd specifies the password of the administrative user.

Example:

ADMINPASSWORD 18emf25dhf

10.3.4 ADMINUSER Statement

The ADMINUSER statement specifies the fully distinguished name of an eDirectory user with Read and Create object rights to the ASAM System container. If there is no ADMINUSER statement, you are prompted to enter a user object name when obtaining a platform security certificate.

Syntax:

ADMINUSER Fdn

Fdn specifies the fully distinguished name of an eDirectory user with Read and Create object rights to the ASAM System container.

Example:

ADMINUSER .Admin.DigitalAirlines

10.3.5 AM.GROUP.INCLUDE Statement / AM.GROUP.EXCLUDE Statement

AM.GROUP.INCLUDE and AM.GROUP.EXCLUDE provide a list of specific groups or group masks to be included or excluded from Identity Provisioning. This can be useful for installation verification and early implementation and for special groups that should be managed locally. Multiple AM.GROUP.INCLUDE and AM.GROUP.EXCLUDE statements can be coded, and they can be mixed together. There is no limit to the number of groups that can be included or excluded.

Syntax:

AM.GROUP.INCLUDE GroupMask[ GroupMask, GroupMask ...]
AM.GROUP.EXCLUDE GroupMask[ GroupMask, GroupMask ...]

GroupMask can be a single complete group name, or it can include masking characters to represent more than one group. If more than one GroupMask matches a given group, the most specific GroupMask is used. GroupMask is case-insensitive. For more information, see Mask Characters and Examples.

Unless AM.GROUP.EXCLUDE * is coded, AM.GROUP.INCLUDE * is always assumed. Certain special groups are always excluded unless the IGNORESTANDARDEXCLUDES statement is specified. For details, see IGNORESTANDARDEXCLUDES Statement.

Do not code both an AM.GROUP.INCLUDE statement and an AM.GROUP.EXCLUDE statement.

For more information, see Section 10.4, Using Include and Exclude Configuration Statements.

Example:

AM.GROUP.EXCLUDE sales, mkt*

10.3.6 AM.USER.INCLUDE Statement / AM.USER.EXCLUDE Statement

AM.USER.INCLUDE and AM.USER.EXCLUDE provide a list of specific user IDs or user ID masks to be included or excluded from Identity Provisioning. This can be useful for installation verification and early implementation and for special user IDs that should be managed locally. Multiple AM.USER.INCLUDE and AM.USER.EXCLUDE statements can be coded, and they can be mixed together. There is no limit to the number of users that can be included or excluded.

Syntax:

AM.USER.INCLUDE UserMask[ UserMask, UserMask ...]
AM.USER.EXCLUDE UserMask[ UserMask, UserMask ...]

UserMask can be a single complete user ID, or it can include masking characters to represent more than one user ID. If more than one UserMask matches a given user ID, the most specific UserMask is used. UserMask is case-insensitive. For more information, see Mask Characters and Examples.

Unless AM.USER.EXCLUDE * is coded, AM.USER.INCLUDE * is always assumed. Certain special users are always excluded unless the INGORESTANDARDEXCLUDES statement is specified. For details, see IGNORESTANDARDEXCLUDES Statement.

Do not code both an AM.USER.INCLUDE * statement and an AM.USER.EXCLUDE * statement.

Identity Manager Fan-Out Driver Linux/UNIX platforms always manage root locally.

For more information, see Section 10.4, Using Include and Exclude Configuration Statements.

Example:

AM.USER.EXCLUDE act*, billing%, sys*, sales48

10.3.7 AS.USER.INCLUDE Statement / AS.USER.EXCLUDE Statement

AS.USER.INCLUDE and AS.USER.EXCLUDE provide a list of specific user IDs or user ID masks to be included or excluded from Authentication Services. This can be useful for installation verification and early implementation and for special user IDs that should be authenticated locally. Multiple AS.USER.INCLUDE and AS.USER.EXCLUDE statements can be coded, and they can be mixed together. There is no limit to the number of users that can be included or excluded, although a large list can cause a performance impact because it must be searched for every user login. These statements apply to system authentications only and are not used by the AS Client API routines (although there is an API call to test whether a user ID is excluded).

Syntax:

AS.USER.INCLUDE UserMask[ UserMask, UserMask ...]
AS.USER.EXCLUDE UserMask[ UserMask, UserMask ...]

UserMask can be a single complete user ID, or it can include masking characters to represent more than one user ID. If more than one UserMask matches a given user ID, the most specific UserMask is used. UserMask is case-insensitive. For more information, see Mask Characters and Examples.

Unless AS.USER.EXCLUDE * is coded, AS.USER.INCLUDE * is always assumed. Certain special users are always excluded unless the INGORESTANDARDEXCLUDES statement is specified. For details, see IGNORESTANDARDEXCLUDES Statement.

Do not code both an AS.USER.INCLUDE * statement and an AS.USER.EXCLUDE * statement.

For more information, see Section 10.4, Using Include and Exclude Configuration Statements.

Example:

AS.USER.EXCLUDE act*, billing%, sys*, sales48

10.3.8 AS.USER.NONNDS Statement

The AS.USER.NONNDS statement specifies how Platform Services handles users that are defined in the local security system but not in eDirectory. This allows an installation to avoid confusion between the Platform Services security system exit and standard TSO full-screen logon if a user is not defined in eDirectory.

Syntax:

AS.USER.NONNDS Action

Action specifies the action to take for a user that is defined in the local security system but not in eDirectory. Possible values follow.

Table 10-1 Possible Values for Specified Action

Value

Description

DISABLED

The user ID is handled as though it were revoked in the local security system.

UNDEFINED

The user ID is handled as though it were not defined to the local security system.

AUTHLOCAL

The user ID is authenticated locally, as though the Core Driver was not available. It is not allowed to change its password.

EXCLUDED

The user ID is authenticated as though it were excluded. The user can change its password in the local security system.

In each case, a message is written to the ASCLIENT log describing how the user's authentication request was modified.

If no AS.USER.NONNDS statement is provided, the default Action is undefined.

Example:

AS.USER.NONNDS authlocal

10.3.9 ASAMDIR Statement

The ASAMDIR statement specifies the file path where the Identity Manager Fan-Out Driver is installed. Fan-Out Driver components use ASAMDIR to find files needed for execution.

Syntax:

ASAMDIR FilePath

FilePath specifies the location in file system where the component is installed. If there is no ASAMDIR statement, FilePath defaults as follows:

  • z/OS: /usr/local/ASAM in HFS

  • IBM i: /usr/local/ASAM

  • Linux and UNIX: /usr/local/ASAM

  • Windows: c:\novell\asam

Example:

ASAMDIR c:\novell\asam

10.3.10 AUTHENTICATION Statement

The AUTHENTICATION statement specifies the network address and port of one Core Driver used for Authentication Services. In order to use Authentication Services, you must have at least one AUTHENTICATION statement in your configuration file.

A maximum of 100 AUTHENTICATION statements can be coded.

Syntax:

AUTHENTICATION Address [PORT PortNumber] [PREF PrefGroup]

Address specifies the DNS name or IP address of a Core Driver used for Authentication Services.

PortNumber specifies the TCP port number that is to be used to communicate with this Core Driver. PORT is optional. PortNumber defaults to 3451.

IMPORTANT:If you specify a port number other than the default, you must also use the Web interface to specify the same port number for the Core Driver configuration object.

PrefGroup specifies the Preference Group Number that determines the way a Core Driver is selected. It is optional, and the default is for all Core Drivers listed to be in Preference Group 1. Core Drivers within a Preference Group are selected equally for load balancing. Core Drivers with the lowest Preference Group Number are always tried first, followed by the Core Drivers with the next Preference Group Number, and so on, until a Core Driver can be contacted. Preference Group Number must be coded as a positive integer.

Examples:

AUTHENTICATION cdriver1.digitalairlines.com
AUTHENTICATION cdriver2.digitalairlines.com
AUTHENTICATION cdriver5.digitalairlines.com PORT 5009 PREF 2

10.3.11 HONORMVSDISABLE Statement

The HONORMVSDISABLE statement controls whether or not the local z/OS platform’s security system user disabled status is honored if the user is enabled for login in eDirectory.

Users whose Login Disabled attribute is set in eDirectory cannot log on through Authentication Services regardless of the setting in the local security system.

Syntax:

HONORMVSDISABLE Action

Action must be either YES or NO.

If Action is YES, a user that is enabled in eDirectory but disabled in the local security system is not allowed to log on.

If Action is no, a user that is enabled in eDirectory but disabled in the local security system is allowed to log on, and the flag in the local security system is set to enable logons.

For RACF, the Revoke attribute is used to determine the local disabled status.

For CA ACF2, the logonid attribute specified by the ACF2.DISABLE statement is used to determine the local disabled status.

For CA Top Secret, the PSUSPEND flag is used to determine the local disabled status. The ASUSPEND flag is not programmatically accessible. Users with the ASUSPEND flag set are always prevented by CA Top Secret from logging on.

If no HONORMVSDISABLE statement is present, the default Action is NO.

Example:

HONORMVSDISABLE YES

10.3.12 IGNORESTANDARDEXCLUDES Statement

The IGNORESTANDARDEXCLUDES statement specifies that the standard list of users and groups excluded from Identity Provisioning and Authentication Services processing is not used. If this statement is not present, the standard list of excludes is used. For the standard list of excluded users and groups, see Section 8.8, Standard Exclude List.

Syntax:

IGNORESTANDARDEXCLUDES

Example:

IGNORESTANDARDEXCLUDES

10.3.13 KEY Statement

The KEY statement specifies a 56-bit DES encryption key for communications between a platform that uses DES encryption, and Core Drivers.

Syntax:

KEY KeyValue

KeyValue specifies the value of the key. KeyValue must be entered as sixteen hexadecimal digits (0-9, A-F, a-f). The Web interface is used to enter this value in the corresponding Platform object. You must specify the same key value in both places. For details about using the Web interface to set the attributes of a Platform object, see Section 6.5.6, Configuring Platforms.

Example:

KEY 0f4b9692d8bca5f6

10.3.14 LOCALE Statement

The LOCALE statement identifies the language to be used by the component.

Syntax:

LOCALE Id

Id specifies the two-character ISO 639 language identifier.

Example:

LOCAL en

10.3.15 PLATFORMNAME Statement

The PLATFORMNAME statement specifies the common name of the Platform object. If there is no PLATFORMNAME statement, you are prompted to enter the name when obtaining a platform security certificate.

Syntax:

PLATFORMNAME Cn

Cn specifies the common name of the Platform configuration object that was specified in the Web interface when platform was defined.

Example:

PLATFORMNAME WestCentral

10.3.16 PROVISIONING Statement

The PROVISIONING statement specifies the network address and port of one Provisioning Manager Core Driver. A PROVISIONING statement must appear in the configuration file for the Platform Receiver and when obtaining a security certificate.

You can code more than one PROVISIONING statement. The first PROVISIONING statement in the file identifies the Provisioning Manager that is tried first. If a connection with the Provisioning Manager identified by the first PROVISIONING statement fails, the Provisioning Managers identified by any other PROVISIONING statements are tried, in the order the PROVISIONING statements appear in the configuration file, until a connection is successful or there are no more PROVISIONING statements.

Syntax:

PROVISIONING Address [PORT PortNumber]

Address specifies the DNS name or IP address of a Provisioning Manager.

PortNumber specifies the TCP port number that is to be used to communicate with the Provisioning Manager. PORT is optional. The default port number for the Provisioning Manager is 3451.

IMPORTANT:If you specify a port number other than the default, you must also use the Web interface to specify the same port number for the Core Driver configuration object.

Example:

PROVISIONING cdriver1.digitalairlines.com
PROVISIONING cdriver4.digitalairlines.com

10.3.17 RUNMODE Statement

The RUNMODE statement specifies the mode of operation the Platform Receiver uses. Command line parameters that specify a mode of operation override the mode specified on the RUNMODE statement.

Syntax:

RUNMODE Mode

Mode specifies the mode of operation for the Platform Receiver. Possible values follow.

Table 10-2 Values For Specified Mode

Value

Description

PERSISTENT

The Platform Receiver uses Persistent Mode.

POLLING

The Platform Receiver uses Polling Mode.

SCHEDULED

The Platform Receiver uses Scheduled Mode.

If no RUNMODE statement or mode-related command line parameter is present, the Platform Receiver uses persistent Mode.

For more information about Platform Receiver modes of operation, see Modes of Operation.

Example:

RUNMODE polling

10.3.18 SECURITY Statement

The SECURITY statement specifies the type of security system in use. ASCLIENT attempts to determine the security system type by examining the subsystem table. RACF and CA ACF2 normally have subsystem table entries, but CA Top Secret does not.

If ASCLIENT cannot determine the security system that is in use, it writes a message to the log and disables password migration.

Syntax:

SECURITY SecuritySystemType

SecuritySystemType must be ACF2, RACF, or TSS.

Example:

SECURITY TSS

10.3.19 SMF Statement

The SMF statement specifies the SMF record type for the z/OS platform's performance statistics record. If the SMF statement is not present, the z/OS platform does not produce SMF records.

Syntax:

SMF RecordType

RecordType must be an integer between 128 and 255.

Example:

SMF 240