Security

Organizational Unit Visibility

By default, if a user does not have permission to access a container above the current container, it will still appear in the breadcrumbs on the computer list screen so that users are given a more complete view of the Active Directory structure. Any containers for which they do not have access cannot be clicked on, they are simply there for reference, as shown below.

Breadcrumbs showing containers which the user does not have permission to view

However, by checking the Hide Organizational Units that a user doesn’t have permission to access box these containers will no longer appear in the breadcrumbs, instead only the containers that the user has permission to read will be shown.

Notifications Require “View History” Permission

If unchecked, any user with permission to read computer passwords (with or without authorisation) can set up notifications for events occuring in a container (such as other users reading a computer’s password). By checking this box, they will only be allowed to do this if they also have permission to view the History page.

Authorisation Requests

Authorisation Request Expiry

By default, requests to view a computer’s password which have been authorised will expire 24 hours (1440 minutes) after the password is viewed by the Requestor. This means that if the Requestor attempts to view the password again after this time has passed they will need to submit another request.

This grace period can be removed by changing this value to “0” which will cause the request to expire immediately when the user views the password, meaning that any subsequent attempts will require a new Authorisation Request.

This does not prevent a user from keeping the view password window open but will stop them from re-opening it once the expiry period has passed.

Authorisation Request Maximum Age

Change this value (shown in minutes) to specify how long Authorisation Requests are kept before they are automatically cleaned up (deleted). This defaults to 1440 minutes (24 hours).

Authorisation Requests older than this will be deleted regardless of their status.

Send a copy of all Authorisation Requests to this email address

By default, when a user submits an Authorisation Request to view or expire a computer’s password, the request is emailed to all users marked as an Authorisor for that container. This option allows you to also send a copy of the request to another email address, such as a shared mailbox.

You can combine this with the Do not email Authorisers individually checkbox to only use this address to send requests to.

Do not email Authorisers individually

If checked, users with the permission to authorize requests will not be emailed when a request is made. This can be used in combination with the above setting to use a shared mailbox for request authorization.

Prevent Authorisers from Authorising their own Requests

Setting this option makes it so that nominated Authorisers cannot authorise their own Authorisation Requests and must get someone else to allow or deny it.

Authorisation Request Email Format

Select whether Authorisation Request emails are formatted as a Summary (the number of pending requests that the recipient has outstanding), or Detailed (which includes a full list of requests).

Two Factor Authentication Settings

OVERLAPS Identification for Authenticator Apps

By default, when a user enables Two Factor Authentication (2FA), OVERLAPS will identify itself in their Authenticator app as “OVERLAPS”. However, if you are running more than one OVERLAPS server, this can become confusing.

Changing this setting allows you to specify a custom identifier that will be used whenever a user enables 2FA. Note that this only works when using the QR code to register OVERLAPS in an authenticator app as the manual code allows users to enter any text as the identifier.

Enforce Two Factor Authentication for All Users

If this option is checked, the next time any user without 2FA enabled logs in they will be prompted to enable it and given a QR Code to enter into their Authenticator app. Once done, they will then be required to enter a code from that app before they can complete the login.

Any users without an access to an authenticator app will be unable to login if this option is enabled.

Maximum Days to Remember Devices

Set how long (in days) a device will be remembered when the user selected the “Remember this Device” option when completing a 2FA login. Once this period has expired the user will be required to enter a 2FA code again. This is 30 days by default, and can be set to any value between 1 and 90 days.

Recommended Authenticator Apps

Enable or disable which TOTP authenticator apps are suggested to users when they go to enable Two Factor Authentication.

Custom Authenticator App

If the Authenticator app used by your company is not shown in the list above you can add it yourself by supply its name, and a link to where it can be downloaded on either the Apple App Store and/or the Google Play Store.

If you want this included in the main list instead, just email us the details to support@int64software.com and we will check to make sure it is appropriate and add it to the list if approved.

If you have multiple domains and would like a particular one to be selected by default on the login screen, select it here.

If you are prioritising Windows Authentication (WIA) or SAML authentication, then this provides the option to hide the form login from the login screen. However, if neither WIA or SAML are enabled then this setting will be ignored and the form will show so that users can still login.

Checking this box hides the button on the login screen for logging in with Windows Integrated Authentication (WIA).

SAML

Configuration options for Security Assertion Markup Language (SAML). See here for full details.