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.
See X.509 Certificates - Setup Requirements to be sure the requirements for this authentication scheme are met.
Use this option to prompt the user for LDAP credentials when certificate-based authentication fails.
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.
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.
This property is used only when upn is present in the field; otherwise this property is ignored. The User Principal Name (UPN) is an Internet -style login name and generally takes the form firstname.lastname@example.org.
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: userPrincipalNameemail@example.com.
Enter the name of the userPrincipalName. Other LDAP implementations may use a different attribute name, such as email or a custom name.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:
This setting logs the date and time of the user's logon to the specified LDAP attribute.
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.
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.
Use this field to add custom text to the Enter your smart card PIN.dialog prompt. For example,
Applies to: Reflection for the Web
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:
The browser on the client is used to browse to the Administrative Server (https://<servername>:<port>/rweb).
During X.509 authentication, the launcher checks for the usercert.pfx file before checking for a smart card.
When the usercert.pfx file is found in the preference files location on the client, either
X.509 authentication completes and the user’s list of links displays
– or –
an usercert.pfx. Once the user enters the correct passphrase, X.509 authentication completes and the list of links displays.dialog box opens, if required for
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.
Theis 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 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.
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.
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.
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 thecheck box, or if the certificate does not contain an AIA extension, only the URLs in this text box will be used. HTTP URLs are supported.
Use this option when the revocation status cannot be determined using OCSP.
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.
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.
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.