Skip to main content Skip to complementary content

Setting the login authentication method

By default, Enterprise Manager uses Single Sign-on through Windows Authentication to authenticate users. This allows users to open the Enterprise Manager Console without providing additional authentication. To require users to authenticate themselves at login, you can change the authentication method to Form or SAML. Setting the authentication method is done using the Enterprise Manager CLI, as described below.

To see the current authentication settings, run the command described in Showing the connectivity and login settings.

Information note
  • All commands in this section should be "Run as administrator" from the Enterprise Manager bin directory. The default location is C:\Program Files\Attunity\Enterprise Manager\bin.

  • When the Enterprise Manager data folder is in a non-default location (such as in a cluster installation), make sure to include the --d data_folder parameter in all commands, where data_folder is the location of the data folder. The parameter should immediately follow the name of the Enterprise Manager executable file (e.g. aemctl --d f:\mydatafolder {command} {parameters})
  • Changes to the authentication method will take affect only after you restart the Enterprise Manager service.
  • If Form authentication is used, all Login/Logout operations are reported to the Audit Trail.

Setting Single Sign-on authentication

This is the default authentication method, which uses Windows authentication.

To set the authentication method to single sign-on, run:

aemctl.exe configuration set --authentication_method sso

Abbreviated form of --sso: -w

Setting Single Sign-on authentication with Kerberos

Kerberos is an enterprise authentication protocol that uses the concept of tickets and three-way authentication to enable users and computers to identify themselves and secure access to resources.

Using Kerberos SSO, users can seamlessly log into Enterprise Manager and administrators can completely externalize and centrally manage users or group memberships using their existing Kerberos infrastructure.

To set the authentication method to single sign-on with Kerberos, run:

aemctl.exe configuration set --authentication_method sso-kerberos

Information note

If the Kerberos protocol fails, Enterprise Manager will try to log in using NTLM authentication. If NTLM authentication is not enabled in the system, an error will be returned.

Setting form authentication

As opposed to Single Sign-on through Windows Authentication, this method requires users to provide a user name and password at login.

To set the authentication method to Form, run:

aemctl.exe configuration set --authentication_method form

Abbreviated parameter: -f

Setting a user timeout

Parameter: --user_timeout

Abbreviated form: -u

When setting --form authentication, you can use this parameter to override the default user idle timeout period (5 minutes) or to disable user idle timeout entirely.

When a user idle timeout value is specified, Enterprise Manager will automatically log out users that have been inactive for the specified time period (or longer).

aemctl.exe configuration set --authentication_method form --user_timeout timeout

Where timeout is the length of time in minutes after which users will be logged out. The minimum permitted value is 1 minute.

aemctl.exe configuration set --authentication_method form --user_timeout 2

aemctl.exe configuration set --authentication_method form --user_timeout -1

Specifying an Active Directory domain

Parameter: --domain

Abbreviated form: -m

When setting --form authentication, you can use this parameter to specify an Active Directory domain name that will be used when a user logs in with a user name only (i.e. without a domain name).

aemctl.exe configuration set --authentication_method form --domain DomainName

Where DomainName is the name of the domain.

For example, to set the domain to ad2_acme, run:

aemctl.exe configuration set --authentication_method form --domain ad2_acme

By default, when only a user name is provided in the login form, the domain of the server is used. If the server does not belong to any domain the server machine name will be used instead.

A user who logs in as "doe" will be assumed to identify as "ad2_acme\doe". If a user specifies a fully qualified domain name when logging in, this parameter is ignored.

Setting up SAML authentication

This method requires you to log in via your organization's SAML Identity Provider. The command parameters for setting SAML authentication are the same regardless of your SAML provider, although the parameter values are slightly different.

Information noteSAML login using the Enterprise Manager API is currently not supported.

The setup procedure consists of the following steps:

Information note

Before running the commands, you must have already configured Enterprise Manager as an application in your SAML Identity Provider.

When Enterprise Manager is not installed in a Cluster, the Enterprise Manager Assertion Consumer Service (ACS) URL is:

https://{host_name}/attunityenterprisemanager/rest/?action=login_saml

When Enterprise Manager is installed in a Cluster, make sure to fulfill the following prerequisites:

  • Finish the cluster install on all nodes before configuring SAML.
  • In order to propagate the configuration changes, make sure to include the -d data_folder parameter in the SAML configuration commands described below, where data_folder is the location of the cluster's shared data folder.
  • The Assertion Consumer Service (ACS) URL which the IDP should call when redirecting SAML calls should be the cluster wide DNS name (as opposed to a specific machine name).

    This is how it should look:

    https://{em-cluster-fqdn}/attunityenterprisemanager/?action=login_saml

For more information about setting up Enterprise Manager in a cluster, see Installing Qlik Enterprise Manager in a Windows cluster.

Step 1: Set up SAML on Enterprise Manager

Syntax:

aemctl [--d data_folder] configuration set --authentication_method SAML --idp_url SsoUrl --idp_issuer issuer_name --idp_certificate_file CertificateFile [--idp_user_displayname_attribute displayname] [--idp_username_attribute username] [--idp_user_groups_attribute groups]

Example: using Microsoft Azure as the SAML IdP

aemctl configuration set --authentication_method SAML --idp_url https://login.microsoftonline.com/12854727-3c42-4866-ab29-0c418b8310a1/saml2 --idp_issuer aemdevtest --idp_certificate_file AEMDevTest.pem

Where:

  • SsoUrl is the URL of the SAML IdP (Identity Provider) that handles sign-in requests.

    When using Okta, this is the Okta Single Sign-On URL.

    When using Microsoft Azure, this is the Azure AD SAML single sign-on URL.

    Enterprise Manager will direct users to this URL to complete the SAML login operation.

  • issuer_name is a unique name that the identity provider uses for SAML 2.0.

    When using Okta, this should be a URL.

    When using Azure, this should be a string.

  • CertificateFile - The certificate is used by the IdP to sign the SAML assertions sent to Enterprise Manager. The certificate file can be anywhere on the Enterprise Manager machine, but only needs to be specified with a path when it does not reside in the Enterprise Manager bin directory.

    When using Okta, the certificate must be in .cert format.

    When using Microsoft Azure, the certificate must be in .pem format.

  • data_folder - The location of the data folder when it is not the default location such as when Enterprise Manager is installed in a Windows cluster.

The following parameters are optional and should only be used if required by your SAML IdP:

  • --idp_user_displayname_attribute - The user display name attribute.
  • --idp_username_attribute - By default, with SSO, the SAML Assertion’s “Subject” attribute is used to define the username. Using the subject is the right solution in most situations, but in extreme cases (such as the subject being a transient ID) it may be necessary to provide the username in some other form.
  • --idp_user_groups_attribute - The user group attribute.
Warning note

Once you have set up SAML, you need to restart the Qlik Enterprise Manager service for the settings to take effect.

Step 2: Set Up an Enterprise Manager Superuser

The first time you log in to Enterprise Manager using SAML, you must log in as an Enterprise Manager superuser. This is because none of the existing (or default) Enterprise Manager users are authorized SAML users.

Information note

The instructions below assume that you have already changed the default Master User key. For instruction on how to do this, see Configuring Enterprise Manager using the CLI and Configuring Enterprise Manager using the CLI respectively.

To set up a superuser, run the following command:

aemctl authorization setsuperuser -s username -e ExpirationTimeoutInMinutes -m MasterUserKey

Where:

  • username is the superuser user name. The user must be an existing SAML user and can contain any Unicode character up to 255 characters.
  • ExpirationTimeInMinutes is the expiration time for the specified user. The maximum is 60 minutes.
  • MasterUserKey is your Master User Key.

Step 3: Log in to Enterprise Manager and create SAML users

After setting up SAML authentication, you will be presented with the following page when you try to open the Qlik Enterprise Manager console:

Qlik Enterprise Manager login dialogue

  1. Click Log In with SAML.

    You will be redirected to Okta or Microsoft Azure to provide your SAML login credentials.

  2. Authenticate yourself with SAML.

    After successful authentication, you will be redirected back to the Enterprise Manager Console.

  3. Add authorized SAML users and groups, as described in Managing user permissions.

For information about other CLI options, see Configuring Enterprise Manager using the CLI.

Switching between SAML and SSO/Form authentication

If you wish to switch from SAML to SSO/Form authentication (or vice versa), you may need to clear the existing users from Enterprise Manager. When switching from SAML to SSO/Form authentication, you will not be able to change user permissions or add users unless you clear the existing SAML users. However, when switching from SSO/Form authentication to SAML, you do not need to clear the existing users in order to add/delete users or edit user permissions. You may still want to do this however if you find the presence of non-SAML users distracts you from managing the SAML users.

Information note

Before clearing the users, it is strongly recommended to export them as this will save time (by importing them) should you later need to revert the authentication type.

aemctl repository export_acl -f [fullpath\]filename

where filename is the name of the file to which the users will be exported. By default, the file will be exported to the Enterprise Manager bin directory. If you wish the file to be exported to a custom path, include [fullpath\] in the command.

Example:

aemctl repository import_acl -f C:\temp\Enterprise ManagerUsers

aemctl repository clear_acl

aemctl repository import_acl -f [fullpath\]filename

where filename is the name of the file to import. Unless you specified a custom export path, the file will be located in the Enterprise Manager bin directory. If you wish the file to be imported from a custom path, include [fullpath\] in the command.

Example:

aemctl repository import_acl -f C:\temp\Enterprise ManagerUsers

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!