Before you set up Ivanti Access

Verify that you have the following items before configuring Ivanti Access.

Deployment Type

Ivanti Access supports deployment with Standalone Sentry or Ivanti Access (as a service). Before you begin with Ivanti Access, ensure that you understand the deployment types.

For more information, see Ivanti Access overview.

Federated authentication

Ivanti Access supports federated authentication using SAML and WS-Federation.

Before you begin with Ivanti Access, ensure that you are able to login to every service provider you intend to use with Access using federated identity from your identity provider(s).

Federated authentication setup is not required for implementing certificate-based SSO with Ivanti Access.

Ivanti Access credentials

When you sign up for Ivanti Access, an email is forwarded to you by your sales representative.

The email contains the following important information that you will need for accessing the system:

  • URL for the Ivanti Access administrative portal
  • local administrator login credentials

Be sure to retrieve the information in the email before proceeding.

Root Admin credentials lets you perform the following tasks:

  • Sign in to Ivanti Access administrative portal
  • Create cloud service provider (SP) and identity provider (IdP) federated pairs
  • Set up access control rules
  • User management
  • Activate or deactivate admins
  • Self Serve
  • Configuration Management
  • Analytics and Dashboard
  • Register Standalone Sentry
  • View reports

Standalone Sentry information

If your deployment is Ivanti Access + Standalone Sentry, add a secondary hostname to the Standalone Sentry you use for access control. The primary DNS FQDN is reserved for Standalone Sentry for AppTunnel. The secondary hostname will be reserved for the Access module on the Standalone Sentry. You will use the second hostname when you first log in to the Ivanti Access administrative portal and go through the setup wizard.

Certificates for Ivanti Access + Standalone Sentry

Ensure that you have an SSL certificate to use with Ivanti Access. You will also require signing certificates when you set up a cloud service provider (SP) and identity provider (IdP) federated pair.

SSL certificate for Ivanti Access

The SSL certificate must be in PKCS 12 format and issued by a publicly trusted certificate authority (CA). The issuer can be an intermediate or root CA. The common name (CN) in the certificate must be exactly the same name as the second hostname reserved for the Access module on Standalone Sentry. You will upload this certificate when you go through the setup wizard.

Generating an SSL certificate (PKCS12 file) for Ivanti Access

If you don’t already have a PKCS12 file, you can use OpenSSL to generate a PKCS12 file. Ignore this section if you already have a PKCS12 file.

Execute the following commands to generate a PKCS12 file:

  1. Generate a certificate signing request (CSR) to submit to a certificate authority (CA). Enter the following command in OpenSSL:

    openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

  2. Forward the CSR.csr file to the CA for signing.The CA returns a .crt (example: certificate.crt) file.
  3. Combine the certificate and private keys into a PKCS12 file.
    To combine the certificate and private keys into a PKCS12 file, enter the following OpenSSL command:

    openssl pkcs12 -export -out certificate.p12 -inkey privateKey.key -in certificate.crt -certfile CACert.crt

    • CACert.crt contains the CA’s cert chain that signed certificate.crt.
    • You must upload certificate.p12 in the Ivanti Access administrative portal.
    • You will be asked for an export password. You will use the export password when you upload the certificate in Ivanti Access.

Signing certificate

Ivanti Access uses signing certificates to sign authentication requests and SAML assertions. A default signing certificate specific to your Access instance is automatically provided. When you set up a federated pair in the Ivanti Access administrative portal, you are also provided with the option to either generate a new signing certificate or upload a certificate of your choosing. If you do not want to use the default certificate, you can use the option to generate or upload a new certificate. For more information, see Federated Pairs.

The SSL certificate should not be used in lieu of a signing certificate.