THE DAILY DIGEST

The daily edition.

Essential reading from Rocket Enterprise. Straight to the source.

Archived edition
DAILY EDITION1 story· 6 min read
IN FOCUS

ESF Passtokens: A [Passtoken] allow= Switch, Per-User LDAP Rights, and Why MFDS and ESCWA Must Share One Security Configuration

Passtokens let one Enterprise Server security domain sign a user on to another without the user's password. In Enterprise Developer 12.0 for Eclipse (UNIX), the ESF Manager [Passtoken] allow= option and, for the MLDAP ESM Module, per-user LDAP attributes govern who may generate and use them. [1] [3]

Read the full briefing

Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX) documentation; Enterprise Server security (External Security Facility, ESF).

What a passtoken is

Passtokens are an optional ESF feature for communicating a user's identity between security domains. They allow one Enterprise Server component (an enterprise server region or MFDS) to sign on to another component on behalf of a user, without requiring that user's normal credentials, typically a password. The manual describes a passtoken as "a one-time or limited-time substitute for a user's password". It is associated with a user (and signon group) when created and can only be used to sign on as that user. (ESF Passtokens)

The documented uses, when passtokens are enabled, are:

  • Administrator convenience: switching between the MFDS administrative interface and ESCWA without a manual signon, provided the destination accepts the passtoken and the administrator has authority there.
  • Inter-system communication: some MTO facilities can use passtokens rather than actual passwords when invoking functions or programs in other regions.
  • TN3270 automated sign-on using ELF or DCAS.

Not every ESM Module supports passtokens. With a module that does not, user identities are not transferred automatically across security domains and users must sign on explicitly in each domain.

Controlling passtokens in the ESF Manager

Because passtokens bypass the normal mechanism that establishes identity, they can be a risk if an unprivileged user can create them for other users. ESF Manager can therefore be configured to disallow generation, use, or both, and this affects every security domain (region or MFDS) using that security configuration. (Access to Passtokens)

The option is set in the Configuration Information area on the Security tab of the region configuration in MFDS (or the "Default ES Security" or "MF Directory Server" tabs in the security options). This is not the configuration area of the Security Manager object used for ESM Module options. Text there is organized into bracketed tag sections followed by name=value lines. (Passtoken Options for ESF Manager)

[Passtoken]
allow=option

The accepted values of option:

  • none: disable passtokens.
  • generate: allow passtoken generation but not use.
  • signon: allow passtoken use for signon but not generation.
  • both: allow both generation and signon.
  • yes: a synonym for both.

The manual notes that generation-only may suit a region that makes ISC requests to another region but does not receive them, while signon-only may suit a region that receives remote requests but never makes them. Passtoken support is enabled by default in the ESF Manager. (Typical Passtoken Configurations)

Per-user rights with the MLDAP ESM Module

ESM Modules that implement passtokens often add their own controls. The MLDAP ESM Module lets each user be assigned whether they can generate passtokens for themselves, for any user, or not at all, and whether they can be signed on using a passtoken. These rights are set as attributes on the user objects in the LDAP repository. (Access to Passtokens)

The two attributes named in the documented configurations are microfocus-MFDS-User-CreateToken and microfocus-MFDS-User-UseToken, with values of self or any.

Typical configurations

The manual presents four typical configurations. (Typical Passtoken Configurations)

  • No passtokens: described as the most secure option. Users always sign on explicitly when entering security domains, administrators log on to MFDS and ESCWA separately, and user identity is not transferred automatically over ISC links (for example for CICS Transaction Routing). Passtokens are disabled in the ESF Manager configuration of each Security Manager object in the MFDS repository.
  • MFDS and ESCWA administration:
    • MFDS and ESCWA are in different security domains because ESCWA runs within an enterprise server region and MFDS is separate. With passtokens, an administrator logs in once and moves between them.
    • MFDS and ESCWA always use normal passtokens, so this can be enabled without enabling surrogate tokens.
    • MFDS and the region being administered must use the same security configuration, for example both set to Default ES Security.
    • With the MLDAP ESM Module, each administrative user who should switch transparently needs microfocus-MFDS-User-CreateToken and microfocus-MFDS-User-UseToken both set to "self". System users such as SYSAD need this only if used as administrator IDs.
  • ISC (Transaction Routing and Function Shipping between two enterprise server regions):
    • ISC passtokens are surrogate passtokens generated automatically, always by the region's system user (the account used to start the region).
    • For the MLDAP ESM Module, accounts used to start the region need microfocus-MFDS-User-CreateToken set to any, and accounts running CICS transactions that might cause an ISC request need microfocus-MFDS-User-UseToken set to any.
    • If the regions use different LDAP repositories, the system user belongs to the initiating region and the signed-on regular user belongs to the region processing the request.
    • Passtokens are not supported for ISC conversations with non-enterprise-server regions, such as MFE or mainframe CICS.
  • Multi-factor authentication: logging on without a username and password requires passtokens. MFA uses RACF-style (short) passtokens generated by the Digital Certificate Access Server (DCAS). With the MLDAP ESM Module, each such user needs the same two attributes set to "self".

Prerequisites and cautions

  • The security configurations of components exchanging passtokens, such as the MFDS administration interface and the ES Monitor & Control interface in the region, must be identical. The manual states that passtokens between components with differing configurations "might work but are not supported". (ESF Passtokens)
  • In its default configuration MFDS does not require signon. If the administrator is not signed in, no passtoken is generated when switching to ESCWA, so MFDS must be configured to require an administrative signon for MFDS/ESCWA passtokens to be used.
  • The manual states that Rocket Software recommends not using surrogate passtokens: any user permitted to create them can impersonate any other user who is allowed to sign on with a surrogate passtoken. ISC passtokens are nonetheless surrogate passtokens, so the any rights on the region start-up account and transaction users deserve deliberate scoping.
  • In this version of ESF there are no facilities for manually using or administering passtokens beyond these access controls; the product uses them automatically in certain facilities. (Using Passtokens)

Takeaway

Passtokens are enabled by default in ESF Manager, so the [Passtoken] allow= option (none, generate, signon, both, yes) and, under the MLDAP ESM Module, the microfocus-MFDS-User-CreateToken and microfocus-MFDS-User-UseToken attributes are the documented controls for narrowing who can create and use them.

Rocket Enterprise Developer / Enterprise Server 12.0 (Linux/UNIX docs)
Documentation references
That’s the briefing.You’ve reached the end of this edition.
More editions

From the archive

View all
Nov 4

Fileshare Rollback Recovery: Faster, but Only with the Right Logging Guarantees

Nov 3

CHARSET and MF_CHARSET: EBCDIC Execution, In-Flight Code Set Translation, and System Library Constraints

Nov 3

XA Reconnect Modes: Retry Per Transaction or Disable the Resource Manager