Introduction

Similar to the Deepnet MobileID, Microsoft Authenticator is an OATH compliant One-Time Password generator. Microsoft Authenticator is officially available on iPhone, Android and Blackberry. Deepnet DualShield authentication server natively supports Google Authenticator, in very much the same way that it supports Deepnet MobileID. This document describes how users can use Microsoft Authenticator with DualShied.

This policy provides options that control lMicrosoft Authenticator/Time-Based Authentication (another OATH compliant One-Time Password generator that works in a similar fashion to MobileID);

The following system policy settings are for the policy "Microsoft Authenticator/Time Based default policies", in the category "Microsoft Authenticator/Time Based";

Tips for using the Microsoft Authenticator app for MFA - Todd Klindt's Office 365 Admin Blog

The Microsoft Authenticator/Time-Based policy settings can be edited by left clicking on the context menu of the policy and selecting "Edit"";

A new window will not open titled "Policy - Edit";




The category for this policy is "Microsoft Authenticator/Time-Based" (this property cannot be edited).

The holder of this policy is "System" (this property cannot be edited).

The name assigned to identify the Microsoft Authenticator/Time Based default policy by the System Administrator.

The System Administrator may use this field to annotate this policy.

This option allows the System Administrator to enable or disable this policy.

The maximum number of GoogelAuthenticataor tokens allowed in a user account (enter "0" if there is no limit).


This value indicates how many days the token will be active (enter "0" if there is no limit).


This value specifies the maximum number of passcodes that can be kept in the History List (this list is used to avoid repeat usage of recent passcodes).


This option allows the system administrator to allow users to logon whilst offline.


In order to use MobileID Authentication in DualShield, the user must first have a MobileID token in their user account in the DualShield Server. 

The token can be manually created by the system administrator for the user using the DualShield Management Console or manually created by the DualShield Server if the MobileID's policy is set up to automatically provisioning tokens to users.

  • Automatically provision token
    Automatically create a token for a user when needed.

  • Manual
    Tokens will be sent manually to users.


This field determines how DualShield deploys the MobileID client to a user;

  • Automatically push
    DualShield will automatically send the MobileID download link via the specified Message Channel.

    If the Token Authorisation Code is required and its policy is set to automatically send Authorisation Code, then the Authorisation Code will also be sent in the same message.

    To complete automatic provisioning of clients you will also need to configure the Message Channel fields "Primary Delivery Channel:" and "Secondary Delivery Channel:"

  • Manual
    DualShield will not send out a download link to the user (the user will need to find and download the MobileID from app stores).


Expandable Policy Sections

The expandable sections can be broken down as follows;

EXPIRATION

The purpose of the section "Expiration" is to allow the system administrator to specify how much notice users should have before a message is sent out warning that a token is expiring, and how that message should be sent.

 



States the number of days before the token expires (if this is set to 0, then the token will not expire).


This option allows you to specify how notice of token expiry is sent to the user (either by SMS or Email).

.

TOKEN ACTIVATION

The purpose of the section "Token Activation" is to allow the system administrator to specify how token activation takes place, and what messages are sent when this is required.

 



This option allows the system administrator to determine the action to be taken when a token is created or assigned to a user.

    • Automatically activate the token when created or assigned
      The token is automatically activated and usable as soon as it is created or assigned to the user.

      When this option is set, token creation during user authentication will cause the token to be created in an activated state;

    • Send Activation Code to the user when crated or assigned
      The token is not activated after it is created or assigned, and not usable until it is activated by the user.
      DualShield will automatically send an Activation Code to the user via the specified Message Channel.

      When this option is set, token creation during user authentication will cause a token to be created (during authentication), the token will be created inactive, and the user will be prompted for the token activation code, and the required activation code will be sent to the user;

      The required activation code will then be sent to the user (together with an activation link);

      The user can then enter the received activation code into the logon screen.

      Once the code has been entered the token will be activated, and the user will be be able to complete the logon process.

    • Do Nothing
      The token is not activated after it is created or assigned, and not usable until it is activated by the user, and DualShield will not send an Activation Code to the user.

      When this option is set, token creation during user authentication will cause a token to be created (during authentication), the token will be created inactive, and the user will be prompted for the token activation code, and the required activation code will be sent to the user;

      The required activation code will then be sent to the user (together with an activation link);

      The user can then enter the received activation code into the logon screen.

      Once the code has been entered the token will be activated, and the user will be be able to complete the logon process.



This setting determines if the users can request an activation code from the available portals.



This message will be sent via a message channel to the user whenever the system administrator wants the user to get in contact.

DELIVERY CHANNELS USED BY THE SYSTEM

The purpose of the section "Delivery Channels Available to Users" is to provide the system administrator with the ability to specify which message channels can be used to send messages to the Users.

 



If selected then the SMS delivery channel is made available for messages sent to the Users.


If selected then the SMTP (emails) delivery channel is made available for messages sent to the Users.


If selected then the Twitter delivery channel is made available for messages sent to the Users.

DELIVERY CHANNELS AVAILABLE TO USERS

The purpose of the section "Delivery Channels Used by the System" is to provide the system administrator with the ability to specify how system messages are sent.

 




This option determines the main delivery channel for sending messages to the user;

  • SMS
    Message sent to the User's mobile device as a text message.

  • SMTP
    Message sent to the User's email account.

  • Twitter
    Message sent to the User's Twitter account. 

  • Telephone
    Message sent to the User's landline.



This option determines the secondary delivery channel for sending messages to the user;

  • SMS
    Message sent to the User's mobile device as a text message.

  • SMTP
    Message sent to the User's email account.

  • Twitter
    Message sent to the User's Twitter account. 

  • Telephone
    Message sent to the User's landline.


If this option is selected, then if the the personal email, mobile or telephone details are known for the assigned user, then this delivery channel will be used.

TOKEN DOWNLOAD

The purpose of the section "Token Download" is to provide the system administrator to determine the token authorisation, authentication, download options and link expiry duration.

The Microsoft Authenticator policy settings "Authorisation" and "Authentication" affect what the user must do prior to downloading a token, whist the download link expiry settings determine how long the links remain viable.





  • Authorisation Code not required
    When the user attempts to download the token, no authorisation code will be required. The user will be able to download the token by simply providing his/her username and password.

    When this option is selected, all tokens pushed to the user will end with the message "Your authorization code: not required" (see example below);


  • Authorisation Code required. Send Authorisation Code
    When the user attempts to download the token, an additional Authorisation Code will be required from the user. DualShield will automatically send an Authorisation Code via the specific Message Channel.

    When this option is selected, all tokens pushed to the user will end with the message "Your authorization code:", followed by the authorization code (see example below);


  • Authorisation Code required. Do not send Authorisation Code
    When the user attempts to download the token, an additional Authorisation Code will be required from the user. DualShield will not send an Authorisation Code.

    When this option is selected, all tokens pushed to the user will end with the message "Your authorization code:", followed by the authorization code (see example below);



This option will specify if token downloading from the mobile app is to be alllowed only from the network, from anywhere, or not at all;

.


This field determines if user authentication is required when downloading the token;

  • Authentication required
    Authentication is required when downloading the token.

    When this option is selected the download link will not take the user directly to the download page (unless they are already logged in to the provisioning server).

    If the user is not already authenticated, they will first need to authenticate their user account (see example below);

    After the user has authenticated his account he will then be taken to the token download screen;

  • Authentication not required
    Authentication is not required when downloading the token.

    When this option is selected the download link will take you directly to the download screen without needing to log in to your user account (see example below);


If a non zero value is supplied then this value determines how many minutes can pass before the download link expires.

After this time has elapsed (since the download link was sent to the user), then the download link will no longer be usable, and a new link will need to be sent to the user.


If a non zero value is supplied then this value determines how many minutes can pass after the user's visit before the download link expires.

After this time has elapsed (since the user visited the provisioning server), then the download link will no longer be usable, and a new link will need to be sent to the user.


When a MobileID token is set to "Confined", it becomes un-downloadable. In other words, a confined token cannot be downloaded by the user to his/her MobileID clients. It is safely confined in the server.

If this option is set then the MobileID token is safely confined to the server and cannot be downloaded.


SYNCHRONISATION

The purpose of the section "Synchronisation" is to provide a means to control the time synchronisation settings.

One-time password tokens can be out of sync causing failure to login.  For time based OTP tokens, time drifts in the token device can cause a token to be out of sync with the server.

In DualShield you can preset a window in which tokens can be automatically synchronised by the server.  However, when the counter or the clock in a token has drifted outside the preset window, the token has to be manually synchronised by the user or the system administrator.



This option allows the system administrator to specify the number of time windows that should be searched (both backwards and forwards) to find a matching OTP in order to automatically re-synchronise the token.


The value stored in this option specifies the default maximum time windows that the server will look forward and backward in order to manually synchronisation the token.

Manual synchronisation of a token is normally performed when a token has failed automatic synchronisation, and this option will state the number of time windows that will searched during a manual synchronisation.

If the system administrator wishes to performing a manual token synchronisation with a larger (or smaller) range of time windows, then a value will need to be supplied in field "Search Scope" (which will be used in preference to this policy setting);


This option allows the system administrator to specify the number of time windows that should be searched (both backwards and forwards) to find a matching OTP after an automatic synchronisation attempt has failed. The supplied value will therefore be higher than the value supplied for automatic synchronisation.

The purpose of this wider check for a matching OTP is to determine what type of authentication failure message to send to the user.


This option can be enabled if you want to automatically adjust for time and event drift on hardware tokens.

PIN

An OTP token can optionally have a PIN. This is the so-called “Token PIN” or “Server PIN”, not the “User PIN” or “Client PIN”.

A User/Client PIN is a PIN that the user set up on the client to lock the MobileID client software from being accessed by unauthorised people. A User/Client is not a part of the token and is never submitted to the server in the authentication process.

A Token/Server PIN is a PIN that the user set up on the server as an extra password to be attached to an OTP (one-time password) generated from his/her MobileID token each time at logon. For instance, if an OTP is 123456 and PIN is 0987 then the password submitted in the authentication process is 1234560987, assuming that the PIN is set to be appended to OTP by the PIN policy.


 



This option must be enabled if you want to use a PIN code with the token.


This option specifies the minimum length (in characters) of the PIN.


This option specifies how many days the PIN will be active (before it is automatically expired).


This option allows you to specify how much notice the user should be given before their PIN expires.


This policy setting will specify if notice of PIN expiry is sent by SMS or Email;



This option states the obligatory components of the PIN (zero, 1, many or all options may be selected)



Specify how many how many times a pair of characters may repeat (default = 2).

e.g. "ABCAB" will be 2 repeating pairs.


Specify how many ascending or descending character will be allowed (default = 3).

e.g. "ALKSDFABCFKL" is 3 ascending sequential characters.


If this checkbox is selected the PIN cannot include the users's login name (default = false).


If ticked, this option will prevent the PIN from including the user's login name.


If supplied, this PIN will be used when the token is created (until the PIN is changed by the user).


If this option is selected, then all newly assigned tokens will have a random PIN generated for them.


If this option is selected, then when the user next logs in they will be forced to change the PIN.


The PIN history list prevents duplicate PINS being used within recent history (as defined by the size of the list).

  • No labels