3.7 Configuring Policies

Policies contain configuration settings for the Advanced Authentication methods, events, and so on. For example, to use the Email OTP method, you must configure the server and port settings in the Mail sender policy and to use the Multitenancy mode, you must enable the Multitenancy options policy.

Advanced Authentication provides the following policies:

To configure a policy, perform the following steps:

  1. Click Policies in the Administration portal.

  2. Click the Edit icon against the policy you want to configure.

    You can also double-click on the policy to edit the configuration.

  3. Make the required changes for a specific policy.

  4. Click Save.

IMPORTANT:The configured policies are applied for all the Advanced Authentication servers.

3.7.1 Authenticator Management Options Policy

This policy allows you to configure the following two settings:

Enabling Sharing of Authenticators for the Helpdesk Administrators

This setting allows a user to authenticate with his or her authenticator to another user’s account. The helpdesk administrator can share an authenticator of one user with another user.

To enable sharing authenticators, set Enable sharing of authenticators to ON.

The account of an helpdesk administrator must be added to the SHAREAUTH ADMINS group to grant privilege to share the authenticators. For more information about how to allow the helpdesk administrators to share authenticators, see Local Repository.

NOTE:Shared authenticators work only in the online mode. Cached login does not work for the shared authenticators. The supported methods for sharing authenticators are TOTP, HOTP, Password, Fingerprint, Card, and FIDO U2F.

For more information, see Sharing Authenticators in the Advanced Authentication- Helpdesk Administrator guide.

Disabling Re-Enrollment of the Authenticators in the Self-Service Portal

This setting allows you to restrict users from re-enrolling, editing, and deleting the enrolled authenticators in the Self-Service portal.

NOTE:This setting disables re-enrollment and removal of the authenticators only in the Self-Service portal. The setting has no effect on the Helpdesk portal.

To disable re-enrollment or removal of authenticators, set Disable re-enrollment to ON.

WARNING:If you access the Administration portal with a local user credentials such as local\admin, you might get into a lockout situation. This can happen when the administrator's password expires and it is not possible to change the password through the Self-Service portal. Therefore, to use the Disable re-enrollment option, you must configure the access of a repository account to the Administration portal. To do this:

  • Add authorized users or a group of users from a repository to the FULL ADMINS role.

  • Assign chains, which contain methods that are enrolled for users, to the AdminUI event (at a minimum with an LDAP Password method).

3.7.2 Cache Options Policy

In this policy, you can disable the local caching of authenticators. The policy is supported for Windows Client, Mac OS X Client, and Linux PAM Client for chains that use the methods: LDAP Password, Password, HOTP, TOTP, Smartphone (offline mode), Card, FIDO U2F, Fingerprint, and PKI.

This policy allows you to configure the following settings:

  • By default, the Enable local caching option is enabled. To disable the caching, set the option to OFF and click Save.

    The caching functionality enables the storing of credentials on the Client for offline authentication, when the Advanced Authentication server is not available. Therefore, a user who has successfully logged in once to the server with the authentication, can now login with the offline authentication.

  • By default, the Cache expire time is set to 0, to indicate that the cache never expires. Use the Cache expire time option to set the duration (in hours) to store user authenticators in Client cache. The maximum expiry time that you can set is 24 * 366 (8784 hours). This setting is applicable for the Advanced Authentication Clients.

    When a user logs in with cached authenticators, Advanced Authentication compares the last online login time with the current offline authentication time. If the time duration is less than or equal to the specified duration in Cache expire time, the user is authenticated to Clients.

    For example, consider the Cache expire time is set to 2 hours. The last online log in time of the user to Client is 1:00 PM. When the user tries to log in to Windows Client using cached authenticator credentials at 2:30 PM, the authentication is successful and the user is logged in to Windows Client. But, if the user tries to log in with cached authenticator credentials at 4:00 PM, the offline authentication fails and displays the following message as the cache has expired.

    Authenticators of <user name> were not cached. Press OK and try again to log in as local user or cached user

NOTE:You can use the enforced cached logon instead of the default online logon, to improve the logon and unlock speed on Clients. For more information, refer to the following topics:

3.7.3 Custom Messages

In this policy, you can customize the error messages, method message and prompt message of a specific language.

For example, you can customize the default logon error message in English to Your login failed. In the Self-Service portal, when the user specifies wrong user name, the customized error message is displayed.

To customize the messages, perform the following tasks:

NOTE:The customized messages are cached in the Advanced Authentication server. The refresh interval for custom messages is one hour. Therefore, when you customize a message or upload a custom localization file, the respective message is displayed on the corresponding Advanced Authentication portals after an hour.

You can also perform the following tasks in the Custom Messages section:

Customizing Messages in the Custom Localization File

To customize preferred messages using the Custom localization file, perform the following steps:

  1. Click Custom Messages.

  2. Perform one of the following action to download the custom localization file on your local drive:

    • Click Download original to save the custom_messages.tar.gz file that contains the default messages.

    • If you have customized the messages, click Download current messages to save the current_custom_messages.tar.gz file that contains the latest messages.

  3. Extract the files from the custom_messages.tar.gz file.

  4. Navigate to the preferred language folder.

    To customize English messages, use the custom_messages.pot file and for other languages use the custom_messages.po file.

  5. Open the custom_messages.pot file in the text format.

  6. Specify the message in the msgstr "".

  7. Save the changes.

  8. Compress the custom_messages folder to .tar.gz or .zip format.

  9. Click Browse and select the compressed custom_messages file from the local drive.

  10. Click Upload.

Customizing a Specific Message on the Portal

To customize a specific message on the portal, perform the following steps:

  1. Click Custom Messages.

  2. Use the Message filter to search for a specific message or you can find the preferred message manually.

  3. Use the Message Group to search a specific message by group. Options available are All, Method messages, Error messages, and Other messages.

  4. Click the Edit icon next to the preferred message. You can also double-click on the message to edit the content.

  5. Specify the message in the preferred language.

  6. Click Save.

Customizing Authentication Request Message For Smartphone Method

You can customize the authentication request message that is displayed on the NetIQ Auth app when user initiates Smartphone authentication. The authentication can be either to the endpoint or to the Advanced Authentication portals.

To customize the message for smartphone method, perform the following steps:

  1. Click Custom Messages.

  2. Search for one of the following keys:

    • method.smartphone.authentication_hint to edit the request message specific to endpoint authentication.

    • method.smartphone.authentication_hint_no_endpoint to edit the request message for any authentication that does not use endpoint such as Advanced Authentication portals login.

  3. Click for the preferred key.

  4. Specify any of the following parameters in the preferred language message as per your requirement:

    • {user} to fetch the user name.

    • {client_ip} to fetch the client IP address.

    • {event} to fetch the event name.

    • {tenant} to fetch the tenant name.

    • {endpoint} to fetch the endpoint name.

  5. Click Save.

NOTE:The customized authentication request message reflects on the NetIQ smartphone app after an approximate delay of one hour.

For example, to customize the endpoint specific authentication message for the smartphone method you must search the key method.smartphone.authentication_hint and specify the message {user} requested for authentication request from the client {client_ip} for the {event} to access the {endpoint} in the field corresponding to English language. When the user tries to authenticate to Windows Client using the smartphone method then the customized message is displayed on the NetIQ smartphone app as:

Bob requested for authentication request from the client 10.3.10.5 for the Windows logon to access the Windows-machine-589.

Customizing Prompt Messages of the Authentication Methods for RADIUS Event

You can customize prompt messages of the authentication methods that are configured for the RADIUS event. The customized prompt messages are displayed when a user initiates authentication to the RADIUS event using the configured methods.

To customize prompt message, perform the following steps:

  1. Click Custom Messages.

  2. Use the Message filter to search for a specific prompt message or you can find the preferred message manually.

    For example, specify radius.totp.prompt to search the prompt message displayed on RADIUS client for the TOTP method.

  3. Click the Edit icon or double-click on the preferred message to edit the content.

  4. Specify the message in the preferred language on the Edit Customer Message page.

  5. Click Save.

For example, consider Thomas, an administrator, wants to customize the default prompt message of the Voice OTP method that is configured for the RADIUS event. Thomas must first search the key radius.voice_otp.prompt and modify the message to Specify the OTP that you heard from the voice call in the text box corresponding to English.

When Mark, an end user tries to authenticate to RADIUS event using the Voice OTP method, the customized prompt message is displayed.

Customizing the Message for Clients

You can customize the error messages, method message and prompt message specific to any authentication method that is displayed on endpoints such as Windows, Linux PAM, and Mac OS Clients.

To customize the message for clients, perform the following steps:

  1. Copy the aucore_custom.zip custom localization file from one of the following path based on the Client:

    • Windows: C:\Program Files\NetIQ\Windows Client\locale\

    • Linux PAM: /opt/pam_aucore/locale/

    • Mac OS X: Library/Security/SecurityAgentPlugins/aucore_login.bundle/Contents/Resources/aucore/locale

  2. Navigate to Policies > Custom Messages in the Administration portal.

  3. Click Choose file and select the custom localization file.

  4. Click Upload.

    NOTE:You can find the messages specific to the Clients with the prefix client. in the Key.

  5. Search a specific message using the Message filter or find the preferred message manually.

    For example, specify client.method.smartcard.waiting_for_card to search the message displayed for the Card method on all clients.

  6. Click Edit next to the preferred message. You can also double-click on the message to edit the same.

  7. Specify the message in the preferred language.

  8. Click Save.

NOTE:The customized messages reflect on the respective Clients after an approximate delay of one hour. However, after the first online log in to the Client, users can view the customized messages.

For example, consider Thomas, an administrator wants to customize the default method message (Enter one-time password) of the TOTP method that is displayed for all clients. In the key client.method.totp.password, Thomas can modify the default message to Specify the OTP that is displayed on Token or App in the text box corresponding to English language.

When Mark, an end user tries to authenticate to any client using the TOTP method, the customized method message is displayed.

3.7.4 Custom CSS

This policy allows you to use a customized css for all the Advanced Authentication portals.

To use a customized css, perform the following steps:

  1. Place the css file in Content.

    For example, you can place the following sample css file.

    body {
   color: #000000;
   background-image: url("http://cgcreative.com/videos/poster/MicroFocus_2017_Brand_Cutdown_AMC_01.jpg") !important; 
}

.skin-ias .main-header {
    background: linear-gradient(90deg,#0ecce4,#5c1bd7);
    color: #ffffff;
}

table.table-hover tr:hover td {
   background-color: #808080;
}

.skin-ias .sidebar-menu li a:hover  {
   background-color: #808080;
}

.skin-ias .sidebar-menu li.active.open {
   background-color: #D3D3D3;
}

.content-wrapper {
   color: #000000;
   background: transparent !important; 
}

.well {
   background: transparent !important; 
   border: 0px;
   border-radius: 0px;
   box-shadow: none;
}

.box  {
   color: #000000;
   background: transparent !important; 
}

.main-footer {
   color: #000000;
   background: transparent !important; 
}

.auth .content .login {
   background: transparent !important; 
}

.auth .content .login .header-row {
   background: #ffffff;
}

  2. Click Save.

To revert the changes, remove the custom code from Content and click Save.

3.7.5 Delete Me Options

In this policy, you can configure settings that enable deleting all the user data from the server, including the enrolled methods.

When you set Enable the Delete me policy to ON, the users can view the Delete me option in a drop-down by clicking on the user name on the top-right corner of the Self-Service portal.

NOTE:To comply with General Data Protection Regulation (GDPR), you must set the Enable the Delete me policy option to ON.

3.7.6 Endpoint Management Options

In this policy, you can configure the following settings for managing an endpoint:

  • Require the administrator password to register an endpoint or workstation: Set this option to ON for registering an untrusted endpoint from any IP address. Typically, this option is configured along with Whitelist IP address.

    You must disable the option when installing any components from the Advanced Authentication distributives package that uses endpoints (Advanced Authentication Windows Client, Mac OS X Client, Linux PAM Client, Logon Filter, and RDG plug-in). Otherwise, the endpoints are not created. You must use the option for third-party integrations only.

  • Whitelist IP Address: Add the preferred IP addresses to the Whitelist IP Address to register either a trusted or an untrusted endpoint from these IP addresses. You can add a single IP address, multiple IP addresses, or a range of IP addresses to the whitelist. The IP address must be in IPv4 or IPv6 format.

    The following conditions summarizes the use of endpoint management options:

    • Whitelist IP Address is empty and Require the administrator password to register an endpoint or workstation is OFF: Untrusted endpoints can be registered from any IP address without the administrator’s credentials.

      Regardless of the status of Require the administrator password to register an endpoint or workstation and Whitelist IP Address options, the administrator’s credentials are required to perform the following actions:

      • To delete and update any endpoint.

      • To register a trusted endpoint.

      Endpoint registration is restricted only from those IPs that are specified in Whitelist IP Address.

    • Whitelist IP Address is empty and Require the administrator password to register an endpoint or workstation is ON: The administrator’s credentials are required to register an untrusted endpoint from any IP address.

    • IP addresses are specified in Whitelist IP Address and Require the administrator password to register an endpoint or workstation is ON: The administrator's credentials are required to register untrusted endpoints only from the IP addresses specified in the whitelist.

      The endpoint registration request from any other IP address that is not specified in the whitelist is blocked automatically.

3.7.7 Event Categories

In this policy you can add categories, which can be used in an event to support multiple enrollments for a method. For each event, you can specify one category.

To add a category, perform the following steps:

  1. Click Event categories.

  2. Click Add.

  3. Specify a name and description for the category.

  4. Click Save.

  5. Click Events and edit the required event to specify the category.

    Ensure that users or helpdesk administrators enroll authenticators for the new category.

NOTE:

  • You can enroll only one authenticator of one type for each category.

  • The Authenticator category option in Events is not displayed when no category is created.

  • The LDAP Password method is an exception. There is one LDAP password authenticator always, it can be used with any category.

3.7.8 Geo Fencing Options

In this policy, you can create authentication zones by drawing boundaries for a geographical location. When you enable the geo-fencing policy, users can authenticate with their Smartphones only from the allowed geographical locations.

To enable geo-fencing, set Enable Geo-fencing to ON. For more information about how to configure the geo-zones, see the Smartphone method.

NOTE:When you enable the Geo-fencing options policy, the functioning of the TOTP mode of the Smartphone method, which is used in the offline mode, is affected. An error message TOTP login is disabled is displayed to the users when they try to authenticate with this method.

3.7.9 Google reCAPTCHA Options

The Google reCAPTCHA Options policy helps to prevent the Advanced Authentication web portals login page from bots and to confirm that the user is a human and not a robot. This policy adds an additional layer of security before users go through multi-factor authentication. A series of images are displayed and the users must select the images for the specified condition to login.

To configure the Google reCAPTCHA for Advanced Authentication, you must perform the following configuration tasks:

Registering the Google reCAPTCHA Account

Before you configure Google reCAPTCHA in Advanced Authentication, you must have a Google reCAPTCHA account.

To register for the Google reCAPTCHA account, perform the following steps:

  1. Log in to the Google reCAPTCHA website with your Google account.

  2. Click Get reCAPTCHA.

  3. Specify a Label, select reCAPTCHA V2 from Choose the type of reCAPTCHA.

  4. Specify the IP address or the domain name of the Advanced Authentication server in Domain.

  5. Accept the terms of Google reCAPTCHA.

  6. Click Register.

  7. Copy the Site key and Secret key to configure reCAPTCHA in Advanced Authentication. For more information, see Configuring Google reCAPTCHA for Advanced Authentication.

    NOTE:If you forget the generated secret key, you can retrieve it from your Google account.

    WARNING:If you have enabled the Google reCAPTCHA policy for the Admin UI event, you must consider the following guidelines. Otherwise, a deadlock scenario can happen and you will not be able to access the Administration portal without the cluster re-installation:

    • If the site key or secret key gets deleted at the Google server, you will not be able to get the same site key or secret key. The site key and secret key used on the Administration portal are no more valid and there is no way to bypass the reCaptcha on the Administration portal.

    • If you have registered the reCAPTCHA for one domain name and you change the domain name or migrate the Advanced Authentication server to another domain name, the site key or secret key used on the Administration portal are no more valid.

Configuring Google reCAPTCHA for Advanced Authentication

To configure Google reCAPTCHA for Advanced Authentication, perform the following steps:

  1. Log in to the Administration portal.

  2. Click Policies > Google reCAPTCHA Options.

  3. Specify the Site Key and Secret Key that you received when you registered for a Google reCAPTCHA account.

    For more information about how to register the Google reCAPTCHA account, see Registering the Google reCAPTCHA Account.

  4. Click Test to test the policy after the configuration.

  5. Click Save.

Enabling the Google reCAPTCHA Options Policy for Events

After you configure the Google reCAPTCHA policy, you must enable the policy for the respective events.

To enable the policy for events, perform the following steps:

  1. Click Events.

    NOTE:You can enable the Google reCAPTCHA policy only for the Admin UI event, Authenticators Management event, Helpdesk event, Helpdesk User event, Report logon event, , Tokens Management event, and Web authentication events such as OAuth and SAML 2.0 events.

  2. Set Enable Google reCAPTCHA to ON.

  3. Click Save.

3.7.10 Helpdesk Options

In this policy, you can configure the following settings for the Helpdesk portal:

  • Ask for the credentials of the managed user: Set this to ON to prompt the helpdesk administrator to provide the credentials of the managed user in the Helpdesk portal. This enhances security, however reduces convenience of the operations.

    When this setting is enabled, the helpdesk administrator must know the users’ credentials to manage their authenticators. Ensure that you have specified a chain (with all the methods of the chain enrolled for the users) for the Helpdesk User event. When you set the option to OFF, the user management becomes faster, but less secure.

  • Allow to unlock user accounts: Set to ON to allow a helpdesk administrator to unlock users who are locked in the Advanced Authentication server local repository. Users are locked when the Lockout options policy is enabled. The helpdesk administrator can view and unlock the users in the Helpdesk portal under the Locked Users tab.

  • Allow to manage endpoints: Set Allow to manage endpoints to ON to allow a helpdesk administrator to manage the endpoints of the Advanced Authentication server. When the helpdesk administrator logs in to the Helpdesk portal, an Endpoints tab is displayed where all the endpoints are listed. The helpdesk administrator can remove the endpoints. This option is disabled by default. For more information, see Managing Endpoints.

3.7.11 Linked Chains

This policy allows you to perform the following settings:

  • Enable linked chains: This policy allows users to use a simple chain within a few hours of authentication done with a high-security chain. You must enable this policy for the Require chain option while creating a chain.

    NOTE:This policy has replaced the Last Logon Tracking Options policy.

    For example, if a user authenticates with the LDAP Password+Card chain once in a day, the user can further use a linked chain with only the Card method without the LDAP Password method, or if a user authenticates with the Fingerprint+Smartphone chain once in every four hours, the user can authenticate once with this chain and next authentication he can use only the linked Smartphone chain. The duration for which he can use the linked chain depends on the grace period that you specify in the Require chain option.

  • Hide required chain: After using the required chain within the grace period, a user will see both the required and linked chain on Windows Client, Mac Client, and Linux PAM Client. This policy allows to hide the required (high-security) chain after you authenticate once. Therefore, instead of displaying both the chains, after authenticating with the required chain, only the linked chain will be displayed. By default, this policy is disabled. Enable the policy to hide the high security chain.

3.7.12 Lockout Options

In this policy, you can configure settings to lock a user’s account when the user reaches the maximum failure attempts of login. This enhances security by preventing the guessing of passwords and one-time passwords (OTPs).

You can configure the following options in this policy:

  • Enable: An option to enable the lockout settings.

  • Attempts failed: The limit of failure attempts of authentication, after which the user’s account is locked. The default value is 3.

  • Lockout period: The period within which the user’s account is locked and the user cannot authenticate. The default value is 300 seconds.

  • Lock in repository: The option to lock the user account in repository. You cannot use Lockout period if you enable this option. Only the system administrator must unlock the user in the repository.

    IMPORTANT:You must configure the appropriate settings in your repository for the options to function appropriately. For Active Directory Domain Services, you must enable the Account lockout threshold policy on Domain Controllers.For NetIQ eDirectory, you must configure the Intruder Detection properly.

After a user’s account is locked (not in the repository), you can unlock the user account. To do this, click Repositories > Edit > Locked Users and click Remove against the user’s account name.

The Helpdesk administrator can also unlock the locked users, if the Allow to unlock user accounts is enabled in the Helpdesk Options policy.

3.7.13 Login Options

In this policy, you can configure the settings to add default repository and ensure not to disclose valid username for malicious attack.

This policy allows you to configure the following settings:

  • Default repository: You can add repositories that are used as default repositories. Therefore while logging in, you need not prefix the repository name before the username for authentication.

    For example, if pjones is a member of the company repository, then while logging in, instead of specifying company\pjones, you can specify only pjones.

    To add a repository as default, move the repository from Available to Default and click Save.

  • Username disclosure: This option is set to OFF by default. It is recommended to keep default setting to prevent security vulnerabilities and to make it difficult for hackers to predict the valid username.

    If you set Username disclosure to ON and a user specifies an invalid username on the Advanced Authentication login page, an error message User not found is displayed. When the user specifies a valid username, the associated chain details are prompted to confirm the specified username and disclosing valid username. This can cause security vulnerability making it easy for attackers to guess the valid username.

    When this option is set to OFF, chain details are displayed instead of error message even though a user specifies an invalid username on the login page. A user can select a preferred authentication method. If the input data specific to the selected method is incorrect, a generic message Invalid credentials is displayed. This does not disclose whether username or first-factor authentication is incorrect.

    For example, a user specifies an invalid username, selects the SMS OTP method from the authentication chain. In this case, the SMS with OTP is not sent to the user. If the user specifies some random 6 digit as OTP, the server prompts an error message Incorrect OTP password. This helps the user to determine that specified username is valid though it is invalid.

  • LDAP caching: This option allows you to enable or disable the caching of a user’s information on the Advanced Authentication server. This information can be the lockout status of users, whether users have been disabled, or about the expiry of a user's password.

    By default, the option is set to OFF. This indicates that the Advanced Authentication server communicates with the LDAP server each time to check a user's information. You can enable the option to allow the caching of a user’s information. Enabling the option increases the performance. However, it may also lead to security vulnerabilities. Therefore, it is recommended to set the option to OFF.

3.7.14 Logon Filter for Active Directory

In this policy you can configure settings to enable the use of Logon Filter that you must install on all the Domain Controllers in the domain and configure it. Logon Filter allows you to automatically update group membership if you login with the Advanced Authentication Windows Client.

To enable the policy, set Enable filter to ON and click Save.

NOTE: Before enabling the policy, you must ensure the Advanced Authentication Logon Filter is installed on all the Domain Controllers in the domain. Else, you might face problems with password validation during password synchronization on workstations that have the Windows Client installed.

For information about how to configure Logon Filter, see Configuring Logon Filter.

3.7.15 Mail Sender

In the Mail sender policy, you can configure settings for the Email OTP method to facilitate sending email messages with one-time passwords to users.

To configure the Mail sender settings, perform the following steps:

  1. Specify the following details:

    1. Host: The outgoing mail server name. For example, smtp.company.com.

    2. Port: The port number. For example, 465.

    3. Username: The username of an account that is used to send the authentication email messages. For example, noreply or noreply@company.com.

    4. Password: The password for the specified account.

    5. Sender email: The email address of the sender.

    6. Recipient Mask: Specify the masked value that you want to display for the email.

      The email address of the users value is masked when users authenticate with the email method.

      NOTE:The default value is set and if you do not change the Recipient Mask value, the default value is considered for masking of the email address.

    7. TLS and SSL: The cryptographic protocol used by the mail server.

  2. You can test the configurations for the Mail sender policy in the Test section.

    1. Specify the email address in E-mail to which you want to send the Email OTP.

    2. Specify a message to be sent to the phone in Message.

    3. Click Send test message!.

  3. Click Save.

    Real messaging uses async sender. Ensure that you have configured a chain with the Email OTP method and assigned it to an event. Login to the Self-Service portal and test the Email authenticator. If it does not work, click async log.

Authentication Flow

The authentication flow for the Mail sender is described in the following image.

A user wants to authenticate on an endpoint such as a laptop or a website with the Email OTP method. The following steps describe the authentication flow:

  1. When the authentication request is initiated, the endpoint contacts the Advanced Authentication server.

  2. The Advanced Authentication server validates the user’s credentials and gets an email address of the user from a repository.

  3. Advanced Authentication server sends the request to a configured mail server to send an email message with the content that includes a one-time password (OTP) for authentication.

  4. Mail server sends the message to the user's email address.

  5. Mail server sends the sent signal to the Advanced Authentication server.

  6. Advanced Authentication server sends a request to the user to specify an OTP on the endpoint.

  7. The user specifies the OTP from the email message. The Advanced Authentication server gets the OTP.

  8. Advanced Authentication server validates the authentication. The authentication is done or denied.

HTTPS protocol is used for the internal communication.

Access configuration

Advanced Authentication server - Mail Server (SMTP, outbound).

3.7.16 Password Filter for Active Directory

In this policy, you can configure settings to synchronize the password update between the appliance and Active Directory through the Password Filter. The Password Filter automatically updates the LDAP Password stored in Advanced Authentication, whenever the password is changed or reset in the Active Directory. This helps you to authenticate without getting any prompt to synchronize the password after it is changed or reset.

You can perform the following settings in this policy:

  • Set Update password on change to ON to update the LDAP password automatically in Advanced Authentication when it is changed in the Active Directory. This helps you to authenticate without getting a prompt to synchronize the password after it is changed.

    Set Update password on change to OFF to prompt the user to synchronize the LDAP password while logging in to Windows when the password is changed in the Active Directory.

  • Set Update password on reset to ON to update the LDAP password automatically in Advanced Authentication when it is it is reset in the Active Directory.This helps users to authenticate without getting a prompt to synchronize the password if it is reset.

    Set Update password on reset to OFF to prompt the user to synchronize the LDAP password while logging in to Windows when the user's password has been reset in the Active Directory.

    NOTE:If Enable local caching is set to ON in the Cache Options policy and when the password is changed or reset in the Active Directory. Then, a user is prompted to synchronize the password while logging in to Windows irrespective of the status of the following Password Filter for AD settings:

    • Update password on change

    • Update password on reset

    If Enable local caching is set to OFF, the Password Filter works according to the settings configured in this policy.

NOTE:Endpoint for the Password Filter must be trusted. To do this, perform the following steps:

  1. Click Endpoints in the Advanced Authentication Administration portal.

  2. Edit an endpoint of the Password Filter.

  3. Set Is trusted to ON and add a description.

  4. Save the changes.

3.7.17 Reporting Options

In this policy, you can configure settings to delete the history about the login information of users that is recorded in the reports.

Specify a value in History max age(days). The default value is 30 (days). This indicates that the history about the login information of users will be recorded from the current date to the previous 30 days. Any data before that will be deleted.

3.7.18 SMS Sender

In this policy, you can configure the settings for the SMS OTP method. The SMS OTP method sends SMS messages with one-time passwords to the users. Advanced Authentication contains predefined settings for Twilio and MessageBird services.

The Sender Service consists of the following three options:

To configure SMS sender manually perform the following steps:

  1. Select Generic in Sender service.

  2. Recipient Mask: Specify the masked value that you want to display for the SMS.

    The SMS OTP of the users is masked when users authenticate with the SMS OTP method.

    NOTE:The default value is set and if you do not change the Recipient Mask value, the default value is considered for masking of the SMS OTP.

  3. Specify a Service URL value. For example, Clickatell http://api.clickatell.com/http/sendmsg?.

  4. Leave HTTP Basic Authentication Username and HTTP Basic Authentication Password blank.

  5. Select POST from HTTP request method.

  6. Click Add and create the following parameters in HTTP request body.

    • name: user

      value: name of your account

    • name: to

      value: {phone}

    • name: text

      value: {message}

    • name: api_id, this is a parameter that is issued after addition of an HTTP sub-product to your Clickatell account. A single account may have multiple API IDs associated with it.

    • name: from

      value: sender’s phone number

  7. Click Add secure and create the following parameter in HTTP request body.

    • Name: password

      Value: current password that is set on the account

    For more information about the additional parameters for Clickatell, see the Clickatell documentation.

    NOTE:The parameters may differ for different SMS service providers. But the {phone} and {message} variables are mandatory.

To configure SMS sender settings for Twilio service, perform the following steps:

  1. Select Twilio in Sender service.

  2. Recipient Mask: Specify the masked value that you want to display for the SMS.

    The SMS OTP of the users is masked when users authenticate with the SMS OTP method.

    NOTE:The default value is set and if you do not change the Recipient Mask value, the default value is considered for masking of the SMS OTP.

  3. Specify the following details:

    • Account sid and Authentication token: In Twilio, the Account SID acts as a username and the Authentication Token acts as a password.

    • Use Copilot: The copilot option is used to send SMS from a Twilio’s phone number of your location. This is helpful when SMS messages have to be sent across the geographical locations. For example, with copilot, SMS will be sent from Indian phone number to the Indian users. Without copilot, SMS will be sent from US phone number to the Indian users.

      For more information on Copilot option and its features, see https://www.twilio.com/copilot#phone-number-intelligence and https://www.twilio.com/docs/api/rest/sending-messages-copilot#features.

      • Messaging Service SID: Service SID.

    • Sender phone: Sender’s phone number.

For more information, see the Twilio website.

To configure SMS sender settings for MessageBird service, perform the following steps:

  1. Select MessageBird in Sender service.

  2. Recipient Mask: Specify the masked value that you want to display for the SMS.

    The SMS OTP of the users is masked when users authenticate with the SMS OTP method.

    NOTE:The default value is set and if you do not change the Recipient Mask value, the default value is considered for masking of the SMS OTP.

  3. Specify the Username, Password, and Sender name.

For more information, see the MessageBird website.

IMPORTANT:MessageBird API v2 is not supported. To activate MessageBird API v1, perform the following steps:

  1. Go to the MessageBird account.

  2. Click Developers in the left navigation bar and open the API access tab.

  3. Click Do you want to use one of our old API's (MessageBird V1, Mollie or Lumata)? Click here.

You can test the configurations for the SMS sender policy in the Test section.

  1. Specify the phone number in Phone to which you want to send the SMS OTP.

  2. Specify a message to be sent to the phone in Message.

  3. Click Send test message!.

  4. Click Save.

    Real messaging uses async sender. Ensure that you have configured a chain with the SMS method and assigned it to an event. Then sign-in to the Self-Service portal and test the SMS authenticator. If it does not work, see the async logs.

Authentication Flow

The authentication flow for the SMS sender in Advanced Authentication is described in the following image.

A user wants to authenticate on an endpoint such as a laptop or a website with the SMS method. The following steps describe the authentication flow:

  1. When the authentication request is initiated, the endpoint contacts the Advanced Authentication server.

  2. The Advanced Authentication server validates the user’s credentials and gets a phone number of the user from a Repository.

  3. Advanced Authentication server sends the request to a configured SMS Service Provider to send an SMS message with the content that includes a one-time password (OTP) for authentication.

  4. SMS Service Provider sends the SMS message to the user's phone.

  5. SMS Service Provider sends the 'sent' signal to the Advanced Authentication server.

  6. Advanced Authentication server sends a request to the user to specify an OTP on the endpoint.

  7. The user specifies the OTP from the SMS message. The Advanced Authentication server gets the OTP.

  8. Advanced Authentication server then validates the authentication. The authentication is done or denied.

HTTP/HTTPS protocol is used for the communication.

Access configuration

Advanced Authentication server - SMS Service Provider (HTTP/HTTPS, outbound).

3.7.19 Services Director Options

In this policy, you can configure settings required to integrate with the Services Director.

Perform the following steps to configure this policy:

  1. Set Enable integration to ON to enable the integration of Advanced Authentication with Services Director.

  2. Specify the Public DNS name of Advanced Authentication, Services Director DNS Name, Tenant administrator name, and Tenant administrator password of Services Director to integrate it with Advanced Authentication.

3.7.20 Voice Sender

In this policy, you can configure the settings for the Voice and Voice OTP methods. Advanced Authentication supports the Twilio service for the Voice methods.

To configure Voice Sender settings for Twilio service, perform the following steps.

  1. Recipient Mask: Specify the masked value that you want to display for the Voice OTP.

    The Voice OTP of the users is masked when users authenticate with the Voice OTP method.

    NOTE:The default value is set and if you do not change the Recipient Mask value, the default value is considered for masking of the Voice OTP.

  2. Specify the following details in the Voice sender policy:

    • Account sid and Authentication token: In Twilio, the Account SID acts as a username, and the Authentication Token acts as a password.

    • Sender phone: The phone number of the sender.

    • Server url: The public URL to which the Twilio service connects for authentication. You can use http protocol for testing purpose, but for production environment you must use https protocol. You must have a valid certificate when you use https.

  3. You can test the configurations for the Voice sender policy in the Test section.

    1. Specify the phone number in Phone to which you want to send the Voice OTP.

    2. Specify a message to be sent to the phone in Message.

    3. Click Send test message!.

  4. Click Save.

    Real messaging uses async sender. Ensure that you have configured a chain with the Voice OTP method and assigned it to an event. Then sign-in to the Self-Service portal and test the Voice authenticator. If it does not work, see the async logs.

IMPORTANT:The users may receive calls with the voice Application error. This happens because of incorrect settings or invalid certificates. Ensure that the certificate is valid and is not expired. Invalid certificates cannot be applied by Twilio.

Authentication Flow

The authentication flow for the Voice sender in Advanced Authentication is described in the following image.

A user wants to authenticate on an endpoint such as a laptop or a website with the Voice Call method. The following steps describe the authentication flow:

  1. When the authentication request is initiated, the endpoint contacts the Advanced Authentication server.

  2. The Advanced Authentication server validates the user’s credentials and gets a phone number of the user from a repository.

  3. Advanced Authentication server sends the request to a configured voice call service provider (Twilio) to call the user.

  4. The voice call service provider calls the user.

  5. The user picks up the phone, listens to the call, and specifies the PIN followed by the hash (#) sign.

  6. Voice call provider sends the specified PIN to the Advanced Authentication server.

  7. Advanced Authentication server then validates the authentication. The authentication is done or denied.

HTTP/HTTPS protocol is used for the communication.

Access configuration

Advanced Authentication server - Voice Call Service Provider (HTTP/HTTPS, inbound/ outbound).

3.7.21 Web Authentication

This policy replaces the SAML 2.0 options policy. The Web Authentication policy allows you to configure the following settings:

Configuring Settings for the SAML 2.0 Events

You can configure the settings to specify the Identity Provider’s URL to download the SAML 2.0 metadata file. The downloaded SAML 2.0 metadata file is used to configure the service provider.

For more information about configuring this policy, see SAML 2.0.

NOTE:From Advanced Authentication 6.1 onwards, the web authentication services such as SAML 2.0, OAuth 2.0 are available only on the 8443 port. Any OAuth 2.0 or SAML 2.0 requests to the 443 port (default SSL) are redirected with a 308 status to the 8443 port. The third-party solutions that integrates with Advanced Authentication using the OAuth 2.0 or SAML 2.0 services must manage the URL redirection or append the port number 8443 with the IP address or domain name in the following format:

https://<ip address>:8443/osp… or https://<dns name>:8443/osp…

Customizing the Login Page of Web Authentication Events

You can customize the login page of the OAuth 2.0, SAML 2.0, or Open ID Connect events. To do this, perform the following steps:

  1. Set Custom Branding to ON.

  2. Click Download Template.

  3. Save the osp-custom-resources.jar file.

  4. Unzip the osp-custom-resources.jar file and in the resources folder open the file that you want to customize.

    For example, to edit the custom branding in the English language, customize the oidp_enduser_custom_resources_en_US.properties file.

    NOTE:Ensure that you edit the attributes in the Login page properties section of the oidp_enduser_custom_resources_en_US.properties file for the custom branding of the login pages in the English language.

  5. After you edit the specific file in the resources folder, zip the file osp-custom-resources.jar.

  6. Click Browse to upload the osp-custom-resources.jar file in the Web Authentication policy.

  7. Click Save.

NOTE: When you upload the custom branding changes for the first time, you must restart the Advanced Authentication server to reflect the changes on the login pages of the web authentication events. This is applicable per tenant.

You can also add your customized .css file in the css folder of the osp-custom-resources.jar file.

The following section describes an example of the customization that you can achieve for the Web authentication.

Example of Customizing a Login Page

To achieve the customized login page in the Figure 3-1 for Acme Group of company, you can perform the following:

Figure 3-1 Customized Page for Acme Group

Adding a Customized CSS for the Login Page

You can add a customized css file to reflect changes for the login pages.

The following sample.css file has been customized for achieving the customized login page in Figure 3-1 for the Acme Group of company.

/* general styles
------------------------------- */
body { 
	margin:0; 
  padding:0; 
	background:#fff url("/osp/TOP/images/login_bg.jpg") no-repeat center center fixed; 
  -webkit-background-size: cover;
	-moz-background-size: cover;
  -o-background-size: cover;
	background-size: cover;
  font-family:Arial, Helvetica, sans-serif; 
}
img { 
	border:none; 
  max-width: 100%;
}
/* login box 
------------------------------- */
div.page-container {
	position:absolute;
  top: 50%;
	left: 0px;
  width:100%;
	margin:-265px auto 0 auto;
}
div.dialog {
  border: 12px solid rgba(255, 255, 255, 0.3);
	border-radius: 2px;
  width: 318px;
	max-width:100%;
  margin:0 auto;
	background-color: transparent;
}
div.dialog-content {
  height:525px;
	padding:0 15px;
  background:url(/osp/TOP/images/acme.png);
	background-color:#414749 ;
  background-position:180px 20px;
	background-repeat:no-repeat;
  font-family: Arial, Helvetica, sans-serif;
	text-align: left;
  }
.dialog-header {
  margin:0; 
	padding: 150px 0 40px 0; 
  color:#48c6e7; 
	font-size:22px; 
  font-weight:100;
	background: none;
}
div.dialog-header-content { 
  display:block; 
	color:#fff; 
  font-weight: 200;
}
p { margin:0; padding:0; }
div.dialog-body {
  padding: 0;
}
.product-name {
	margin: 0;
}
#password, #Ecom_User_ID {
  color: #000 !important;
	background-color: #999; 
  font-size: 13px; 
	line-height: 20px; 
  margin: 0 0 3px 0; 
	padding: 11px 10px 12px; 
  width: 100%; 
	box-sizing: border-box; 
  border: none; 
	border-radius: 0; 
}
.dialog-footer-content {
  display: none;
}
.button-container button, .btn { 
	display: block; 
  text-align: center; 
	color: #fff; 
  font-size: 13px; 
	background-color: #48c6e7; 
  border: none; 
	margin: 30px 0 0 0; 
  padding: 11px 10px 12px; 
	box-sizing: border-box; 
  width: 100%; 
	cursor: pointer; 
  -webkit-appearance: none; 
	text-decoration: none;
}
.button-container button:hover { 
  background-color:#00B4DF;
	border: none;
}
.input-box input {
  box-sizing: border-box;
	background-color: #999;
}
p.error {
    color: #cccccc;
    font-size: 13px;
    margin: 0;
    padding: 0 0 18px;
}
#logoutmsg, #logoutmsgsub { color:#fff; }
.error h1 { padding-bottom:20px; }
.help p { margin:0; padding:20px 0 0 0; font-size:11px; }
.help a { color:#cccccc; text-decoration:none; }
.help a:hover { color:#fff; }
.title {
	display: none;
}
.image-custom-link, .login-custom-link {
  display: inline;
}
.image-custom-link a {
	padding: 0;
}
.image-custom-link a:hover {
  color: #fff;  
	background-color: transparent;
  display: inline;
	padding: 0;
}
.image-custom-link img {
  height: 0;
	width: 0;
}
#loginCustomLink1 {
  float: right;
}
/*------------------------------------*\
    RESPONSIVE
\*------------------------------------*/
@media only screen and (max-width:480px) {
  div.page-container { 
		position: static;
    top: 0;
		margin: 0;
  }
	div.dialog {
    width: auto;
		margin: 0;
  }
}

Perform the following steps to add the sample.css file to the osp-custom-resources.jar file.

  1. Open the osp-custom-resources.jar file.

  2. Upload your .css file to the css folder.

  3. Open the resources folder.

  4. Open the oidp_enduser_custom_resources_en_US.properties file to edit the custom branding of the login pages in the English language.

  5. Uncomment the line OIDPENDUSER.LoginCss=reset.css,uistyles.css,uistyles_loginselect.css by removing the # sign.

    You can add your .css file here. For example, OIDPENDUSER.LoginCss=sample.css.

Customizing the Logo of an Enterprise

You can edit the logo displayed on the login page of web authentication event using the parameter OIDPENDUSER.LoginProductImage available in the Login page properties.

For example, to edit the logo of the login page of an OAuth 2.0 event in the English language, perform the following:

  1. Open the oidp_enduser_custom_resources_en_US.properties file and edit the following attribute:

    OIDPENDUSER.LoginProductImage=company_img.png.

    You can also edit the .css file. The following code has been added to the sample.css file to display the logo in the Figure 3-1:

    div.dialog-content {
  height:525px;
  padding:0 15px;
  background:url(/osp/TOP/images/company_img.png);
  background-color:#414749 ;
  background-position:180px 20px;
  background-repeat:no-repeat;
  font-family: Arial, Helvetica, sans-serif;
  text-align: left;
  }

  2. Ensure that you add the image that you want as a logo to the images folder with the name that matches with the attribute value in OIDPENDUSER.LoginProductImage.

    By default the images folder contains the image company_img.

Customizing the Copyrights

You can edit the copyright text displayed on the login page of web authentication event using the parameter OIDPENDUSER.50004 available under the JSP Strings.

For example, to remove the copyright note that is displayed on the login page of an OAuth 2.0 event in the English language:

  1. Open the oidp_enduser_custom_resources_en_US.properties file and search the following parameter:

    #OIDPENDUSER.50004=Copyright [copy] [year] NetIQ[nbsp]Corporation, a Micro[nbsp]Focus company. All rights reserved

  2. Uncomment the following parameter as follows:

    OIDPENDUSER.50004=

    This removes the copyright note from the web authentication event - login page.

Customizing the Branding Text

You can edit the branding text displayed on the login page of web authentication event using the parameter OIDPENDUSER.LoginProductName available in the Login page properties section of the oidp_enduser_custom_resources_en_US.properties file.

For example, to edit the branding of the company to Acme Group, perform the following:

  1. Open the oidp_enduser_custom_resources_en_US.properties file and search the following parameter:

    #OIDPENDUSER.LoginProductName=Company[nbsp]Name[reg]

  2. Edit the following parameter as follows:

    OIDPENDUSER.LoginProductName=Acme[nbsp]Group[reg]

If you want to remove the branding text Acme Group, perform the following:

  1. Open the oidp_enduser_custom_resources_en_US.properties file and search the following parameter:

    #OIDPENDUSER.LoginProductName=Company[nbsp]Name[reg]

  2. Uncomment the following parameter as follows:

    OIDPENDUSER.LoginProductName=

This removes the branding text, Acme Group, from the web authentication event - login page.

Adding Links on the Login Page

You can add links for the login page of the web authentication event.

For example, if you want to add the link Forgotten Password that is displayed on the login page in the English language, add the following:

  1. Open the oidp_enduser_custom_resources_en_US.properties file.

  2. Add the following:

    #OIDPENDUSER.70000=null
OIDPENDUSER.70001=https://intra.sample.net/ForgottenPassword <link where the users gets redirected to>
OIDPENDUSER.70002=Forgotten Password? <label of the link>
OIDPENDUSER.70004=_top <name of the tenant>
OIDPENDUSER.70005=LOGIN_PAGE <attribute>

Customizing Messages and Authentication Method Names for the Web Authentication Events

You can customize the messages and authentication methods name for the Web Authentication events in the Custom Messages policy. Set Use Custom Messages to ON to enable using the custom messages for the OAuth, SAML 2.0, or Open ID Connect events. You must customize the messages in the Custom Messages policy.