docmain.css" /> Authentication & Authorization - Management and Security Server Administrator Guide

5.8 Authentication & Authorization

5.8.1 Choose Authentication Method

Authentication validates the user's identity based on some credentials, such as a username/password combination or a client certificate. Select a method to authenticate users:

  • None - Management and Security Server does not present a login screen. Any user can access their assigned sessions without being prompted for credentials. Session authorization is not available.

    NOTE:If you set the authorization method to None, be aware that all users are logged in as Guest. During session configuration, it is best to not allow users to modify their session settings (User Preference Rules), because they can overwrite each other’s choices.

  • LDAP - Management and Security Server makes a read-only connection to your existing LDAP (Lightweight Directory Access Protocol) server to verify usernames and passwords. You can also use LDAP to authorize session access. LDAP is an industry standard application protocol for accessing and maintaining distributed directory information services over a network.

    NOTE: You can enable more than one LDAP server.

  • Single sign-on through IIS - This option uses Microsoft IIS web server. This option requires no additional setup as long as you used the automated installer and chose to integrate with IIS during the installation process. You can find more information on install configurations in the Management and Security Server Installation Guide.

  • Single sign-on through Windows authentication - This option uses the NT LAN Manager version 2 (NTLM v2) protocol to authenticate users. When a user logs into the Windows domain and requests a session using a web browser that supports integrated authentication though NTLM v2, a secure hash of the user's credentials is sent to a domain controller for verification. Once verified, the Administrative Server establishes an authenticated HTTP session with the user's browser.

    NOTE:NTLM v1 is no longer supported. Any settings saved for Single sign-on through Windows are exclusively for NTML v2 and will overwrite any existing NTLM v1 settings.

    Microsoft Internet Explorer, as well as other web browsers, support integrated authentication through NTLM, but other browsers may require additional configuration to enable this functionality. The computer running the Administrative Server does not need to be a member of the Windows domain.

  • X.509 - X.509 is a standard for managing digital certificates and public key encryption. When you use certificate-based authentication, you can specify the certificate source and setting for LDAP failover if certificate-based authentication fails.

  • SiteMinder - To enable this option on a Windows system, install both the Administrative Server and a SiteMinder web agent on the same machine as IIS, and set up the server to use your IIS web server.

The setup options vary based on your selection.

Related Topics

5.8.2 Choose Authorization Method

The authorization method determines who can access your terminal emulation sessions.

  • Allow authenticated users to access all published sessions

    When this option is selected, the Assign Users & Groups panel presents the list of sessions that you can to publish to all end users. Users see the list of sessions when they log in.

  • Use LDAP to restrict access to sessions

    When this option is selected, the Assign Users& Groups panel allows you to assign specific sessions to specific LDAP users or groups. Logon userids must match those in the LDAP directory. After the sessions are assigned, the authorized users see their list of sessions when they log in.

Related Topics

5.8.3 LDAP Server Configuration

When you use LDAP to authenticate or authorize users, Management and Security Server makes a read-only connection to the LDAP server. Use these settings to configure that connection.

LDAP Servers

You can Add, Edit, Test, or Delete the connection for each LDAP server. Check with your organization’s LDAP administrator for more information, if needed to configure these options.

To use more than one LDAP server to authenticate or authorize users, you must first set a property. See Enabling Multiple LDAP Servers, and then proceed with the LDAP configuration for each server.

Enabling Multiple LDAP Servers

More than one LDAP server can be configured to authenticate and authorize users. A property must be set, and then the servers can be added and configured.

To enable multiple LDAP servers:

  1. Open PropertyDS.xml. (Administrative privileges are required.)

    On Windows: C:\ProgramData\Micro Focus\MSS\MSSData\

  2. Locate this property, and set the value to true:

    <CORE_PROPERTY NAME="AC.DirAllowMultiLdap">

    <BOOLEAN> true </BOOLEAN>

    </CORE_PROPERTY>

  3. Save the file.

  4. Restart the MSS server.

  5. Return to the Administrative Console and enter the LDAP Configuration information for each LDAP Server.

    Or, if you are configuring Single sign-on through Windows authentication, return to Adding Another Server for Single Sign-on Through Windows.

NOTE:To revert to a single LDAP server, set the property in step 2 to false, save the file, and restart the MSS server.

LDAP Configuration

Click +Add to open the LDAP Configuration panel, or select a server and click Edit.

Enter or edit the LDAP Server information.

  • Server type

    Select the type of LDAP server you are using. 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 Server 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. When selected, you do not need to specify a domain controller address or the corresponding NetBIOS name because Management and Security Server provides the Domain Controller Locator Service. This service can be used only when the Administrative Server is running on Windows.

    For example, when you enter a domain name, such as mycompany.com, Management and Security Server automatically finds an available domain server and the domain name, which can be different from the DNS domain.

  • 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 Windows 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 and Groups/Folders

  • 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.

  • Groups or folders

    While you can assign sessions to specific users in the directory, you can also assign sessions to either Logical groups or Folders. Choose the option that reflects the way the data is organized in your directory -- and the way you want to Assign Access. For instance if you want to assign access to a folder, then Folders must be selected here.

    In Management and Security Server, the term folder is used to describe both organizational units and containers. Most directories have an organizational structure that uses logical groups; for example, groupOfNames and groupOfUniqueNames.

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.

Authentication of End Users

LDAP attribute for identifier. The default LDAP attribute to use as an identifier is available when you select an LDAP server type.

Table 5-2 Default LDAP identifiers

Server type

Default user identifier

OpenLDAP Directory Server

cn

Generic LDAP Compliant Directory Server (RFC 2256)

cn

RACF Directory Server

racfid

Oracle LDAP Directory Server

uid

IBM Tivoli Directory Server

cn

Windows Active Directory

List of domains*

NetIQ eDirectory

cn

Windows Active Directory with LDAP login form

cn

* When you select Windows Active Directory with Kerberos, you must enter a Kerberos realm (such as domain@example.com). If you are using Windows Active Directory with Plain text, enter a NetBIOS domain name with a maximum of 15 characters (such as MYCOMPANY, SALES). If you have more than one domain or realm, separate the entries with commas (for example, 1stDomain, 2ndDomain, 3rdDomain). When an end user requests the list of sessions, the login panel prompts for a username and password and displays available domains or realms in a drop-down list.

Validate LDAP Connection

Click Test Connection to verify that this LDAP server can connect to the Administrative Server (Management and Security Server). If the test fails, check the logs and resolve the issue before continuing.

Advanced Settings

Maximum nested level for groups

This number determines how assigned sessions are inherited. If Group A contains Group B of which JohnUser is a member, and you assign a session to Group A, JohnUser will also have access to that assigned session. If users do not inherit sessions as you expect, increase this number. Do not raise this level more than necessary because too high a number can impair performance if you have a large number of users. The default is 5.

After the LDAP servers are configured, use Assign Users & Groups to authorize users’ access to sessions.

Related Topics

5.8.4 Single Sign-on through IIS

This method assumes that Management and Security Server is set up to use your IIS web server (Windows only).

If you installed using the automated installer and integrated with IIS during installation, setup is complete. If you used an alternative installation method, see the Management and Security Server Installation Guide for more information.

Users who have logged in to Windows do not need to log in again to access sessions. You must administer usernames and passwords through the identity system used by IIS, typically Active Directory.

Credential Prompts When Using Single Sign-on

When Management and Security Server is configured to use Single Sign-On through IIS or through Windows, a user will be prompted for credentials under certain circumstances:

  • The browser's process owner is not a valid Windows user or a member of the Active Directory domain. Typically the browser's process owner performs the interactive login to the operating system. However, an exception to this occurs when the Run As command launches the browser as a different user.

  • The browser does not support single sign-on using Kerberos.

    • - In Internet Explorer, this option is enabled by selecting Enable Integrated Windows Authentication. While this option is enabled by default, it can be overridden through Group Policies and practices.
    • - In Mozilla Firefox, you must configure support for Kerberos authentication. Refer to Firefox documentation for instructions.
  • When using Internet Explorer, if the management.server.iis.url property contains periods (such as http://www.microsoft.com or http://10.0.0.1), the requested address is assumed to exist on the Internet. Credentials are not passed automatically, and a credentials prompt will appear. However, Internet Explorer can be configured to automatically pass credentials for such an address by adding it to the Trusted Sites list. Alternatively, you can configure a Custom security level in Internet Explorer to perform an Automatic logon with current username and password.

Related Topics

5.8.5 Single Sign-on through Windows Authentication

Use this configuration to set up Management and Security Server in a Windows environment that uses Active Directory authentication (NTLM v2) with or without LDAP authorization.

NOTE:NTLM v1 is no longer supported. Any settings saved for Single sign-on through Windows authentication are exclusively for NTML v2 and will overwrite any existing NTLM v1 settings.

If you cannot upgrade to NTLM v2, you can manually edit your NTLM v1 settings. Contact Support for details.

  1. In Configure Settings - Authentication & Authorization, click Single sign-on through Windows authentication.

  2. Select your authorization method:

    • Allow authenticated users to access all published sessions

    • Use LDAP to restrict access to session

      NOTE: The same server will be used for Windows (Active Directory) authentication and LDAP authorization.

  3. Click +Add and proceed according to your selected authorization method.

Related Topics

Configure Windows Single Sign-on (without LDAP)

Use these settings to configure Windows Single Sign-on authentication without using LDAP authorization.

(If instead you want to use LDAP, click Cancel. Click Use LDAP to restrict access to sessions, click +Add and proceed with Use LDAP to restrict access to Single Sign-on sessions.)

  1. Enter the settings to Add or Edit an NTLM server for Single Sign-on through Windows Authentication:

    1. Choose and enter either

      • Domain Controller DNS name or IP address

        IP address or DNS name of the Active Directory Domain Controller.

        NetBIOS hostname of domain controller

        The first 15 characters of the domain controller’s host name, for example, myComputer.

        Note: The term NetBIOS is called pre-Windows 2000 in some Windows utilities.

        — or —

      • DNS domain

    2. NetBIOS domain name

      The first 15 characters of the left-most label in the DNS domain name.

      Example: For the DNS domain name mydomain.mycompany.com, enter the NetBIOS domain value mydomain.

      HINT:To obtain the NetBIOS name for a domain on Windows Server 2000 or higher:

      1. Open the Active Directory Domains and Trusts snap-in (domain.msc).

      2. In the console tree, right-click the domain and select Properties.

      3. The Domain name (pre-Windows 2000) field displays the NetBIOS name.

      On Windows Server 2008 or higher, you can also use the Active Directory module for Windows PowerShell to find the NetBIOS name of a domain in Active Directory Domain Services.

      On Windows Server 2008 only, if the Active Directory module is not available, you may need to install it first, using this PowerShell command:

      import-module activedirectory

      This example demonstrates how to find the NetBIOS name of the domain called mydomain.com:

      Get-ADDomain -Identity mydomain.com | findstr /I NetBIOSName

    3. Computer account (for servicing)

      A computer account in the Active Directory domain. A computer account is different than a user account. The computer account should not be associated with an actual physical or virtual computer.

      To specify the Computer account for servicing

      A computer account's syntax is the pre-Windows 2000 computer name, followed by a $ sign, followed by the @ symbol, and then the DNS domain name.

      Syntax: <Computer name (pre-Windows 2000)>$@<DNS domain name>

      For example, if the Computer name is ReflServiceAccount, the pre-Windows 2000 Computer name is REFLSERVICEACCO and the computer account is: REFLSERVICEACCO$@mydomain.com

    4. Computer account password

      If the password of the computer account is not already known, it must be explicitly reset in Active Directory. You can reset a computer account’s password using a simple VBScript, or the ADSI Edit tool.

  2. Click Test Connection.

    This action checks the NTLMv2 connection to be sure the server is listening and is in fact a domain controller. The test attempts to authenticate to the server using the IP address or alias for the domain controller, the NetBIOS hostname, computer account, and password.

    Note: The Domain is not tested and could still be a cause for error later in the authentication process.

    If the result is Success, click OK.

    If Test Connection fails, check the logs and resolve the issue before continuing.

  3. To add another server, see Adding Another Server for Single Sign-on Through Windows.

Related Topics

Use LDAP to restrict access to Single Sign-on sessions

To configure Single Sign-on through Windows authentication with LDAP authorization, first enter the LDAP settings and then the authentication settings for Single Sign-on through Windows.

  1. Enter the LDAP Server information:

    • Server type and Security options

    • Server name and Server port — or — DNS domain and Server port

    • Username

    • Password.

  2. Enter the Directory search base, and choose Logical groups or Folders.

  3. Enter the Domain used to authenticate end users.

  4. If desired, click Password expiration to set a reminder.

  5. Continue with the Single Sign-on through Windows Authentication Configuration. Enter the required settings:

    1. NetBIOS hostname of domain controller

      HINT:To obtain the NetBIOS name for a domain on Windows Server 2000 or higher:

      1. Open the Active Directory Domains and Trusts snap-in (domain.msc).

      2. In the console tree, right-click the domain and select Properties.

      3. The Domain name (pre-Windows 2000) field displays the NetBIOS name.

      On Windows Server 2008 or higher, you can also use the Active Directory module for Windows PowerShell to find the NetBIOS name of a domain in Active Directory Domain Services.

      On Windows Server 2008 only, if the Active Directory module is not available, you may need to install it first, using this PowerShell command:

      import-module activedirectory

      This example demonstrates how to find the NetBIOS name of the domain called mydomain.com:

      Get-ADDomain -Identity mydomain.com | findstr /I NetBIOSName

    2. Computer account (for servicing)

      A computer account in the Active Directory domain. A computer account is different than a user account. The computer account should not be associated with an actual physical or virtual computer.

      To specify the Computer account for servicing

      A computer account's syntax is the pre-Windows 2000 computer name, followed by a $ sign, followed by the @ symbol, and then the DNS domain name.

      Syntax: <Computer name (pre-Windows 2000)>$@<DNS domain name>

      For example, if the Computer name is ReflServiceAccount, the pre-Windows 2000 Computer name is REFLSERVICEACCO and the computer account is: REFLSERVICEACCO$@mydomain.com

    3. Computer account password

      If the password of the computer account is not already known, it must be explicitly reset in Active Directory. You can reset a computer account’s password using a simple VBScript, or the ADSI Edit tool.

  6. Click Test Connection.

    This action checks the NTLMv2 connection to be sure the server is listening and is in fact a domain controller. The test attempts to authenticate to the server using the IP address or alias for the domain controller, the NetBIOS hostname, computer account, and password.

    Then, the LDAP connection is tested.

    Note: The Domain is not tested and could still cause an error later in the authentication process. If the result is Success, click OK and continue with your setup.

    If Test Connection fails, the message specifies whether check the NTLM or the LDAP server connection failed. Check the logs and resolve the issue before continuing.

  7. Advanced Settings: For the Maximum nested level for groups, accept the default (5), or change the number.

  8. Click OK.

  9. To add another server, see Adding Another Server for Single Sign-on Through Windows.

Related topics

Adding Another Server for Single Sign-on Through Windows

You can add one or more Active Directory servers to use Windows authentication with or without LDAP authorization.

  1. Prerequisite: The property must be set to enable multiple LDAP servers—even if you do not use LDAP to restrict sessions. See Enabling Multiple LDAP Servers.

  2. On the Configure Authentication panel, verify that this method is selected:

    • Single sign-on through Windows authentication

  3. Select the Authorization method for this server:

    • Allow all authenticated users to access all sessions

    • Use LDAP to restrict access

  4. Click Add under Servers (or NTLM Servers).

  5. Continue with the steps for the selected type of authorization:

Related Topics

5.8.6 X.509 Configuration

Use this configuration to enable users to authenticate with X.509 client certificates, and then automatically connect to a host session. Optionally, you can specify settings to fall back to LDAP authentication if certificate-based authentication fails.

NOTE:X.509 is supported through the HTTPS port. Users should disable HTTP ports when running X.509.

Pre-requisites

See X.509 Certificates - Setup Requirements to be sure the requirements for this authentication scheme are met.

Authentication Settings

LDAP options for authentication

  • Fallback to LDAP authentication

    Use this option to prompt the user for LDAP credentials when certificate-based authentication fails.

  • Validate LDAP User Account

    Account validation is always enabled and causes authentication to fail when an LDAP search fails to resolve a Distinguished Name (DN) for the name value obtained from the user’s certificate. If you are using Microsoft Active Directory as your LDAP server type, additional validation is performed. User authentication will fail when the user’s Active Directory account is either disabled or expired.

  • Distinguished Name Resolution Order

    The values in this property can be re-ordered, added, or removed. Items are listed in order of preference. For example, to locate the User Principal Name of the certificate before checking other values, enter upn, email, cn_val, cn.

  • UPN Attribute Name

    This property is used only when upn is present in the Distinguished Name Resolution Order field; otherwise this property is ignored. The User Principal Name (UPN) is an Internet -style login name and generally takes the form auser@domain.com.

    The UPN value is retrieved from the Subject Alternative Name field in the user’s certificate. The Administrative Server then performs a search for an LDAP user object, based on the UPN attribute name and value, to validate that the user object exists in the LDAP database. The LDAP search filter takes the form of (upn-attribute-name=upn-value-from-certificate). For example: userPrincipalName=auser@domain.com.

    Enter the name of the LDAP attribute used in the LDAP directory where the UPN-style name is stored. If the LDAP Server type is Microsoft Active Directory, use the default UPN attribute name: userPrincipalName. Other LDAP implementations may use a different attribute name, such as email or a custom name.

Client options

  • Login Timeout (optional)

    Enter any available single value LDAP attribute, such as wWWHome (if using Microsoft Active Directory), or enter a custom single value LDAP attribute created by the LDAP administrator.

  • Custom Message when Authentication Fails (optional)

    When authentication fails, the user sees the default message, "The attempt to authenticate using a certificate or smart card has failed."

    You can append the general message with customized text. To do so, use \n to begin a new line. For example, to add a Help Desk number, enter

    \n\nFor further assistance:\n 1. Click OK to log on with User name and Password.\n 2. Call the Help Desk at 411-555-1212.

  • Custom PIN Prompt (optional)

    Use this field to add custom text to the Enter PIN dialog prompt. For example, Enter your smart card PIN.

Allowed source of certificates for Reflection for the Web clients

Note: If you do not use Reflection for the Web, the Hard and Soft certificate settings do not apply.

  • Select Hard certificates to use smart cards as an alternative to permanently installing client certificates on local hard drives. This option simplifies user authentication and prevents the unauthorized capture of passwords over networks. For more information, see Smart card settings

  • Select Soft certificates to use certificates stored on the client’s computer for X.509 authentication. The user's certificate must be included in a keystore named usercert.pfx.

    The admin must copy usercert.pfx to the preference files directory on a client workstation, typically in C:\Users\<username>\AppData\Roaming\mfmss.

    When soft certificates are enabled, X.509 authentication proceeds as follows:

    1. The browser on the client is used to browse to the Administrative Server (http://<servername>:<port>/rweb).

    2. During X.509alt authentication, the launcher checks for the usercert.pfx file before checking for a smart card.

    3. When the usercert.pfx file is found in the preference files location on the client, either

      X.509alt authentication completes and the links list displays

      – or –

      an Enter Passphrase dialog box opens, if required for usercert.pfx. Once the user enters the correct passphrase, X.509alt authentication completes and the links list displays.

Certificate Revocation Checking

Changes to the certificate revocation checking settings below do not take effect until the server is restarted.

NOTE:If you enable both OCSP and CRL checking, then OCSP will always be tried first. If the revocation status cannot be determined using OCSP, the validation will fall back to using CRL.

Enable Online Certificate Status Protocol (OCSP)

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate.

Use this option to specify Online Certificate Status Protocol (OCSP) settings that verify the TLS/SSL client certificate chain. OCSP is an alternative to Certificate Revocation Lists (CRLs), and is often implemented in a Public Key Infrastructure (PKI).

An OCSP server, also called a responder, may return a signed response signifying that the certificate specified in the request is good, revoked, or unknown. If it cannot process the request, it may return an error code.

Enable OCSP

Check this box to enable and configure OCSP options. The OCSP responder's signing certificate is checked using the same settings as the rest of the certificate validation.

Use Authority Information Access (AIA) Extension

The Authority Information Access (AIA) extension indicates how to access Certificate Authority information and services for the issuer of the certificate in which the extension appears. When enabled, the OCSP server URL specified in the Authority Information Access extension of a certificate is used to check the certificate revocation status using the Online Certificate Status Protocol.

Additional OCSP Responders

In addition to the URLs from the AIA extension, you can specify the URLs (separated by a space) of other OCSP responders. If you clear the Use AIA Extension checkbox, or if the certificate does not contain an AIA extension, only the URLs in this text box will be used. HTTP URLs are supported.

Example: http://ocsp.example.com

Enable Certificate Revocation List (CRL)

Use this option when the revocation status cannot be determined using OCSP.

Enable CRL

Check this box and enter the URLs of Certificate Revocation List issuers to be used for certificate verification. These are the URLs that your Security Proxy server is set to use when checking the user's client certificate. Enter each URL, separated by a space. LDAP and HTTP URLs are supported.

Use CRL Distribution Point (CRLDP) Extension

The CRL Distribution Point (CRLDP) extension indicates how to access Certificate Authority information and services for the issuer of the certificate in which the extension appears. When enabled, the CLR server URL (specified in the CRLDP extension of a certificate) is used to retrieve the Certificate Revocation List.

Additional CRL Issuers

In addition to the URLs from the CRLDP extension, you can specify the URLs (separated by a space) of other CRL issuers. If you clear the Use CRL Distribution Point checkbox, or if the certificate does not contain a CRLDP extension, only the URLs in this text box will be used.

Examples:

ldap://myCAServer.example.com/CA/certificaterevocationlist

http://server1.example.com/CertEnroll/server1.example.com.crl

5.8.7 SiteMinder Configuration

Management and Security Server uses Microsoft IIS to integrate with SiteMinder. For instructions on how to integrate IIS with MSS and if needed, Host Access for the Cloud, see Using the IIS Reverse Proxy with Host Access for the Cloud

If you selected SiteMinder as your authentication method, complete the configuration:

  • Agent version

    Some configurations vary depending on the version you select.

  • Agent name

    The name of the SiteMinder agent that is used by IIS. This is the Name of the agent configured to work with IIS that is integrated with the Management and Security Server.

  • Configuration file (version 5+)

    Provide a full path to the SiteMinder host configuration file. This is typically SmHost.conf and resides in the config directory in the SiteMinder web agent installation directory.

  • Shared secret (version 4)

    The secret used by the policy server to verify the agent. This is the Shared secret that was created in the SiteMinder Administration tool under System Configuration > Agents.

  • Policy server host (version 4)

    The IP address (preferred) or DNS name of the host on which the SiteMinder policy server is installed.

  • Authentication port (version 4)

    The SiteMinder policy server's authentication port. The default for this port is 44442. To check the port number, open the SiteMinder Policy Server Management Console, click the Settings tab, and look for the Authentication port number under Access Control. If other SiteMinder port numbers were changed from their defaults, you must reset the corresponding port numbers in the Management and Security Server PropertyDS.xml file, located in the MSSData folder.

  • User identity

    Determines which SiteMinder user attribute is displayed in the list of sessions and used for LDAP authorization.

  • User identity LDAP search attribute (optional)

    When the Administrative Server is configured to use authorization, use this field to specify the LDAP attribute used by the Administrative Server to perform an LDAP search request for the user's distinguished name (DN). During authorization, the Administrative Server issues an LDAP search request to obtain the user's LDAP DN. The LDAP search request's filter uses the attribute specified in this field.

    For example, if you enter the value "uid" into this field, then the LDAP search filter will look like: (uid=<SiteMinder username>) where <SiteMinder username> is the value of the SiteMinder user's name, obtained from the SiteMinder session token, using the ATTR_USERNAME key. Example: (uid=johns)

    NOTE:When the Administrative Server is not configured for authorization, any value entered in this field is ignored.

SiteMinder and 64-bit systems

If you’re using a 64-bit operating system, check to be sure that the PATH variable places the path to the 64-bit libraries before the path to the 32-bit libraries. To confirm the order, open a command window and type: echo %PATH%.

If the 64-bit libraries are not first in the path, then edit the PATH variable so that the path to the 64-bit libraries comes before the path to the 32-bit libraries.

Related Topics

5.8.8 Micro Focus Advanced Authentication

Advanced Authentication is a separate Micro Focus product that offers biometric and multi-factor authentication for several Micro Focus products, including Management and Security Server.

A separate Add-On license is required to use Micro Focus Advanced Authentication with Management and Security Server. See the Preliminary Tasks for details.

Configuring Advanced Authentication

To activate and set up Advanced Authentication, complete the preliminary tasks prior to configuring the Advanced Authentication server to trust the Management and Security Server.

Preliminary Tasks

  1. Install Micro Focus Advanced Authentication Server, and note the

    • server name (or IP address)

    • server's port number

  2. After you obtain the separate license for Host Access Management and Security Server - Advanced Authentication Add-On, download the activation file, named activation.advanced_authentication-<version>.jaw, from the product download page.

  3. Upload the activation file.

    1. Log in to Management and Security Server.

    2. Open the Administrative Console to Configure Settings - Product Activation.

    3. Click Activate New.

    4. Browse to and click the activation file you downloaded in step 2.

      The file is installed and added to the list of Currently Installed products.

  4. Continue with the steps for Configuring Advanced Authentication in the Administrative Console to establish trust between the Advanced Authentication server and Management and Security Server.

Configuring Advanced Authentication in the Administrative Console

Follow these steps to establish trust between the Advanced Authentication server and the Management and Security Server.

  1. In Management and Security Server, open Configure Settings - Authentication & Authorization.

  2. Select Micro Focus Advanced Authentication as the authentication method.

    Select LDAP as the Authorization method, if desired.

  3. Import the Advanced Authentication server’s certificate:

    1. Enter the Server name or IP address of the Advanced Authentication server (noted in Preliminary Tasks - step 1) without a prefix, such as https://.

      For example, enter <myserver>.<mycompany>.com.

    2. Enter the server’s Port number (also noted in Preliminary Tasks - step1).

    3. Click Import Certificate. A message displays to confirm whether the server is trusted.

      NOTE:If you are presented with multiple certificates to import, it is best to choose the CA certificate.

      If this error appears, Failed to retrieve the certificate chain for the server, be sure the server name is entered correctly. The host name must match the name in the server certificate.

  4. By default, the Verify server identity option checks to make sure the host name is matched with the certificate from the Advanced Authentication server.

    Note: When present, the SANs (Subject Alternative Names) in the Advanced Authentication server certificate is used, not the common name.

    CAUTION:Clearing the Verify server identity check box is a security risk. Do not disable this feature unless you understand the risk.

  5. Click the Test Connection, with Verify server identity checked.

    The test is successful when the entry for the Advanced Authentication server is valid, and the server address is in the certificate.

    If the test connection is not successful, troubleshoot the error as follows:

    • Advanced Authentication Failure - The hostname you entered does not match the server certificate.

      Check the certificate in the Configure Settings - Trusted Certificates list. Then, correct the server name to match the SAN in the certificate.

      For instance, a mismatch occurs when you enter the IP address, and the IP address is not in the certificate.

    • For more information, see trace.0.log. By default, trace.0.log is located in \ProgramData\Micro Focus\MSS\MSSData\log. To view the trace log file, use the LogViewer utility. For more information, see Using Log Viewer.

Configuring Advanced Authentication Methods

Refer to the Advanced Authentication documentation to configure Advanced Authentication methods, such as Fingerprint or Voice.

5.8.9 SAML Authentication

SAML (Security Assertion Markup Language) is an xml-based open standard format that exchanges authentication and authorization data between an identity provider* and a service provider**.

This release supports SAML v2.0 Web Browser SSO Profile for Reflection ZFE* 2.3 or higher.

* Beginning with version 2.4, Reflection ZFE is called Host Access for the Cloud.

Configuring Management and Security Server (MSS) to use SAML is a multi-step process.

In general, you must:

  • 1. Configure MSS as a SAML service provider.
  • 2. Download or access the service provider’s metadata from MSS.
  • 3. Export the service provider’s metadata into the identity provider.
  • 4. Map the identifier source.
  • 5. Configure the SAML whitelist.
  • 6. Configure LDAP, when used for authorization.
  • Follow the SAML Configuration steps.
  • * identity provider: the server that issues SAML assertions and performs authentication on behalf of the service provider.
  •  ** service provider: the web server from which you access information or services. MSS acts as the service provider.

SAML Configuration steps

Be sure to read the Important information, Cautions, and Notes as you configure Management and Security Server (MSS) to use SAML.

IMPORTANT:The SAML authentication scheme in MSS relies on HTTP session cookies for proper operation. Consistent use of fully-qualified DNS names across all SAML entities is strongly recommended. In particular, any clients of MSS should be configured to access MSS using the same DNS name that is used for the Assertion Consumer Service prefix URL.

Detailed steps:

Configure MSS as a SAML Service Provider

These steps are required before you can download the service provider’s metadata.

  1. Import the identity provider’s metadata to MSS (the service provider).

    Click Import and enter the file name or the HTTP endpoint (a URL). You may need to consult with your SAML administrator to locate the metadata.

    After importing, click Apply to store the metadata.

    Note: The colored box under the Import button displays the status of the identity provider (IdP) metadata: not stored, imported, or stored.

  2. Enter the service provider SAML Entity ID. The entry can be either a URL (preferred) or a URN for your installed Management and Security Server.

    URN examples: com:company:hostname:sp , com:microfocus:mssprod:sp

  3. Enter the SAML Assertion Consumer Service prefix URL.

    This entry is the prefix URL for the MSS endpoint that handles SAML assertions. At runtime, this prefix is used to build the web endpoint for the SAML assertion consumer service (SACS) and will resolve to <prefix URL>/callback.

    For example, if your prefix is https://hostname.domain.com/mss , then at runtime, the assertion consumer service will be https://hostname.domain.com/mss/callback

    CAUTION:  The value specified for the prefix URL must meet these requirements. If you encounter an error message, be sure these requirements are met:

    • The prefix URL value must end with the MSS server's web application context.

      For example, the default context is /mss.

    • The protocol must match the one used by MSS clients attempting to authenticate using SAML.

      For example, when using SAML authentication in Host Access for the Cloud, the protocol specified in the management.server.url property in Host Access for the Cloud must match the protocol of the prefix URL defined in this field: http or https. A mix of protocols (http and https) is not supported.

  4. Click Apply.

    The Download button is enabled when these values have been specified and applied:

    • Identity Provider metadata

    • Service Provider SAML Entity ID

    • SAML Assertion Consumer Service prefix URL

  5. Sign Requests. Check this box to sign the SAML service provider requests made by MSS.

    NOTE:If needed, a different private key and/or certificate may be specified in the keystore named saml.bcfks, located in the MSSData directory. You can manage this keystore with Java's KeyTool.

    When the saml.bcfks keystore is changed, restart MSS, and then repeat the steps to Download the service provider (MSS) metadata and Export it to the identity provider.

  6. Download or access the service provider (MSS) metadata.

    Use the Download button or the HTTP endpoint defined in the Export service provider’s metadata field.

  7. Export the service provider’s metadata to the identity provider.

    Refer to your identity provider’s documentation to complete these steps:

    1. Upload the service provider metadata to the identity provider.

    2. Configure the identity provider to trust MSS (the service provider).

Identity Mapping

The SAML assertion provides values that can be used as the source for the user identifier. When LDAP authorization is enabled, you could use the LDAP user identifier.

Choose your preferred sources to identify and authorize each user.

User identifier source

Choose a value from the SAML assertion. Note: The user identifier appears in the user interface.

  • Assertion subject. Use the SAML assertion’s Subject name identifier as the user identifier.

  • Assertion attribute. Enter a SAML assertion attribute name to use as the source for the user identifier.

Distinguished name source (for LDAP authorization)

Choose whether to use the LDAP source or a value from the SAML assertion.

  • LDAP. Use LDAP when the user's identifier is unique within LDAP.

  • Assertion subject. Use the SAML assertion’s Subject name identifier as the user’s distinguished name for LDAP authorization.

  • Assertion attribute. Enter a SAML assertion attribute name to use as the source for the user’s distinguished name for LDAP authorization.

SAML whitelist

MSS uses a whitelist composed of trusted host names to mitigate a potential security vulnerability when using SAML authentication. By default, the SAML whitelist is enabled and contains the registered Host Access for the Cloud session servers and the MSS host itself.

NOTE:The SAML whitelist is restrictive by default. That is, if a user specifies a valid host name in the URL — but that host name is not in the whitelist — the end-user browser application will not be able to use SAML.

For example, the user may specify a numeric IP address in the browser, but by default, numeric IPs are not whitelisted. When an untrusted host name is specified in the browser URL, an HTTP 403 error is returned, and the browser content indicates that a technical error has occurred. The Trace log file will also contain a Warning message indicating that a request was received that is "not from a host in the SAML whitelist."

To configure the SAML whitelist:

  • Check Enable SAML whitelist (the default).

    For troubleshooting purposes, the SAML whitelist can be disabled.

  • Enter alternative host names to include in the SAML whitelist.

    Specify any alternate host names for the SAML client application hosts, such as a short host name, a fully-qualified DNS name, or a numeric IP address. Separate the host names with a space.

LDAP Servers

Verify or edit the configuration of your LDAP Servers.

Related Topics