Introduction

This document serves as a reference guide for Mideye server 5. For installation guidelines, please refer to the pre-install and installation guides.

Mideye architecture

The figure below gives an overview of the Mideye architecture.

• The Mideye Server is a general-purpose authentication server that supports standard RADIUS. Supported authentication protocols are PAP, MSCHAPv2, and EAP-MSCHAPv2. Refer to software requirements for a list of supported operating systems.
• RADIUS clients: VPN concentrators, access portals, and firewalls act as RADIUS clients towards Mideye (RADIUS server). Mideye utilizes the challenge-response mechanism in RADIUS (RFC 2865, sections 2.1 and 4.4). For access products that do not support RADIUS challenge-response, the Mideye+ app can be used, see section Mideye+ and Touch Accept.
• LDAP Directory: End-user data can be read from an existing repository via LDAP/LDAPS, which eliminates the need for separate account administration (no account administration in the Mideye Server).
• SQL Database: Database that holds the configuration data for Mideye. As an option to using an LDAP repository, user accounts can also be registered in the database. A list of supported databases can be found here.
• Network Policy Server (NPS): Mideye acts as a proxy to the NPS when MSCHAPv2 and EAP-MSCHAPv2 are used. For more information, see section Network Policy Server.
• Mideye Web GUI: Administrative interface for the Mideye Server.
• Primary and secondary Mideye service: The Mideye Server is connected via the Internet to two independent Mideye Service centers. Each customer is assigned a unique TCP port for communicating with the Mideye Service. Firewalls only need to be open for outbound traffic, meaning that the Mideye Server does not need to be exposed to the Internet. The Mideye Service maintains direct connections with mobile networks for managed real-time delivery of one-time passwords (SMS-OTPs) and data push notifications to Mideye+ apps. As an option to using mobile phones, OTPs from token cards can be verified against a centrally operated Token Server.

Mideye Server 5 is a Java application built using Spring Boot (backend) and React JS (frontend). Mideye Server 5 uses Java Runtime Environment version 8, which comes bundled with the installation package. The Mideye Server runs as a background application and handles RADIUS requests on one or multiple ports. Configuration and administration of the Mideye Server are done from a web GUI. All configuration is saved in real time, meaning no server restarts are required.

Mideye authentication types

The Mideye server is a general-purpose RADIUS server with ten supported authentication types:

1. Password: The user is authenticated with a static password.
2. Mobile: The user is authenticated with a static password, in combination with a one-time password (OTP) which is sent to the user’s mobile phone in real-time via the mobile network. This authentication type relies on a two-step challenge-response dialogue.  Users that have activated the Mideye+ app get OTPs primarily via data push (mobile data or wifi), with Plus (auth type 5) as a fallback in case the phone is not reachable. Users without the Mideye+ app log in with SMS-OTP.
3. Token: The user is authenticated with a static password, in combination with a one-time password which is obtained from a token card (YubiKey or HID Mini Token). This authentication type relies on a two-step challenge-response dialogue since the static password and the OTP are provided in two separate steps.
4. Concatenated: Only supported with HID Mini Token. The user is authenticated with a static password, in combination with an OTP which is obtained from the user’s token card. The OTP is concatenated with the static password in one single step, which means that this authentication type does not require support for a two-step challenge-response dialogue. Example: If the static password is Sd43Erg7 and the OTP is 28592434, this is entered as Sd43Erg728592434.
5. Plus: The user is authenticated with a static password in combination with an OTP which is obtained by manually signing an access challenge in the Mideye+ app. This authentication type only works for users that have activated Mideye+ and is mainly intended as a fallback from other authentication types in case the phone is not reachable. It relies on a two-step challenge-response dialogue.
6. Touch: The user is authenticated with a static password, followed by an ‘Accept’ option presented directly in the Mideye+ app. This authentication type requires that the Mideye+ app is reachable via data push (mobile data or wifi). It does not require support for a two-step challenge-response dialogue.
7. Touch-Plus:  The user is authenticated primarily using Touch (auth type 6), but with a fallback to Plus (auth type 5) in case the phone is not reachable via data push.
8. Touch-Mobile: The user is authenticated primarily using Touch (auth type 6), but if the phone is not reachable via data push, the system reverts to Mobile (auth type 2) by sending an encrypted SMS to the Mideye+ app.  If the phone is not reachable at all via the network, the server reverts to Plus (auth type 5).
9. Assisted login: The user is authenticated with a static password, followed by the acceptance by an authorized approver. The approver must have the Mideye+ installed and activated in order to accept the login.
10. Shared account: The user is authenticated with a static password, after which the user is prompted to enter a pre-registered phone number or token serial number. This phone/token is then used for the second step of the authentication. For user accounts in Active Directory, the attribute ‘otherMobile’ is used to search pre-registered numbers. For other LDAP repositories, the attribute ‘Mobile’ is used.

Authentication types 6, 7 and 8 require Mideye+ for the Touch functionality.  Users that haven’t activated Mideye+ are automatically assigned authentication type 2 (SMS-OTP).

Administrative web interface

The Mideye Server has a web interface for server operation, administration and management. The web interface is reached via https://<IPofMideyeServer>:<TCP-port>, where the port is specified during server installation.

To find out which port is used for the web interface, use Netstat or similar tool to list all TCP-ports the server is listening to. The default port for Windows is 443, for Linux it is 8443. In the example below, netstat -a -n -o -p tcp was executed on a Windows Server 2019 to list all possible ports used by Mideye Server 5.

It is recommended to access the web interface from a desktop client using a web browser such as IE, Edge, Firefox, Chrome or Safari. Web browsers on servers are often locked down and may not work as expected.

Web interface SSL-certificate

During the installation of a Mideye Server a self-signed certificate will automatically be generated. To replace this with a custom certificate please see section Certificate Management.

Web interface Root password

A root user is created at server installation.  This account should only be used for creating administrative accounts and for emergency purposes.

Reset password for Root account

Encrypt the new Root password using

https://<FQDN>:<ssl-port>/api/get-hashed-password?password=<new_password>

Where <FQDN> is the DNS-name or IP to the Mideye Server. 
Where <SSL-port> is the TCP-port used by Mideye Server Web GUI.
Where <new_password> is the new password that should be used.

Make sure to remove all < >.

Log on to the database using an account with write permission and execute

UPDATE mideye_user SET jhi_password = 'encrypted_password' WHERE user_name = 'root'

Unlock Root account

To unlock the Root account, log on to the database with write permission and execute

UPDATE mideye_user SET is_locked = 0 WHERE user_name = 'root'

Web interface administrative accounts

To administer the web GUI, Mideye Server has four user roles:

• Root: There is only one root user, and this account should not be in use after creating a Super Administrator.
• Super Administrators: Same permissions as root user.
• Administrators
• Operators

All roles except for the root role can be mapped to LDAP accounts. See section LDAP-RADIUS Translation for details.

User Management (only authorized to perform these operations on a user with a lower security level)

• Create user
• Update user
• Delete user (any user is not allowed to delete itself)

Note: Operators are not allowed to write to any table except locked LDAP users.

The table below shows different tasks and what roles are allowed to perform the entity:

Entity	Operation	Role
Radius Server	Create	Root, Super Admins, Admins
	Update	Root, Super Admins, Admin
	Delete	Root, Super Admins, Admin
	Read	Root, Super Admins, Admin, Operators
Radius Client	Create	Root, Super Admins, Admins
	Update	Root, Super Admins, Admins
	Delete	Root, Super Admins, Admins
	Read	Root, Super Admins, Admin, Operators
Ldap Profile	Create	Root, Super Admins, Admins
	Update	Root, Super Admins, Admins
	Delete	Root, Super Admins, Admins
	Read	Root, Super Admins, Admin, Operators
Approved Radius IP	Create	Root, Super Admins, Admins
	Update	Root, Super Admins, Admins
	Delete	Root, Super Admins, Admins
	Read	Root, Super Admins, Admin, Operators
LDAP RADIUS Translation	Create	Root, Super Admins, Admins
	Update	Root, Super Admins, Admins
	Delete	Root, Super Admins, Admins
	Read	Root, Super Admins, Admin, Operators
Accounting	Read	Root, Super Admins, Admin, Operators
Authentication Log	Read	Root, Super Admins, Admin, Operators
Locked Ldap Users	Update	Root, Super Admins, Admin, Operators
	Read	Root, Super Admins, Admin, Operators

Create a new database Super Administrator

To create a new Super Administrator account, navigate to “Users” followed by “Database users”. Select “Create a new Database User” and select Super Administrator from the dropdown list “Role”. Add the following data to the account:

• Username
• Authentication Type
• Password
• Phone number (optional)
• Token number (optional)
• Message type (default FLASH-SMS)
• Expiration Date (optional)
• Select Web Admin RADIUS client in the “Radius Client” dropdown list

Change password for database account

All database accounts can have their password changed. It is not possible to change the password of an account with the same privileges level as the logged-on account meaning that a Super Administrator can only change the password on accounts that have lower permission i.e Administrators, Operators and database users.

An administrator or operator can change their own password inside the portal using the “Change password” page located at the top right menu.

Map LDAP-accounts to Mideye Web GUI roles

Instead of using database accounts to administrate Mideye Server, LDAP-accounts can be mapped to all roles except for the ROOT-role. Complete the following steps to add LDAP-accounts:

• An LDAP-profile is required. See the section “LDAP Profile” for instructions.
• Enable “LDAP Profile – LDAP-RADIUS Translation” and add the attribute memberOf next to “LDAP Attribute Name”.
• Last part is to map LDAP-accounts or groups to the predefined roles used by Mideye Server. Navigate to “Configuration” followed by “LDAP-RADIUS Translation”.
• Add the DN of a user or group to the predefined roles. In the example below, three groups was added to Super Administrator, Administrator and Operator

Database users for end-user authentication

Mideye Server can create database users that can be used by RADIUS-clients that will work as an alternative to LDAP-accounts. To create a new database user, navigate to “Users” followed by “Database users”. Click “Create a new Database User”. Give the user a username, select “User” as role and select a password. If RADIUS client field is left empty, the user will be able to authenticate to any radius client that have the flag “Check database” enabled.

Search for database users

To search for any database user (both administrative accounts and with the role “user” navigate to “Users” followed by “Database users”. In the “Search for Database User” field, type any data that can be used to find the user. It is also possible to search for users using the Token number. All searches can be made using wildcards, for example, test*. This example will show any user that starts with the username test.

Password change

When creating a new database user, a temporary password can be set that will allow the user to set a new password when logging in for the first time. This can be done from “Users” followed by database users.

Server Configuration

Configuration

Assisted login

Assisted Login (Authentication type 9) can be enabled on each RADIUS client and will enable managers, administrators, etc. to give temporary access to end-users that normally do not need to have permanent access to certain resources. Assisted login is only applicable to LDAP accounts, and can be set as a default authentication type as well as per LDAP-account with “Read optional attributes”.

Create a new Assisted Login Profile

Navigate to Configuration followed by “Assisted Login Profiles”. Click “+” to create a new profile.

General

• Give the profile a suitable name.
• Adjust the session and the idle timeout for the approved users. These values are only applicable if RADIUS attribute 27 (Session-Timeout) and RADIUS attribute 28 (Idle-Timeout) can be configured on the RADIUS client (e.g. Cisco Anyconnect, Pulse secure). Please refer to RFC 2865 section 5.27 and 5.28 for more details.

Approver

• Choose what LDAP attribute that should be used to identify the approver. Default values are sAMAccountName and mobile but can be customized to any other LDAP-attribute available.
• Enable or disable “Allow self approval”. This allows the approver and the approved to be the same person.
• Select, None, Any or All for the following conditions:
  1. Manager attribute match: In ADUC, the approver must be added as a Manager in the approvers LDAP-profile.
  2. Approver member of authorized group: Specify an LDAP-group that contains all the managers.
  3. Approver pre-listed: Add approvers based on their UPN.

User

• Select, None, Any or All for the following conditions:
  1. User assigned authentication type 9 in the user repository: This requires that read optional attributes is enabled on the LDAP-profile. See section Authentication for more details.
  2. User member of authorized group: Specify an LDAP-group that contains all the users that should be allowed to login using Assisted Login.
  3. Users pre-listed: Add users based on their UPN.

If none of the options are selected all users can be approved.

Additional challenges

As part of the assisted login-flow, additional challenges can be added to add more information to the login. This requires that the RADIUS-client can handle challenge-response messages.

Modify the RADIUS-client

Navigate to “Configuration” followed by RADIUS-clients. Choose to modify the RADIUS-client that should be enabled with Assisted login. At “Assisted Login” select the profile created in the previous step.

Enable Disconnect Messages

If the RADIUS-client (e.g. Pulse Secure) supports Disconnect Messages, this option can be enabled. This will allow the approver to disconnect the approved user at any time.

End-user experience

Pictures below will show the authentication flow when user “Consultant” (user who should be approved) tried to authenticate with authentication type 9 set. User “gustav.warlinge.a” will be the approver.

Assisted login with RADIUS Disconnect Messages

If the RADIUS client has support for RADIUS Disconnect Messages the approver have the option to terminate an ongoing session directly from the Mideye+ app.

Azure Active Directory

Starting from release 5.5 it is now possible to use Azure Active Directory (AAD) as a user repository for Mideye Server.  A secure connection between the Mideye Server and Azure AD is established using Microsoft Graph. Complete the following steps to create a “App registration” in Azure AD.

App Registration

1. Navigate to portal.azure.com.
2. Sign in as a global administrator and select “Azure Active Directory”.
3. Click “App Registrations” and select “New registration”.
4. Give the application a friendly name and select what user repository to be allowed to use the application.
5. Select “Single-page application (SPA)” and leave the url blank. Complete the registration by clicking “Register”.

App Configuration

Once the app is registered in Azure Active Directory it must be configured. Click the created app and complete the following steps:

1. Navigate to “Certificates & Secrets”
2. Click “New client secret” and give the client secret a friendly name. Click “Add”
3. Make note of the shared secret value. It will be needed later when configuring the Mideye Server.

4. Navigate to API permissions and click “Add a permission”
5. Select Microsoft Graph and Application permissions. Navigate to “User” and  select “User.Read.All”. Click “Add permissions”

6. (Optional). To be able to retrieve more information about a specific user, such as group membership a delegated permission must be added. Click “Add Permissions”. Select “Microsoft Graph” followed by “Delegated permissions”. Navigate to user and select “User.Read.All”. Click “Add permissions”

7. Last step is to grant admin consent for the app by clicking “Grant admin consent for app”.

Navigate to “Overview” and take note of the following ID´s. These will be used later when configuring the Mideye Server.

• Application ID
• Object ID

Mideye Server configuration

Login to Mideye Server 5 as an administrator and navigate to “Configuration” followed by “Azure Active Directory”. Click “Create Azure Active Directory”. Add a Display name and paste the Tenant ID, Client ID and Client secret saved from previous steps.

Click “Verify Connection” followed by the UPN of a user that should be reachable in the tenant.

Navigate to the “User Properties” tab and select what properties to be read to fetch the mobile phone number and Token number. Default values are mobilePhone and businessPhones.

Click the “Group Check” tab. If group membership should be retrieved from users, check the “Enable Group Check”. This will only work if the optional step in API-permissions is configured (LINK). The group must be added using the object ID of the group in azure AD.

If needed, check the Enable Radius Translation and follow the instructions on how to create a new LDAP-RADIUS translation rule.

Click “Save”. To add a Azure AD profile to a RADIUS client, see section

Certificate Management

Certificate Management allows management for both the certificate for the graphical interface as well for the LDAPS bind when using an encrypted connection to a configured LDAP-server such as Active Directory. Navigate to “Configuration” followed by “Certificate Management”. An overview of all the imported and fetched certificate will be shown. To import a new certificate, click “Import”.

From the menu above, select the purpose of the certificate that should be imported and click import. Select the certificate and click import. If importing a new LDAPS certificate, make sure that the certificate is present on the actual domain controller as well. Supported formats are:

LDAPs: cer, pem or crt
Mideye Web Admin graphical interface: p12 or pfx

The expiry of imported certificates is monitored and presented in the dashboard of the server web GUI. The server starts to issue warnings to the log files 10 days before imported certificates expire.

LDAP-profile

To integrate RADIUS clients with a LDAP-repositorie such as Active Directory, login to the web GUI and navigate to “Configuration” followed by “LDAP Profiles”. Click “Create a new LDAP Profile”.

General

Mideye Server 5 currently supports preconfigured settings for the following repositories:

• Active Directory
• eDirectory
• Sun Directory Server
• Lotus Domino
• OpenLDAP

Complete the following steps to configure Mideye Server to read from a directory:

1. LDAP Profile: Give the LDAP Profile a unique friendly name.
2. LDAP Server Type: Choose what kind of directory that should be integrated into the dropdown list. In this guide, Active Directory will be configured.
3. Hostname: Enter the FQDN or the IP-address of the LDAP server. Note that with LDAPS, only FQDN is accepted.
4. Port: Default port for none encrypted bindings is tcp/389. If a Certificate Authority is installed on the Domain Controller, port tcp/636 can be used to encrypt the connection between the Mideye Server and the Domain Controller. Make sure to check the “Use LDAPS” and import the certificate from the Certificate Authority when using an encrypted connection. This can be done by clicking the “Fetch Certificate” button.
   The default validity length of the certificate used for encrypted traffic between the Mideye Server and the Domain controller is one year. When this certificate expires, Mideye will have to fetch the new certificate by manually adding it using the “Get Certificate” button. Be advised that when the old certificate expires and the new certificate still hasn’t been manually added, all authentication using the LDAP server will fail. See section Extend LDAPS validation time on how to increase the time from 2 years.
5. LDAP service account: Mideye Server needs a service account and password from the directory to be able to read LDAP-data. This account needs the “Domain User” permission. Enter the username as DN or UPN format. Add the password. Remember to check the flag “Password never expires”.
6. Skip Certificate Validation: Check this box to ignore certificate validation. This facilitates automation of LDAP profile provisioning via the server REST API. Be advised that this should be enabled with caution since Mideye Server will not validate the certificate, and could potentially lead to a man-in-the-middle-attack (MITM).
7. Search Base: Add the search base where the users are located in the directory repository.
8. Test Connection: Click the Test connection button to verify that it is properly setup.
9. Network Policy Server: When authentication using MSCHAP-V2 or EAP-MSCHAP-V2 are used, a Network Policy Server must med integrated with the LDAP-profile. All requests that use these protocols will be proxied to an NPS-server for user authentication.

Use the “Find User” button to verify that users included in the search base can be found. User identity sAMAcccountName and userPrincipalName are enabled by default.

User Attributes

Object Class: The default value for Active Directory is “person” and should not be changed.
User Identity: The attribute populated by default is sAMAccountName and userPrincipalName. This attribute(s) are used to identify the username when authenticating.
Mobile Phone Number: Attribute used to find the user´s phone number. The default value is mobile, but this can be customized to any other attribute. Also, two or more attributes can be specified, meaning that Mideye Server will start searching for data in the first attribute, and continue with the next attribute if the field is empty. Example otherMobile,Mobile.
Token Number: Attribute used to find the user´s token-number. The default value is ipPhone, but this can be customized to any other attribute.

Enable Logging LDAP Attributes: If enabled, the LDAP attributes added to the LDAP-attributes field will be logged with the returning LDAP-value to the logfile. This value can also be shown in detailed authentication logs when the “Store LDAP Attributes in Authentication Logs” box is checked.

Group Check

To further control permissions, a group check can be configured that will control what users who should be able to access the resource protected with Mideye. This can be done by adding the DN of a group in LDAP. Wildcard/Java Regular Expressions, e,g. CN=Mideye-administrators.* are supported

If the group specified contains groups inside, make sure to enable “Search nested groups” in the Active Directory tab.

Authentication

Default authentication type: Mideye Server comes predefined with authentication type 8 (Touch Mobile). This can be customized to any of the authentication types 1-8 as specified here.

Default OTP Presentation: The default value is Flash SMS, but can be changed to Inbox SMS.

Read optional attribute: If a group of users should have a different authentication type than the one specified as default, read optional attribute can be used. When this option is enabled an LDAP-attribute can be configured in the field “Authentication type attribute” Once enabled, that field in LDAP will control what authentication that should be in use. For example, if the attribute “Pager” is set in the “Authentication type attribute” and the number 3 is set for the user, the authentication type “Token” will be used based on the list above.

OTP Presentation Attribute: OTP presentation can be customized using an LDAP-attribute. The number in that attribute will decide what kind of OTP that should be used.

Department attribute: If the department of the user should be visible in accounting, the default value should be attribute “Department”

Password Compare: See document “Password Comparison” for detailed information and configuration example.

Activate LDAP user blocking: If enabled, the user will be temporarily locked out after defined failed attempts for x number of minutes. 0 is equal to permanently blocked. Users can be unblocked from the web GUI.

Active Directory

The following options will only function for LDAP users.

Check remote flag: If checked, access is only granted if the “Dial-in” properties are set to “Allow remote access”.
Allow password reset (PAP): If checked, access is granted if the password is correct but needs to be reset. This option is only used for PAP authentication when allowing a secondary authentication using LDAP.
Allow password expired (PAP): If checked, access is granted if the password is correct, but has expired. This option is only used for PAP authentication when allowing a secondary authentication using LDAP.
Search nested groups: If checked, Mideye Server will search for users in groups that are nested in the group specified.
Use Framed IP Addresses: If checked, Mideye Server will read the “Assign static IP Addresses” from LDAP and pass the IP address along as attribute 8 with a successful login.

Password change using PAP

Starting from release 5.2.1 it is possible to perform a password change using only PAP. The following circumstances must be fulfilled for password change to work with PAP:

1. LDAPS must be configured on the LDAP Profile. If LDAPS is not enabled, users will be able to log in until the password expired (User lockout) IF step 2 is enabled
2. Allow Password Reset (PAP), and Allow Password Expired (PAP) must be checked in the LDAP Profile
3. The service account used by the LDAP Profile must have the Account Operator permission set in ADUC. Be advised that due to adminSDHolder, account operators will not be able to perform password change on any object that is at the same or higher security level.

LDAP-RADIUS Translation

If LDAP-RADIUS Translation is checked, Mideye Server will translate LDAP-attribute to RADIUS-attribute. Refer to section LDAP-RADIUS Translation for further detailed instructions.

Number Correction

Enable Auto-Correction: When enabling this option, the Mideye Server will automatically correct the phone number to international format (e.g. +1234567890) before contacting the Mideye Switch. Spaces and non-numeric characters (apart from an intial + sign) are removed. Initial 00 is replaced with a + sign. Digits within parentheses are removed, unless otherwise specified (see below).

Auto-Correction Prefix: Default international prefix added to numbers that do not begin with + or 00.

Remove leading Zero: Leading zero in the mobile number is removed before adding the international prefix (e.g 070-1234567 is changed to +46701234567).

Keep Digits Within Parentheses: Enable to keep digits within parentheses when correcting numbers.

Advanced

Connection settings for LDAP can be customized. The default value is 10 seconds for connection timeout and 2 seconds for reading timeout.

Create a new Kerberos authentication certificate with longer validation time

The first step is to allow the Certificate authority to create certificates with a longer validity period than 2 years. From the Certificate Authority server, open CMD.exe as an administrator. Type:

certutil -setreg ca\ValidityPeriodUnits X

where X is the desired length that should be allowed. Be advised that this number can not be longer than the validity length of the CA certificate

Type:

certutil -setreg ca\Validityperiod= Years

Restart the Certificate Authority with the commands:

net stop certsvc

Net start certsvc

From the Certificate Authority console, right-click “Certificate Template” and click “Manage. Right-click the Kerberos Authentication template and select “Duplicate Template”. Click the “General” tab and give the template a friendly name and change the Validity period to the desired length. Be advised that the certificate can not have a validity period longer than the CA-certificate.

Select the “Security” tab and add the computer account of the Domain Controller.  Click “OK” and close the “Certificate Templates Console”.

Again, from the “Certificate Authority” console right-click “Certificate Template” and select “New” followed by “Certificate Template to Issue”

Select the created template and click “OK”. Restart the Certificate Authority service.

From the Domain Controller, execute mmc.exe from the start menu. Click “Add/Remove snap-in” from the File menu and select Certificate followed by “Computer Account”. Select “Local Computer”  and click “OK”. Expand Certificate –> Personal and right-click “Certificates” –> “All tasks” –> “Request New Certificate”. Select the certificate template created above and click “Enroll”.

The last step is to update the certificate in the Mideye Server. Navigate to Configuration followed by LDAP-profiles. Click modify on the LDAP server. Click “Fetch Certificate” and import the new certificate with a longer validity time.

Save the configuration.

LDAP-RADIUS Translation

To further extend the functionality of RADIUS, LDAP-RADIUS Translation can be used to assign specific users or group permissions from LDAP when logging in using a VPN-concentrator.

Make sure that LDAP-RADIUS Translation is enabled in the LDAP-profile. Navigate to “Configuration” and “LDAP-RADIUS Translation”.

Press “Create a new LDAP-RADIUS translation rule”, and define a new rule corresponding to a specific group name attribute in the LDAP repository (see screenshot below). In the field “LDAP Value”, enter the full Distinguished Name of the group. Note that it is important that the exact group name is specified – the translation is both case and blank-space sensitive.

To make sure the correct DN is written, from ADUC, open the attribute editor of the group and simply copy the value and paste it into the “LDAP Attribute Value” field in Mideye Server. Wildcard/Java Regular Expressions, e,g. CN=Mideye-administrators.* are supported

In the RADIUS Attribute Type, select the desired attribute, and add a suitable RADIUS Value for the group and click “Save”. To know what attribute that should be used and how to configure it, consult the manufacturer of the VPN concentrator.

Logging

The level of logging can be customized. The default value is “Info”.

The “Start Trace” button can be used for troubleshooting purposes and will continue until the “Stop trace” button is pressed. The trace-file will be written to %installdir%\log.

Advanced

All the loggers can be individually customized. These should normally not be changed.

Network Policy Servers

Users in Active Directory can change their expired passwords during the login process in the RADIUS dialogue. A password can expire because the flag “User must change password” at the next login is set to true, or its expiration date is before the actual login.

Requirements:

• The authentication must use the MS-CHAP v2 or EAP-MS-CHAP v2 protocol.
• A configured Network Policy Server (NPS) pointing to the Active Directory repository.

Configure address, port and shared secret for the NPS. In order for the password change to work, it is important that:

• The NPS points to the same LDAP server as configured for the Mideye Server.
• The IP or hostname of Mideye Server is present among the NPS’s RADIUS clients (in order to be able to accept RADIUS requests).
• The NPS policies are correctly configured.

To create a new NPS Server navigate to “Configuration” followed by Network Policy Servers”. Click “Create a new Network Policy Server”.

Server name: Add a friendly name of the NPS. This must be unique.

Hostname: Enter the IP or hostname of the NPS.

Port: Add the RADIUS port of the NPS. If the NPS is on the same machine as the Mideye Server, make sure that the NPS and the Mideye Server are using different UDP-ports.

Shared Secret: Enter the shared secret that should be used between the Mideye Server and the NPS. This must be identical on both ends.

Save the configuration and navigate to “Configuration” followed by “LDAP Profiles”. Select “Edit” on the LDAP Server that should use the NPS-server.

On the “General” tab select the Network Policy Server that was created in the previous step. Click “Save”.

Click “Save”.

Change your remote-solution to use MS-CHAP

For instruction on how to enable this for Cisco Anyconnect and Citrix Netscaler, click the respective link. For other solutions contact your vendor about how to enable MS-CHAP-V2.

Install and configure Network Policy Server

See Microsoft documentation on how to install and configure the NPS-role.

Troubleshooting

Check RADIUS-logs

Check if anything is written to the Mideye RADIUS logs

 %installdir%\log\radius-messages.log

Contact Mideye support

For further support please contact Mideye support, support@mideye.com, +46854514750.

Radius Clients

To create a new RADIUS Client, navigate to “Configuration” followed by RADIUS clients and click “Create a new RADIUS client”. Note that shared secrets are added separately in the shared secret menu.

General Settings

Client Name: Add a friendly name to the RADIUS client. This must be unique.

NAS IP Address: Add the hostname or the IP of the RADIUS client.

NAS Identifier: Instead of using a NAS IP address, a NAS Identifier (Attribute #32) can be used for the RADIUS client.

Authentication Server: Select what authentication server to use.

Accounting Server: Select what accounting server to use.

User Repositories

Use Mideye Database: Except for LDAP, Mideye Server can perform a search from its own database. When enabled, Mideye Server will always start searching for users in the database before moving on to LDAP.

LDAP Profiles: Select one or more LDAP-profiles to use for the RADIUS client.

Azure Active Directory: Select one or more Azure AD profiles to use for the RADIUS client

Client Configuration

OTP Length: The Default value of the OTP length is 6, but it can be customized to a minimum 4 and maximum 12.
OTP Type: Default all OTP will be numeric but can be customized to numeric, alphabetic and alphanumeric.
Encoding: Assign the appropriate encoding for the RADIUS client. The default value is UTF-8.

Ignore password: Enabled by default, but can be disabled if Mideye should ignore the password sent by the end-user. If ignored, be advised that only a correct username is needed for successful authentication. Will not work with authentication type “Password” (1)
User suffix: Enable if Mideye should enable user-selected authentication types.
Allow Auth Type 1 (Password): Starting from release 5.2 auth type 1 will be disabled by default. This can be enabled by checking the “Allow auth type 1 (Password).
Require Token-coupled Plus login: Enable to only accept login with token-coupled Mideye+ apps or token cards.
Allow Personalized Token: Starting from release 5.2, the use of personalized YubiKeys will be disabled by default. This can be enabled by checking the “Allow Personalized Token”.
Require Local Authentication: With this option enabled, PIN or biometric authentication is mandatory if end users are using Mideye+ and Touch. No fallback will be available.
Require Mideye+ app: If enabled, Mideye+ app is mandatory for all end users.

Username Filtering

Mideye can filter part of the username sent from the RADIUS client. Choose the filter method and add a filter separator. Username filtering will only function with authentication type PAP.

Default RADIUS-client

A default RADIUS client can be configured to allow all incoming requests from any RADIUS client that is not specified in the RADIUS client list. This can be done by adding a new RADIUS-client with the IP-address 0.0.0.0. Also, a new shared-secret must be added for the default RADIUS-client using the Shared Secret menu.

RADIUS Servers

Mideye Server 5 comes predefined with a RADIUS Server running on udp/1812. More RADIUS Servers can be added that will listen on other UDP-ports.

To add a new virtual RADIUS server navigate to “Configuration” followed by “RADIUS Server”. Click “Create a new RADIUS Server”.

General settings

Server name: Friendly name of the RADIUS Server. It must be unique.
Auth Port: Add what UDP port the new RADIUS server should be listening on.

Advanced Settings

Max pending requests: Number of pending requests before Mideye Server drops all requests that reach above the configured value. Once requests go below the value it will continue to handle all requests. The default value is 20.

Max failed user attempts: Failed authentication attempts before the database user account will be locked. The default value is 5

Max user deliveries per minute: Maximum number of deliveries per minute from one unique user before Mideye Server drop the requests. The default value is 5.

Max user deliveries per hour: Maximum number of deliveries per hour from one unique user before Mideye Server drop the requests. Default value is 30.

Reset spam filter

If the maximum number of deliveries per hour gets filled up, no more login attempts will be allowed, and the Mideye Server will return “Too many attempts, try again later” to the RADIUS client.

To reset the spam filter manually, navigate to “Configuration” followed by RADIUS-servers. If the spam-filter is active a yellow button with the text “Spammers” will be presented. To reset, click the button.

Touch Accept User Inactivity Timeout (seconds): Max waiting time for the user to respond to a Touch Accept request.

Push delivery timeout (seconds): Max waiting time for a push message delivery notification.

Database User Authorization Per RADIUS Client: If checked, users in the Mideye internal database will only be authorized to access assigned RADIUS clients.

Identify RADIUS Client By Source IP: If checked, RADIUS clients will be identified based on source IP before attempting identification based on attributes 4 (NAS IP address) and 32 (NAS Identifier).

Ignore multiple logins: Ignore simultaneous requests from a RADIUS client. Used to prevent login problems with RADIUS clients that lack multiple-click protection.

User Messages

All messages sent by the Mideye Server can be customized.

RADIUS Shared Secrets

To add a shared secret to a RADIUS client, navigate to “Configuration” followed by “RADIUS Shared Secrets”. Click “New RADIUS Shared Secret”.

Source IP: Add the IP of the corresponding RADIUS client. To allow any source IP, 0.0.0.0 can be added.

Shared Secret: Add the shared secret for the RADIUS client. If left blank all RADIUS ports will accepting the requests from the RADIUS clients.

RADIUS Port: A RADIUS client can be tied to a certain RADIUS port

Switch Configuration

The Switch configuration tab is the settings for all outgoing connections between the Mideye Server and Mideye central cloud service. The switch port is a customer-specific port, that will be obtained from the Mideye Support.

The switch hosts should normally not be changed. However, if the Mideye Server can not lookup hostnames, IP addresses can be added instead.

To change the hostname of the Switch Configuration navigate to “Configuration” followed by “Switch Configuration”.

Replace primary.mideye.com with: 217.151.192.84 and secondary.mideye.com with 79.136.112.54 and save the changes.

Vendor specific attributes

When using LDAP-RADIUS translation, vendor specific attributes (VSA) are often used to send specific attributes as a reply to the RADIUS client. If a VSA is not present when creating a new LDAP-RADIUS translation it is now possible to create any VSA’s based on a vendors specification. This can be done from “Configuration” followed by “Vendor Specific Attributes”.

1. Click Radius Vendors.
2. Click Create a new RADIUS vendor.
3. Add the Vendor ID and the Vendor name. Click Save.
4. Go back to Vendor specific attributes and click “Create a new Vendor Specific attribute”.
5. Select the Radius Vendor that was created in step 3 and add the ID, name and type. Click Save.
6. Navigate to LDAP-RADIUS translation and create a new rule based on the VSA created above.

The “Vendor Specific Attributes” menu can also be used to create any custom attribute. Simply follow step 1-6 and add your own custom attributes and vendor name.

Mideye rest API

Mideye Server 5 offers a rest API that is hidden by default. This API is mainly used for internal development but can be enabled to automate certain tasks such as exporting accounting information and authentication logs. Please be advised that this API can be changed when new releases are available.

To show the API, open MideyeServer.ini located in the root folder of the installation and add the following to -Dspring.profiles.active=

prod,swagger,mideye-internal

Save the file and restart the Mideye Server service. Open the web GUI and login as root. This is the only role that will have access to the rest API.

In the top right corner, navigate to “Internal rest API”

The Internal rest API page will show all available operations and can be tested by expanding them and click the “Try it out!” button.

These rest API’s can also be executed remotely and should always include the token-ID generated with the “mideye-server-jwt-controller” API.

Password comparison

Introduction

Password comparison feature is to authenticate users against a hashed password that is stored in an optional attribute, rather than the standard password attribute, in the user repository. This feature is specifically designed to work with Microsoft Active Directory user repository. The field containing the hashed password can be any one of the user attributes in Active Directory, and it is specified from Mideye Server. This attribute must contain the (case sensitive) hashed password, Base64 encoded as shown below: {HASH_TYPE}hashed_Password_Base64_Encoded. An account with appropriate permissions for accessing Active Directory in order to retrieve user information (including the field containing the hashed password) is needed. Note: When Password Comparison is used, Activate LDAP user locking feature will be enabled automatically and it is impossible to disable it. The reason is to prevent brute force attacks by locking the user in Mideye Server after a certain number of failed login attempts for a specified time. Max failed user attempts indicate the number of failed login attempts after which the user will be locked and the Number of minutes locked the duration for which the user will remain locked.

Supported Password Hashes

The supported password hashes are:  SHA: SHA-1 hash algorithm  SSHA: Salted SHA CRYPT: Unix crypt function MD5: MD5 hash algorithm SMD5: Salted MD5 algorithm In order to produce valid password hashes, the plain text password must be UTF-8 encoded, and the hash must be Base 64 encoded, as explained in the following example.

Hashing Process

The hashing process is as follow:

• Encode the UTF-8 plain text password to a byte array
• Hash the byte array using one of the supported hash algorithms
• Encode the hash to Base 64 format
• Prepend the hash algorithm name placed between curly brackets to the result, for example, possible hashes of the password “password” are:
  • {SSHA}VtpoxGYLenxwGC88loHYDwb1SpqBbOb6c1OyZiyAQcgFYPPnqRFviA== 
  • {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
  • {CRYPT}aajfMKNH1hTm2
  • {MD5}X03MO1qnZdYdgyfeuILPmQ==
  • {SMD5}swXK27O85U86pZxk/sAN6nNhbHQ=

Note: The encoding used to produce the password hash and the one used by the RADIUS client must be the same. The same string encoded with different encodings may produce different byte arrays, resulting in different final hashes. So even if the password string is the same different encoding will prevent the correct validation.

• {SSHA}VtpoxGYLenxwGC88loHYDwb1SpqBbOb6c1OyZiyAQcgFYPPnqRFviA== 
• {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
• {CRYPT}aajfMKNH1hTm2
• {MD5}X03MO1qnZdYdgyfeuILPmQ==
• {SMD5}swXK27O85U86pZxk/sAN6nNhbHQ=

Note: The encoding used to produce the password hash and the one used by the RADIUS client must be the same. The same string encoded with different encodings may produce different byte arrays, resulting in different final hashes. So even if the password string is the same different encoding will prevent the correct validation.

The strings stored for the password comparison in the repository are case sensitive, so, for example, {CRYPT}aajfMKNH1hTm2 will work but not {crypt}aajfMKNH1hTm2.

Usage Example

Mideye Server is configured to have an LDAP server working, so it is possible to perform a User Search from the LDAP Server Configuration dialog. To enable password comparison, in the LDAP Server Configuration dialog, select the Authentication tab. Use the Password Override field to specify the desired user attribute in Active Directory for the hashed password storage. In this example, the user attribute physicalDeliveryOfficeName is specified to store the hashed password.  Provide that all the other configurations such as authentication type, mobile number and/or token number are correct, after saving the Mideye Server it is possible to perform a RADIUS authentication against the hashed password present in the specified field for the configured LDAP server.

Server monitoring

Mideye Server supports Syslog, SNMP and Event Viewer (Windows) for service monitoring and forwarding of log information. Mideyeserver.log is located in C:\Program Files (x86)\Mideye Server 5\log in Windows Server and /opt/mideyeserver/log/ in Linux.

Linux logs are also sent to /var/log/messages, so it’s a good practice to rotate these logs.

Syslog

Mideye Server log files can be sent to a Syslog server through the logback configuration %installdir%\config\logback.xml. By default it is commented out.

<appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
<syslogHost>10.10.10.10</syslogHost>
<facility>SYSLOG</facility>
<port>514</port>
<suffixPattern>java %d{ISO8601,UTC} %p %t %c %M - %m%n</suffixPattern>
</appender>

<root level="INFO">
<appender-ref ref="SYSLOG" />
</root>

Event Viewer

Windows Event Viewer logging for Mideye Server is enabled by default. All Mideye Server logs with severity Warning or higher will be sent to the Event Viewer. The location for these logs is Windows Logs – Application. To get a better overview of logs, a custom view can be created in the Event Viewer console.

Open Event Viewer and right clock “Custom Views”. Select “Create Custom View…” and choose “By Source”. Click the dropdown list and select “MideyeServer”. Click “OK”.

Now all logs from the Mideye Server will be found in the “Custom View” tree.

To change the severity level of the logs sent to the Event Viewer open %installdir%\config\logback.xml as an administrator. In the appender named “Windows” change the level of severity. Save the file and restart the Mideye Server service.

<appender name="WINDOWS" class="com.mideye.mideyeserver.logging.JNAAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">             <level>WARN</level>
</filter>
<filter class="ch.qos.logback.core.filter.EvaluatorFilter">             <evaluator><expression>return logger.startsWith("com.mideye");</expression></evaluator>
<OnMismatch>DENY</OnMismatch>             
<OnMatch>NEUTRAL</OnMatch>         
</filter>     
</appender>

SNMP

SNMP can be enabled by opening %installdir%\config\logback.xml as an administrator. Uncomment everything for the SNMP appender and add the necessary configuration. Add the following line under root level warn line:

<root level="WARN">
<appender-ref ref="WINDOWS"/>
<appender-ref ref="SNMP"/>
</root>

Save the file and restart the service.

Shared database for two or more Mideye Servers

To create a Mideye Server cluster, two or more Mideye Servers can be configured to use the same database. Changes made in any Mideye Server will propagate in real-time to the other servers.

There are two exceptions that require manual update on all servers:

1. If a RADIUS-server is added or changed a manual restart of the service is required on all other servers.
2. When adding LDAPS or GUI certificates, these must be manually imported on all other servers.

Only one of the servers in a cluster should be configured to execute scheduled database cleanup. Please see the Configuration section of the installation manual for more information.

Server operation

Dashboard overview

After logging in to the web GUI, a dashboard is presented with a quick overview of today’s authentication logs and the health of the server.

• Mideye switch and database status: The top left corner will show two icons with the health of the connection to the central Mideye services and status of the database. Both these should always be green.
• The graph below the icons shows all authentication attempts during the timeline selected to the right.
• The row below the graph gives an overview of the number of unique users, what RADIUS clients that have been used followed by authentication types and failed logins.
• The last row shows all authentication attempts over the selected period of time.

Logs

All accounting, authentication attempts, and logs will be accessed from the logs tab. This tab does not contain any configurable settings and is the only tab except for the dashboard that the role Mideye Operators will be able to view. More information about the different roles can be found here.

Database retention settings

Starting from Mideye Server 5.3 it is possible to customize how long the authentication logs should be stored before being deleted. The retention settings is divided into the following options:

• retentionInDaysForAuthenticationLog
• retentionInDaysForAuthenticationLogEntries

The default settings are 365 days for authentication logs and 30 days for authentication log entries.

Authentication logs can be viewed from the web GUI and will show all user authentication activity.

Log entries are more detailed and can be viewed from \Mideye Server 5\log or directly from the web-GUI under “Logs” followed by “Log Files”

Changing the values for database retention

Both settings for database retention can be changed from the application-prod.yml located in \Mideye Server 5\config\ folder. Open the file as an administrator and scroll to the very end of the code. If not already added, paste the following code:

cron:
# cronExpression: '0 * * * * *'
cronExpression: '0 0 * * * *'
retentionInDaysForAuthenticationLog: 365
retentionInDaysForAuthenticationLogEntries: 30

Change the value of retentionInDaysForAuthenticationLog and retentionInDaysForAuthenticationLogEntries to a desired value.

This will be executed as a cron-job using the following syntax

Save the file and restart the Mideye Server for changes to take effect.

Authentication logs

This view gives a detailed overview of the latest authentication attempts made by all RADIUS clients. The data can be sorted on:

• Time
• Username
• RADIUS client
• Authentication type
• Msisdn (phone number or token)
• Result (Successful or failed authentication)
• Info

Accounting

The accounting page will show all successful logins with a timestamp. The accounting can also be exported to a csv-file.

Log files

This page is helpful for troubleshooting purposes. The default settings will show info, warning and error messages but can be customized from the “Logging” page located in the “Configuration” tab.

Except for the MideyeServer.log file, all trace files that have been created can be viewed from this page.

RADIUS Sessions

All RADIUS clients that supports RADIUS Accounting will send accounting to Mideye Server. Each accounting sent includes timestamps when the sessions started and when the session is closed. If supported by the RADIUS client, updates will also be logged.

RADIUS Disconnect-Messages

If the RADIUS client have support for RADIUS Disconnect-Messages (According to Dynamic Authorization Extensions RFC 3576), the Mideye Server can send a Disconnect-request to the RADIUS client. This can be enabled on each RADIUS client in the Mideye-server on the Assisted Login profile. If Assisted Login should be enabled on the RADIUS client choose a Assisted Login Profile, otherwise leave it blank.

For Radius Sessions to work, the Mideye Server must be able to communicate with mas.mideyecloud.com (13.49.208.156) on port tcp/443.

Server health monitoring

To monitor the Mideye service and the connections to the central Mideye switches, there is a health check API reachable on https://<ServerIP>:<webGUIport>/management/health.

The URL will return {“status”:”UP”} if the Mideye service is running and at least one Mideye Switch is reachable. If the Mideye Server is up and no Mideye Switch is reachable, the URL will return {“status”:”DOWN”}.

Mideye+ and Touch Accept

Introduction

Users with smartphones can choose to download the Mideye+ app. This enables login also when the phone is not reachable via the mobile network. There is no extra charge using the Mideye+ app and does not need to be used by the entire organization.

Installation and activating Mideye+ app

The following section will describe how to download and activate the Mideye+ app.

Downloading the Mideye+ app

Mideye+ can be downloaded for both Android and iPhone users. For iPhone users, download the app here or by searching for Mideye+ directly in the App Store. iOS 9.0 or later is required.

Android users can download the Mideye+ app here or search for it directly in Google Play.

Activating the Mideye+ app using iPhone

Once downloaded and installed, open the Mideye+ app. First time opening the Mideye+ app, the message “Mideye+ Would Like to Send You Notification” pops up. Click “Allow” to allow the app to send notifications each time an authentication attempt is made.

The activation consists of 3 steps:

• Enter the phone number in international format e.g +46735084555 and press “Next”.

• Make an authentication attempt to the corporate resource (e.g Anyconnect, Citrix-portal etc) that is protected with Mideye.

• Once the SMS is received, open the message and click the link. A redirect to the Mideye+ app will take place with the text “Activation successful”.

Activating the Mideye+ app using Android

Once downloaded and installed, open the Mideye+ app and agree to the terms.

Enter the phone number in international format e.g +46701234567 and press “Next”.

Using Mideye+

When Mideye+ is activated, the app can be used to authenticate when logging on to a protected resource that is using Mideye two-factor authentication. Instead of receiving traditional text-messages containing an OTP, Mideye will send the OTP using data traffic and the OTP will be presented in the phone as a notification.

Sending data OTP instead of traditional text messages have a big advantage when end-users do not have any network coverage but still have internet access.

Offline manual challenge

Mideye+ also works as a token card and can be used when both network coverage and internet access is missing. When end users try to authenticate, and the phone does not have any coverage, Mideye will instead present the user with the message “Phone not reachable, please sign xxxxxx”.

To sign, open the Mideye+ app and click “Manual signature at the bottom of the screen”

Enter the challenge presented on your loginscreen.

Troubleshooting Mideye+

Offline signing of challenge

If a manual signing does not work, but instead the end-user is presented with a failed authentication, it is likely because the RADIUS timeout of the RADIUS client is set to less than 35 seconds. Refer to the section “Troubleshooting RADIUS client” in the Configuration guide.

User is not receiving any notifications when using Mideye+

For Mideye+ to function correctly it is important that the end-user accepts that Mideye+ can present notifications. This question is presented to the end-user only once after installing the app. If the user accidentally pressed “Deny” instead of “Allow”, no notifications with OTP will be shown during authentication. To manually fix this follow the instructions below:

iPhone users

1. Tap the “Settings” icon.
2. Scroll down and tap “Notifications”
3. Tap Mideye+ in the “Notification style”
4. Enable “Allow Notifications”

Android users

Enabling notifications vary depending on what version of Android is being used. Refer to each manufacturer’s manual for details.

Android is not presenting any notifications while the phone is in battery saving mode

If the phone is low on battery and the end-user enables battery saving mode, Mideye+ must be excluded to still be able to present notifications when authenticating. The example below shows how to achieve this using a Samsung phone. For other phones, refer to the manual from the manufacturer.

1. Open “Settings”
2. Open “Battery” and navigate to “Unmonitored Apps”
3. Click “Add apps” and select Mideye+ followed by “Done”

Touch Accept

To further ease the authentication process, Touch Accept can be used to simply allow or deny an authentication attempt. This function can be enabled from Mideye configuration tool and does only affect those users that have Mideye+ installed on their cellphones. Also, Touch Accept does not use Challenge Respons when authenticating, which enables two-factor authentication on applications and services that do not have support for traditional two-factor authentication.

Enabling Touch Accept

Navigate to “Configuration” followed by “LDAP Profiles”. Select the LDAP-Profile that is being used, and click “Edit”. Select the tab “Authentication” and change the “Default authentication type” to 6, 7 or 8 depending on if there should be a fallback available to traditional OTP. Fallbacks are only efficient if the authentication service supports challenge-response. In those cases, if for any reason Touch accept would fail, a normal OTP will be sent to the phone. If the authentication service does not have any support for challenge-response, authentication type 6 will be the only option.

To verify if the configuration is working, simply perform an authentication attempt to any Mideye enabled service. Now, instead of receiving an OTP to the Mideye+ app, a question to allow or deny the login will be presented. Since the authentication type 8 (Touch-mobile) was selected in the previous step, an OTP will be sent if Touch should fail.

Token cards

As a complement to using the phone as a second authentication factor, Mideye also supports authentication with token cards. Instead of receiving one-time passwords on the mobile phone, the user obtains one-time passwords from the token card.

The customer assigns token cards to users that require this authentication method. Token cards are ordered from Mideye Support, Yubikeys can also be obtained from third parties. The tokens are fully integrated into the Mideye system. The only difference compared to authentication with the mobile phone is that the user is assigned the token serial number (e.g. AI0123456789, ubbc0123456 or zmub5761949) instead of the mobile number (+46123456789) in the user repository (LDAP directory or internal Mideye database).

Setting Authentication Type in the LDAP repository

For end-user data that is read from an external LDAP repository (LDAP users), the administration is handled via the administrative interface of the LDAP directory. There are two ways to assign token authentication to LDAP users:

Token serial number in the mobile phone field

By registering the user’s token serial number preceded by the prefix “AI (HID mini tokens) or ubbc0 (Yubikey)” in the mobile phone field (e.g. AI0750123456); the user is automatically assigned the authentication type. Token. Note that in this case, the ‘Token Number’ parameter in the tab ‘User’ must be specified as the mobile phone field.

Token serial number in a separate field, with authentication type indicated in yet another field.

In addition to a separate field for the token serial number, the LDAP administrator can assign yet another vacant field that indicates which authentication type should be used (1=Password, 2=Mobile, 3=Token, 4=Concatenated, 5=Plus, 6=Touch, 7=Touch-Plus, 8=Touch-Mobile). This field should be specified via the Mideye Configuration Tool, tab ‘LDAP Servers’, tab ‘Authentication’, parameter ‘Authentication Type Attribute’. Also, the box ‘Read Optional Attributes’ should be marked. (This parameter indicates that Mideye will search certain optional parameters, e.g. Authentication Type, from the LDAP directory). In case no authentication method is specified in the LDAP attribute (= the field is empty), the default authentication method is used.

YubiKey token card

Starting from release 4.5.2 Mideye Server supports both YubiKeys provided by Mideye and YubiKeys obtained from third parties.

Yubikeys provided by Mideye

Mideye can dispatch YubiKeys to the customer’s IT department, or ship them directly to the end-user. These YubiKeys comes preconfigured and will authenticate directly against Mideye’s cloud service.

Complete the following steps to set up a token for an end-user:

1. Obtain the serial number of the YubiKey: This serial number can be found on the back of the token. If the serial number is not visible, attach the YubiKey to a computer and open a text editor. Touch the button on the YubiKey and copy the first 12 characters, e.g ubbc0643451004116861. All tokens dispatched from Mideye will always start with ubbc0.
2. Add the serial number to the user repository: By default, the Mideye Server will search for token numbers in the ipPhone attribute. Open ADUC and locate the user that should use the token. Open the properties of the user and navigate to the “Telephones” tab. Add the serial number in the IP Phone field.
3. Change authentication method: The authentication method for the user must be changed to Tokens (if not already the default authentication type). Open Configuration Tool and navigate to “LDAP Servers”. Click “Modify” and select the “Authentication” tab. Check the “Read optional attributes” and add an LDAP attribute to the “Authentication type attribute”. In this example, the LDAP attribute “pager” will be used for the “Authentication type attribute”, but can be changed to any other attribute. The attribute chosen must be empty from other data.
4. Once again, open ADUC and open the “Telephones” tab for the user. Add the number 3 to the pager field. See section authentication in the configuration guide to see what each number represents in the authentication list.

Yubikeys obtained from third parties

Mideye server also supports YubiKeys that have been bought commercially. For example, a YubiKey that is being used for logging on to Facebook, or an end-users private computer, can also be used to login to the corporate network that is protected by Mideye. Be advised that the authentication will be performed directly against Yubicloud, and Mideye can not control the availability of the service.

Complete the following steps to set up a commercial YubiKey for an end-user:

• Obtain a YubiKey from a reseller. Yubico.com provides all the common YubiKeys. These can be bought here. All YubiKeys should be registered with YubiCloud by default. To verify, visit https://demo.yubico.com and authenticate using the YubiKey. This site also provides information such as YubiKey serial and Yubico provisioned credential identity. If authentication fails, visit https://upload.yubico.com to manually upload the key.

• Obtain the serial number of the YubiKey: This serial number can be found on the back of the token. If the serial number is not visible, copy the YubiKey serial number from https://demo.yubico.com. Mideye requires the prefix zmub followed by the serial number, e.g zmub5761949
• Add the serial number to the user repository: By default, the Mideye Server will search for token numbers in the ipPhone attribute. Open ADUC and locate the user that should use the token. Open the properties of the user and navigate to the “Telephones” tab. Add the serial number in the IP Phone field.

• Change authentication method: The authentication method for the user must be changed to Tokens (if not already the default authentication type). Open Configuration Tool and navigate to “LDAP Servers”. Click “Modify” and select the “Authentication” tab. Check the “Read optional attributes” and add an LDAP attribute to the “Authentication type attribute”. In this example, the LDAP attribute “pager” will be used for the “Authentication type attribute”, but can be changed to any other attribute. The attribute chosen must be empty from other data.
• Once again, open ADUC and open the “Telephones” tab for the user. Add the number 3 to the pager field. See section authentication in the configuration guide to see what each number represents in the authentication list.

HID Mini token card

Complete the following steps to set up an HID token for an end-user:

1. Obtain the serial number of the HID token: This serial number can be found on the back of the token. All tokens dispatched from Mideye will always start with AI.
2. Add the serial number to the user repository: By default, the Mideye Server will search for token numbers in the ipPhone attribute. Open ADUC and locate the user that should use the token. Open the properties of the user and navigate to the “Telephones” tab. Add the serial number in the IP Phone field.
3. Change authentication method: The authentication method for the user must be changed to Tokens (if not already the default authentication type). Open Configuration Tool and navigate to “LDAP Servers”. Click “Modify” and select the “Authentication” tab. Check the “Read optional attributes” and add an LDAP attribute to the “Authentication type attribute”. In this example, the LDAP attribute “pager” will be used for the “Authentication type attribute”, but can be changed to any other attribute. The attribute chosen must be empty from other data. Save and close to restart Mideye services.
4. Once again, open ADUC and open the “Telephones” tab for the user. Add the number 3 to the pager field. See section authentication in the configuration guide to see what each number represents in the authentication list.

Re-synchronisation of HID Mini tokens cards

The token cards provide one-time passwords in a sequence that is unique for each token (time and event synchronous). In case more than ten one-time passwords have been generated from the token card without being entered for central verification in the token server, the token card will come out of synch with the server, and must be re-synchronized. The token card can be automatically re-synchronized within a window of 100 by entering a new one-time password for verification. If the token card is out of sync by more than 100 one-time passwords, it must be manually re-synchronized by Mideye support. For manual re-synchronization, the token card serial number and the counter value must be provided.

Token card serial number

The serial number (10 digits) is printed on the label on the back of the token card (e.g. S/N 0123456789). If the printed serial number is not readable, it can also be obtained from the token display:

• Generate a new one-time password, release the button.
• When the one-time password is displayed, press and hold the button again until the following appears on the display (three alternating strings):
  • ע= SN
  • 1= XXXXX
  • 2= YYYYY

The serial number consists of the five digits XXXXX after the digit 1, followed by the five digits YYYYY after the digit 2.

Token card clock value

• The clock value is obtained as follows:
• Generate a new one-time password, release the button when the one-time password is displayed, press and hold the button again until the following appears on the display (three alternating strings):
  • ע SN
  • 1 XXXXX
  • 2 YYYYY

This is the serial number of the token.

• When the serial number is displayed, release the button, press it again, and hold it until the following appears on the display (3 alternating strings):
  • ע Clock
  • 1 XXXXX
  • 2 YYYYY

The clock value consists of the five digits XXXXX after the digit 1, followed by the five digits YYYYY after the digit 2.

Token card counter value

The counter value is obtained as follows:

• Generate a new one-time password, release the button.
• When the one-time password is displayed, press and hold the button again until the following appears on the display (three alternating strings):
  • ע SN
  • 1 XXXXX
  • 2 YYYY

This is the serial number of the token.

• When the serial number is displayed, release the button, press it again, and hold it until the following appears on the display (3 alternating strings):
  • ע Clock
  • 1 XXXXX
  • 2 YYYYY

This is the token clock value.

• When the clock value is displayed, release the button, press it again, and hold it until the following appears on the display (3 alternating strings):
  • ע Count
  • 1 XXXXX
  • 2 YYYYY

The counter value consists of the five digits XXXXX after the digit 1, followed by the five digits YYYYY after the digit 2.

Note: Older token cards are only event-synchronous and do not have a clock value.

Troubleshooting