5.10 Automated Sign-On for Mainframe

Automated Sign-On for Mainframe enables an end user to automatically log on to a mainframe host application using a terminal emulation client.

Settings must be configured on:

* Management and Security Server — to secure the server connections and manage user access
* the terminal emulation client — to create the login macro and configure the client
* z/OS — to support the use of PassTickets

Refer to the Automated Sign-On for Mainframe Administrator Guide for the configuration needed in the client and on z/OS.

Continue with Configure Settings - Automated Sign-on in Management and Security Server.

5.10.1 Automated Sign-on for mainframe sessions

Check Enable automated sign-on to mainframe sessions to display the required configuration fields.

Then enter the required settings:

5.10.2 DCAS Servers

The DCAS (Digital Certificate Access Server) configuration is used to obtain a PassTicket from the mainframe.

The configured DCAS servers are listed. From here you can:

Add a DCAS server

Click +Add and enter the details for the DCAS Server Configuration.

NOTE:Check with your mainframe host administrator regarding the required DCAS settings.

Each DCAS server must be configured to accept client connections from the Administrative Server,
Several keystores must be correctly configured for client authentication. For details, see Configuring DCAS and RACF on z/OS in the Automated Sign-On for Mainframe Administrator Guide.

To configure MSS for automated sign-on, you need the DCAS server name, port, and the source where the mainframe user names are stored.

Server name

Enter the name of the DCAS server.

Server port

The default port is 8990; however, the DCAS server can be configured to use any port.

Client certificate used to authenticate to DCAS server

Choose which certificate to use for client authentication of the MSS Administrative Server to the DCAS server.

Use Management and Security Server certificate

This option uses the Administrative Server’s certificate and private key (configured on the Configure Settings - Certificates panel).
Use custom keystore

This option uses a separate keystore that contains a certificate and private key.
1. Enter the Keystore filename with the correct extension. The keystore can be one of these formats:
  - Java keystore: .jks
  - PKCS#12 keystore: .p12 or .pfx
  - Bouncy Castle BCFKS keystore: .bcfks
2. Enter the (case-sensitive) Keystore password used to read the keystore.
  
  The password for the keystore and the private key must be the same.
3. The keystore must be placed in the MSSData\trustedcerts folder.
  
  The default Windows location is
  
  C:\ProgramData\Micro Focus\MSS\MSSData\trustedcerts

Verify server identity

Check this box to verify the hostname entered in the Server name field against the certificate received from the DCAS server when a secure connection is made from the Administrative Server to DCAS.

Test Connection

Click this button to test the connection between the MSS Administrative Server and the DCAS server.

Using multiple DCAS Servers

You can configure more than one DCAS server for automated sign-on. Repeat the steps to Add a DCAS server. Then, you can Set a Preferred DCAS server.

Edit an existing DCAS server

Select a server, click Edit, and adjust the settings as needed. Click Apply.

Test the Connection

Select a server click Test Connection to test the connection between the MSS Administrative Server and the DCAS server.

Set a Preferred DCAS server

When multiple DCAS servers are configured, you can select a preferred one that will be used most often when assigning sessions. Select your preferred DCAS server, and click Set Preferred. A star appears next to the name of the preferred DCAS server.

When you assign access to an automated sign-on session, the preferred server will be highlighted; however, you can choose any of your configured DCAS servers.

Related topics

Delete a DCAS server

Select the DCAS server, and click Delete. When sessions are assigned to use this DCAS server, a dialog lists the assigned sessions.

If only one DCAS server is configured, all of the session assignments will be removed. You can cancel this action in the confirmation message.

If multiple DCAS servers are configured, you have the option to either remove or re-assign the sessions. To change the session assignments, select a different DCAS server from the drop-down list.

5.10.3 Secondary LDAP directory

Mainframe usernames may be stored in a secondary LDAP directory, which can be different from the directory used for authentication.

Check Enable secondary LDAP server to display the configuration fields for a separate LDAP server.

When enabled, the search filter on the secondary LDAP directory can be used in Assign Access to authorize users or groups to access specific sessions. When this check box is cleared, the search filter option in the Assign Access is unavailable.

Enter the settings for your secondary LDAP server.

Server type

Select the type of LDAP server that is used to store your mainframe usernames. The options on this panel change depending on the LDAP server type you select. If you do not see your specific LDAP server in the list, select Generic LDAP Compliant Directory Server (RFC 2256).

Security options

Data can be passed between the Administrative Server and the LDAP server as clear text or encrypted. The type of encryption used depends on your LDAP server. TLS/SSL is available for all server types, and Kerberos v5 is available for Windows Active Directory.

Plain Text. By default, Management and Security Server transmits data between the Administrative Server and the LDAP server in clear text. If you choose this option, you should prevent users from accessing the network link between these two servers.
TLS/SSL. When using TLS/SSL as the security option for an LDAP server, you must import the server’s trusted certificate. Use the Import Certificate button (below). If you are presented with multiple certificates, it is best to import the CA certificate.
Kerberos v5. When you select Windows Active Directory with Kerberos, you must enter the name of the Kerberos key distribution centers. Multiple key distribution centers, delimited by commas or spaces, can be used. If you do not know the name of the Kerberos key distribution center, enter the fully-qualified DNS name of the Active Directory server.

The option under the key distribution center name field allows you to encrypt all data transmitted over the Kerberos connection. By default, only user names and passwords are passed securely between the Administrative and LDAP servers using Kerberos. Encrypting all data is more secure, but may increase performance overhead.

Server name

Enter the LDAP server name as either a name or a full IP address. If you selected TLS/SSL, this LDAP server name must exactly match the Common Name on the LDAP server's certificate.

Multiple server names, delimited by commas or spaces, can be used for failover support. If an LDAP server is down, the next server on the list will be contacted. In this case, all fields specified on this panel that are used for LDAP connections should be available on all the LDAP servers, and should have identical configurations.

Windows Active Directory - DNS domain. When Windows Active Directory is selected (without Kerberos), you have the option to use a DNS domain instead of a specific domain controller. No further configuration is required. For more information, see LDAP Configuration.

Server port

Enter the port used by your LDAP server. The default is 389 for plain text or 636 for TLS/SSL.

If you are using Active Directory, you may wish to set the server port to the global catalog port, which is 3268 (or 3269 over TLS/SSL). Global catalog searches can be faster than referral-based cross-domain searches.

Username and Password

Provide the username and password for an LDAP server account that can be used to access the directory in Read-only mode. Generally, the account does not require any special directory privileges but must be able to search the directory based on the most common directory attributes (such as cn, ou, member and memberOf). Re-enter the password in the Password confirmation box.

NOTE:The username must uniquely identify the user in the directory. The syntax depends on the type of LDAP server you are using.

For Windows Active Directory with Plain Text, enter
- NetBIOS domain\sAMAccountName (such as exampledomain\username)
- userPrincipalName (such as username@exampledomain.com)
- or
- distinguished name (such as uid=examplename,DC=examplecorp,DC=com).
For any other LDAP server type, enter the distinguished name (such as uid=examplename,DC=examplecorp,DC=com).

If this account password changes, be sure to update the account password here and apply the new settings. To avoid this problem, you may wish to set up an account that is not subject to automatic password aging policies, or that cannot be changed by other administrators without notice.

Search Base

Directory search base. Enter the distinguished name of the node in the directory tree you want to use as the base for Administrative Server search operations.

Examples: DC=my_corp,DC=com or o=my_corp.com.

For more information about how to describe the search base, see the LDAP administrator for your organization.

Certificate

Click Import Certificate to import the LDAP server's trusted certificate into the JRE's default trusted keystore. This button displays when TLS/SSL is selected.

Validate LDAP Connection

Click Test Connection to verify that the secondary LDAP server can connect to the Administrative Server (Management and Security Server).

It the test fails, consult the logs to resolve the issue.

Related topics

5.10.4 User Principal Name (UPN)

An LDAP attribute value in the form of a User Principal Name (UPN) may be used as a direct source for a mainframe username or as an element in a search filter for a secondary LDAP directory.

Enter the name of the LDAP attribute in the authenticating directory that contains the UPN value. The UPN generally has the form auser@domain.com.

Management and Security Server identifies the UPN value used to authenticate, then the portion before the @ sign is used either

as the mainframe username itself (when the UPN is selected for mapping directly without the use of a secondary LDAP directory).

For example, a UPN of auser@domain.com would result in the mainframe username of "auser" (the portion before the @).

or
as an element in a search filter for a secondary LDAP directory.

Related topics

5.10.5 Search filter used with secondary LDAP directory

Choose the method for obtaining mainframe usernames from your secondary LDAP directory.

Use value derived from the UPN.

When using a secondary LDAP directory, "auser" is used as the derived value to look up another value in the secondary directory that contains the mainframe username.

For instance, a search filter could be created for a secondary lookup, where “(some attribute in 2ndary=auser)”

Enter the attribute from the secondary directory
Alternatively, Automated Sign for Mainframe can use a value of another attribute in the authenticating directory can be used as the value in the search filter to find the object in the secondary LDAP directory containing the user's mainframe username.

Enter the attributes for both the authenticating and the secondary LDAP servers.

5.10.6 Next step

After Automated Sign-on for Mainframe is configured in MSS, be sure the client is configured to use a session with an automated sign-on macro. Then, you can assign access to those sessions.

For details, see the Configuration Workflow in the Automated Sign-on for Mainframe Administrator Guide.

Related topics