Identikey Server Product Guide

IDENTIKEY Server
Product Guide
3.0
3.3
Disclaimer of Warranties and Limitations of Liabilities Disclaimer of Warranties and Limitations of Liabilities
The Product is provided on an 'as is' basis, without any other warranties, or conditions, express or implied, including but not limited to warranties of merchantable quality, merchantability of fitness for a particular purpose, or those arising by law, statute, usage of trade or course of dealing. The entire risk as to the results and performance of the product is assumed by you. Neither we nor our dealers or suppliers shall have any liability to you or any other person or entity for any indirect, incidental, special or consequential damages whatsoever, including but not limited to loss of revenue or profit, lost or damaged data of other commercial or economic loss, even if we have been advised of the possibility of such damages or they are foreseeable; or for claims by a third party. Our maximum aggregate liability to you, and that of our dealers and suppliers shall not exceed the amount paid by you for the Product. The limitations in this section shall apply whether or not the alleged breach or default is a breach of a fundamental condition or term, or a fundamental breach. Some states/countries do not allow the exclusion or limitation or liability for consequential or incidental damages so the above limitation may not apply to you.
Copyright
Copyright 2011 VASCO Data Security, Inc., VASCO Data Security International GmbH. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of VASCO Data Security Inc.
Trademarks
VASCO, Vacman, IDENTIKEY, aXsGUARD, DIGIPASS, and are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries.
Date last modified: 26/07/11
Table of Contents
Table of Contents
1 Introduction.................................................................................................................................................. 10
1.1 1.2 1.3 Who should read this guide?.............................................................................................................................. 10 IDENTIKEY Server documentation suite.............................................................................................................. 10 Further assistance............................................................................................................................................. 10
Overview...................................................................................................................................................... 12
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 What is IDENTIKEY Server?................................................................................................................................ 12 What is a DIGIPASS?.......................................................................................................................................... 12 Types of DIGIPASS............................................................................................................................................. 13 Structure of IDENTIKEY Server........................................................................................................................... 18 IDENTIKEY Server in a RADIUS Environment....................................................................................................... 21 IDENTIKEY Server in a Web Environment............................................................................................................ 27 Administration Components............................................................................................................................... 29 IDENTIKEY Server Data Model............................................................................................................................ 32 Integrating Your Systems With IDENTIKEY Server............................................................................................... 34
2.10 SOAP SSL ......................................................................................................................................................... 36 2.11 PCI-DSS Compliance......................................................................................................................................... 38
User Authentication Process......................................................................................................................... 40

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Logging in with a DIGIPASS................................................................................................................................ 40 Authentication Process Overview....................................................................................................................... 41 Identifying the Component Record..................................................................................................................... 42 DIGIPASS User Account Lookup and Checks....................................................................................................... 43 Local Authentication.......................................................................................................................................... 51 Back-End Authentication.................................................................................................................................... 63 User Attributes................................................................................................................................................... 73 Host Code Generation........................................................................................................................................ 75 Supported RADIUS Protocols.............................................................................................................................. 76
3.10 Unsupported by IDENTIKEY Server..................................................................................................................... 77
Signature Validation Process......................................................................................................................... 79

4.1 4.2 4.3 4.4 4.5 Signing a Transaction........................................................................................................................................ 79 How Do I Generate a Signature?........................................................................................................................ 79 Time based signature........................................................................................................................................ 80 Event Based Signature....................................................................................................................................... 80 Static Signature................................................................................................................................................. 81
3
IDENTIKEY Server Product Guide
Table of Contents
4.6 4.7 Signature Verification Process............................................................................................................................ 81 Policy Settings................................................................................................................................................... 83
Software DIGIPASS Provisioning.................................................................................................................... 84

5.1 5.2 5.3 5.4 5.5 5.6 Software DIGIPASS Provisioning Overview.......................................................................................................... 84 Provisioning Scenarios....................................................................................................................................... 87 DP110 Provisioning Overview............................................................................................................................ 95 What are the steps in registration of a Software DIGIPASS?................................................................................ 99 What are the steps in activation?..................................................................................................................... 101 Reactivation .................................................................................................................................................... 102
DIGIPASS Authentication for Windows Logon............................................................................................... 103

6.1 6.2 6.3 6.4 6.5 6.6 6.7 Introduction..................................................................................................................................................... 103 Available Guides.............................................................................................................................................. 103 Online Authentication....................................................................................................................................... 103 Offline Authentication...................................................................................................................................... 104 Dynamic Component Registration.................................................................................................................... 105 Password Randomization................................................................................................................................. 105 Static Password Synchronization..................................................................................................................... 106
EMV-CAP.................................................................................................................................................... 107
7.1 7.2 7.3 7.4 7.5 7.6 EMV-CAP Smartcard Readers.......................................................................................................................... 107 Hardware Security Module............................................................................................................................... 108 EMV-CAP Scenario........................................................................................................................................... 108 Licensing......................................................................................................................................................... 108 Unsupported Standard IDENTIKEY Server Features........................................................................................... 108 PANs............................................................................................................................................................... 109
Hardware Security Modules........................................................................................................................ 110

8.1 8.2 8.3 8.4 8.5 8.6 8.7 Supported Hardware Security Modules............................................................................................................ 110 Limitations....................................................................................................................................................... 110 Load Balancing and Fail-Over.......................................................................................................................... 110 Licensing......................................................................................................................................................... 111 Configuration................................................................................................................................................... 111 Unsupported Standard IDENTIKEY Server Features........................................................................................... 111 Cryptographic Keys.......................................................................................................................................... 112
Administration............................................................................................................................................ 113
9.1 Overview of Administration Interfaces.............................................................................................................. 113
4
Table of Contents
9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 Administration Web Interface........................................................................................................................... 114 DIGIPASS Extension for Active Directory Users & Computers............................................................................ 118 DIGIPASS TCL Command-Line Administration ................................................................................................. 119 IDENTIKEY Server Configuration....................................................................................................................... 120 Configuration Wizard....................................................................................................................................... 121 Audit Viewer.................................................................................................................................................... 122 Admintool.jar................................................................................................................................................... 122 Tomcat Monitor............................................................................................................................................... 122
9.10 User CGI Configuration..................................................................................................................................... 122
10 DIGIPASS User Accounts............................................................................................................................. 124

10.1 DIGIPASS User Account Creation...................................................................................................................... 124 10.2 Changes to Stored Static Password.................................................................................................................. 125 10.3 Password Strength ......................................................................................................................................... 125 10.4 Administration Privileges.................................................................................................................................. 126 10.5 LDAP Synchronization...................................................................................................................................... 126
11 DIGIPASS.................................................................................................................................................... 127
11.1 Importing DIGIPASS......................................................................................................................................... 127 11.2 Assigning DIGIPASS to Users............................................................................................................................ 127 11.3 DIGIPASS Record Functions............................................................................................................................. 130 11.4 DIGIPASS Reports............................................................................................................................................ 132 11.5 DIGIPASS Programming................................................................................................................................... 133 11.6 DIGIPASS Record Settings................................................................................................................................ 135 11.7 Virtual DIGIPASS Implementation Considerations.............................................................................................. 138
12 Task Scheduling......................................................................................................................................... 141

12.1 What is Task Scheduling?................................................................................................................................ 141 12.2 How Does Task Scheduling Work?................................................................................................................... 141 12.3 Tasks that can be Scheduled........................................................................................................................... 141 12.4 Available Functions.......................................................................................................................................... 141 12.5 Schedule Timing Options................................................................................................................................. 142 12.6 Restrictions..................................................................................................................................................... 142 12.7 Result Notification............................................................................................................................................ 143
13 Client Components..................................................................................................................................... 144

13.1 Component Types............................................................................................................................................ 144
Table of Contents 14 Server Components.................................................................................................................................... 146

14.1 Server Component........................................................................................................................................... 146
15 Policies....................................................................................................................................................... 147
15.1 Policy Inheritance............................................................................................................................................ 147 15.2 Pre-Loaded Policies......................................................................................................................................... 150
16 Reporting................................................................................................................................................... 155
16.1 Understanding Reports.................................................................................................................................... 155 16.2 Considerations for Reporting and Auditing........................................................................................................ 158
17 Wireless RADIUS......................................................................................................................................... 160

17.1 Overview......................................................................................................................................................... 160 17.2 Wireless Network Encryption........................................................................................................................... 160 17.3 Fast Reconnect................................................................................................................................................ 160
18 IDENTIKEY Server Data Store...................................................................................................................... 164

18.1 Active Directory............................................................................................................................................... 164 18.2 ODBC Database............................................................................................................................................... 172
19 Licensing.................................................................................................................................................... 184
19.1 Overview......................................................................................................................................................... 184 19.2 Obtaining and Loading a License Key............................................................................................................... 184
20 Performance Monitoring............................................................................................................................. 185

20.1 Overview......................................................................................................................................................... 185 20.2 Filters.............................................................................................................................................................. 185 20.3 Plugins............................................................................................................................................................ 185
21 System Monitoring...................................................................................................................................... 186

21.1 Overview......................................................................................................................................................... 186 21.2 Filters.............................................................................................................................................................. 186 21.3 Targets............................................................................................................................................................ 186
22 Auditing and Tracing................................................................................................................................... 188

22.1 Audit System................................................................................................................................................... 188 22.2 Secure Auditing............................................................................................................................................... 190 22.3 Tracing............................................................................................................................................................ 191
Table of Contents 23 Message Delivery Component..................................................................................................................... 192

23.1 What is the Message Delivery Component?...................................................................................................... 192 23.2 Starting the Message Delivery Component....................................................................................................... 192 23.3 Enabling SSL on the Message Delivery Component.......................................................................................... 192
24 User Self Management Web Site................................................................................................................. 193

24.1 What is the User Self Management Web Site?.................................................................................................. 193 24.2 Customizing the User Self Management Web Site............................................................................................ 194
Table of Contents
Illustration Index
Image 1: GO 3...................................................................................................................................................................................................................14 Image 2: GO 6...................................................................................................................................................................................................................14 Image 3: GO 7...................................................................................................................................................................................................................14 Image 4: GO 8...................................................................................................................................................................................................................14 Image 5: GO 100...............................................................................................................................................................................................................14 Image 6: DIGIPASSS Nano.................................................................................................................................................................................................14 Image 7: DP 560...............................................................................................................................................................................................................15 Image 8: DP 260...............................................................................................................................................................................................................15 Image 9: DP 270 Xpress...................................................................................................................................................................................................15 Image 10: DP 310 Comfort Voice......................................................................................................................................................................................15 Image 11: DP 810.............................................................................................................................................................................................................16 Image 12: DP 855.............................................................................................................................................................................................................16 Image 13: DP 110.............................................................................................................................................................................................................17 Image 14: Structure of IDENTIKEY Server..........................................................................................................................................................................18 Image 15 : SSL handshake process..................................................................................................................................................................................38 Image 16 : Login Methods................................................................................................................................................................................................40 Image 17: Authentication Process Overview......................................................................................................................................................................41 Image 18: Name Resolution with Active Directory.............................................................................................................................................................45 Image 19: Name Resolution with ODBC database.............................................................................................................................................................46 Image 20 - Dynamic User Registration Process.................................................................................................................................................................50 Image 21: Server PIN States and actions...........................................................................................................................................................................53 Image 22: Virtual DIGIPASS Login.....................................................................................................................................................................................56 Image 23: Multiple DIGIPASS Assignment.........................................................................................................................................................................59 Image 24: The steps in Back-End Authentication for Active Directory...............................................................................................................................68 Image 25: The steps in Back-End Authentication for Novell eDirectory and ADAM............................................................................................................70 Image 26: RADIUS Attributes Overview.............................................................................................................................................................................73 Image 27: Custom User Attributes Overview.....................................................................................................................................................................74 Image 28: Steps of Signature Verification Process ...........................................................................................................................................................81 Image 29: Steps of Provisioning........................................................................................................................................................................................86 Image 30: DIGIPASS for Mobile Scenario 1 process ..........................................................................................................................................................88 Image 31: DIGIPASS for Web Scenario 1 Process .............................................................................................................................................................90 Image 32: DIGIPASS for Web Scenario 2 Process .............................................................................................................................................................92 Image 33: DIGIPASS for Web Scenario 3 Process .............................................................................................................................................................94 Image 34: DP110 Scenario 1............................................................................................................................................................................................96
Table of Contents
Image 35: DP110 Scenario 2............................................................................................................................................................................................98 Image 36: Steps of Software DIGIPASS Registration..........................................................................................................................................................99 Image 37: Steps of Software DIGIPASS Activation...........................................................................................................................................................101 Image 38: DIGIPASS Authentication for Windows Logon Online Authentication................................................................................................................104 Image 39: DIGIPASS Authentication for Windows Logon Offline Authentication................................................................................................................105 Image 40: DIGIPASS 810.................................................................................................................................................................................................107 Image 41: Cryptographic keys allocated by token name and Slot ID................................................................................................................................112 Image 42 : IDENTIKEY Server Web Administration Interface............................................................................................................................................115 Image 43 : IDENTIKEY Server Configuration....................................................................................................................................................................120 Image 44 : Configuration Wizard.....................................................................................................................................................................................121 Image 45: Self Assignment Process ...............................................................................................................................................................................128 Image 46: Auto Assignment Process ..............................................................................................................................................................................129 Image 47: Manual Assignment Process ..........................................................................................................................................................................130 Image 48: Policy Inheritance...........................................................................................................................................................................................147 Image 49: Fast Reconnect overview................................................................................................................................................................................161 Image 50: Fast Reconnect authentication process..........................................................................................................................................................161 Image 51: Roaming Wireless Fast Reconnection.............................................................................................................................................................162 Image 52: Roaming Wireless Fast Reconnection Roaming Zones.................................................................................................................................163 Image 53: DIGIPASS Record Locations - DIGIPASS Pool..................................................................................................................................................167 Image 54: DIGIPASS Record Locations - Parent Organizational Unit................................................................................................................................168 Image 55: DIGIPASS Record Locations - Individual Organizational Units..........................................................................................................................170 Image 56: Domains and Organizational Units..................................................................................................................................................................172 Image 57: DIGIPASS Record Locations Domain Root....................................................................................................................................................174 Image 58: DIGIPASS Record Location Parent Organizational Unit..................................................................................................................................175 Image 59: DIGIPASS Record Locations Individual Organizational Units.........................................................................................................................176 Image 60: Additional ODBC databases............................................................................................................................................................................178 Image 61: Multiple IDENTIKEY Server Using Single Database..........................................................................................................................................179 Image 62: Replication between a Primary and Backup IDENTIKEY Server........................................................................................................................180 Image 63: Replication between Primary, Backup, and Disaster Recovery in IDENTIKEY Server........................................................................................181 Image 64: Replication between three IDENTIKEY Servers................................................................................................................................................182 Image 65: Complex IDENTIKEY Server Replication Scenario............................................................................................................................................182 Image 66: Audit System Overview...................................................................................................................................................................................188 Image 67: Audit Viewer...................................................................................................................................................................................................189 Image 68: User Self Management Web Site....................................................................................................................................................................193
Introduction
Introduction
This IDENTIKEY Server Product Guide introduces the features and concepts of IDENTIKEY Server and explains various usage options. It provides a comprehensive overview of IDENTIKEY Server for anyone wishing to gain familiarity with the product.
1.1
Who should read this guide?

This guide is designed for anyone interested in using or learning about IDENTIKEY Server products, particularly system managers, administrators and developers. It would be helpful if the reader is already familiar with: Online authentication and authorisation tools and protocols, including SOAP, RADIUS, WSDL, SSL, XML, HTML and TCP/IP. Windows and Linux security software environments including IIS, Active Directory and ODBC. Administration tasks including user management , policy, scheduling, reports, and performance monitoring. Password management and encryption techniques. EMV-CAP and other e-commerce transaction standards. An understanding of programming languages, especially Java and ASP.NET, would also be helpful.
1.2
IDENTIKEY Server documentation suite

The following IDENTIKEY Server guides are available: Product Guide - introduce the features and concepts of IDENTIKEY Server and explains various usage options. Getting Started Guide - leads you through a standard setup and testing of key IDENTIKEY Server features. Windows Installation Guide - planning and working through a Windows installation of IDENTIKEY Server. Linux Installation Guide - planning and working through a Linux installation of IDENTIKEY Server. Administrator Guide - in-depth information required for administration of IDENTIKEY Server. Administrator Reference detailed references such as data attributes, backup, recovery and utility commands. Performance and Deployment Guide - information on common deployment models and performance statistics. Release Notes latest information on IDENTIKEY Server releases. SDK Programmers Guides - information on the IDENTIKEY Server Software Development Kit (SDK), plus dedicated guides for .NET, Java and SOAP. Authentication SDK Guides - in-depth information required to develop using the authentication SDK, plus dedicated guides for .NET, Java and SOAP.
1.3
Further assistance
10
Introduction
Comprehensive Help Files including context-sensitive assistance are available via IDENTIKEY Server interfaces. For more information, please visit http://www.vasco.com. user
11
Overview
2
2.1
Overview
What is IDENTIKEY Server?
IDENTIKEY Server is a server product designed to support the deployment, use and administration of VASCO DIGIPASS technology. It can be easily integrated with existing applications using a Software Developer Kit (SDK). IDENTIKEY Server provides support for the following primary functions: DIGIPASS One Time Password Authentication DIGIPASS Signature Validation Software DIGIPASS Provisioning Administration and Reporting Auditing IDENTIKEY Server is designed to be easily usable with Web applications and has a Web-based Administration interface.
2.2
What is a DIGIPASS?
A DIGIPASS is a device for providing One Time Passwords and Digital Signatures to a User. A DIGIPASS may be provided to each person whom an organization wishes to be able to log into their system using a One Time Password (OTP). The User obtains an OTP from the DIGIPASS to use instead of, or as well as, a static password when logging in. In addition, a DIGIPASS may be provided for the user to sign transaction data. The user enters key details of the transaction into their DIGIPASS and receives a signature. They enter the signature into a transaction confirmation page in order to confirm that they authorize the transaction. Virtual DIGIPASS is a mechanism where an OTP is generated by the server and sent to the User's mobile phone or email account. In this case, a physical DIGIPASS device is not needed. A Software DIGIPASS may be installed onto your computer, or onto a mobile device such as a Blackberry or Javaenabled mobile phone. It can be used to generate an OTP or a Signature in the same way as a physical DIGIPASS device.
12
Overview
2.3
Types of DIGIPASS
Each DIGIPASS is programmed with at least one DIGIPASS Application and a unique secret. The DIGIPASS Application uses this secret when generating One Time Passwords and Signatures. Each type of DIGIPASS Application generates One Time Passwords or Signatures from different data, and in slightly different ways:
Response Only
Creates a One Time Password based on the current date and time or on the number of uses (events).
Challenge/Response
Creates a One Time Password (also referred to as a 'Response') based on a numerical challenge given on a login page. This may be either a challenge custom-created for the specific DIGIPASS, or a randomly created challenge. The One Time Password may also be based on the date and time.
Digital Signature
Digital Signature DIGIPASS Applications are typically used in online banking. The DIGIPASS generates a unique code - referred to as a 'Digital Signature' - based on a number of transaction data fields entered, plus (optionally) the date and time or number of uses (events).
Multi-Mode
Multi-mode DIGIPASS are DIGIPASS that are capable of being used in all of the above modes. This setting is used mainly for DIGIPASS for Web.
13
Overview 2.3.1 Hardware DIGIPASS

Hardware DIGIPASS are devices specifically designed for creation of One Time Passwords and Digital Signatures. Depending on the model supplied, they may be used for Response Only, Challenge/Response and Digital Signature methods. The three basic types of hardware DIGIPASS are:
DIGIPASS without keypads

These are the simplest type of DIGIPASS. They have a triggering mechanism - typically a button or action, such as pulling the DIGIPASS open - which causes a One Time Password to be generated. They have only one Application, which is always Response Only, except for the DIGIPASS Nano, which can have more than one Application.
Image 1: GO 3
Image 2: GO 6
Image 3: GO 7
Image 4: GO 8
Image 5: GO 100
Image 6: DIGIPASSS Nano
14
Overview DIGIPASS with keypads

These are typically capable of supporting more than one Application, and can be programmed so that a PIN must be entered before a One Time Password or Digital Signature may be generated.
Image 7: DP 560
Image 8: DP 260
Image 9: DP 270 Xpress
Image 10: DP 310 Comfort Voice
15
Overview Smartcard reader DIGIPASS

These provide two-factor authentication based on smartcard technology in a similar way to the above two types. The smartcard itself provides the 'secret' that is used to generate OTPs and Digital Signatures. IDENTIKEY Server includes support for EMV-CAP compliant smartcards and readers. See 7 EMV-CAP for more information.
Image 11: DP 810
Image 12: DP 855
2.3.2
Software DIGIPASS
Software DIGIPASS may be installed onto a Blackberry, Java-enabled mobile phone or other mobile device. The User then accesses a DIGIPASS application to obtain a One Time Password or Digital Signature. They typically support Response Only, Challenge/Response or Digital Signature DIGIPASS Applications. Distribution of Software DIGIPASS is controlled by IDENTIKEY Server using Provisioning scenarios. See 5 Software DIGIPASS Provisioning for more information.
DIGIPASS for Web

DIGIPASS for Web is a Java applet that runs on your internet browser. DIGIPASS for Web can generate One Time Passwords and Digital Signatures. DIGIPASS for Web supports the Multi-Mode Application type.
DIGIPASS for Mobile

DIGIPASS for Mobile is an application that will run on your mobile phone, Blackberry, iPhone or Windows Mobile. DIGIPASS for Mobile can generate One Time Passwords and Digital Signatures.
16
Overview 2.3.3 Hardware/Software DIGIPASS

The DIGIPASS 110 is currently the only DIGIPASS available which combines the security of a hardware DIGIPASS with the portability of a software DIGIPASS. It consists of a secure USB stick used with a Java applet on the User's computer. It holds the cryptographic information used in generating One Time Passwords for the User. Distribution of the Java applet used with the DP 110 is handled by IDENTIKEY Server in the same way as Software DIGIPASS. See 5 Software DIGIPASS Provisioning for more information.
Image 13: DP 110
2.3.4
Virtual DIGIPASS
Virtual DIGIPASS can be used instead of hardware DIGIPASS tokens, or as a backup mechanism when a User has mislaid their hardware DIGIPASS. Using Virtual DIGIPASS means that a User may receive a One Time Password on their mobile phone via text message. There are two forms of Virtual DIGIPASS available: Primary Virtual DIGIPASS are treated by IDENTIKEY Server almost identically to hardware and software DIGIPASS a record of each Primary Virtual DIGIPASS must be imported into the data store, and may then be assigned to a User automatically or manually. The User will typically log in with their User ID and static password, have a One Time Password sent to their mobile phone or email account, and then enter the received One Time Password in the second stage of their login. The Backup Virtual DIGIPASS feature allows a User to request a One Time Password sent to their mobile phone or email account if they do not have their usual DIGIPASS at hand. It may be limited by number of uses or days of use - eg. a User may be limited to 2 days' usage, after which they will again need to use their usual DIGIPASS to log in.
17
Overview
2.4
Structure of IDENTIKEY Server

The diagram below shows the basic structure of an organization's existing applications integrated with IDENTIKEY Server.
Image 14: Structure of IDENTIKEY Server
18
Overview 2.4.1 Customer Web Applications

IDENTIKEY Server provides support for web applications through an SDK based on the standard SOAP protocol. These applications may cover operational tasks such as authentication and signature validation, provisioning of Software DIGIPASS or administration of IDENTIKEY Server. SOAP over HTTPS is supported, versions 1.1 and 1.2. 'Document Literal' binding is used. A variety of SOAP client SDKs have been tested.
2.4.2
Remote Access Clients

IDENTIKEY Server supports the RADIUS protocol (according to RFC 2865) for remote network access authentication, to the same level as VACMAN Middleware 3.0. Some applications are written using RADIUS as an authentication protocol, and these applications will also be supported. The SEAL protocol is a proprietary VASCO protocol used by the VASCO authentication modules. At the time of writing this includes DIGIPASS Authentication for Citrix Web Interface, Outlook Web Access, IIS, SBR and DIGIPASS Authentication for Windows Logon.
2.4.3
IDENTIKEY Server
The IDENTIKEY Server is a Service which receives and processes requests from the various client components. It may refer to a Back-End System for a part of the processing tasks. IDENTIKEY Server has a modular architecture incorporating the following key concepts:
2.4.3.1
Communicator Modules
For each protocol by which requests can be received, a Communicator module is present. Each Communicator can be enabled or disabled as preferred, subject to support in the license. The following Communicators are present: SOAP (requires a license option) RADIUS (requires a license option) SEAL (does not require a license option)
2.4.3.2 Scenario Modules
For each major group of functionality in the IDENTIKEY Server, a Scenario module is present. Each Scenario can be enabled or disabled as preferred, subject to support in the license. The following Scenarios are present: Authentication (requires a license option) Signature Validation (requires a license option)
19
Overview
Provisioning (requires a license option) Administration (does not require a license option) Reporting (does not require a license option) Replication (does not require a license option) Administration (does not require a license option) Audit Scenarios (does not requrire a license option) Configuration (does not require a license option) EMV-CAP (requires a license option)
2.4.4
Back-End Systems
A Back-End System is used as an authority for user accounts and static passwords, before a user account is created in IDENTIKEY Server and the user starts to use a DIGIPASS. A RADIUS server may be used for both BackEnd Authentication and returning RADIUS attributes. See 3.6 Back-End Authentication for more information.
2.4.5
Data Store
IDENTIKEY Server uses Active Directory or an ODBC-compliant database to store administration and configuration data. An embedded PostgreSQL database is included in the installation package.
2.4.6
Hardware Security Module

A Hardware Security Module may be used to safeguard IDENTIKEY Server data. See 8 Hardware Security Modules for more information.
Note
Hardware Security Module support is only available where IDENTIKEY Server is using an ODBCcompliant database.
20
Overview
2.5
IDENTIKEY Server in a RADIUS Environment

IDENTIKEY Server can be used in a RADIUS environment in a number of ways, depending on your company's requirements. In the following scenarios, a RADIUS Client may be a dial-up NAS (Network Access Server), firewall/VPN appliance, Wireless Access Point, or another device that uses the RADIUS protocol for user authentication. Some software applications can also use RADIUS for authentication, for example Microsoft Internet Security and Acceleration Server (ISA), and can therefore also act as RADIUS Clients. In the RADIUS protocol, 'attributes' are used for authorization and configuration of the remote access session in many cases. IDENTIKEY Server can return authorization attributes from the DIGIPASS User account, or these attributes may be retrieved from a separate RADIUS server.
2.5.1
Stand-alone: No RADIUS Attributes Required
This scenario can be implemented with the following protocols: One of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2
2.5.2
Stand-alone: RADIUS Attributes from DIGIPASS User Account
In this scenario, IDENTIKEY Server retrieves RADIUS attributes from the DIGIPASS User account and returns them
21
Overview
with an Accept message to the RADIUS client. This scenario can be implemented with the following protocols: One of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2
22
Overview 2.5.3 Wireless RADIUS

Using this method, the User only enters their OTP (including a PIN if used). IDENTIKEY Server has to learn the static password for the User, so that when the User gives the correct OTP, it can send the static password to the RADIUS server.
This method can be used if: One of the supported protocols is used (see 3.9 Supported RADIUS Protocols for a list of supported RADIUS protocols)
23
Overview 2.5.4 Proxy Target: RADIUS Server Acts as Proxy

In this scenario, a RADIUS server acts as a proxy for authentication, effectively delegating the authentication process to IDENTIKEY Server. The RADIUS server provides the authorization attributes after IDENTIKEY Server has accepted the user credentials.
A RADIUS server can forward authentication to IDENTIKEY Server if: The RADIUS server supports the proxying of authentication while returning attributes itself The RADIUS server can forward the authentication request using one of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2 The RADIUS server supports an Access-Challenge response from IDENTIKEY Server, if required. The AccessChallenge mechanism is used for Challenge/Response and Virtual DIGIPASS, although it is still possible to use Virtual DIGIPASS without that mechanism. If the RADIUS server is capable, this scenario allows IDENTIKEY Server to operate in an environment that uses certificate-based EAP protocols such as PEAP and EAP-TTLS. To make this work, the RADIUS server decrypts the user credentials into a simpler protocol before forwarding the request to IDENTIKEY Server.
24
Overview 2.5.5 Intermediary: RADIUS Server as Back-End Server

In this scenario, IDENTIKEY Server will forward requests to a RADIUS server in order to retrieve authorization attributes, after validating the One Time Password. It is necessary to provide a static password to the RADIUS server to achieve this. Therefore, there are two methods of implementing this:
2.5.5.1 Log in with OTP Only
Using this method, the User only enters their OTP (including a PIN if used). IDENTIKEY Server has to learn the static password for the User, so that when the User gives the correct OTP, it can send the static password to the RADIUS server.
This method can be used if: One of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2 The static passwords can be 'learnt' by IDENTIKEY Server If PAP is used, IDENTIKEY Server has the ability to learn the static passwords automatically. The User has to perform at least one login with their static password if the RADIUS server accepts the password, IDENTIKEY Server can learn it. However, if one of the other password protocols is used, this process is not possible. In that case, there are a few other ways in which the passwords can be learnt, through administrative data entry or using the User SelfManagement Web Site.
25
Overview
2.5.5.2 Log in with Password and OTP
Using this method, the User enters their static password and OTP at each login. IDENTIKEY Server validates the OTP and if correct, forwards the static password to the RADIUS server.
This method can be used if: The PAP password protocol is used, because CHAP and MS-CHAP hash the password and OTP together inseparably
26
Overview
2.6
2.6.1
IDENTIKEY Server in a Web Environment

Soap Integration
IDENTIKEY Server has a SOAP module that can be used to integrate IDENTIKEY Server with web applications. The IDENTIKEY Server SOAP interface allows the following IDENTIKEY Server functions to be integrated into web applications: User Authentication Signature validation Software DIGIPASS Provisioning Administration Reporting
2.6.2
IIS Module
In an IIS Web environment, IDENTIKEY Server can also use a component that plugs into Internet Information Services (IIS) to intercept authentication requests. This component, the IIS Module, verifies the credentials with IDENTIKEY Server first. Normally this means verification of the One Time Password (OTP). If the OTP is valid, the static password is given back to IIS as if the user had entered it, and the normal web site authentication process completes the login. To enable verification by IDENTIKEY Server it is necessary to provide a static password, typically the Windows password, to IIS. Therefore, there are two methods of implementing this:
2.6.3
Log in with OTP only

Using this method, the User only enters their OTP (including a PIN if used). IDENTIKEY Server has to learn the static password for the User, so that when the User gives the correct OTP, it can give the static password back to IIS.
27
Overview
IDENTIKEY Server has the ability to learn the static passwords automatically if they are Windows passwords. The User has to perform at least one login with their static password if this password is validated by Windows, IDENTIKEY Server can learn it. The same process can also be used if the static passwords are held in a RADIUS server however, the IDENTIKEY Server license must have RADIUS support activated for this to be enabled. This process is not possible if the static passwords are not Windows or RADIUS passwords. In that case, administrative entry is required for the passwords.
28
Overview 2.6.4 Log in with Password and OTP

Using this method, the User enters their static password and OTP at each login. IDENTIKEY Server validates the OTP and if correct, returns just the static password to IIS.
This method may be necessary when the static passwords are not Windows passwords, for example they may be Novell passwords. It also may be suitable if you do not want IDENTIKEY Server to store your users' Windows passwords (although they are strongly encrypted).
2.7
2.7.1
Administration Components
Web Administration
A web-based administration application is provided with IDENTIKEY Server to enable administrators to carry out the majority of administration functions for the system. The Web Administration package allows administrators to perform tasks such as: Administer User accounts Administer DIGIPASS Define the organizational structure Manage Policies Create and run reports Manage Client components
29
Overview
Manage and Configure the IDENTIKEY Server The Web Administration application uses the IDENTIKEY Server's SOAP administration interface to manage data.
2.7.2
DIGIPASS Extension for Active Directory Users and Computers

An extension to Active Directory Users and Computers is available. This extension allows administration of DIGIPASS User accounts and DIGIPASS records where IDENTIKEY Server uses Active Directory as its data store.
2.7.3
The Audit System

The Audit System tracks operations carried out by IDENTIKEY Server, including RADIUS accounting information where required. Each operation generates audit messages that are written to either a text file or a database. Audit information can be used to generate reports, for example, the number of failed authentications over a certain period. Audit information can also be used by IDENTIKEY Server system administrators to monitor system performance, or suspicious activity.
2.7.3.1
The Audit Viewer
System administrators can use the Audit Viewer program to view Audit information. It allows System administrators to filter the audit information to make it easier to view and understand. The Audit Viewer also allows you to view audit information from different sources. Using the Audit Viewer information helps system administrators to troubleshoot effectively, and to keep track of significant events in the system.
2.7.4
Reporting
The Web Administration package contains a reporting module. This module contains the tools required to run a set of standard reports and to create and run custom reports. Reports may be based on User account and DIGIPASS data as well as audit data. Formatting templates can be used to convert the output into the preferred format, using XSLT.
2.7.5
DIGIPASS TCL Command-Line Administration

An extension to TCL is used for command-line administration tasks. The full power of TCL scripting can be used in order to automate bulk or regular administration tasks. A stand-alone TCL interpreter is also provided so that this functionality can be used where there is no TCL environment present already. The TCL extension uses the IDENTIKEY Server to manage the data store. It uses the SEAL protocol to communicate with the IDENTIKEY Server.
30
Overview 2.7.6 IDENTIKEY Server Configuration

The IDENTIKEY Server uses a local XML text file to store certain configuration settings. These can be managed using a graphical user interface program. There is also a Configuration Wizard program available to carry out certain maintenance tasks such as changing the IP address of the server.
31
Overview
2.8
IDENTIKEY Server Data Model

IDENTIKEY Server can use either an ODBC database (including the embedded PostgreSQL database) or Active Directory as its data store. The data model will vary slightly between ODBC and Active Directory stores. The following kinds of record are stored in the IDENTIKEY Server data store:
2.8.1
DIGIPASS record
A DIGIPASS record must exist in the data store for each DIGIPASS in use. This record contains: Information about the DIGIPASS (eg. serial number and model) The names and programming parameters of Applications in the DIGIPASS The status of various options (eg. DIGIPASS lock) Some of the information in this record is encrypted together in what is called the 'DIGIPASS Blob'. There is one 'Blob' per Application.
2.8.2
DIGIPASS User account record

Each User who will be logging in using DIGIPASS authentication will require a DIGIPASS User account. The DIGIPASS User account record contains information needed by IDENTIKEY Server such as authentication settings. A DIGIPASS must be assigned to a DIGIPASS User account before it can be used for authentication. Administrative privileges are assigned to DIGIPASS User accounts and therefore a DIGIPASS User account is needed for each administrator.
2.8.3
Component record
Component records are created to represent: IDENTIKEY Servers Authentication, Signature and Provisioning client components Administration client components They are used for the following main purposes: For clients, to indicate that it is permitted to process a request from that client and to specify a Policy (see below) to be used For RADIUS Clients, to hold the Shared Secret To hold a License Key for IDENTIKEY Servers and IIS Modules
2.8.4
Policy record
32
Overview
Policies specify various settings that affect the request handling processes. Each request is handled according to a Policy that is identified by the applicable Component record. There are many Policy settings including the following examples: Whether Local and/or Back-End authentication should be used Whether various automatic management features should be used The DIGIPASS Application types required Backup Virtual DIGIPASS settings
2.8.5
Back-End Server record

A Back-End Server record is required when a RADIUS or LDAP server is to be used by IDENTIKEY Server for authentication. It is possible to create more than one Back-End Server record, for fail-over purposes. You can also allocate different Back-End Servers for different user domains.
2.8.6
Domain record
Domains form the basis for the Organizational Structure in an ODBC database. Where IDENTIKEY Server uses Active Directory as its data store, the standard Active Directory Domains are used instead.
Active Directory
IDENTIKEY Server operates within the pre-existing Active Directory domain and Organizational Unit structure. Each DIGIPASS User and DIGIPASS must belong to a domain in Active Directory. User IDs must be unique within a domain, but may be repeated between domains. While DIGIPASS User account and DIGIPASS records can belong to any domain, a single domain is identified during installation as the DIGIPASS Configuration Domain. This domain is used to store the Component, Policy and BackEnd Server records. It is also used as a default domain for user lookup, when no domain is specified.
ODBC Database
Domains perform the following functions: allow different user groups to be separated provide the ability to limit administrator activities to the administrator's own domain (delegated administration) allocate unassigned DIGIPASS records to different Domains, for example to mirror the geographic location of the devices Each DIGIPASS User and DIGIPASS must belong to a domain. One domain is identified as the Master Domain this will be the default domain when none is specified. In addition, administrators in the Master Domain can be given rights to access data in all domains, where other administrators are limited to data in their own domain. User IDs must be unique within a domain, but may be repeated between domains. DIGIPASS serial numbers must
IDENTIKEY Server Product Guide 33
Overview
be unique in the database.
2.8.7
Organizational Unit record

Organizational Units, like Domains, are handled differently depending on whether the IDENTIKEY Server uses Active Directory or an ODBC database as its data store.
Active Directory
Where IDENTIKEY Server uses Active Directory as its data store, the standard Active Directory Organizational Units are used instead. DIGIPASS User accounts and DIGIPASS records are normally stored in Organizational Units or the Users container. A special container called DIGIPASS-Pool is created during installation to hold unassigned DIGIPASS, although they can be located in Organizational Units instead. Administration duties may be assigned to administrators per Organizational Unit, in the same way that regular user administration is delegated at that level.
ODBC Database
Where IDENTIKEY Server uses an ODBC database as its data store, Organizational Units allow further compartmentalisation of DIGIPASS User accounts, DIGIPASS records and administration duties. Organizational Units are included to: provide the ability to limit administrator activities to the administrator's own Organizational Unit (delegated administration) allocate unassigned DIGIPASS records to different Organizational Units, for example to mirror the geographic location of the devices DIGIPASS User accounts and DIGIPASS records may belong to an Organizational Unit, but this is not mandatory.
2.9
2.9.1
Integrating Your Systems With IDENTIKEY Server

SOAP Interfaces
SOAP interfaces are provided to support the following functions: User Authentication Signature Validation Software DIGIPASS Provisioning Administration Reporting
34
Overview
See the SDK documentation for more information.
2.9.2
RADIUS
RADIUS support is present for authentication (Access-Requests) using PAP, CHAP, MS-CHAP and MS-CHAP2. MPPE keys are generated for MS-CHAP and MS-CHAP2. IDENTIKEY Server can also handle accounting requests and return RADIUS attributes for authorization. However, IDENTIKEY Server does not act as an authorization server. An existing RADIUS server may be used as a Back-End System to allow dynamic creation of DIGIPASS User accounts and verification of static passwords, or to retrieve RADIUS attributes for a User.
2.9.3
Custom Back-End Integration

You can write your own plug-in Engine to attach IDENTIKEY Server to your own back end system. This would be used primarily as an authority to permit dynamic creation of user accounts in IDENTIKEY Server and for verification of static passwords. Refer to the SDK Overview Guide for further information.
2.9.4
Back-End Integration
There are a number of systems that can be used as Back-Ends to IDENTIKEY Server. These back-ends can be used as an authority on authentication data. Refer to 3.6 Back-End Authentication for further information.
35
Overview
2.10
2.10.1
SOAP SSL
What is SSL?
SSL stands for Secure Sockets Layer, which is a cryptographic protocol that provides secure communications over the Internet for e-mail, web browsing and, in this case, connection of two web-based applications via SOAP. SSL is the method by which a client can obtain a secure connection to a SSL-enabled server. The SSL-enabled server can identify itself to the client in a trusted manner before any information is passed between the client and the SSL-enabled server.
2.10.2
Terms Used in SSL

Some of the terms used in describing the function of SSL are specific to SSL and cryptography. Listed below are some of the terms used in this chapter, and what they mean: Handshake Procedure - The client machine and the SSL-enabled server establish a trusted and secure connection before any sensitive information is passed between them Certificate - The certificate in this context is an encrypted file attached to a message. Certificate Authority - a trusted third party used to issue the certificates. Each browser will have a list of trusted Certificate Authorities it can use to check against the signature on a certificate. Public Key - A key used to encrypt and decrypt information that is known to the SSL-enabled server and clients that use it. Private Key - A key known only to the SSL-enabled server that is used to decrypt information. Symmetrical Encryption - encryption that uses only one key to encrypt and decrypt information. Asymmetric Encryption - encryption that uses two keys to encrypt and decrypt information.
2.10.3
How Does SSL work?

1. 2. 3. 4. 5. A client initiates a connection using a handshake procedure. The client connects to an SSL-enabled server (the server), requesting a secure connection. The server sends back an encrypted certificate which usually contains the server name, the Certificate Authority and the server's public key. The client decrypts the certificate using the server's public key. The client checks the Certificate Authority against its browser's list of trusted Certificate Authorities. The client then encrypts a random number using the server's public key and sends this back to the server. This will be the secret that the client and server use to encrypt information passed between them. The server then decrypts the random number using the private key. The nature of the public and private keys is that information encrypted with the public key can only be decrypted by the private key.
36
Overview
6. Information encrypted using the generated secret is passed between the client and server.
If any part of the handshake procedure fails the whole handshake procedure will fail.
2.10.4
SSL, SOAP and IDENTIKEY Server

If you want to write SOAP interfaces for IDENTIKEY Server, the server side of SSL is mandatory. The SOAP client must utilize SSL to verify the server when attempting to connect. When setting up the SOAP Communication Protocol on the IDENTIKEY Server Configuration application, you can specify whether the client certificate is required: Never - the client certificate is never required. Optional - the client certificate is optional Required - The client certificate is required Required - Signed Address Only - The Server must include its IP address in the certificate. The client will match this IP address against that of the server it is connecting to. If they don't match the handshake will fail. Similarly, the client certificate must include the IP address of the client. The Server will check the IP address from the client certificate against the client it is establishing a connection with, and the handshake will fail if the two IP addresses don't match. The IDENTIKEY Server Configuration application provides a test SSL certificate. The test SSL certificate is time limited so it will expire after a period of time. When the test SSL certificate expires you can recreate it from the configuration application. Alternatively purchase an SSL certificate with a longer expiry period.
37
Overview
Image 15 : SSL handshake process The IDENTIKEY Server Configuration application SOAP Communication protocol page also contains a check box labelled Re-Verify on Re-Negotiation. Check this box to force the connection between SOAP and the IDENTIKEY Server to be re-verified each time a connection is established. Please note that this may cause problems with performance and so should not be checked unless absolutely necessary.
2.11
PCI-DSS Compliance
38
Overview
IDENTIKEY Server contains features which support the following PCI-DSS compliance requirements: Cryptographic Key Rotations Performance Monitoring PAN number not available/displayed in the clear Enhanced security for replicated data SEAL over SSL OWASP testing Unused User account check Report to show inactive DIGIPASS Password management imposing high strength passwords for Administrator passwords Secure Auditing
39
User Authentication Process
3
3.1

Logging in with a DIGIPASS
The diagram below shows a typical login process for the three basic login methods supported by IDENTIKEY Server.
Image 16 : Login Methods
40
3.2
Authentication Process Overview

IDENTIKEY Server Authenticates logins in two basic ways: Using information from its data store ('local' authentication) Asking a Back-End system for verification of information ('back-end' authentication) The exact authentication process used by IDENTIKEY Server will vary depending on settings in the applicable Policy and DIGIPASS User account. The diagram below shows the basic process followed when authenticating a DIGIPASS User login.
Image 17: Authentication Process Overview
41
3.3
Identifying the Component Record

The component making an authentication request will be identified using: Component Type A name provided by the SOAP application, or a fixed name such as RADIUS Client, Citrix Web Interface, Outlook Web Access or Administration Program Location the source IP address of the request The component lookup and verification processes are a little different according to the type of component, as outlined below.
3.3.1
RADIUS Client Component Check

For a RADIUS Client, the following component checks are made: Component Record exists A Component record for the RADIUS Client must exist, otherwise the request is discarded without responding: Type = RADIUS Client Location = the source IP address of the request OR if there is no RADIUS client at the specified location, Location = default Shared Secret is set The Component record must have a Shared Secret value set, otherwise the request is discarded without responding. Any RADIUS Client which does not have an explicit Component record will be handled using the default RADIUS Client Component if it exists.
3.3.2
IIS Module Component Check

For an IIS Module Component the following component checks are made: Component Record exists A Component record for the IIS module must exist, otherwise the request is discarded without responding: Type = IIS module Location = the source IP address of the request
42
3.4
DIGIPASS User Account Lookup and Checks

IDENTIKEY Server performs a number of checks before proceeding to local authentication.
3.4.1
User ID and Domain Resolution

In IDENTIKEY Server, DIGIPASS User accounts are identified using a User ID and a Domain, not just a User ID. There are a few ways to do this:
3.4.1.1
Windows Name Resolution
In Windows environments, there are a few ways to provide these details when logging in: Using NT4-style domain qualification in front of the User ID: DOMAIN\userid Using User-Principal-name (e.g. userid@domain) With separate User ID and Domain fields (this is not possible using RADIUS) When DIGIPASS User accounts correspond to Windows user accounts, the Windows Name Resolution feature can be used to support these three login formats. With ODBC or an embedded database, it is optional whether to user Windows Name Resolution or not. However, if the Windows Name Resolution process is enabled and fails, the login is rejected. Therefore, a login with a User ID that does not correspond to a Windows user account will be rejected. With this feature enabled, Windows is used to resolve the NT4-style and User-Principal-Name User ID formats. Windows Name Resolution is enabled using the IDENTIKEY Server Configuration program. Select Storage, and click on the Advanced Settings tab; under User ID Conversion check the Use Windows User Name Resolution checkbox.
3.4.1.2 Simple Name Resolution
When Windows Name Resolution is not used, the following formats are available: Using a similar format to User-Principal-Name: user@domain With separate User ID and Domain fields If the user@domain format is used for the User ID, the IDENTIKEY Server will look for a Domain record with the name given after the @. If the Domain is found, the @domain part will be stripped from the User ID before the authentication process continues. If it is not found, the User ID will be left as user@domain, and no Domain will be identified. In that case, the Default Domain processing will be used, as described next.
3.4.1.3 Default Domain
43

Using either Windows or Simple Name Resolution, if none of the above formats are used, only the User ID is given, with no Domain qualification. It is still necessary to identify the Domain in order to look up the DIGIPASS User account. The Default Domain can be configured in the following ways: In the Policy record, the Default Domain field can be set. If this is set, it will be used when no Domain has been identified by the Windows or Simple Name Resolution. When the Policy has no Default Domain set, the Master Domain will be used.
Note
When enabling Windows User Name Resolution in a Linux environment, the Defalut Domain must be specified.
3.4.1.4
Active Directory User Account
When Active Directory is used as the data store, DIGIPASS User accounts are always attached to Active Directory User accounts. Therefore, if an authentication request is received for a User who does not have an account in Active Directory, the request is rejected. This is not mandatory for an ODBC or embedded database.
44

3.4.1.5 Summary Active Directory
The full process of User ID and Domain name resolution is illustrated in the following diagram, for the case where Active Directory is the data store:
Image 18: Name Resolution with Active Directory
45

3.4.1.6 Summary ODBC Database
The full process of User ID and Domain name resolution is illustrated in the following diagram.
Image 19: Name Resolution with ODBC database
46
User Authentication Process 3.4.2 Windows Group Check (optional)

Specific Windows Groups can be selected for authentication by the IDENTIKEY Server when all Users are Windows accounts. This Windows Group Check feature might be used when: Deploying DIGIPASS in stages. Users are not required to log in using a DIGIPASS until they are put into a Windows group. They can be put into the group in manageable stages. Two-factor authentication is needed only for access to sensitive data, which has been granted to certain Users (for example, administrators). Only this group of people will require DIGIPASS, and will be authenticated by the IDENTIKEY Server. Other Users will be authenticated by another authentication method. Most Users will have DIGIPASS and be permitted to log in to the system, but some Users should not be authenticated under any circumstances. Authentication is needed for the live Audit Viewer connection to the IDENTIKEY Server, when using Active Directory as the data store. The Group Check can be used to limit which users are allowed to connect, for example to the Domain Admins group. When the Group Check is active, Users who are in one of the defined groups go through the full authentication process. However, there are a few Group Check Modes that control the outcome for Users who are not in one of the groups. The Group Check Mode is defined in the Policy. One or more Windows Group names must be defined in a Group List in the Policy. Group membership is checked within the User's own domain only, therefore these Groups must exist in each domain where there are Users who need to be included in a Group.
Important Note
When the Group Check is used, if the Group Check fails, the login will fail. This will occur for a user who is unknown to Windows. The following Group Check Modes are available:
3.4.2.1 'Pass Back' Mode
The full name in the Policy property sheet for this mode is: Pass requests for users not in listed groups back to host system The IDENTIKEY Server does not handle authentication for Users who are not in one of the defined groups. These Users are handled by the host system (eg. IIS). In effect, this means that they do not need to have DIGIPASS User accounts and they do not need to use a DIGIPASS to log on. As soon as the Group Check indicates that the User is not to be handled, authentication processing stops and the 'not handled' result is returned. This mode is suitable for staged deployment of DIGIPASS and for the case where only certain Users need strong (DIGIPASS) authentication.
47

3.4.2.2 'Reject' Mode
The full name in the Policy property sheet for this mode is: Reject requests for users not in listed groups The IDENTIKEY Server rejects authentication immediately for Users who are not in one of the defined groups. This mode is suitable for restricting which Users are permitted to log in.
3.4.2.3 'Back-End' Mode
The full name in the Policy property sheet for this mode is: Use only Back-End Authentication for users not in listed groups This mode can be used when Back-End Authentication is set up (see 3.6 Back-End Authentication). The IDENTIKEY Server will just use Back-End Authentication for Users who are not in one of the defined groups. For example, if RADIUS Back-End Authentication is used, the job of authenticating Users not in the defined groups is delegated to the RADIUS server. No lookup will be carried out for the DIGIPASS User account, and no further Local Authentication will be carried out. Back-End Authentication will be used for the out-of-group Users even if the Policy setting for Back-End Authentication is set to None. In that case, the in-group Users would be authenticated only by Local Authentication, while the out-of-group Users would be authenticated only by Back-End Authentication. However, it is necessary to define the Back-End Protocol Policy setting. This mode is suitable for staged deployment of DIGIPASS and for the case where only certain Users need strong (DIGIPASS) authentication.
3.4.3
DIGIPASS User Account Lookup

The IDENTIKEY Server checks that the User attempting to log in has a DIGIPASS User account in the IDENTIKEY Server data store. The User ID and Domain Resolution performed earlier determines the search criteria to look up the DIGIPASS User account. If a DIGIPASS User account is found, the Disabled and Locked indicators are checked. If either is set to Yes, the authentication request is rejected immediately. If no DIGIPASS User account is found, then Policy settings will determine whether the IDENTIKEY Server continues processing or rejects the authentication request: If Local Authentication is required, a DIGIPASS User account must exist. It is only possible to proceed if the Dynamic User Registration feature is enabled. This is explained further below. If Local Authentication is not required, authentication processing can proceed without a DIGIPASS User account. If the Local Authentication Policy setting is None, no Local Authentication is required. If it is set to
48

DIGIPASS/Password or DIGIPASS Only, Local Authentication is required.
3.4.4
DIGIPASS User Account Expiry

IDENTIKEY Server can be configured to force a DIGPASS User account to expire if it is not used for a specified amount of time. The number of days that a DIGIPASS User Account can remain unused before expiring can be configured on the policy used to log in. This value will be checked and the number of days since the last log in will be calculated. If the DIGIPASS User Account has been unused for too long, log in will be denied.
3.4.5
Accepted Domain
An accepted domain can be defined,on the component policy (3.3 Component Record) to restrict the domain that Users can use to log in with. See 3.4.1 User ID and Domain Resolution for information about how the domain is determined. The User's domain is compared to the defined Accepted Domain, and if they do not match, then access is denied. This facility can be used in conjunction with the default domain (3.4.1.3 Default Domain).
3.4.6
Dynamic User Registration

Dynamic User Registration (DUR) allows DIGIPASS User accounts to be created automatically when their credentials are validated by Back-End Authentication. The correct static password will be sufficient to permit a DIGIPASS User account to be created. DUR saves the administrative work of manually creating or importing DIGIPASS User accounts. It is typically used in conjunction with: the DIGIPASS Auto-Assignment feature, which will assign the next available DIGIPASS to the new DIGIPASS User account as it is created, or the DIGIPASS Self-Assignment feature, which will allow the new User to assign a DIGIPASS to their account as part of their login process For more details on these DIGIPASS assignment features, see 11 DIGIPASS. In order to control the creation of new accounts, DUR can be used with: the Windows Name Resolution feature (mandatory for Active Directory). This will prevent more than one DIGIPASS User account being created for the same Windows User account, when they use different User ID formats to log in the Windows Group Check feature, so that a staged creation of DIGIPASS User accounts and assignment of DIGIPASS is achieved A typical DUR process using Auto-Assignment and the Windows Group Check is illustrated below.
49
Image 20 - Dynamic User Registration Process
50
3.5
Local Authentication
Local Authentication is a term used to describe the IDENTIKEY Server authenticating a User based on information in its data store. Typically the DIGIPASS One Time Password is required, but in other cases a static password may be sufficient. The Local Authentication Policy setting indicates whether to perform Local Authentication, and if so, whether a static password is permitted. This setting is overridden by the same setting in the DIGIPASS User account, unless that has the value Default. However, this setting in the DIGIPASS User account would typically be used only for rare special case Users. Using the Windows Group Check in Back-End Mode, this setting can be overridden. If a User is not in the list of groups, no Local Authentication will be performed. The possible values for the Local Authentication setting are as follows:
None
No Local Authentication will take place.
DIGIPASS/Password
A DIGIPASS One Time Password or static password may be verified. As a general rule, until a User starts to use a DIGIPASS, they may continue to authenticate with their static password.
DIGIPASS Only
A DIGIPASS One Time Password must be verified. Users without DIGIPASS will not be able to log in. However, SelfAssignment is still possible, as an OTP is used as part of the process.
3.5.1
DIGIPASS Lookup
The first step of Local Authentication is to search for DIGIPASS records applicable to the login. Normally, this is a simple search for all DIGIPASS assigned to the DIGIPASS User account. However, there are exceptions:
3.5.1.1
No DIGIPASS User Account
If there is no DIGIPASS User account, no search will be done. This can occur if Dynamic User Registration is enabled.
3.5.1.2 Policy Restrictions
The Policy can specify restrictions on which types of DIGIPASS and/or DIGIPASS Applications may be used. Any combination of the following restrictions can be defined:
51

Application Names - a list of named Applications. Only DIGIPASS that have one or more of the named Applications will be usable. Application Type - either Response Only, Challenge/Response or Multi-Mode. Only DIGIPASS with that Application Type will be usable, except Multi-Mode will match all application types. DIGIPASS Type - a list of models such as DPGO3, DP260. Only DIGIPASS from the listed models will be usable. Therefore, it is possible that a DIGIPASS User account that has a DIGIPASS assigned is not able to use that DIGIPASS to log in, when a certain Policy applies. They will be regarded as a User without a DIGIPASS in that case. In a different kind of login, a different Policy may apply, with no restrictions. Then they would be treated as a User with a DIGIPASS. For example, a company has Go 3 DIGIPASS (DPGO3) and Primary Virtual DIGIPASS (DPVTL). The Outlook Web Access login permits both, so its Policy does not restrict DIGIPASS Types. However the RADIUS VPN login requires the Go 3, so its Policy specifies DIGIPASS Type = DPGO3.
3.5.1.3 Linked User Accounts
If a person has two DIGIPASS User accounts, for example an administrative account and a 'normal user' account, the two accounts can be linked together. This provides the ability for the two accounts to share a DIGIPASS. The DIGIPASS is assigned to one of the accounts, then the other account is linked to it. When an authenticating DIGIPASS user account is linked to another, the search for DIGIPASS will be done for the other account. For example, DIGIPASS User account 2 is linked to DIGIPASS User account 1. The DIGIPASS is assigned to DIGIPASS User account 1. When DIGIPASS User account 1 logs in, the DIGIPASS search is for that account. When DIGIPASS User account 2 logs in however, the DIGIPASS search is for DIGIPASS User account 1.
52
User Authentication Process 3.5.2 Authentication with DIGIPASS

When the DIGIPASS lookup returns at least one DIGIPASS record, authentication processing requires a valid One Time Password to succeed, unless: All DIGIPASS found are within a Grace Period. This feature is described below. The User successfully requests a Challenge for Challenge/Response (see below). The User successfully requests a Virtual DIGIPASS One Time Password (see below).
3.5.2.1 Server PIN
A Server PIN may be required in addition to the One Time Password. The Server PIN is entered during login with the OTP - instead of a DIGIPASS PIN, which is entered into the DIGIPASS device. In some cases a new Server PIN may need to be set. This gives the following permutations: OTP - the normal login where a Server PIN is not required. PINOTP - the normal login where a Server PIN is required. PINOTPnewpinnewpin - to change the Server PIN, the new PIN is put twice after the OTP. OTPnewpinnewpin - to set the Server PIN on first use, when no initial PIN was programmed, the new PIN is put twice after the OTP. This is also necessary after an administrative PIN reset.
Server PIN States

The following diagram illustrates the different server PIN states and which user/administrator actions result in each one:
Image 21: Server PIN States and actions
53
When a server pin is in the PIN SET CHANGE FORCED state, its corresponding user is forced to change PINs upon login. Once the user changes the PIN (user action PINOTPnewpinnewpin), the server PIN state changes to PIN SET. For more information on other user and administrator actions that affect server PIN states, refer to 11.3 DIGIPASS Record Functions.
54

3.5.2.2 Grace Period
Each DIGIPASS may be given a Grace Period when it is assigned to a DIGIPASS User account. The Grace Period is there to allow some time before the User receives the DIGIPASS and learns how to use it. The first time that the User logs in successfully with their DIGIPASS, the Grace Period is ended. After that, they have to continue to use the DIGIPASS. The Grace Period is time limited, so that the User is not able to delay too long before they start to use the DIGIPASS. The Grace Period can be set during manual administrative assignment of DIGIPASS as well as during AutoAssignment. However, it is not applicable to Self-Assignment, because the User must use the DIGIPASS to complete the Self-Assignment process. The Grace Period cannot apply when the Local Authentication setting is DIGIPASS Only. During the Grace Period, if OTP validation fails, the static password is checked. If the static password is valid, Local Authentication succeeds (but note that Back-End Authentication, if used, can subsequently still cause the overall login to fail). The password is compared against the DIGIPASS User account's password value. However, if the DIGIPASS User account does not have a password set, the password has to be verified with Back-End Authentication. If there is no Back-End Authentication and no password in the DIGIPASS User account, Grace Period password logins will not work. If the passwords do not match and Back-End Authentication is enabled, the password will be verified with BackEnd Authentication.
3.5.2.3 Challenge Generation
There are two modes of Challenge generation for Challenge/Response: 2-Step Challenge/Response This mode can be used for Web authentication, where Challenge/Response is supported. In this mode, the authentication process takes place in two steps. First, the User requests a Challenge to be generated for them. The Policy defines how this request should be made, with the Request Method and Request Keyword settings (see below for more details on Request Methods). The Challenge is generated specifically for their DIGIPASS, according to its programming. Assuming that the request for the Challenge is accepted and a Challenge is returned, the User submits a second step login with the Response to the Challenge as their OTP. This second step goes through the whole authentication process again to verify the Response. 1-Step Challenge/Response This mode is also possible for Web authentication, where Challenge/Response is supported. In this mode, the User sees only one logon step. This mode is suitable for time-based Challenge/Response, but is less secure for nontime based Challenge/Response. If an attacker manages to capture some valid Responses, they can repeatedly request new Challenges until one they know comes up again.

A random Challenge is requested automatically by the Web Application and presented to the User on the login page. A general-purpose Challenge is generated, without reference to any particular DIGIPASS' programming. The User logs in with their Response to the Challenge as their OTP.
3.5.2.4 Virtual DIGIPASS OTP Generation
Using Virtual DIGIPASS, the authentication process takes place in two steps. First, the User requests an OTP to be generated and delivered to them. The Policy defines how this request should be made, with the Request Method and Request Keyword settings (see below for more details on Request Methods), and the delivery method SMS or email. The OTP is generated specifically for their DIGIPASS, according to its programming. It is sent to their mobile phone number or email address recorded in the DIGIPASS User account. Backup Virtual DIGIPASS have additional available restrictions on usage, to minimise the cost of usage. These are verified before an OTP will be generated. The restrictions are described in 11 DIGIPASS. Assuming that the request for the OTP is accepted and an OTP is generated and delivered successfully, the User submits a second step login with the OTP. This second step goes through the whole authentication process again to verify the OTP. This process is illustrated below:
Image 22: Virtual DIGIPASS Login
56
3.5.2.5
Requesting a Virtual DIGIPASS OTP - User Perspective
There are three ways a User might request a One Time Password to be delivered with either a Primary or Backup Virtual DIGIPASS:
2-step Login
Two login prompts are used to provide an easy-to-use login interface for Users with Virtual DIGIPASS. The first prompt is used to request an OTP, the second to enter the received OTP. This can be used with applications which support 2-step logins eg. Citrix Web Interface, RADIUS with support for Challenge/Response.
Two 1-step Logins

The User must attempt two logins, the first of which will fail but will initiate the sending of an OTP to the User. This is used when the 2-step login process is not supported - eg. RADIUS without support for Challenge/Response, Web HTTP Basic Authentication.
57
User Authentication Process OTP Request Site

Alternatively - especially if a more user-friendly option than the previous is needed - Users can go to the OTP Request site when they need an OTP sent, then login normally at the usual login screen.
3.5.2.6 Request Method and Keyword
For 2-Step Challenge/Response and Virtual DIGIPASS, the method of requesting a Challenge or OTP respectively can be defined in the Policy. The methods for Primary Virtual DIGIPASS and Backup Virtual DIGIPASS are defined separately. The request methods are: Password - the static password. Keyword - a fixed keyword, which can be blank. PasswordKeyword - the static password followed by a fixed keyword, with no whitespace or separating characters inbetween. KeywordPassword - a fixed keyword followed by the static password, with no whitespace or separating characters inbetween. None - no method, the feature is disabled.
Note
If Password is set for the Request Method, and a User's DIGIPASS is still within the Grace Period, IDENTIKEY Server may process the authentication with the password only and not as a 2-Step Challenge/Response or Virtual DIGIPASS login. The static password in the request method is compared against the DIGIPASS User account's password value. However, if the DIGIPASS User account does not have a password set, the password has to be verified with BackEnd Authentication. If there is no Back-End Authentication and no password in the DIGIPASS User account, the request methods that use a password will not work. If the passwords do not match and Back-End Authentication is enabled, the password will be verified with BackEnd Authentication. The methods of requesting these three login processes can be the same. When it recognizes a request, the IDENTIKEY Server will verify that there is a DIGIPASS capable of that login process. If there is not, it will ignore the request. For example, say that the request methods for Primary and Backup Virtual DIGIPASS are both defined as keyword otp. A User has a Go 3 with Backup Virtual DIGIPASS enabled. When they login with the keyword otp, the IDENTIKEY Server will produce a Backup Virtual DIGIPASS OTP, because the User does not have a Primary Virtual DIGIPASS.
3.5.2.7 Multiple DIGIPASS or DIGIPASS Applications
58

A DIGIPASS User may have multiple DIGIPASS assigned to their User account, and/or multiple Applications enabled for a DIGIPASS. If so, the IDENTIKEY Server will need to know: 1. Whether a user is allowed to have multiple DIGIPASS applications assigned. 2. Which DIGIPASS and DIGIPASS Application will be used for a particular login of the User. The following diagram illustrates an example of how DIGIPASS tokens and applications can be assigned.
Image 23: Multiple DIGIPASS Assignment
In IDENTIKEY Server 3.3, you can now configure whether to allow the use of multiple DIGIPASS applications per user. By default, this setting is enabled. Aside from configuring whether multiple DIGIPASS applications per user is allowed, you can also restrict which DIGIPASS application is allowed for a specific policy. With this kind of restriction, IDENTIKEY Server will only verify OTP against that type of DIGIPASS application. So if a policy restricts allowed DIGIPASS applications to ResponseOnly, then IDENTIKEY Server will verify all OTP only against RO applications assigned to a user. When considering whether to allow multiple DIGIPASS applications per user and/or which DIGIPASS applications to allow, consider the following table (refer to Image 23: Multiple DIGIPASS Assignment for DIGIPASS assignments).
59

This table explains how IDENTIKEY Server authenticates OTP from each DIGIPASS user accounts, given four possible scenarios: Scenarios
Multiple DIGIPASS applications allowed, no Policy restrictions on DIGIPASS applications Multiple DIGIPASS applications allowed, only RO applications allowed Single DIGIPASS applications allowed, no Policy restrictions on DIGIPASS applications Single DIGIPASS applications allowed, only RO applications allowed
DIGIPASS User Acct 1

OTP is authenticated against all DIGIPASS applications from assigned DIGIPASS tokens

OTP is authenticated against all DIGIPASS applications from assigned DIGIPASS token

OTP is authenticated against DIGIPASS application from assigned DIGIPASS token
OTP is authenticated only against OTP is authenticated only against OTP is authenticated against application1 of both assigned application 1 of assigned application 1 of assigned DIGIPASS tokens DIGIPASS token DIGIPASS token IDENTIKEY Server detects multiple DIGIPASS applications assigned and immediately fails the login attempt IDENTIKEY Server detects multiple RO DIGIPASS applications assigned and immediately fails the login attempt IDENTIKEY Server detects multiple OTP is authenticated against DIGIPASS applications assigned DIGIPASS application from and immediately fails the login assigned DIGIPASS token attempt IDENTIKEY Server detects one RO OTP is authenticated against DIGIPASS applications assigned, DIGIPASS application from and authenticates OTP against assigned DIGIPASS token. this application.
Grace Period
A Grace Period may be applied to each DIGIPASS assigned to a DIGIPASS User. Because an applied Policy might restrict which DIGIPASS can be used during a login, the Grace Period on each DIGIPASS is independent of other DIGIPASS. This means that if a User is assigned two DIGIPASS, each with a Grace Period of seven days, the User may log in using one DIGIPASS within the seven-day period (ending the Grace Period for that DIGIPASS) without affecting the Grace Period for the other DIGIPASS.
Example
The company has set up Policies which require a Response Only login via the local area network, and a Challenge/Response login via the internet limited to certain employees. John has two DIGIPASS assigned to him a DP300 with the Challenge/Response application enabled, and a Go 3 with a Response Only application. The DIGIPASS are both assigned on Tuesday. John receives his Go 3 on Friday, and immediately uses an OTP to login. His grace period for the Go 3 ends at that time in future he must use the Go 3 when logging into the intranet from the LAN. Over the weekend, John needs to access the company intranet from home. Because a Challenge/Response login is required via the internet and he does not yet have his DP300, he uses only his User ID and static password to log in. As he is still within the grace period for the DP300, the login is valid.
3.5.3
Authentication without DIGIPASS

When the DIGIPASS lookup does not return a DIGIPASS record, authentication processing requires a static password check to succeed. In addition, Self-Assignment is possible when the DIGIPASS lookup does not return
60

any DIGIPASS.
3.5.3.1 Static Password Verification
The password is compared against the DIGIPASS User account's password value. If the static password is valid, Local Authentication succeeds (but note that Back-End Authentication, if used, can subsequently still cause the overall login to fail). However, if the DIGIPASS User account does not have a password set, the password has to be verified with BackEnd Authentication. If there is no Back-End Authentication and no password in the DIGIPASS User account, authentication without DIGIPASS cannot work. Similarly, during Dynamic User Registration, where there is no DIGIPASS User account yet, the password has to be verified with Back-End Authentication. If the passwords do not match and Back-End Authentication is enabled, the password will be verified with BackEnd Authentication. If the Local Authentication setting is DIGIPASS Only, static password verification on its own is not permitted. An OTP must be used during login. This is possible using Self-Assignment.
3.5.3.2 Self-Assignment
A User is able to assign a DIGIPASS to their DIGIPASS User account using the Self-Assignment mechanism, when permitted by the Policy settings. The Assignment Mode setting must be Self-Assignment. In order for Self-Assignment to succeed, the User needs to provide the following: A static password, validated by Back-End Authentication. The Serial Number of an available DIGIPASS record. A valid OTP for the DIGIPASS. A new Server PIN, if required. The Self-Assignment process is possible during Dynamic User Registration. It is also possible when the Local Authentication setting is DIGIPASS Only.
Response Only
For a DIGIPASS that supports Response Only, the User needs to enter the following in the password login field, depending on whether a Server PIN is needed or not: SERIALNUMBERpasswordOTP where a Server PIN is not required. SERIALNUMBERpasswordPINOTP where a Server PIN is required. SERIALNUMBERpasswordOTPnewpinnewpin where a Server PIN is required and no initial PIN was set.
Challenge/Response
For a DIGIPASS that supports only Challenge/Response, this process requires two steps. In the first step, the static

password and Serial Number are given. This results in a Challenge being returned. If the correct Response is given to the Challenge, the Self-Assignment is successful. Step 1: SERIALNUMBERpassword Step 2: OTP
Serial Number Format

The SERIALNUMBER may be entered in one of two formats, depending on the Serial No. Separator Policy setting. No separator specified the full 10 digit Serial Number must be entered, with no dashes (-) or spaces, for example 0097123456. Separator value specified the Serial Number can be entered as written on the back of the DIGIPASS, for example 9-712345-6.
62
3.6
Back-End Authentication
Back-End Authentication is a term used to describe the process of checking User credentials with another system. It is used primarily for: Enabling automatic management features such as Dynamic User Registration and Self-Assignment Static password verification for Users who do not have a DIGIPASS and for Virtual DIGIPASS Retrieval of RADIUS attributes from a RADIUS server Password Replacement - allowing the User to log in with just a One Time Password, in an environment where the Windows password is required (eg. Outlook Web Access) IDENTIKEY Server supports Back-End Authentication with the following systems: Windows Microsoft Active Directory Microsoft ADAM Novell e-Directory RADIUS Tivoli Custom solution (requires SDK) An IDENTIKEY Server can authenticate Windows Users via Windows or LDAP Active Directory Back-End Authentication. Windows Back-End Authentication should be used where the IDENTIKEY Server is installed on a Windows machine which is a member server of the Windows domain. LDAP Back-End Authentication may be used where the machine on which it is installed is either not a member server of the Windows domain, or running a Linux operating system. The Back-End Authentication Policy setting indicates whether to perform Back-End Authentication, and if so, when to do it. This setting is overridden by the same setting in the DIGIPASS User account, unless that has the value Default. However, this setting in the DIGIPASS User account would typically be used only for rare special case Users. Using the Windows Group Check in Back-End Mode, this setting can be overridden. If a User is not in the list of groups, Back-End Authentication will be performed whether it is enabled or not. The Back-End Protocol setting indicates which type of Back-End Authentication is to be used. The possible values for the Back-End Authentication setting are as follows: None The IDENTIKEY Server will not utilize Back-End Authentication. Always The IDENTIKEY Server will use Back-End Authentication for every authentication request.
63

If Needed Back-End Authentication will only be used in situations where Local Authentication is not sufficient and to support certain features: Dynamic User Registration Self-Assignment Password Autolearn (see below) Requesting a Challenge or Virtual DIGIPASS OTP, when the Request Method includes a Password Static password authentication, when verifying a Virtual DIGIPASS password-OTP combination or during the Grace Period
3.6.1
Stored Static Password

The DIGIPASS User account has a Stored Static Password field. When Back-End Authentication is used, this field can be used: To store the static password required for Back-End Authentication. This means that the User does not need to type in the static password at each login, they only need enter the OTP. The IDENTIKEY Server can retrieve the Stored Static Password from the DIGIPASS User account and use it for Back-End Authentication. To support Password Replacement. Back-End Authentication is used to learn the static password so that it can be replayed to the host system (eg. Outlook Web Access) when a successful OTP is given. Two product features are used to support this usage of the Stored Static Password: Stored Password Proxy and Password Autolearn.
3.6.2
Stored Password Proxy

When the Stored Password Proxy setting is enabled in the Policy, the IDENTIKEY Server will retrieve the Stored Static Password from the DIGIPASS User account. If Back-End Authentication is required for a login, the Stored Static Password will be used. If there is a host system (eg. Outlook Web Access), the Stored Static Password will be returned to it, for it to complete its login process. However, if the User enters a static password in front of their OTP, the static password they enter will take precedence over Stored Static Password. In that case, the Stored Static Password will not be used at all for that login. When the Stored Password Proxy setting is not enabled in the Policy, the Stored Static Password will not be used for Back-End Authentication. If Back-End Authentication is required for a login, the User will have to enter the static password. This is done in front of the OTP if an OTP is also used. Similarly, if there is a host system that requires a static password to be returned, the User will have to enter the static password.
64
User Authentication Process 3.6.3 Password Autolearn

When the Password Autolearn feature is enabled in the Policy, the IDENTIKEY Server will automatically store the static password when it is verified by Back-End Authentication. This can happen at any time from Dynamic User Registration onwards. If the User's static password has changed in the Back-End Authentication system, they will need to provide the new static password during their next login. This is done in front of the OTP if an OTP is used. When the IDENTIKEY Server sees that the User has entered a static password, if it does not match the Stored Static Password already, Back-End Authentication will occur to verify the new password. If it is verified, the Stored Static Password will be updated.
3.6.4
Back-End Server Records

A Back-End Server record is required for RADIUS and LDAP-based Back-End authentications. It contains connection information for the system to be used. Typically, only one Back-End Server record will be required for LDAP Back-End Authentication, whereas RADIUS Back-End Authentication will require a record per RADIUS Server to be used.
3.6.4.1
Fail-over Strategy
Each Back-End Server record is assigned a Priority. This comes into effect when multiple Back-End Servers are available, and the IDENTIKEY Server must decide which to use for a Back-End Authentication request. It will attempt to connect to the Back-End Server with the highest Priority rating. If it is not available after the set No. of Retries, the IDENTIKEY Server will attempt to connect to the Back-End Server with the next-highest Priority rating. If the IDENTIKEY Server repeatedly fails to get a response from a Back-End Server, it will ignore it for some minutes before trying it again. Therefore, a temporary slow response will not prevent the IDENTIKEY Server from using a Back-End Server. But a consistent availability problem will cause it to stop using the Back-End Server for a while, when it has an alternative.
3.6.4.2 Domain-Specific Back-End Servers
Back-End Server records may be configured for use with a specific Domain. This may be useful when multiple Back-End servers exist with different groups of User records on each. When the IDENTIKEY Server has to choose a Back-End Server, it will search for those records in the Domain identified by the User ID and Name Resolution process. If any are found, it will only use those Back-End Servers for that Domain. If none are found, it will use the Back-End Servers that are not assigned to a Domain.
65
User Authentication Process 3.6.5 RADIUS Back-End Authentication

IDENTIKEY Server can pass RADIUS return attributes from the Back-End server to the client. Back-End Authentication is supported with the following protocols: PAP CHAP MS-CHAP MS-CHAP2 with MPPE key generation
3.6.6
Microsoft Active Directory Back-End Authentication using LDAP protocol
Note
For instructions on setting up a Back-End Server record for an Active Directory server, see the Administration Web Interface online help.
Note
The Active Directory back end may be configured to authenticate Active Directory users via an instance of ADAM that has been installed on the domain controller, with the condition that the user's IDENTIKEY Server domain and Active Directory domain have the same name. The ADAM instance will automatically delegate authentication to Active Directory The steps in Back-End Authentication for Active Directory are: 1. Identify the Active Directory server based on the Active Directory Back-End entries in IDENTIKEY Server. If no Active Directory Back-End entries have been defined in IDENTIKEY Server then an attempt will be made to identify the Active Directory Domain Controller using the Global Catalog. Bind to Active Directory using the security principal ID and password defined for the Active Directory backend if principal details specified. The format for the Security Principal ID is as follows: If this is an encrypted connection, the format of the Security Principal ID will be the DN. For example, cn=Administrator, cn=User, dc=vasco,dc=com If this is not an encrypted connection, the format of the Security Principal ID is the sAM Account Name. For example, administrator 3. Search Active Directory for the attributes of the user that has to be authenticated.
2.
66

4. IDENTIKEY Server will bind to the directory server that handles the authentication request. It will use the UserID and the password specified in the authentication request received by the IDENTIKEY Server. If the bind succeeds, the user authentication is deemed to be successful. If the bind fails, the authentication is deemed to have failed.
If authentication fails, the attributes retrieved during the search will be used to determine the cause of the failure.
Note
IDENTIKEY Server only supports SASL.Digest-MD5 binding as the client authentication mechanism for binding with the supported Back-End authentication servers.
67
Image 24: The steps in Back-End Authentication for Active Directory
3.6.7
Novell e-Directory Back End Authentication using LDAP protocol
Note
68
For instructions on setting up a Back-End Server record for an e-Directory server, see the Administration Web Interface online help. The steps in Back-End Authentication for Novell eDirectory are: 1. 2. 3. 4. Identify the eDirectory server based on the eDirectory Back-End entries in IDENTIKEY Server. Bind to eDirectory using the security principal DN and password defined for the eDirectory back-end if principal details specified. Search eDirectory for the FQDN and attributes of the user that has to be authenticated (starting from the Base Search DN). Try to authenthicate with eDirectory using a bind with the FQDN and password of the user to be authenticated.
Note
69
Image 25: The steps in Back-End Authentication for Novell eDirectory and ADAM
70
User Authentication Process 3.6.8 ADAM Back End Authentication using LDAP protocol
Note
For instructions on setting up a Back-End Server record for an ADAM server, see the Administration Web Interface online help. The steps in Back-End Authentication for ADAM are: 1. 2. 3. 4. Identify the ADAM server based on the ADAM Back-End entries in IDENTIKEY Server. Bind to ADAM using the security principal DN and password defined for the ADAM back-end if principal details specified. Search ADAM for the FQDN and attributes of the user that has to be authenticated (starting from the Base Search DN). Try to authenthicate with ADAM using a bind with the FQDN and password of the user to be authenticated.
Note
71
User Authentication Process 3.6.9 Tivoli Back End Authentication using LDAP protocol
Note
For instructions on setting up a Back-End Server record for an Tivoli server, see the Administration Web Interface online help. The steps in Back-End Authentication for Tivoli are: 1. 2. 3. 4. Identify the Tivoli server based on the Tivoli Back-End entries in IDENTIKEY Server. Bind to Tivoli using the security principal DN and password defined for the Tivoli back-end if principal details specified. Search Tivoli for the User to be authenticated based on the User Object Class Name and the User ID Attribute Name defined on setup. Try to authenticate with Tivoli using a bind with the User ID and password of the user to be authenticated.
Note
IDENTIKEY Server only supports Simple binding with SSL as the client authentication mechanism for binding with the supported Tivoli servers.
72
3.7
User Attributes
User attributes are used by IDENTIKEY Server to return specific information to a Client Component. There are two types of user attributes available in IDENTIKEY Server: RADIUS attributes can be returned when handling authentication requests from a RADIUS Client. Custom user attributes can be returned to IIS Modules, DIGIPASS Plug-Ins and custom web applications User attributes may be set for each DIGIPASS User individually, or to a group of DIGIPASS Users. For instructions on adding User attributes to one or more DIGIPASS User accounts, see the Administration Web Interface Help.
3.7.1
RADIUS Attribute Settings

RADIUS Reply attributes can be returned with an Access-Accept when handling authentication requests from a RADIUS Client. The attributes may include authentication parameters or authorization settings.
Image 26: RADIUS Attributes Overview
Acceptable RADIUS Attribute names for use with IDENTIKEY Server are contained in a text file. The default dictionary file provided with IDENTIKEY Server is named radius.dct and located in either <IK install-dir>\bin (Windows) or /etc/identikey (Linux). It may be edited or replaced, if required, to allow more or less RADIUS attributes to be used.
73
User Authentication Process Attribute Group

For RADIUS attributes, one or more Attribute Groups are specified in the Policy used for the specific Client. When multiple Client Components require RADIUS reply attributes, the specified Attribute Group ensures that only attributes required by the specific RADIUS Client are sent.
Name
The name of the RADIUS attribute. This must conform to a RADIUS attribute name specified in the RADIUS dictionary in use. If an attribute is to be returned multiple times in one transaction with different values, it needs to be added to the attribute group the required number of times
Usage
Not currently in use for RADIUS attributes.
Value
The required value of the RADIUS attribute.
3.7.2
Custom User Attribute Settings

Custom attributes can be used with VASCO's Plug-Ins and IIS Modules.
Image 27: Custom User Attributes Overview
Attribute Group
An Attribute Group is specified by the Client Component as a parameter in the authentication request. When multiple Client Components are using custom user attributes, the specified Attribute Group ensures that only attributes required by the specific Client are returned.
Name
A name for the attribute as expected by the Client Component.
74
User Authentication Process Usage

Basic indicates that the attribute is for use by the IIS 6 Module for Basic Authentication. Return indicates an SBR return attribute Check indicates an SBR check attribute
Value
The required value of the named attribute.
3.8
Host Code Generation

If the Client Component requests a Host Code and the DIGIPASS is capable of generating one then IDENTIKEY Server will generate a Host Code and the application will display it to the User. The User generates a Host Code on their DIGIPASS and checks that it is the same as the one on the screen. Host Code generation is passed as a parameter in the authentication request. There are two options: Optional - only return a Host Code if the DIGIPASS is Host Code capable Required - DIGIPASS must be Host Code capable or the request will fail.
75
3.9
Supported RADIUS Protocols

The following protocols are supported by IDENTIKEY Server: PAP CHAP MS-CHAP with MPPE (Microsoft Point-to-Point Encryption) MS-CHAP2 with MPPE EAP-TTLSv0/PAP EAP-TTLSv0/CHAP EAP-TTLSv0/MS-CHAP EAP-TTLSv0/MS-CHAPv2 EAP-TTLSv0/EAP-MS-CHAPv2 EAP-TTLSv0/EAP-GTC PEAPv0/EAP-MS-CHAPv2 PEAPv0/EAP-GTC PEAPv1/EAP-MS-CHAPv2 PEAPv1/EAP-GTC Some protocols do not support all authentication features of IDENTIKEY Server. See 3.10 Unsupported by IDENTIKEY Server and the Login Permutations section of the Administrator Reference for more information.
76
3.10
3.10.1
Unsupported by IDENTIKEY Server

Limitations of RADIUS Password Protocols
Some features of the IDENTIKEY Server are not supported with CHAP or MS-CHAP. These protocols hash login data together, making separation of various entries impossible. The unsupported features are outlined below: Self-Assignment of DIGIPASS cannot be performed. The Server PIN cannot be changed. Challenge/Response is not supported. Windows Back-End Authentication is not supported unless the User ID and Windows password are manually stored, and Stored Password Proxy is enabled. Password Autolearn is not supported, as clear text passwords cannot be identified. The User Self-Management Web Site, when utilized, can circumvent many of these problems by allowing Users to manage their account and DIGIPASS. It uses RADIUS with the PAP password protocol. Users can: Perform Self-Assignment Change their Server PIN Change their own Stored Static Password
3.10.2
Unsupported RADIUS Password Protocols

MS-CHAP with LM Hash The password change mechanism for MS-CHAP and MS-CHAP2
3.10.3
Limitations of International Character Support

A number of IDENTIKEY Server components provide international character support, and some limitations apply: Database International character support in the database is dependent on the individual database driver. See the Encoding and Case Sensitivity topic in the Administrator Reference for more information. RADIUS International character support in the IDENTIKEY Server using the RADIUS protocol is dependent on the RADIUS Client(s) being used. If a RADIUS Client uses UTF-8 encoding, international characters will be fully supported. If a RADIUS Client uses a localized encoding (eg. ISO-8859-13), the same locale setting must be configured on each machine.
77

Web DIGIPASS Authentication for OWA, both Forms and Basic Authentication options, limit international character support to a single configured encoding. See the Guide for the specific IIS Module for more information. DPADMINCMD DPADMINCMD supports international characters, but your console window must be able to support the characters or they will not display correctly.
3.10.4
Limitations of Web Basic Authentication

Some features of the IDENTIKEY Server are not supported with the HTTP Basic Authentication mechanism. This mechanism does not support a 2-step login process. The unsupported features are outlined below: Challenge/Response is not supported.
78
Signature Validation Process
4
4.1

Signing a Transaction
IDENTIKEY Server will allow you to sign transaction data using a DIGIPASS that is set up to generate digital signatures. A digital signature is based on transaction details entered into the DIGIPASS. The DIGIPASS uses the transaction details and an embedded secret to generate a signature, which is typically entered into a confirmation page to proceed with the transaction. This signature will be validated by the server if it is incorrect the transaction will not be permitted to proceed.
4.2
How Do I Generate a Signature?

Signature generation will be an application on your DIGIPASS. 1. 2. Select the Signature application on your DIGIPASS. Enter the required transaction details. DIGIPASS can be programmed to accept up to eight transaction data fields such as: transaction amount transaction ID destination account number 3. The DIGIPASS will generate a signature and display it on its screen. Enter the generated signature into the transaction you are signing and submit the transaction.
4.2.1
Real Time Signature Validation

Real Time Signature Validation is signature validation that is performed in real-time, such as through an online banking application. A typical scenario is where a User creates a transaction, say, paying a bill on a banking website. The transaction requires a signature so the User enters the relevant details into their DIGIPASS. The DIGIPASS produces a signature and the User enters this into the website and then submits the transaction The transaction details and signature are verified by IDENTIKEY Server and a status message is returned straight to the web page the User is on. The User knows within the time it takes to process a normal transaction whether or not the transaction they submitted has been verified.
79
Signature Validation Process 4.2.2 Deferred Signature Validation

Deferred time Signature Validation is signature validation that is not performed in real time. An example scenario may be that a User submits a transaction online with the signature generated by the DIGIPASS. The transaction will then enter a queue to be verified. The User receives a message that the transaction has gone into a queue. A batch job picks up the transaction and verifies it against the policies and details of the DIGIPASS. The User may not know until minutes or hours later that the transaction has been signed and verified. It is important in this case for the User to keep a record of the time the transaction was submitted, as this may be important if the transaction is challenged.
4.3
Time based signature

The signature application may be time based. This means that the DIGIPASS will generate a different signature for the same input data at different times. The signature validation procedure relies on the time on the DIGIPASS and the time on IDENTIKEY Server being synchronized to within an acceptable tolerance. Each time a One Time Password or a signature is generated the IDENTIKEY Server records the difference in times between the DIGIPASS and itself. The time based signature validation procedure also uses Time Steps to verify signatures. A Time Step is a setting which specifies the number of seconds between generations of a One Time Password on a DIGIPASS. The IDENTIKEY Server will use the time step and the known difference in time between itself and the DIGIPASS to verify signatures. Use the STimeWindow policy setting to set the tolerance allowable for signature verification. Time based signatures can be real-time or deferred. If deferred time based signatures are used they may be reverified at a later date by comparing the input details against the signature produced by the DIGIPASS, as long as the time the transaction was performed is known.
4.4
Event Based Signature

The signature application may be event based. This means that it contains a numeric counter that increases every time a signature is generated. The signature process relies on an event counter to enable each signature to be unique. The DIGIPASS and IDENTIKEY Server need to have synchronized event counters. The tolerance for the difference between the event counters can be set by using the Event Windows policy setting. During Real Time Signature Validation the event counter on IDENTIKEY Server is updated with the value used by the DIGIPASS, to keep the two event counter values synchronized. During Deferred Time Signature Validation the event counters for transactions generated on the DIGIPASS may get out of step with the event counter held on IDENTIKEY Server. Setting the Event Window policy setting will enable signed transactions to be processed in any order without causing a verification error.
80
4.5
Static Signature
These signatures are generated using neither time or event counter. They will always produce the same signature for the same input. There is no difference between real-time and deferred time with these signatures.
4.6
Signature Verification Process

Digital Signatures are verified by IDENTIKEY Server using a number of specific checks.
Image 28: Steps of Signature Verification Process
4.6.1
Component Checks
IDENTIKEY Server will try to identify the application from which the request for registration came. There must be a component record on the data store for that application. A client component record must exist for the Signature Verification application and location from which it connects to the server. The component type is set as a parameter by the application; the location is the source IP address of the SOAP address.
81
Signature Validation Process 4.6.2 Policy Checks

IDENTIKEY Server identifies the policy to use in the signature authentication from the client component record and checks the validity of the policy.
4.6.3
User Account Lookup and Checks

IDENTIKEY Server checks the User Account to : Ensure that the User ID and Domain have been defined Perform the Windows Group Check if necessary Check whether a User Account exists Check whether the User account is disabled or locked if it already exists. Dynamic User Registration is NOT possible. If the User Account does not exist then the check will fail.
4.6.4
Signature Validation
A search is performed for a DIGIPASS that is assigned to the User that fulfils the Signature policy limits. If more than one DIGIPASS is found the list is filtered by using the Serial Number for the DIGIPASS, which will have to be passed into the signature process as a parameter. Allowance should be made when designing the web page that will allow transactions to be signed, to make sure that Users with more than one DIGIPASS can enter a Serial Number to identify which one is being used. When the correct DIGIPASS is identified the DIGIPASS type is checked. The DIGIPASS type must be either 'SG' (Signature) or 'MM' (Multi Mode) to allow signatures. The signature is then verified and a response is produced.
4.6.5
Finalization
The relevant parts of the Data Store are updated after the signature validation has been carried out successfully. A response is produced. The Audit data is updated with the transactions that took place and the result of those transactions. If the Web Application requests a Confirmation Code and the DIGIPASS is capable of generating one then IDENTIKEY Server will generate a Confirmation Code and the application will display it to the User. The User generates a Confirmation Code on their DIGIPASS and checks that it is the same as the one on the screen. Confirmation Code generation is passed as a parameter in the authentication request. There are two options: Optional - only return a Confirmation Code if the DIGIPASS is Confirmation Code capable Required - DIGIPASS must be Confirmation Code capable or the request will fail.
82
4.7
Policy Settings
There are specific Policy settings for signature verification. See the Policy Properties topic in the Field Listings section of the Administration Reference for information on these settings. Event Window - the allowable difference between the DIGIPASS event counter and IDENTIKEY Server event counter. OnlineSG specifies how signatures will be verified. STimeWindow - Shows the acceptable difference in time between the time set on the DIGIPASS and the time set on IDENTIKEY Server for signatures. The lowest value is 2, the highest is 500.
83
Software DIGIPASS Provisioning
5
5.1
5.1.1

Software DIGIPASS Provisioning Overview
What is a Software DIGIPASS?
Software DIGIPASS are software versions of DIGIPASS that provide authentication and signature functions for mobile devices and web browsers. They generate a One Time Password or Digital Signature for you in the same way as a hardware DIGIPASS. See 2.3 Types of DIGIPASS for more information. Each Software DIGIPASS requires: Software installed on the client device A unique activation code Each Software DIGIPASS will have to be installed on the host device, then activated using an activation code. It can then be used to generate One Time Passwords and Digital Signatures.
5.1.2
Software DIGIPASS Types

The following types are supported by the Provisioning function in IDENTIKEY Server:
DIGIPASS for Mobile
The DIGIPASS for Mobile is an application that runs on any Java enabled mobile phone, BlackBerry, iPhone, or Windows mobile phone. You can use it to generate a One Time Password or Digital Signature on demand.
DIGIPASS for Web
The DIGIPASS for Web is a Java applet that runs on your internet browser using cookies for data storage. You must therefore have cookies enabled on your internet browser. DIGIPASS for Web will also generate a One Time Password or Digital Signature on demand.
DP110
The DP110 is a hybrid DIGIPASS. This means that there is a hardware component, and a software component. A Java applet runs on your internet browser, and a USB stick is plugged in to the same machine. These two components together will generate a One Time Password on demand.
5.1.3
What is Provisioning?
The term 'Provisioning' in IDENTIKEY Server refers to delivery, registration, and activation of the software. The
84

three steps of provisioning are: 1. Software Delivery
You are free to deliver the software in any way you choose. You can either deliver software to Users, or allow them to download the software from a secure site. The code required for activation of the Software DIGIPASS or DP110 - the Activation Code - may be delivered 'online' to the Software DIGIPASS application or DP110 that requires it, or it may be delivered 'offline'
Online delivery
Online delivery means that the Activation Code is delivered directly to the application that is going to use it. If the Activation Code is delivered in this way the User will never see it. This option is available for DIGIPASS for Web, DP110, and DIGIPASS for Mobile 3.0.
Offline Delivery
Offline delivery means delivering the Activation Code using a mechanism such as email, text message or fax. In DIGIPASS for Web the Activation Code will typically be delivered in an email containing a link. The applet reads the Activation Code from the link. 2. User/DIGIPASS Registration
The DIGIPASS records must be imported from a DPX file before Registration can occur. Each Software DIGIPASS User requires a DIGIPASS User account on IDENTIKEY Server. The User accounts can either be imported into IDENTIKEY Server, created individually, or created dynamically during registration if Dynamic User Registration is available. For Software DIGIPASS to work, a DIGIPASS record needs to be allocated to the User account. This can be done in two ways: a. b. Manually by an Administrator using, for example, the Web Administration interface.
Automatically. This is where the DIGIPASS is assigned to the User account during the Registration process. This will allocate the first DIGIPASS of the correct type and functional ability that it can to the User. In IDENTIKEY Server this functionality is known as Auto Assignment. See the DIGIPASS chapter in the Product Guide for more details. The second step of Registration is to generate an activation code and send it to the User. 3. Activate Software
Each Software DIGIPASS needs to be activated before it can be used. This means that IDENTIKEY Server is informed that all the components are in place for the Software DIGIPASS and you are ready to use it. There are two stages to activation: a. b. Delivering the Activation Code to the software Sending the first One Time Password to the server.
85
Image 29: Steps of Provisioning
5.1.4
Which Server Components implement Provisioning?

There are two main components and one optional component required to implement Provisioning:
Web Application - Customer written.

The Web Application controls the user interaction during Provisioning. The Web Application uses the SOAP SDK to communicate with IDENTIKEY Server. Refer to the SOAP SDK documentation for more information. The Web Application: Can make the Software DIGIPASS software available for download Has to arrange delivery of the Activation Code to the User Sends the first One Time Password to IDENTIKEY Server
IDENTIKEY Server
IDENTIKEY Server handles DIGIPASS User accounts and DIGIPASS records. It generates Activation Codes, verifies One Time Passwords and stores static passwords.
Back-End System
The Back-End System can be used by IDENTIKEY Server for Dynamic User Registration and/or static password verification. See 3.6 Back-End Authentication for more information.
86
5.2
Provisioning Scenarios
The following scenarios show how Provisioning will work for different DIGIPASS in different situations. Refer to the table below for the scenario that best fits your requirements: Scenarios User account User knows on Static IDENTIKEY Password Server
DIGIPASS for Y Mobile 1 DIGIPASS for Y Web 1 DIGIPASS for Y Web 2 DIGIPASS for N Web 3 Y Y Y
Provisioning Policy Local Auth Back-End Auth

None None None
DIGIPASS Back-End Type Protocol

MOB30 WEB10 WEB10 -

-
None None DIGIPASS Only or DIGIPASS/ Password DIGIPASS Only or DIGIPASS/ Password
Always or If Needed
WEB10
Windows, RADIUS, LDAP, custom Windows, RADIUS, LDAP, custom
Enabled
DP110 1 DP110 2
Y N
Y Y None
None Always
DP110 DP110
5.2.1
DIGIPASS for Mobile Scenario 1 - Activation codes are encrypted with pre-loaded static password Pre-Conditions
The User account has been created on IDENTIKEY Server The User knows their static password The static password has been imported into IDENTIKEY Server The provisioning policy has been defined with the following settings No Local Authentication (DIGIPASS/Password) No Back-End Authentication (None) DIGIPASS type 'MOB30'Process
87
Software DIGIPASS Provisioning Process
Image 30: DIGIPASS for Mobile Scenario 1 process
Procedure The User enters their mobile number and their mobile type (Java, BlackBerry, iPhone, Windows Mobile phone) into the Provisioning website. The Provisioning webserver sends an Text Message to the mobile number which contains the URL to be used to download the DP4Moble application. The User uses the URL to download the DIGIPASS for

Mobile application, and then installs the application on their mobile phone. The User enters their User ID into the application, and the application sends a registration request to the webserver, which sends a registration request to IDENTIKEY Server. IDENTIKEY Server assigns the DIGIPASS for Mobile DIGIPASS to the user, generates an encrypted activation code and sends it to the DIGIPASS for Mobile application. When the User has the serial number and activation code the second part of the activation can take place. The User enters their static password into the Software DIGIPASS to activate it. The One Time Password is then generated and submitted to the Provisioning Server and from this server to IDENTIKEY Server to complete the activation procedure. A response will be received on the mobile phone indicating whether the activation has been successful.
5.2.2
DIGIPASS for Web

There are three scenarios that can be employed when activating DIGIPASS for Web. They all have different preconditions. Which scenario is employed will depend on how IDENTIKEY Server is implemented.
Scenario 1 Activation codes are encrypted with pre-loaded static passwords Pre-conditions.
User account has been created on IDENTIKEY Server The User knows their static password The static password has been imported into IDENTIKEY Server Provisioning policy defined with the following settings: No Local Authentication (None) No Back-end Authentication (None)
89

Process
Image 31: DIGIPASS for Web Scenario 1 Process Procedure
The User enters their user ID, email address and PIN on the website. If registration is successful the DIGIPASS for Web applet is provided with the serial number of the DIGIPASS that is to be activated and an encrypted activation code. Note that the PIN is not sent to the server but is used locally by the DIGIPASS for Web applet. The User will have to re-enter their User ID, PIN and password to decrypt the Activation Code and complete activation. The applet decrypts the Activation Code, activates itself and sends a One Time Password to the server.
90

A response will be received indicating whether the activation has been successful.
Options
To make sure that the User changes their static password, extra fields can be added to the second page in this scenario. Fields can be added to the input page so that the User can enter a new static password, and then enter it again for confirmation. The User needs to do this so that the original password can only be used once, for activation. The new password can be used for re-activation. See Reactivation section below.
Scenario 2 Pre-Loaded User Accounts and Static Passwords Pre-conditions.
the User account has been created on IDENTIKEY Server the User knows their static password The static password has been imported into IDENTIKEY Server The provisioning policy has been defined with the following settings: Local Authentication (DIGIPASS Only or DIGIPASS/Password) No Authentication (None)
91

Process
Image 32: DIGIPASS for Web Scenario 2 Process
Procedure
The User enters their user ID, email address, static password and PIN on the registration website. If registration is successful the serial number of the DIGIPASS that is to be activated and an activation code are delivered to the DIGIPASS for Web applet. The User re-enters the User ID and PIN. DIGIPASS for Web generates a One Time Password and then submits this with the serial number to the server. Activation then takes place. A response will be received indicating whether the activation has been successful.
92

Options
To make sure that the User changes their static password, extra fields can be added to the second page in this scenario. Fields can be added to the input page so that the User can enter a new static password, and then enter it again for confirmation. The User needs to do this so that the original password can only be used once, for activation. The new password can be used for re-activation. See Reactivation section below.
Scenario 3 Dynamic Registration using Back-End System Pre-conditions
the User account has not been created on IDENTIKEY Server the User knows their static password for their account in the Back-End system The Provisioning policy has been defined with the following settings: Local Authentication (DIGIPASS Only or DIGIPASS/Password) Back-End Authentication (Always or If Needed) Back-End Protocol (Windows, RADIUS, LDAP Back-End authentication, or Custom name) Dynamic User Registration EnabledProcess
93
Image 33: DIGIPASS for Web Scenario 3 Process
Procedure
The procedure very similar to scenario 2; the User will not see a difference. The difference for the IDENTIKEY Server is that the Back-End system is used to verify the User Id and Password. If they are OK, and account is created automatically in IDENTIKEY Server.

Options
To make sure that the User changes their static password, extra fields can be added to the second page in this scenario. Fields can be added to the input page so that the User can enter a new static password, and then enter it again for confirmation. The User needs to do this so that the original password can only be used once, for activation. The new password can be used for re-activation. See 5.6 Reactivation section below.
5.3
DP110 Provisioning Overview

The DP110 is a hardware/software combination DIGIPASS. It does not require any software to be installed on the client side to enable it to run, but it does require the correct policy settings to be provided, followed by activation. There are two scenarios that can be employed when activating a DP110. They both have different pre-conditions. Which scenario is used will depend on how IDENTIKEY Server is implemented.
5.3.1
Scenario 1 Pre-Conditions
User account created User knows historical secret Historical Secret imported in IDENTIKEY Server (as static password) Provisioning policy defined with following settings: Local Authentication NO Back-End authentication DIGIPASS type is 'DP110'
95
Image 34: DP110 Scenario 1
Procedure
The User opens the browser on his PC, and goes to the registration page of the DP110 provisioning website. The DP110 provisioning website generates a challenge which will be used to encrypt the new server PIN. The User enters their user ID, static password, new server PIN, confirmation of new server PIN, and DP110 serial number on the registration website. The DP110 Applet generates a Challenge Encrypted Static Password (CESPR) using the generated challenge and the new server PIN. On the server side, the CESPR is verified. If verification is successful the DP110 is assigned to the User, and the initial PIN is set. The DIGIPASS Grace Period is set according to pre-defined parameters. The activation page is returned if the provisioning is successful, or an error message will be returned if the provisioning is not successful.
96
Software DIGIPASS Provisioning 5.3.2 Scenario 2 Pre-Conditions

User Account NOT created User knows historical secret to allow authentication by a legacy back-end system Provisioning policy defined with the following settings: NO local authentication (None) Back-End authentication (Always) DIGIPASS type DP110
97
Image 35: DP110 Scenario 2
Procedure
The User enters their user ID, static password, challenge, CESPR, and DP110 serial number on the registration website. On the server side, the user is authenticated on the Back-End. If the Back-End authentication is successful the User is then registered to IDENTIKEY Server using Dynamic User Registration. The DP110 is then assigned to the User, and the initial PIN is set. The DIGIPASS Grace Period is set according to pre-defined parameters. A response will be received indicating whether the activation has been successful.
98
5.4
What are the steps in registration of a Software DIGIPASS?
Image 36: Steps of Software DIGIPASS Registration
5.4.1
Identify Component
IDENTIKEY Server will try to identify the application from which the request for registration came. A client component record must exist for the Provisioning application and location from which it connects to the server. The component type is set as a parameter by the application; the location is the source IP address of the SOAP request.
5.4.2
Identify Policy
IDENTIKEY Server identifies the policy to use in the registration from the client component record and checks the validity of the policy. The following settings on the policy will not be used as they are not relevant to Provisioning.
99

DIGIPASS Assignment Settings Challenge Settings
5.4.3
DIGIPASS User Account Lookup and Checks

IDENTIKEY Server checks the User Account to: Ensure that the User Account and Domain have been defined Perform the Windows Group Check if necessary Check whether a User Account exists Check whether the User account is disabled or locked if it already exists.
5.4.4
Local Authentication
Local Authentication is an optional step in Software DIGIPASS Registration. If Local Authentication is performed a static password MUST be entered. The static password will be verified against the static password held against the User Account. If the static password is not verified or no User Account exists or the User Account exists but has no password recorded against it, the registration will fail if Back-End Authentication is not enabled. If Back-End Authentication is enabled then the Back-End system will verify the password. If the password is verified but there is no User Account in IDENTIKEY Server, an account will be created. Dynamic User Registration must be enabled for this to succeed.
5.4.5
Back-End Authentication
The static password will be authenticated by the Back-End system. If the Back-End System does not verify the credentials, Registration will fail.
5.4.6
DIGIPASS Assignment
The Registration process will perform the following steps: Search for an applicable DIGIPASS according to the criteria on the policy associated with the User account that is capable of activation. If one was not found, Assign the first applicable and available DIGIPASS record to the User Account F
5.4.7
Activation Code Generation

The reactivation restrictions are checked. If this is a reactivation and reactivation is allowed, then the User Account and the DIGIPASS record already exist in IDENTIKEY Server and will be used in the following steps.
100
The Activation Code is generated using the first capable application in the DIGIPASS. The Activation Code may be encrypted with the User's password if the password was not verified by Local and Back-End authentication.
5.4.8
Finalization
In the finalization step the created Users and assignment are confirmed to the Data Store. Records are written to the Audit system to record the actions that have taken place, and the results. A response is sent to the User to confirm registration or to show an error message if activation failed.
5.5
What are the steps in activation?
Image 37: Steps of Software DIGIPASS Activation
5.5.1
Identify Policy, Component, and DIGIPASS User Account Lookup and Checks
The activation process performs the same Identify Policy and DIGIPASS User Account Lookup and Checks as the registration process, except that the User Account MUST already exist.
5.5.2
Verify One Time Password

The One Time Password is verified against the DIGIPASS record.
101
Software DIGIPASS Provisioning 5.5.3 Activation

The DIGIPASS is set to ACTIVE in the data store and the grace period will end, if one was set.
5.5.4
Finalization
In the Finalization step the activation is confirmed to the Data Store. Records are written to the Audit system to record the actions that have taken place, and the results. A response is sent to the User to confirm activation or show an error message if activation failed.
5.6
Reactivation
From time to time software DIGIPASS will have to be reactivated. This may occur rarely for DIGIPASS for Mobile, such as when the User buys a new mobile phone, or it may occur more often for DIGIPASS for Web, such as when the User clears the cookies in their browser Reactivation is carried out in the same way as the original activation, but the User account will already exist with a capable DIGIPASS assigned. The registration process will use the assigned DIGIPASS to generate the Activation Code. Configuration Settings can be set up to set the following limits: Activation Limit - this will limit the number of activations that can be performed on one Software DIGIPASS. Minimum Interval - This sets the minimum time interval between reactivations. Maximum Locations - This sets the maximum number of locations a Software DIGIPASS can be activated from, such as home, office, laptop. This only applies to DIGIPASS for Web.
Note
The activation limits apply to all activation attempts. If an activation fails in the second stage this will still count as an activation, and will count against the activation limits. These settings are defined in the Scenarios Section of the IDENTIKEY Server Configuration
102
DIGIPASS Authentication for Windows Logon
6
6.1

Introduction
DIGIPASS Authentication for Windows Logon provides strong authentication when logging on to Windows. A User logs on to Windows using a User ID, Password, a One Time Password (OTP) generated by a DIGIPASS, and optionally a PIN. The User ID, Password, and OTP are validated online by IDENTIKEY Server, or offine using Encrypted Offline Logon Data generated by IDENTIKEY Server. The DIGIPASS Authentication for Windows Logon consists of a Client module which is installed on the Client PC, and server side functionality as part of IDENTIKEY Server. DIGIPASS Authentication for Windows Logon must be enabled on IDENTIKEY Server by installing the DIGIPASS Authentication for Windows Logon License.
6.2
Available Guides
The following guides are available for DIGIPASS Authentication for Windows Logon: DIGIPASS Authentication for Windows Logon Product Guide DIGIPASS Authentication for Windows Logon Getting Started Guide
6.3
Online Authentication
Online Authentication occurs when a User logs on to Windows using DIGIPASS Authentication for Windows Logon when the Client PC is connected to the network. Authentication takes place using IDENTIKEY Server in real time.
103
Image 38: DIGIPASS Authentication for Windows Logon Online Authentication
The User ID, Password and OTP are sent to IDENTIKEY Server to be authenticated. The authentication result is then sent back to the DIGIPASS Authentication for Windows Logon module on the client PC. Communication between the Client PC and IDENTIKEY Server is carried out using SEAL over SSL. For information on setting up SSL with IDENTIKEY Server, please refer to the SSL Certificate sections of the IDENTIKEY Server Advanced Setup chapter in the IDENTIKEY Server Adminstrator Reference.
6.4
Offline Authentication
Offline Authentication occurs when a User logs on to Windows using IDENTIKEY Server when the Client PC is not connected to the network. Authentication takes place using Encrypted Offline Logon Data created during successful Online Authentication.
104
Image 39: DIGIPASS Authentication for Windows Logon Offline Authentication
The User ID, Password and OTP are authenticated using the Encrypted Offline Logon Data. The authentication result is then sent back to the DIGIPASS Authentication for Windows Logon module on the client PC. The Encrypted Offline Logon Data can be used a limited number of times, and that limit can be configured using the Administration Web Interface.
6.5
Dynamic Component Registration

Dynamic Component Registration (DCR) is used by DIGIPASS Authentication for Windows Logon to register a component for use when logging on to Windows using an OTP. DIGIPASS Authentication for Windows Logon requires a client component to be registered for a User at the IP address they are using. DCR checks to see if a client component for that IP address exists for a User, and if not it creates one. The Windows Logon Client Component is identified by the following formats: Client machine hostname - If a DNS based reverse lookup of an IP address is being used with the DNS suffix not set on the client machine. Fully qualified domain name (FQDN) - If a DNS based reverse lookup of an IP address is being used with the DNS suffix set.
6.6
Password Randomization
DIGIPASS Authentication for Windows Logon can be configured to provide Password Randomization. Password
105

Randomization is where the Windows logon password is generated in the background for each logon, producing a randomized password with the format adhering to strict formatting rules. The User enters only the User ID, OTP, and optionally a server PIN, when logging on, with the password generated in the background. Using Password Randomization prevents a User from logging on to Windows using a client PC which does not have DIGIPASS Authentication for Windows Logon installed.
6.7
Static Password Synchronization

Password Synchronization Manager (PSM) is a product that is installed on the domain controller which allows a change of the Windows Password to be automatically updated on IDENTIKEY Server. The new Windows password will be reflected as the static password on IDENTIKEY Server. When the Windows password is changed, it is updated on the Domain Controller. PSM checks for the availability of IDENTIKEY Server before sending the new password to IDENTIKEY Server so that the datastore can be updated. If IDENTIKEY Server is not available the synchronization will fail. If the User is not defined on IDENTIKEY Server, only the password on the Domain Controller will be changed. See the Password Synchronization Manager User Manual for more details.
106
EMV-CAP
7
7.1
EMV-CAP
EMV-CAP Smartcard Readers
Image 40: DIGIPASS 810
EMV-CAP is the Chip Authentication Program (CAP) developed by credit card leaders Europay, Mastercard and Visa (EMV). VASCO provides a range of smartcard readers which are EMV-CAP compliant.
7.1.1
EMV-CAP Modes
IDENTIKEY Server supports three EMV-CAP compliant DIGIPASS applications, or modes. All modes provide a secure code as output, but differ in the data to be input: Mode
Mode 1
Data sent to IDENTIKEY Server

Challenge Transaction amount Transaction currency
Mandatory?
No No No
Output
Secure code
107
EMV-CAP
Mode
Mode 2 (Transaction Data Signing)
Data sent to IDENTIKEY Server

Data Field 1 Data Field 2 Data Field 3 Data Field 4 Data Field 5 Data Field 6 Data Field 7 Data Field 8 Data Field 9 Data Field 10
Mandatory?
No No No No No No No No No No Yes
Output
Signature
Mode 3 (Challenge/Response)
Challenge
Secure code
7.2
Hardware Security Module

A Hardware Security Module is highly recommended for use with EMV-CAP smartcard readers. See 8 Hardware Security Modules for more information.
7.3
EMV-CAP Scenario
The EMV-CAP scenario must be enabled in the configuration of each IDENTIKEY Server before EMV-CAP functionality is available. See the help files for the Configuration Utility or the Configuration section of the Administrator Reference for more information.
7.4
Licensing
These licensing options must be included for each IDENTIKEY Server: HSM EMV-CAP
7.5
Unsupported Standard IDENTIKEY Server Features

Some standard features of IDENTIKEY Server are not supported with EMV-CAP. The following are not supported: Dynamic User Registration Auto-Assignment
108
EMV-CAP
Self-Assignment
7.6
PANs
Whenever PAN fields are displayed on the Administration Web Interface or the Configuration GUI, they will be masked. Certain administrators will have an additional administrative permission which will enable them to see PANs in clear text, but to most they will appear masked. PANs will be stored as encrypted numbers on the datastore. When the numbers are displayed they are decrypted and then masked.
109
Hardware Security Modules

Hardware Security Modules may be integrated with IDENTIKEY Server to provide an extra layer of security to data storage.
Caution
A Hardware Security Module may not be added to an existing IDENTIKEY Server installation. A new installation will be required. See the Set Up a Hardware Security Module topic in the Administrator Reference for more information.
8.1
Supported Hardware Security Modules

These Hardware Security Modules are supported: Safenet ProtectServer Gold Safenet ProtectServer Internal-Express Safenet ProtectServer Orange
8.2
Limitations
Use of a Hardware Security Module with IDENTIKEY Server imposes some limitations: ODBC-compliant database must be used as IDENTIKEY Server's data store.
8.3
Load Balancing and Fail-Over

IDENTIKEY Server provides load-balancing and failover between Hardware Security Module slots.
8.3.1
Session Pool
When the IDENTIKEY Server service or daemon is started, IDENTIKEY Server will automatically create a Session Pool for use in accessing each HSM. HSM slots with an attribute matching the IDENTIKEY Server configuration setting slotSelectionAttribute will be added to the Session Pool up to the value of the slotsExpected configuration setting.
8.3.2
Load-Balancing
When IDENTIKEY Server needs to access data protected by the HSM(s), it takes a random session from the pool.
110

Where multiple HSMs are available, this spreads the load across all slots.
8.3.3
Failover
If a session does not receive a response from a slot, the HSM is blacklisted and slots on the other HSM(s) will be used, where available.
8.3.4
HSM Re-Initialization
The IDENTIKEY Server will stop and re-initialize all HSMs in the Session Pool when: All configured HSMs are blacklisted, or At least one HSM has been blacklisted and no sessions are currently required
8.4
Licensing
All IDENTIKEY Servers must be licensed for HSM.
8.5
Configuration
Connection and encryption settings for IDENTIKEY Server to use with the Hardware Security Module(s) are configured during installation.
8.6
Unsupported Standard IDENTIKEY Server Features

Some standard features of IDENTIKEY Server are not supported with the Hardware Secuity Module The following are not supported: RADIUS protocols: CHAP MSCHAP MSCHAP2 Any Provisioning Any Software DIGIPASS OATH based tokens Offline Data Generation (for Windows Logon) Active Directory Storage
111
8.7
Cryptographic Keys
A Hardware Storage Module (HSM) can be used to protect and manage your high-value cryptographic keys. HSMs provide stronger authentication for server applications. The diagram below shows how cryptographic keys are stored in slots, each of which contains a token. Access to sensitive and storage data is protected by the keys, which can be rotated at regular intervals, providing even greater security. To rotate the keys a job must be initiated from the Administration Web Interface. The job can be scheduled or run immediately.
Image 41: Cryptographic keys allocated by token name and Slot ID The key rotation process involves decrypting data with an old encryption key, then re-keying the data with a new encryption key. Rotating one sensitive data key affects all other sensitive data keys, while rotating a storage data key affects all other storage data keys. Cryptographic key rotation can take some time. You can schedule a key rotation to run at a convenient time, then cancel it if not finished when system resources are needed again. If you restart the key rotation later, processed data does not need to be re-processed.
112
Administration
Administration
This section introduces the main tools and user interfaces available for administration of IDENTIKEY Server.
9.1
Overview of Administration Interfaces

IDENTIKEY Server provides a range of interfaces to make administration tasks rapid and easy. Available interfaces are readily accessed from the main IDENTIKEY Server menu: IDENTIKEY Server Configuration IDENTIKEY Server Configuration Wizard IDENTIKEY Administration Web Interface DIGIPASS Extension for Active Directory Users and Computers (AD only) Virtual DIGIPASS MDC Configuration User CGI Configuration Audit Viewer Tomcat Monitor Command-line Administration The best administration interface to use in any particular situation will depend on the tasks required, and the data store used by IDENTIKEY Server.
Helpdesk
If IDENTIKEY Server uses an ODBC database as its data store, you will typically use the Administration Web Interface. If IDENTIKEY Server uses Active Directory as its data store, you will typically use the DIGIPASS Extension for Active Directory Users and Computers.
User/DIGIPASS Administrator
The main tools you will use are: Web Administration Interface DIGIPASS Extension for Active Directory Users and Computers (AD only) DIGIPASS TCL Command Line Administration IDENTIKEY Server Configuration
System Administration
The main tools you will use are:
113
Administration
IDENTIKEY Server Configuration Audit Viewer Configuration Wizard
9.1.1
Active Directory v. ODBC administration

Where IDENTIKEY Server uses an ODBC database including the embedded PostgreSQL database as its data store, all data administration can be carried out using the Administration Web Interface. Where IDENTIKEY Server uses Active Directory as its data store, DIGIPASS User accounts and DIGIPASS records are administered via the Active Directory Users and Computers Snap-In, rather than the Administration Web Interface. Active Directory Users and Computers Snap-In
ODBC Database -
Administration Web Interface

DIGIPASS Users DIGIPASS Policies Clients Back End Servers Organization Reports System Policies Clients Back End Servers Reports System
Active Directory
DIGIPASS Users DIGIPASS
9.2
Administration Web Interface

The Administration Web Interface is a web-based administration tool. It can be opened in a browser window with an IDENTIKEY Server administrator userID and password. Click on any of the top-level tabs to view and edit data, configure system settings, run reports and more.
NOTE:
Only Administrators have access to the Administration Web Interface. If you do not have Administrator access you will not be able to use the Administration Web Interface.
114
Administration
Image 42 : IDENTIKEY Server Web Administration Interface
User Accounts
If IDENTIKEY Server uses an ODBC database including the embedded PostgreSQL database as its data store, the Administration Web Interface can be used for the following tasks: Import DIGIPASS User accounts singly or in bulk Create DIGIPASS User accounts Edit DIGIPASS User accounts Disable DIGIPASS User accounts Delete DIGIPASS User accounts Add custom and/or RADIUS User attributes, singly or in bulk Search for User Accounts The Administration Web Interface allows you to search for DIGIPASS User account records in a number of ways: Search directly by entering the User ID Search for the User that a specific DIGIPASS belongs to by searching for the DIGIPASS and double clicking on the User on the DIGIPASS details screen You can enter the first few characters of the User ID followed by a wildcard (*). A results list will be provided
Administration
from which you can select the User required.
DIGIPASS Record Administration

If IDENTIKEY Server uses an ODBC database including the embedded PostgreSQL database as its data store, the Administration Web Interface can be used for the following tasks: Import DIGIPASS either individually or in bulk Create DIGIPASS records Reset DIGIPASS Reset PIN for a DIGIPASS Assign DIGIPASS Unassign DIGIPASS Activate and deactivate applications for DIGIPASS Unlock a DIGIPASS Search for DIGIPASS Records The Administration Web interface allows you to search for DIGIPASS in a number of ways: You can search directly for the DIGIPASS by entering the DIGIPASS Serial Number You can search for DIGIPASS that belong to a User by searching on the User and then double clicking on the DIGIPASS on the User Details Screen You can enter the first few numbers of the DIGIPASS Serial Number followed by a wildcard (*). This will provide you with a list from which you can select the DIGIPASS you require. You can search based on the description field of a DIGIPASS record.
Policies
Policy records can be edited, created or deleted using the Administration Web Interface. New Policy records can be created using a wizard.
Client Records
The Administration Web Interface allow you to create, manage, and delete Client Records.
Back End Server records

The Administration Web Interface can be used to edit, create or delete Back End Server Records, and configure general Back End authentication settings.
Domain and Organizational Unit Records

Use the Administration Web Interface to add, maintain, or delete a Domain or an Organizational Unit.
116
Administration Reports
The Administration Web Interface allows you to run existing reports and to create new reports. See 16 Reporting for more details
Servers
From the Servers tab you can manage various scheduled tasks including cryptographic data rotation.
System
The System tab allows you to administer the system. You can add or remove IDENTIKEY Servers, administer the licence, configure the IDENTIKEY Server and manage administrative sessions.
117
Administration
9.3
DIGIPASS Extension for Active Directory Users & Computers

The DIGIPASS Extension for Active Directory Users and Computers allows administration of DIGIPASS User accounts and DIGIPASS records within the Active Directory Users and Computers interface.
Note
The DIGIPASS Extension for Active Directory Users and Computers is only available where Active Directory is utilized as the data store. The extension adds context menu options, User property sheet tabs and a property sheet for the DIGIPASS records, as outlined below.
Connection
No logon screen is presented by the extension - an implicit logon to Active Directory will be carried out using your current Windows user context. It will connect to the same Domain Controller as the Active Directory Users and Computers connection. The extension will make its own LDAP connection to Active Directory. Administration does not take place via the IDENTIKEY Server. Your administrative permissions will depend on the permissions that your Active Directory user account has within Active Directory.
When do new settings take effect?

When settings are changed with the extension, the new values may not always take effect immediately. See 2.4 Active Directory Replication Issues in the Administration Reference Guide for more information.
9.3.1
Context Menu Extensions

VASCO context menu options are available on the following containers in the tree pane: The Users container All Organizational Units The DIGIPASS-Pool, DIGIPASS-Reserve and DIGIPASS-Configuration containers Additional context menu options are available when right-clicking on one or more User records in the result pane:
9.3.2
User Property Sheet Extensions

Additional tabs are available when viewing the property sheet of a User record: The DIGIPASS User Account tab contains extra information about the DIGIPASS User account required by IDENTIKEY Server. This includes settings such as authentication policy overrides, and the date and time that a
118
Administration
DIGIPASS User account was created. The DIGIPASS Assignment tab contains information on all DIGIPASS assigned to the DIGIPASS User. These DIGIPASS can be administered from this tab, including unassignment or enabling Backup Virtual DIGIPASS. DIGIPASS may also be assigned to the DIGIPASS User from this tab. The Provisioning tab contains features related to the distribution and special administration of software DIGIPASS and DP 110.
9.3.3
DIGIPASS Record Administration

DIGIPASS information may be viewed via the property sheet of its assigned User, or by turning on Advanced Features. This allows you dependent on permissions - to see DIGIPASS records wherever they are located in Active Directory (typically in the DIGIPASS-Pool container if unassigned), view properties and use a number of context menu actions. For more details on these actions, see 11 DIGIPASS. The context menu of the DIGIPASS record contains options for bulk management. The property sheet for the DIGIPASS record shows full details of the DIGIPASS and all its Applications and enables all administration tasks for the record.
Search for DIGIPASS Records

The DIGIPASS Extension for Active Directory Users and Computers allows you to search for specific DIGIPASS records, or DIGIPASS records meeting set criteria. This functionality can be useful when you have DIGIPASS records in various places throughout Active Directory.
9.4
DIGIPASS TCL Command-Line Administration

DIGIPASS TCL Command-Line Administration allows interactive command-line and scripted administration of DIGIPASS related data. It has a number of possible uses: Interactive command-line administration Scripted administration Complex bulk administration tasks Reporting on the data in the data store It is an extension of the TCL 8.4 scripting language, and administrators will require a basic competence in TCL in order to use the command-line utility. See the DIGIPASS TCL Command-Line Administration topic in the Administrator Reference for more information.
119
Administration
9.5
IDENTIKEY Server Configuration

The IDENTIKEY Server uses a local XML text file for various configuration settings. This can be administered using a graphical user interface, referred to as IDENTIKEY Server Configuration, or via the Administration Web Interface. To run the IDENTIKEY Server Configuration tool, go to the install directory and run IDENTIKEY Server Configuration.
Image 43 : IDENTIKEY Server Configuration
When settings are changed with this program, the IDENTIKEY Server must be restarted before the new values take effect. The program will do this for you when you exit. The following groups of settings are configured using IDENTIKEY Server Configuration. For more detail, see the Administrator Reference, Configuration Settings section.
120
Administration
General Server location, RADIUS Dictionary Filepath, Administration Session Settings and Tracing. Communicators - SOAP, RADIUS, and SEAL communication protocols, including SSL. Scenarios available scenarios depend upon your licence agreement. Engines - define your Back-End Authentication plug-in engines. Storage - add additional ODBC databases with optional encryption settings. Auditing - Enable/Disable audit methods. Replication - Specify Replication settings. Server discovery optional DNS Service registration. Performance enable/disable Performance Monitoring filters and plugins.
9.6
Configuration Wizard
Image 44 : Configuration Wizard
The Configuration Wizard is run initially after installation in set-up mode. After installation it can be run again in maintenance mode to manage any of the following changes: Re-run Installation Wizard
121
Administration
Change Server Component Location Backup Audit Messages Rescue Administrators Rescue Administration Client Restore Default Policy and Report Definitions Install SSL Server Certificate Install MDC SSL Server Certificate Re-deploy Web Administration For more details, see the IDENTIKEY Server Administrator Guide.
9.7
Audit Viewer
Use the Audit Viewer to view Audit Messages. Audit messages consist of warnings and errors generated by IDENTIKEY Server.
9.8
Admintool.jar
The Admintool.jar tool can be used to configure the Administration Web Interface. It allows: Modifications to the list of IDENTIKEY Servers which may be administered from the Administration Web Interface Configuration of SSL certificates
9.9
Tomcat Monitor
The Apache Tomcat Monitor can be used to view and edit Tomcat settings, including: logon accounts log paths Java settings startup and shutdown details
9.10
User CGI Configuration

The DIGIPASS User CGI Configuration window manages: Primary Server Settings Backup Server Settings
122
Administration
Connection Settings Tracing Settings
123
DIGIPASS User Accounts
10
10.1

DIGIPASS User Account Creation
A DIGIPASS User account can be created in the following ways: Use the Administration Web Interface to import Users from a file (see the How To Import Users topic in the Administration Web Interface Help for more information) Manually create User records using the Create User function on the Administration Web Interface (see the How To Create a User topic in the Administration Web Interface Help for more information) Dynamically during processing if Dynamic User Registration is enabled
10.1.1

When the IDENTIKEY Server receives an authentication request for a User without a DIGIPASS User account, it can check the credentials with the back-end authenticator (eg. Windows). If the authentication is successful with the back-end authenticator, the IDENTIKEY Server can create a DIGIPASS User account automatically for the User. This process is called Dynamic User Registration (DUR) and can be enabled via the Administration Web Interface. This feature is commonly used in conjunction with Auto-Assignment, so that the new account is immediately assigned a DIGIPASS.
Note
ODBC Database (including embedded database): If the data store is case-sensitive and the IDENTIKEY Server has not been configured to convert User IDs and Domains to upper or lower case, the potential exists for multiple DIGIPASS User accounts to be created for a single User. For example, if a User logs in with 'jsmith' on one occasion, and JSmith on another, two DIGIPASS User accounts may be created jsmith and JSmith. This can be avoided by: Enabling Windows Name Resolution in the IDENTIKEY Server Configuration GUI, if the underlying user accounts are Windows user accounts. See the ODBC Connection and Domains and Organizational Units topics in the Administrator Reference for more information. This is highly recommended. Configuring the IDENTIKEY Server to convert all User IDs and domains to upper or lower case. See the Encoding and Case-Sensitivity topic in the Administrator Reference for more information.
124
10.2
Changes to Stored Static Password

If Stored Password Proxy is enabled, any changes to a User's password on a back-end system need to be communicated to the IDENTIKEY Server. This can be done using Password Autolearn.
10.2.1
Password Autolearn
If Password Autolearn is enabled, a User may directly log in with their new static password in front of their OTP. If it does not match the static password stored by the IDENTIKEY Server, it can be verified with the back-end authenticator. If correct, the IDENTIKEY Server will store the new static password for future use and authenticate the User.
10.3
Password Strength
You can customize formatting rules to enhance password security.
10.3.1
What are the password strength rules?

Password rules are configurable on the policy associated with the IDENTIKEY Server component. The password strength rules can be configured by using the Administration Web Interface policy administration page User tab. The variables that can be configured are: Minimum password length Minimum number of lower case characters Minimum number of upper case characters Minimum number of numeric characters Minimum number of symbols Password Different From # Passwords Previously Used Specify the number of passwords that must be used before you can reuse a password No Inclusion Of Part Of UserID Specify whether parts of the User ID may be used in the password
When are password strength rules enforced?

Password strength rules are ALWAYS enforced in the following circumstances: During the first installation of an ODBC system, the default password strength rules will be applied to the first administrator password. The default password strength rules are: Minimum length = 7 Minimum 1 lower case character
125

Minimum 1 upper case character Minimum 1 numeric character If a User is created or updated, or if a password is set using the Administration Web Interface or the TCL command line tool. Password Strength rules are NOT enforced in the following circumstances: For Users in Active Directory installations Where back-end authentication is used (password rules for the back-end are used in this case) When using the Dynamic User Registration facility
10.4
Administration Privileges
Administration of data in an ODBC database is performed through the IDENTIKEY Server to control the administrator's access to data. An administrator may be assigned permissions based on: Type of permission (eg. Read, Create) Type of object (eg. DIGIPASS, Policy) The Domain and Organizational Unit in which the administrator account is located will determine their range of administration access: If the account belongs to an Organizational Unit, the administrator will be able to administer User accounts and DIGIPASS belonging to that Organizational Unit. If the account does not belong to an Organizational Unit, the administrator will be able to administer all DIGIPASS and User accounts in the Domain to which they belong. If the account belongs to the Master Domain, the administrator may be able to administer all DIGIPASS and User accounts in the database. This depends on the 'Access Data in All Domains' Privilege, which is only available to administrators in the Master Domain. Administrators may also be limited to assigning only privileges which they themselves possess. See the Administrator Reference for more information.
10.5
LDAP Synchronization
User information on IDENTIKEY Server can be synchronized with external LDAP databases by using the LDAP Synchronization Tool. See the LDAP Synchronization Tool Guide for more details.
126
DIGIPASS
11
11.1
DIGIPASS
Importing DIGIPASS
DIGIPASS records may be imported into IDENTIKEY Server via its Administration Web Interface. DIGIPASS can be imported either one at a time, or many can be imported at one time. The DIGIPASS Import Wizard guides you through the steps of importing DIGIPASS from the .dpx file. You can specify the applications that will be available with the imported DIGIPASS, and whether the imported DIGIPASS will be set as Active or Inactive on import. You can also specify if existing DIGIPASS will be updated with the data from the .dpx import file.
11.2
Assigning DIGIPASS to Users

DIGIPASS may be assigned to Users in a number of ways, depending on the requirements of your company. For example, a company with only a few User accounts may use Manual Assignment. A larger company needing to distribute large numbers of DIGIPASS may find it easier to simply distribute the DIGIPASS and require each User to go through Self-Assignment.
Note
DIGIPASS records must be imported into the data store before being assigned to Users.
127
DIGIPASS 11.2.1 Self-Assignment

A DIGIPASS may be assigned to a User by their own action. The User must log in and include the serial number, static password and One Time Password. This informs the IDENTIKEY Server of the assignment, and provided that the User enters the details correctly, a link will be made between the DIGIPASS record and the User account. A grace period is not used for this method.
Image 45: Self Assignment Process
128
DIGIPASS 11.2.2 Auto-Assignment

The IDENTIKEY Server can automatically assign an available DIGIPASS when a DIGIPASS User account is created using Dynamic User Registration (DUR). The correct DIGIPASS must then be delivered to the User. A grace period is typically set, which allows a number of days in which the User may still log in using only their static password.
Image 46: Auto Assignment Process
11.2.3
Manual Assignment
A selected DIGIPASS is manually assigned to a specific DIGIPASS User account. The DIGIPASS must then be sent
129
DIGIPASS
out to the User. A grace period is typically set, during which the User may still log in using only their static password.
Image 47: Manual Assignment Process
11.3
DIGIPASS Record Functions

A number of functions are available to administer DIGIPASS records. These are typically required for maintenance eg. a User has forgotten their Server PIN, or a DIGIPASS has been locked.
11.3.1
Reset Application
A DIGIPASS Application may need to be reset if the time difference between it and the server needs to be recalculated. This would typically be for time-based Response Only DIGIPASS after a very long period of inactivity.
130
DIGIPASS
The 'reset' widens the allowable time window for the next login, allowing the User to log in and the IDENTIKEY Server to calculate the current time shift.
11.3.2
Set Event Counter

If the event count for an event-based application has become unsynchronised between the DIGIPASS and the server, this function can be used to set the server event count to the event count on the DIGIPASS.
11.3.3
Enable/Disable Server PIN

An administrator may enable or disable use of a Server PIN with a specific DIGIPASS token, or with multiple tokens. If Server PIN is enabled, the User must include their Server PIN when logging in. If Server PIN is disabled, the User must not include a Server PIN.
11.3.4
Reset PIN
If a Users Server PIN needs to be changed usually because the User has forgotten it then it can be reset, and the User can create a new Server PIN when they next log in. This may be done when unassigning or re-assigning a DIGIPASS.
11.3.5
Force PIN Change

This function can be used when an administrator wants a User to change their Server PIN on their next login. This may be desirable as a security measure.
11.3.6
Set PIN
A Users Server PIN can be set to a specific value and communicated to the User.
11.3.7
Unlock DIGIPASS
If a User incorrectly enters their DIGIPASS PIN into their DIGIPASS a predetermined number of times, the DIGIPASS will become locked. Once locked, the assistance of an administrator will be required to unlock it. This function allows an administrator to provide the User with an Unlock Code to enter into their DIGIPASS.
11.3.8
Reset Application Lock

If a User has attempted to log in with incorrect details too many times, the DIGIPASS Application used may be locked, depending on Policy settings. This function can be used to set the record for the DIGIPASS Application to the status of unlocked. This differs from User locking, as the User may still log in with a different DIGIPASS.
11.3.9
Test a DIGIPASS Application

Use this function to check that a DIGIPASS Application is working as expected. There is also a function to test the Backup Virtual DIGIPASS functionality. This works for either One Time Password or Signature.
11.3.10
Reset Activation
131
DIGIPASS
Use this function to reset the Event Counter, Activation time and Activation location on a DIGIPASS.
11.4
DIGIPASS Reports
IDENTIKEY Server comes with a wide variety of pre-set reports useful for managing and analyzing DIGIPASS activity. These reports are available via the Administration Web Interface, and can track the following statistics (among others): Assignment actions per user, organizational unit and domain Available DIGIPASS, broken down by type DIGIPASS deployment trends Breakdown of the number of deployed DIGIPASS per DIGIPASS type, further broken down by organizational unit List of all DIGIPASS, and the last time they were used Inactive DIGIPASS (i.e. DIGIPASS that have not been used for more than six months) For more information about reports, refer to 16 Reporting.
132
DIGIPASS
11.5
DIGIPASS Programming
Common settings which may affect your administration tasks are explained below.
11.5.1
DIGIPASS PIN
A DIGIPASS PIN may be required for a DIGIPASS. If set, the PIN must be entered into the DIGIPASS before obtaining a One Time Password. This means that just possessing the DIGIPASS is not enough to log in to a network the person logging in must also know the DIGIPASS PIN. DIGIPASS PIN settings include: An Initial PIN can be set for a DIGIPASS. The PIN must then be sent to the User of the DIGIPASS, typically separate from the DIGIPASS delivery. First Use PIN Modification allows a DIGIPASS to require a PIN change from the User upon first use. PIN Change allows a User to change their PIN as desired. The PIN Length can be set for a DIGIPASS. DIGIPASS Lock sets the number of consecutive faulty PIN entries allowed before the DIGIPASS is locked.
11.5.2
Time/Event-based DIGIPASS Applications Response Only

Response Only DIGIPASS Applications can be either time-based or event-based: Time-based A time-based Application will change the OTP to be displayed based on the current time. The common time step used is 36 seconds and means that the OTP to be displayed will change every 36 seconds, whether or not an OTP has been requested from the DIGIPASS. Event-based An event-based DIGIPASS Application will display a new OTP each time a request for an OTP is made.
Challenge/Response
Challenge/Response DIGIPASS Applications can be either time-based or non-time-based: Time-based A time-based Challenge/Response DIGIPASS Application will generate an OTP based on the Challenge given and the current time. The common time step used is 9 hours ('slow challenge'). This would mean that if the exact same Challenge were given to a DIGIPASS within a 9 hour period, the DIGIPASS Application will generate the same OTP. However, Challenges are very rarely repeated within such a time period.
133
DIGIPASS
Non-time-based A non-time-based Challenge/Response DIGIPASS Application will generate an OTP based only on the Challenge given.
Signature
Time-based The signature application may be time based. This means that the DIGIPASS will generate a different signature for the same input data at different times. Event-based The signature application may be event based. This means that it contains a numeric counter that increases every time a signature is generated. Neither Time- nor Event-based These signatures are generated using neither time or event counter. They will always produce the same signature for the same input. There is no difference between real-time and deferred time with these signatures.
11.5.3
OTP Length
The length of the OTP (excluding check digit) generated by the DIGIPASS for Response Only and Challenge/Response DIGIPASS Applications.
Check Digit
A check digit may be added to each OTP. This is generated from the response and allows for faster invalidation of incorrect OTPs.
11.5.4
Challenge Length
The length of the Challenge (excluding check digit) which should be expected by the DIGIPASS. This is used by the Challenge/Response DIGIPASS Application.
Check Digit
A check digit may be expected with each Challenge. This is generated by the server from the Challenge and allows the DIGIPASS to reject most invalid Challenges.
11.5.5
Signature Length
The length of the Signature generated by the DIGIPASS.
11.5.6
Signature Data Fields

134
DIGIPASS
These are the data fields that may be provided when signing a transaction. There may be from 1 to 8 fields, each with a minimum length of 0 and a maximum length of 16.
Check Digit
A check digit is optional.
11.6
DIGIPASS Record Settings

These settings are kept in the record for a DIGIPASS Application, and affect which OTP is expected by the IDENTIKEY Server.
11.6.1
Time/Event-based Settings Time Step Used

The time step used by the DIGIPASS Application (see Time/Event-based DIGIPASS Applications for more information).
Last Time Shift

Time Shift records any misalignments between the time recorded on the DIGIPASS and the time recorded on the server, each time a User logs in. This ensures that if either clock drifts from the correct time, an allowance can be made by the IDENTIKEY Server and the User will still be able to log in. If the time drift goes beyond the allowable time window between User logins, the DIGIPASS record will have to be reset (this allows for recalculation of the time drift).
Example
Time window may be 5 steps in either direction. This means that 11 OTPs would be considered valid the exact OTP for that time, and the OTPs for the 5 time steps either side of the exact time. If the OTP given is for a different time step, the time shift for that DIGIPASS will be recorded. The next time the User logs in, the expected OTP will be calculated based on that time shift.
Last Time Used

This records the time when the DIGIPASS Application was last used. If the amount of time lapsed between authentications is greater than the expected time drift for the DIGIPASS, the time window is widened to allow a greater number of One Time Passwords to be accepted.
Last Event Value

The current number of uses of the DIGIPASS Application, according to the DIGIPASS. This can get out of sync with the number of uses recorded by the IDENTIKEY Server when:
135
DIGIPASS
Login failures occur for other reasons than incorrect OTP The DIGIPASS has been used without a login (eg. children have been playing with it) The DIGIPASS is being used to log in to two separate systems The purpose of this setting is much the same as the Last Time Shift setting it allows the IDENTIKEY Server to track any shifts between the event count recorded by itself and the DIGIPASS.
11.6.2
Server PIN
The term 'Server PIN' is used to mean a PIN that the user enters into the login password field in front of the OTP displayed on the DIGIPASS. It is checked by the authenticating server. The 'DIGIPASS PIN' referred to earlier indicates a PIN entered into a keypad on the DIGIPASS. That is checked by the device itself, and is never transmitted to the server. There are a number of Server settings regulating Server PINs: PIN Supported Whether a PIN must be included in a User's login. PIN Change On Is a User allowed to change their Server PIN for this DIGIPASS? Force PIN Change Must the User change their Server PIN the next time they log in? PIN Length The length of the current Server PIN. PIN Minimum Length The minimum PIN length required by the Server.
11.6.3
Backup Virtual DIGIPASS Policy and DIGIPASS settings

Several settings dictate how a User may utilize the Backup Virtual DIGIPASS feature. These settings are: Enable or disable Backup Virtual DIGIPASS and enable method (eg. Required). Time limit/expiry (applies to Time Limited enable only) Maximum number of times a User may make use of the Backup Virtual DIGIPASS. The above settings may be set both at the Policy level and at the DIGIPASS record level. Individual settings override Policy settings for an individual DIGIPASS, but some Policy settings (see below) may be used to automatically set DIGIPASS settings which are blank when the Backup Virtual DIGIPASS is first utilized by the User.
136
DIGIPASS
Time Limit and Max. Uses/User Policy Setting
Time Limit Max. Uses/User
DIGIPASS Setting
Enabled Until Uses Remaining
Table 1: Backup Virtual DIGIPASS Policy/DIGIPASS Settings
If Backup Virtual DIGIPASS is enabled for a DIGIPASS and set to Time Limited, and the Enabled Until field in the DIGIPASS property sheet is blank on their first use of the Backup Virtual DIGIPASS, their time limit will begin on their first use of the feature. The expiry date (todays date + Time Limit) will then be displayed in the Enabled Until field. If a Max. Uses/User is set for the relevant Policy and a DIGIPASS record's Uses Remaining field in their User property sheet is blank on their first use of the Backup Virtual DIGIPASS, a number (Max Uses/User) will be automatically entered into their Uses Remaining field and immediately decremented by 1.
Note
If a User has Backup Virtual DIGIPASS enabled with Enabled Until date set and their Uses Remaining has been set (automatically or manually), whichever of these expires first will disable Backup Virtual DIGIPASS for the User. eg. Backup Virtual DIGIPASS is enabled for a User as Time Limited, and the server Time Limit setting is 3 days. The Max. Uses/User Policy setting is 5. When the User first makes use of the Backup Virtual DIGIPASS, their Enabled Until is set to a date 3 days hence and their Uses Remaining to 4. During the next 48 hours, they log in 4 more times. Although the Users time limit does not run out for another 24 hours, their Uses Remaining is now 0 and Backup Virtual DIGIPASS is disabled.
137
DIGIPASS
11.7
11.7.1
Virtual DIGIPASS Implementation Considerations

DIGIPASS Assignment Options
With the introduction of Virtual DIGIPASS, there are several different assignment combinations that can be used. The first option in the table below does not utilize Virtual DIGIPASS. The others include a Virtual DIGIPASS in either a backup or primary mode. Primary
DIGIPASS DIGIPASS None Backup Virtual DIGIPASS
Backup
User must log in using a DIGIPASS. User usually logs in using a DIGIPASS, but may utilize the Backup Virtual DIGIPASS feature where required. Usage of the feature may be limited. User must log in using the Backup Virtual DIGIPASS feature. This might be used while a Users DIGIPASS is lost, until the DIGIPASS is recovered. User is assigned a Virtual DIGIPASS and must log in using it.
DIGIPASS (temporarily disallowed)
Backup Virtual DIGIPASS
Primary Virtual DIGIPASS N/A Table 2: DIGIPASS Options
11.7.2
Cost
Your company will probably need to pay an amount for each text message sent. In some countries, mobile phone owners might need to pay an amount for each text message received on their mobile phone. This will need to be taken into consideration when deciding how to implement Virtual DIGIPASS functionality.
11.7.3
Security
Hardware DIGIPASS devices provide the highest level of security. Virtual DIGIPASS provides a lower, although still high, level of security. This needs to be weighed against other considerations before deciding whether your company will implement Virtual DIGIPASS, and if so, how it will be implemented.
11.7.4
Convenience
Virtual DIGIPASS is more convenient than a hardware DIGIPASS for many Users. Only ones usual mobile phone is required: there are no extra devices to carry around. Users who do not habitually carry their mobile phone with them, though, are likely to find a GO 3 or GO 1 easier to transport. For Users with the Backup Virtual DIGIPASS enabled, it might be the difference between going to work to pick up a forgotten DIGIPASS and getting important work done at home.
138
DIGIPASS 11.7.5 Gateway and account

Your company will need the use of an text message gateway and an account with the gateway. The Message Delivery Component will need configuration information for the gateway and the Username and password for the account. Your VASCO supplier can assist with this process.
11.7.6
Limiting Usage of Virtual DIGIPASS

Use of Virtual DIGIPASS may be limited by: Using Backup Virtual DIGIPASS only. Minimizing the number of Users assigned a Primary Virtual DIGIPASS. A Users Primary Virtual DIGIPASS use cannot be limited. The Backup Virtual DIGIPASS feature may be enabled as an emergency backup for Users who have left their primary DIGIPASS at home, or for other reasons do not have access to their primary DIGIPASS. Use of this feature can be limited for each DIGIPASS by: Time period Set a time period in which a User may access the Backup Virtual DIGIPASS. After this period has expired, any Virtual DIGIPASS requests from the User will be rejected. If the User is still unable to use their DIGIPASS, the time period must then be extended by an administrator. Once they have started using their DIGIPASS again, the administrator must reset the time period if the User is to be allowed to use Backup Virtual DIGIPASS again. Number of Uses Set a maximum number of times a User may request an OTP using the Backup Virtual DIGIPASS feature. When the User has reached this number of uses, any further OTP requests from the User will be rejected. This must be reset by an administrator if further use of the Backup Virtual DIGIPASS is required for the User. Global and Individual Backup Virtual DIGIPASS settings Backup Virtual DIGIPASS options can be set globally or individually, to allow a standard policy for all DIGIPASS with exceptions made where necessary. Global settings will affect all DIGIPASS whose individual option is set to 'Default'. Global options are defined in the Policy that controls authentication. Therefore, by using multiple Policies, you have some additional flexibility.
11.7.6.1
Backup Virtual DIGIPASS Usage Guidelines
Some questions which will need to be answered before arriving at a Backup Virtual DIGIPASS usage guidelines are: Will any users have access to Backup Virtual DIGIPASS? If so, will all users have access to Backup Virtual DIGIPASS?
139
DIGIPASS
Will usage of Backup Virtual DIGIPASS be limited? If so, how? Time-limited? Limited number of uses? Some Possible Guidelines Guideline Pro Con
Manual enable for each User and circumstance. Possible heavy administration load. Administrator may need to reset limits frequently medium administration load. Possible high text message costs. Backup Virtual DIGIPASS disabled for all - Low text message costs enabled for individual Users as required. Backup Virtual DIGIPASS enabled for all either time/number of usage limit set. Backup Virtual DIGIPASS enabled for all no limits set. Predictable text message costs
Lighter administration load
Table 3: Backup Virtual DIGIPASS Example Guidelines
11.7.7
Resetting Virtual DIGIPASS Restrictions

When a User has reached their limit of Virtual DIGIPASS use, an administrator must reset their limit.
11.7.8
Virtual DIGIPASS Login options

A decision must be made as to how Users will log in using Virtual DIGIPASS. In particular, Users with a hardware DIGIPASS and the Backup Virtual DIGIPASS enabled must be able to request an OTP to be sent to their mobile when required, but to login using the hardware DIGIPASS at other times. The simplest method for the User is to allow a 2-step login process, where the User enters their User ID and password only, triggering an OTP Request, and are redirected to a second login page to enter the OTP sent to them. To use this method, though, your system must be set up to allow 2-step logins. Check with your system administrator if unsure. Alternatives to the 2-step login are a sequence of two 1-step logins or the use of a specific web page to request an OTP, separate from the login page screen. See the Administrator Reference for information on possible login permutation.
140
Task Scheduling
12
12.1
Task Scheduling
What is Task Scheduling?
Task Scheduling allows selected tasks to be scheduled to run at specific times. Certain tasks can be scheduled to run either immediately, or at certain times on certain days in the future. The schedule for each task must be defined using the Task Scheduling pages in each relevant wizard on the Administration Web Interface. For each Scheduled Task, you can set the required time and date, and also configure your preferred notification method (an SMS or Email notification can be sent to you when the task is completed). You can also schedule recurring tasks for running reports. These can be scheduled to recur on a daily or monthly basis. The Task Scheduling page in the Administration Web Interface lists all scheduled tasks. If an Administrator has the 'view tasks' privilege they will be able to see all scheduled tasks.
12.2
How Does Task Scheduling Work?

When a task is scheduled its details are stored on the data store. The tasks run at the scheduled date and time, and audit messages are generated for their start, end, and result transactions. The results of the task are communicated to the task owner via SMS or Email, if desired.
12.3
Tasks that can be Scheduled

Only certain categories of tasks may be scheduled: User import Reports DIGIPASS DPX file import (with restrictions) Cryptographic Key rotations
12.4
Available Functions
On the Task Management pages the following functions are available:
Future Tasks
Edit Delete
141
Task Scheduling
Suspend Resume
Running Tasks
Cancel
12.5
Schedule Timing Options

There are various timing options available for Task Scheduling. The availability of these settings will vary depending on task and circumstance. Run Immediately runs the task in the foreground, and ties up the Administration Web Interface session until the task is complete Run in Background runs the task in the background, and allows the Administration Web Interface session free to perform other processing. Scheduled Yes plus no scheduled date will run the job in foreground immediately Yes plus schedule details will run the job in background at the scheduled time No will run the job immediately in foreground Notify Me of Completion by Select Email or SMS Schedule details Date Time Recurring whether task is recurring Recurrence Settings Recurrence type daily, monthly For Daily, select one or more days. These tasks will recur on a weekly basis. For monthly, indicate which day of the month to run the task
12.6
Restrictions
There are restrictions as to how tasks may be scheduled, and where they can be scheduled from. The DIGIPASS Import task can only be run immediately and in foreground. It cannot be scheduled for a later date. You cannot schedule tasks for a server from another server. You may only schedule tasks for a specific server if you are logged on to that server. You can only edit tasks for the server you are logged on to. To edit tasks on a different server you must log on to
142
Task Scheduling
that server.
12.7
Result Notification
Results of sheduled tasks can optionally be advised via: SMS Email The result notification method is configured on the Task Scheduling pages.
143
Client Components
13
13.1
13.1.1
Client Components
Component Types
SOAP Client Programs
SOAP client programs will not be called 'SOAP clients'. The program itself specifies the type, as a parameter to each request. A client component record must exist for this type at the location (IP address) where the application runs. The policy in the component record will be used for all processing of requests from this client.
13.1.2
Administration Program
Creating a Component record for a VASCO administration program - either the Web Administration Interface or the Audit Viewer - allows a Policy to be set for connections from that program. A Component record MUST exist for each Web Administration Interface or any other administration program using SOAP. For the IDENTIKEY Server SEAL interface for TCL and the Audit Viewer, SEAL Require administration client component registration configuration setting determines whether an Administration Program component must be provided or not.
13.1.3
RADIUS Client
A RADIUS Client Component record is required when clients will be sending authentication requests to the IDENTIKEY Server using the RADIUS protocol. The IDENTIKEY Server will check the Component record to find: The Shared Secret to use in communicating with the RADIUS Client. The Policy to apply to the authentication request. A default RADIUS Client Component record is automatically created during installation of IDENTIKEY Server. This can be deleted and specific records created for each location.
Note
The default RADIUS Client created during installation will be given a Shared Secret of default.
144
Client Components 13.1.4 IIS Module

A Component record is required for any IIS Modules used with IDENTIKEY Server. The Component record will be checked whenever the IIS Module sends an authentication request to the IDENTIKEY Server. The IDENTIKEY Server will check: That the Component record contains a valid License Key for a Client module Which Policy to apply to the authentication request The following client types fall under this category: Citrix Web Interface Outlook Web Interface IIS 6 Module
13.1.5

A Client Component record is required for DIGIPASS Authentication for Windows Logon for each User for each IP address they are using to log on to Windows. DIGIPASS Authentication for Windows Logon uses Dynamic Client Registration to ensure that the correct Client Component record is available when required.
13.1.5.1
Dynamic Client Registration
Dynamic Client Registration must be enabled on the Windows Logon Policy. Dynamic Client Registration: Checks to see if a Client component already exists for the User at that IP address Creates a Client component if it doesn't exist See the DIGIPASS Authentication for Windows Logon Product Guide for further details on the functionality and settings for Dynamic Client Registration.
145
Server Components
14
14.1
Server Components
Server Component
A Server Component record holds the License Key for a specific IDENTIKEY Server. This Component record will be checked when the IDENTIKEY Server is started. The IDENTIKEY Server will check for: License Key. If the License Key is missing, invalid or expired, all authentication except for administration logons will be refused. The following items need to be supported in the Licence Key: RADIUS SOAP Authentication scenario Signature Validation scenario Provisioning scenario DIGIPASS Authentication for Windows Logon The Policy to use for SEAL administration logins. If an ODBC database (including the embedded PostgreSQL database) is used as the data store, the Policy will be applied to all administration logins (including live audit connections) for which an Administration Program Component record is not found. A Server Component record is automatically created for each IDENTIKEY Server as it is installed.
146
Policies
15
15.1
Policies
Policy Inheritance
Policies may be set up in a hierarchy, where one Policy will inherit most of its attributes from a parent Policy, but with some modifications for a slightly different scenario.
Image 48: Policy Inheritance
147
Policies
In the example above, all attributes are inherited from the parent Policy. The attributes shown in the child policies above are explicitly set, which make the policy different from the parent policy. The explicitly set attributes in the child policies override those of the parent policies.
15.1.1
Show Effective Settings

As the various levels of settings in Policy inheritance can get confusing, functionality is available which allows you to view the settings effective for a selected Policy, taking inherited settings into account. The text below shows the effective settings for the IDENTIKEY Server RADIUS Self-Assignment Policy:
Effective Policy Settings [Local/Back-End Authentication] Local Authentication : Digipass/Password Back-End Authentication : Always Back-End Protocol : RADIUS User Accounts] Dynamic User Registration : Yes Password Autolearn : Yes Stored Password Proxy : Yes Default Domain: (none) User Lock Threshold : 3 [Windows Group Check] Group Check Option : No Check Group List: (none) [DIGIPASS Assignment] Assignment Mode : Self-Assignment Grace Period (days) : 0 Serial No. Separator : | Search up Organizational Unit Hierarchy : Yes [DIGIPASS Settings] Application Names Application Type : No Restriction DIGIPASS Types PIN Changed Allowed : Yes [1-Step Challenge Response] Enabled : No Challenge Length : 0 Challenge Check Digit : No [2-Step Challenge Response] Request Method : Keyword Request Keyword [Primary Virtual DIGIPASS] Request Method : Password Request Keyword [Backup Virtual DIGIPASS] Enabled : No Maximum Days : 0 Maximum Uses : 0 Request Method : KeywordPassword Request Keyword : otp [Digipass Control Parameters] Identification Time Window : 20
148
Policies
Signature Time Window:24 Event Window : 20 Initial Time Window : 6 Identification Threshold : 0 SignatureThreshold : 0 Check Challenge Flag : 1 Level of Online Signature : 0 Allowed Inactive Days : 0
You will note that the settings listed above include those set in Policies from which the IDENTIKEY Server RADIUS Self-Assignment Policy inherits.
149
Policies
15.2
Pre-Loaded Policies
These Policies are created for the IDENTIKEY Server on installation of the IDENTIKEY Server. They provide an example for setting up Policies in a typical environment.
Table 4: Pre-Loaded Policies

Policy Name
Base Policy -
Parent Policy
Description
Globally applicable settings. In general, all other Policies should inherit from this, directly or indirectly.
Non-Default Settings
User Lock Threshold=3 PIN Change Allowed=Yes Challenge Request Method=Keyword Primary VDP Request Method=Password Backup VDP Request Method=KeywordPassword Backup VDP Request Keyword=otp Identification Time Window=20 Check Challenge Mode=1 Event Window=20 Sync Window=6 Online Signature Level= 0 Identification Threshold=0 Local Authentication=None Back-End Authentication=None DUR=No Password Autolearn=No Stored Password Proxy=No Group Check Mode=No Check Assignment Mode=Neither Search Up OU Path=No Application Types=No Restriction 1-Step Challenge/Response=No 1-Step Challenge Check Digit=No Backup VDP Enabled=No Local Authentication=DIGIPASS/Password User Lock Threshold=0
IDENTIKEY Administration Logon
Base Policy
Settings for an administration logon including Audit Viewer live connection. Separated from the main authentication policies to avoid accidental interference. Locking is off to reduce the chance of a lock-out.
150
Policies
Policy Name
IDENTIKEY Local Authentication
Parent Policy
Base Policy
Description
Settings applicable to all Local IDENTIKEY Server authentication Authentication=DIGIPASS/Password Policies, including local authentication. In general, all other IDENTIKEY Server Policies using local authentication should inherit from this, directly or indirectly. IDENTIKEY Server model for password replacement and Dynamic User Registration, using Windows back-end authentication. Back-End Authentication=Always Back-End Protocol=Windows DUR=Yes Assignment Mode=Neither Password Autolearn=Yes Stored Password Proxy=Yes Local Auth=Default Backend Auth=Always Backend Protocol=Microsoft AD DUR=Yes Password Autolearn=Yes Stored Password Proxy=Yes
IDENTIKEY Windows IDENTIKEY Local Password Replacement Authentication
IDENTIKEY Microsoft AD IDENTIKEY Local Password Replacement Authentication
IDENTIKEY Server model for password replacement with Microsoft Active Directory (LDAP connection).
IDENTIKEY Novell eDirectory Password Replacement
IDENTIKEY Server model for Local Auth=Default password replacement with Novell Backend Auth=Always e-Directory (LDAP connection). Backend Protocol=Novell e-Directory DUR=Yes Password Autolearn=Yes Stored Password Proxy=Yes IDENTIKEY Server model for password replacement for Microsoft ADAM (LDAP connection). Local Auth=Default Backend Auth=Always Backend Protocol=Microsoft ADAM Password Autolearn=Yes Stored Password Proxy=Yes
IDENTIKEY Microsoft ADAM Password Replacement
IDENTIKEY Windows Auto-Assignment
IDENTIKEY Windows IDENTIKEY Server model for Auto- Assignment Mode=Auto-Assignment Password Assignment based on the Search Up OU Path=Yes Replacement Windows password replacement Grace Period=7 model. IDENTIKEY Server model for Auto Assignment for Microsoft Active Directory Local Auth=Default Backend Auth=If Needed Backend Protocol=Microsoft AD Assignment Mode=Auto-Assignment Search-Up-OU-Path=Yes Local Auth = Default Backend Auth = If Needed Backend Protocol = Microsoft ADAM Assignment Mode = Auto-Assignment Search-Up-OU-Path = Yes
IDENTIKEY Microsoft AD IDENTIKEY Local Auto Assignment Authentication
IDENTIKEY Microsoft IDENTIKEY ADAM Auto Assignment Microsoft ADAM Password Replacement
IDENTIKEY Server model for Auto Assignment for Microsoft ADAM
151
Policies
Policy Name
IDENTIKEY Windows Self-Assignment
Parent Policy
Description
Assignment Mode=Self-Assignment Search Up OU Path=Yes Self Assignment Separator=| Local Auth = Default Backend Auth = Always Backend Protocol = Microsoft AD Assignment Mode = Self-Assignment Search-Up-OU-Path = Yes Local Auth = Default Backend Auth = If Needed Backend Protocol = Microsoft ADAM Assignment Mode = Self-Assignment Search-Up-OU-Path = Yes Local Auth = Default Backend Auth = Always Backend Protocol = Novell e-Directory Assignment Mode = Self-Assignment Search-Up-OU-Path = Yes Backend Authentication=Always Backend Protocol=RADIUS Password Autolearn=Yes Stored Password Proxy=Yes
IDENTIKEY Windows IDENTIKEY Server model for SelfPassword Assignment based on the Replacement Windows password replacement model. IDENTIKEY Server model for SelfAssignment for AD Password Replacement
IDENTIKEY Microsoft AD IDENTIKEY Self Assignment Microsoft AD Password Replacement IDENTIKEY Microsoft IDENTIKEY ADAM Self Assignment Microsoft ADAM Password Replacement IDENTIKEY Novell eDirectory Self Assignment
IDENTIKEY Server model for SelfAssignment for ADAM Password Replacement
IDENTIKEY Novell e- IDENTIKEY Server model for selfDirectory Password assignment for Novell e-Directory Replacement
IDENTIKEY RADIUS IDENTIKEY Local Password Replacement Authentication
IDENTIKEY Server model for password replacement and Dynamic User Registration using a RADIUS server for back-end authentication.
IDENTIKEY RADIUS Auto-Assignment
IDENTIKEY Server model for Auto- Grace Period=7 Assignment based on the RADIUS Search Up OU Path=Yes password replacement model. Assignment Mode=Self-Assignment IDENTIKEY Server model for Self- Search Up OU Path=Yes Assignment based on the RADIUS Assignment Mode=Self-Assignment password replacement model. Self Assignment Separator=| IDENTIKEY Server model for only Backend Protocol=RADIUS Back-End Authentication. Change Backend Authentication=Always the back-End Protocol to the one required. IDENTIKEY DIGIPASS for Web Local Auth = DIGIPASS/Password Provisioning model scenario 1 1-Step Challenge/Response=Yes-Any Activation codes are encrypted challenge with pre-loaded static passwords.
IDENTIKEY RADIUS Self-Assignment
IDENTIKEY Back-End Authentication
Base Policy
IDENTIKEY DP110 Provisioning 1
Base Policy
152
Policies
Policy Name
IDENTIKEY DP110 Provisioning 2
Parent Policy
Base Policy
Description
IDENTIKEY DP110 Provisioning model scenario 2 - Dynamic Registration using Back-End System. Change the Back-End Protocol to the one required. IDENTIKEY DIGIPASS for Mobile Register - pre-loaded User accounts and static passwords. IDENTIKEY Digpass for Mobile provisioning model scenario 1 IDENTIKEY DIGIPASS for Mobile provisioning model scenario 2
Local Auth = DIGIPASS/Password Back-End Authentication = Always 1-Step Challenge/Response=Yes Any challenge Online Signature Level = 1 Multiple Signatures allowed in same Time Step
IDENTIKEY DP4Mobile Register IDENTIKEY DP4Mobile Provisioning 1 IDENTIKEY DP4Mobile Provsioning 2
Base Policy
Base Policy Base Policy
Local Authentication = DIGIPASS/PASSWORD Backend authentication= NONE DIGIPASS type: MOB30 Local Authentication = DIGIPASS/PASSWORD Backend authentication= IF NEEDED DIGIPASS type: MOB30
IDENTIKEY DP4Mobile Provsioning 3
Base Policy
IDENTIKEY DIGIPASS for Mobile provisioning model scenario 3
IDENTIKEY DP4Web Provisioning 1
Base Policy
IDENTIKEY DIGIPASS for Web Provisioning model scenario 1 Activation codes are encrypted with pre-loaded static passwords. IDENTIKEY DIGIPASS for Web Provisioning model scenario 2 pre-loaded User accounts and static passwords. Local Auth = DIGIPASS/Password
Base Policy
Base Policy
IDENTIKEY DIGIPASS for Web Local Auth = DIGIPASS/Password Provisioning model scenario 3 DUR=Yes Dynamic Registration using BackEnd System. Change the Back-End Protocol to the one required. Deferred time signature verification settings: Time based. Signature Time Window = 24
IDENTIKEY Deferred Time signature Verfication IDENTIKEY Real-Time signature verfication 1
Base Policy
Base Policy
Real-time signature verification Online signature level = 1 - Multiple settings: Time-based, several Signatures allowed in same Time Step signatures are allowed in the same timestep but 2 identical successive signatures will be rejected. Real-time signature verification settings: Time-based, one signature allowed per timestep. Online signature level = 2 - Only 1 Signature/Time Step allowed
IDENTIKEY Real-Time signature verfication 2
Base Policy
153
Policies
Policy Name
IDENTIKEY Real-Time signature verfication 3 Windows logon online authentication Windows Back-End
Parent Policy
Base Policy
Description
Deferred time signature verification settings: Event based, off-line mode. Windows Logon with Windows Back-End
Signature Time Window = 24
Back-End Authentication = Always Back-End Protocol = Windows Dynamic Component Registration = Yes Enable Random Password = No Client Group List = Client Group Mode = No check Offline Authentication = No Back-End Authentication = Always Back-End Protocol = Microsoft AD Dynamic Component Registration = Yes Enable Random Password = No Client Group List = Client Group Mode = No check Offline Authentication = No
Windows logon online authentication - LDAP AD Back-End
Windows Logon for LDAP AD Back-End
Windows logon online and offline authentication Windows Back-End Windows logon online and offline authentication LDAP AD Back-End
Windows logon Windows logon online and offline OfflineOffline Authentication = Yes online authentication for Windows Back- Offline Time Window (days) = 21 authentication End Offline Event Window = 300 Windows Back-End Windows logon Windows logon online and offline online authentication settings for LDAP authentication AD Back-End LDAP AD Back-End Offline Authentication = Yes Offline Time Window (days) = 21 Offline Event Window = 300
154
Reporting
16
Reporting
IDENTIKEY Server allows you to define and run a wide range of detailed reports, with low-level control of aspects including desired fields, runtime query options, permissions, templates and scheduling. You can use pre-defined standard reports, which can be edited, or you can define elements to create your own customised reports. For detailed instructions on reporting tasks, refer to the Reporting chapter in the Administrator Guide.
16.1
Understanding Reports
Reports are created by collecting and manipulating data from a variety of sources. The principle concepts and features are described in this section.
Report Type
There are four general types of IDENTIKEY Server report: List Analysis Report: lists all items that match the criteria specified in the report definition. For example, a list of users with no DIGIPASS assigned. Detailed Analysis Report: shows detail of the events specified in the report definition. For example, a detailed list of failed authentications for a User. Distribution Analysis Report: shows a count of events and objects. For example, the number of failed authentications for a domain. Trend Analysis Report: shows a trend over a period of time for a the objects specified in the report definition. For Trend Analysis Reports there is an extra parameter. The period of time for which the data needs to be extracted must be specified by Hour, Day, Month, and Year. All reports, whether standard or custom, are based on these report types. Each report type retrieves information from either the audit data, the Data Store, or from both sources.
Grouping Level
The Grouping Level specifies how the data in the report will be grouped. The Grouping Level choices are: Client Domain Organganisational Unit User DIGIPASS If a Detail or List Report is set at Grouping Level of User, each user will be represented individually. If a Detail or List report is set at Grouping Level of Organizational Unit, the data for all the Users in that Organizational Unit will be added together and represented only once under the Organizational Unit.
155
Reporting Data Source

Each report is generated from data existing on IDENTIKEY Server. The choices for Data Source are: Users. This will generate the report based on the User information from the IDENTIKEY Server Data Store. Users + Audit Data. This will generate the report based on the User information mentioned above, and the Audit Data from IDENTIKEY Server. DIGIPASS. This will generate the report based on the DIGIPASS information from the IDENTIKEY Server Data Store. DIGIPASS + Audit Data. This will generate the report based on the DIGIPASS information mentioned above, and the Audit Data from IDENTIKEY Server. Audit Data only. This will generate the report based on the Audit data only.
Fields
You can filter report data at a field level, but only for Detailed Analysis or List Analysis reports, and only where data is selected from the Audit data source. If no specific fileds are selected, then all fields are included in the report. For example, your report could display the number of session times over one hour within the past week.
Query
You can further customise reporting data by setting one or more Queries. For example, to generate a report for a specific Audit message, such as 'Authentication' you can specify in your Query that Audit Message = 'Authentication'. You will then only receive information on 'Authentication' Audit Messages in your report. You can use multiple queries to gain even more fine-grained control of data. For example, the Authentication Activity by Client report includes the following query data: Audit:Category equals Authentication, Audit:Type equals success, Audit:Code equals S-002001, Audit:Code equals S-010001 The Query value field can recognise free text for time values. For example: Audit:Timestamp + is greater than + 6 months ago
Permissions
Each report definition has an owner. The owner is usually the Administrator that created the report, but ownership can be transferred to another Administrator in the same Domain. Permissions associated with each report determine: Who can run the report. Use can be restricted to the report owner, or it can be granted to other administrators. Who can change the report definitions. The ability to change the report format and details can be restricted to
156
Reporting
the report owner, or it can be granted to other administrators. Who can view the report. Usage permissions There are three types of usage permissions: Private only the owner can view and run the report. Public all administrators in all domains can view and run the report. Domain the report can be run and viewed only by administrators that belong to the domain where the report was defined. Change Permissions There are three types of change permissions: Private only the owner can change the report. Public all administrators in all domains can change the report. Domain the report can be changed only by administrators that belong to the domain where the report was defined. Permissions for standard reports The standard reports have 'private' permissions relating to changing the reports, and 'public' permissions relating to running and viewing the reports.
Templates
Reports can be generated in XML, HTML or PDF format. When defining a report, you can either: use the default XML or PDF templates, or provide your own custom template definition. Templates are defined when creating a report, and then selected from a list when running the report. Each report definition can have more than one formatting template. Report data is always generated (initially ) into XML. An SQL query retrieves the data that is required for the report. The generation process thereafter depends on the required output: XML and HTML Reports An XSLT transformation is applied to give the requested output. The result of the SQL query and the report type are then combined into an XML report. The XML report and the report format template are combined to produce the finished report in the required format (XML or HTML). PDF The XML data is run through a PDF generator to produce a basic PDF report. This is then combined with the template data, including header, footer and logo data, to provide a finished PDF with bookmarked headline sections. The PDF header, footer and logo data can be customised, or use the standard template.
157
Reporting Report Retrieval

If a report has been created in PDF format, the saved report can be retrieved using the Administration Web Interface System tab. The PDF report may be opened directly from the Administration Web Interface, or it may be saved.
16.2
Considerations for Reporting and Auditing

When creating reports you should consider how your data is stored, made available for reports, and archived. The reports you can run use the audit data and the Data Store. An issue arises when you have more than one IDENTIKEY Server in your system. Audit messages can be stored on a database or in local text files. The database storage option can be local or centralised; text files are local. A report can only be run on one source of audit data, so if there is more than one IDENTIKEY Server you have the following options to enable reports to run on all the audit data:
Online Centralized Database.
Have a centralized Audit database. All IDENTIKEY Servers write to this database all the time. All reports can be run against this database all the time. If the centralized database is used it must be configured to be fast enough and big enough to cope with the load of Audit data.
Offline Centralized Database
Write the Audit data locally but periodically load the local data to a centralized Audit database. Each IDENTIKEY Server must be configured to read the Audit data from the centralized database. Reports will only contain data up to the last load to the centralized Audit Database.
Offline Centralized Database with Reporting Server
Write the Audit data locally but periodically load the local data to a centralized Audit database. Each IDENTIKEY Server must be configured to read the Audit data from the local Audit data source. A reporting server can be installed that is configured to read its data from the centralized Audit database. Reports that need to use up to the minute data can be run on the server that retrieves its data locally. An example of this would be a user activity report for troubleshooting. Reports that need to use global data can be run on the reporting server. Reports will only contain data up to the last load to the centralized Audit Database.
No Centralized Audit Data
Configure each IDENTIKEY Server to retrieve Audit report data locally. An option to Upload Audit Data is available in the Configuration Wizard. This will allow you to configure IDENTIKEY Server to upload local Audit Data to a centralized Audit Database.
158
Reporting Archiving Strategy

If you are running reports that will require data which is spread out over a long period of time, the reports will take a long time to run as the volume of data gets bigger. The best way of dealing with this growth is to archive the data. It is best to develop a good archiving strategy when your system is being implemented. Consider the kind of data you will want to report on, and the length of time you would like data to be available before being archived. Remember, archived data cannot be reported upon.
159
Wireless RADIUS
17
17.1
Wireless RADIUS
Overview
IDENTIKEY Server supports authentication over a wireless connection, using the RADIUS protocol.
17.1.1
Wireless RADIUS Terminology Used

Term
Supplicant Wireless Access Point Authenticator
Usage in 0
The machine from which a wireless access request originates. A wireless network signal transmitter and receiver. The machine to which the Wireless Access Point passes authentication requests.
17.2
Wireless Network Encryption

The Wireless Access Point must be configured to use one of the following wireless protocols: WPA Enterprise WPA2 Enterprise
Caution
VASCO does not recommend the use of the TKIP encryption algorithm on wireless networks due to inherent security issues. Configure your WAP(s) to use the AES algorithm.
17.3
Fast Reconnect
Wireless sessions may be renewed at regular intervals by using Fast Reconnect.
160
Wireless RADIUS
When an OTP Authentication is performed, a Session ID is assigned to the wireless connection. A Fast Reconnect uses this Session ID to automatically re-authenticate the wireless connection rather than requiring User ID and One Time Password input from the User.
Image 49: Fast Reconnect overview
17.3.1
Fast Reconnect Authentication Process
Image 50: Fast Reconnect authentication process
161
Wireless RADIUS 17.3.2 Roaming Connections

Users are considered to be 'roaming' where: multiple Wireless Access Points are available, and the User may connect to more than one Wireless Access Point, and the User will be moving from the range of one Wireless Access Point to another. A change from one Wireless Access Point to the next can be made without inconvenience to the User when Fast Reconnect can be used between the Access Points.
Note
Roaming Connections are not supported over multiple IDENTIKEY Servers. Fast reconnect will only work for roaming wireless connections where: All Wireless Access Points are sending authentication requests to the same IDENTIKEY Server, and All Component records for the Wireless Access Points are using the same Policy, and All Wireless Access Points are configured to use the same SSID
Image 51: Roaming Wireless Fast Reconnection
162
Wireless RADIUS
17.3.2.1 Multiple Roaming Zones
Multiple roaming zones where roaming wireless connections are not permitted between zones - may be established by assigning different SSIDs to Wireless Access Points in different zones, and using different Policies for Components in each Zone.
Image 52: Roaming Wireless Fast Reconnection Roaming Zones
163
IDENTIKEY Server Data Store
18
18.1
18.1.1

Active Directory
What is Stored in Active Directory?
The following information is stored in Active Directory: DIGIPASS User accounts DIGIPASS and DIGIPASS Application records DIGIPASS configuration records (Policies, Components, Back-End Servers, Reports and Report Formats) IDENTIKEY Server Configuration information
18.1.2
Schema Extensions User attributes vasco-UserExt class

Extra VASCO attributes are added to an Active Directory User record via an 'auxiliary class' vasco-UserExt on the User class.
DIGIPASS and DIGIPASS Application records

The vasco-DPToken class is used to store DIGIPASS attributes. It is also a container, in which vasco-DPApplication records for that DIGIPASS are stored. Upon assignment to a User, the DIGIPASS record is stored in the same location as the User.
Policies, Components and Back-End Servers

Policy, Component, Back-End Server, Report and Report Format records are stored in vasco-Policy, vascoComponent, vasco-BackEndServer, vasco-Report and vasco-ReportFormat objects respectively. They are located in a single DIGIPASS-Configuration container in a single Domain.
18.1.3
18.1.3.1
DIGIPASS Records
Location of DIGIPASS Records
When a DIGIPASS is assigned to a User, it is moved to the same location as the DIGIPASS User account it is assigned to. This makes it easier to set up the permissions necessary for delegated administration.
164
Note
A DIGIPASS record will not automatically be moved when the User account to which it is assigned is moved to another location. When moving User accounts within Active Directory, ensure that the records of any assigned DIGIPASS are manually moved to the same location. Unassigned DIGIPASS records may be stored in various places in the data store: DIGIPASS Pool A container called DIGIPASS-Pool is created during installation. This is intended as a general store for unassigned DIGIPASS. Organizational Units If an Organizational Unit structure is used in the data store, DIGIPASS can be loaded or moved either into the exact Organizational Units where the User accounts to which they will be assigned are located, or into a few key Organizational Units in the hierarchy where they may be assigned to Users in lower level Organizational Units. Users Container When Active Directory is used as the data store, DIGIPASS can be loaded into the Users container so they are available for Users in that container. However, it is not recommended to use the Users container for either User accounts or DIGIPASS. When looking for an available DIGIPASS to assign to a User, the IDENTIKEY Server will first look in the same Organizational Unit as the specific User account. The Search Upwards in Organizational Unit hierarchy option, when enabled, allows the IDENTIKEY Server to search in parent Organizational Units and the DIGIPASS Pool container. This option may be set at the Policy level for system searches (eg. Auto-Assignment and SelfAssignment) or at the time of the search for manual assignment.
Note
The IDENTIKEY Server will always find or assign the closest available DIGIPASS record to the selected User record(s).
18.1.3.2
Delegated Administration in Active Directory
If the assignment is manual (performed by an administrator), it will only find and successfully assign DIGIPASS from locations where the administrator has the correct permissions. The administrator must have read permission for DIGIPASS objects in the location to find a DIGIPASS record, and if it needs to be moved to the User's location, they must have delete permission for DIGIPASS objects to successfully assign the DIGIPASS. If the administrator has sufficient permissions to view a DIGIPASS record but not to assign it, the assignment will fail.
165
IDENTIKEY Server Data Store Table 5: Summary of DIGIPASS Record Location Options
Record Location
DIGIPASS Pool
Pros
DIGIPASS are available to be assigned to all Users, regardless of the Organizational Unit structure. Only administrators with access to the DIGIPASS Pool may view or modify records for unassigned DIGIPASS. This also means that only those administrators may manually assign DIGIPASS. DIGIPASS may be portioned out to various Organizational Units. This is particularly useful where a company is contracted to provide authentication services to multiple companies, or where various departments have different DIGIPASS quota. DIGIPASS can be assigned to any User in the Users container.
Cons
An extra permission must be assigned to all administrators who should be able to assign DIGIPASS (if they are not Domain Admins). It is not possible to strictly subdivide the unassigned DIGIPASS among the Organizational Units according to quotas. If an Organizational Unit runs out of DIGIPASS to assign its Users, more DIGIPASS records must be manually moved to the right location.
Organizational Unit
Users Container
DIGIPASS in the Users container are only available to User accounts stored there.
166

18.1.3.3 Typical DIGIPASS Location Models
DIGIPASS Pool
A centralised point of access and importation can be implemented by using the DIGIPASS Pool to hold unassigned DIGIPASS records. This option requires less calculation and high-level administration, as DIGIPASS records are all imported into one area and there is no need to manually move records or calculate the exact number of DIGIPASS required for each Organizational Unit or group of Units. However, permissions will need to be set up to permit delegated administrators access to move the DIGIPASS out of the container upon assignment. The DIGIPASS Pool is treated as the Domain Root by the IDENTIKEY Server, as DIGIPASS records may not be saved in the Domain Root.
Image 53: DIGIPASS Record Locations - DIGIPASS Pool
In the diagram above, the IDENTIKEY Server is shown searching upwards through the Organizational Unit structure for available DIGIPASS to assign to a DIGIPASS User in the Organizational Unit B1. Because no available DIGIPASS are found in B1, it searches in B, then in the DIGIPASS Pool. Administrator 1 needs delegated administrator permissions for the Organizational Unit B and its child Organizational Units. They must also have read and delete permissions for DIGIPASS objects in the DIGIPASS Pool container.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
167
IDENTIKEY Server Data Store Parent Organizational Units

Unassigned DIGIPASS can be kept in key Organizational Units, and made available to their lower level Organizational Units. This requires a delegated administrator to have permissions not only for the Organizational Unit in which the User accounts are stored, but also read, write and delete permissions for DIGIPASS objects in the Organizational Unit in which the DIGIPASS are stored.
Image 54: DIGIPASS Record Locations - Parent Organizational Unit
In the diagram above, the IDENTIKEY Server can search in the parent Organizational Unit for available DIGIPASS. The delegated administratration permissions can be set up in two basic ways: Administrator 1 has full admin permissions for Organizational Unit B and its child Organizational Units. She does not require any other permissions to assign DIGIPASS from Organizational Unit B to a User in Organizational Unit B1. Administrator 2 has full admin permissions for Organizational Unit A2 only. He has read and delete permissions for DIGIPASS objects in Organizational Unit A in order to assign DIGIPASS from Organizational Unit A to a User in Organizational Unit A2.
Note
168
IDENTIKEY Server Data Store Individual Organizational Units

DIGIPASS can be loaded or moved into each Organizational Unit where and when they are required. It is then easy to set up permissions for delegated administrators to assign them only within their scope of control. If all DIGIPASS in the Organizational Unit are assigned, more DIGIPASS will need to be moved in manually by a Domain Admin before they can be assigned by a delegated administrator.
169
Image 55: DIGIPASS Record Locations - Individual Organizational Units
In the diagram above, unassigned DIGIPASS are stored in the exact Organizational Units in which they will be assigned. Each delegated administrator only requires permissions within their specific Organizational Unit(s).
Note
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for this model.
Combination of models
DIGIPASS may be stored in the DIGIPASS Pool as well as some or all Organizational Units. If no unassigned DIGIPASS records are found in the Organizational Unit, and the Search Upwards in Organization Unit hierarchy option is enabled, the IDENTIKEY Server will search upwards to the Domain Root and search in the DIGIPASS Pool for an available, unassigned DIGIPASS record.
18.1.4
Permissions Needed by the IDENTIKEY Server

The installation process will ensure that the IDENTIKEY Server has sufficient permissions. This is achieved by assigning permissions in the domain to the in-built RAS and IAS Servers group. It is necessary to make sure that the IDENTIKEY Server is added to that group.
18.1.5
Administrative Permissions
Administrative permissions for IDENTIKEY Server administrators are controlled using Active Directory security
170

properties. See the Permissions Needed by Administrators topic in the Administrator Reference for more information. Domain Administrators may view and edit all DIGIPASS and DIGIPASS User information in their domain, plus DIGIPASS Configuration information if the DIGIPASS Configuration Container is located in their domain. No permissions setup is required for them. Delegated Administrators may view and edit all DIGIPASS and DIGIPASS User information within their administrative scope of control. It is necessary to grant them full control, create and delete permissions over the DIGIPASS and DIGIPASS Application objects within their scope. Reduced Rights Administrators may perform a subset of the administration tasks. 'Property sets' are defined with the directory which can be used to enable or limit them in various DIGIPASS administration tasks (eg. Access to the DIGIPASS blob).
18.1.6
Active Directory Command Line Utility

This utility has to perform several tasks that are needed at various times during installation and upgrade if Active Directory is selected, or afterwards for maintenance. Some of the commands are run automatically by the installation program, while others are run manually. The commands that are run automatically can be run manually also, for example to troubleshoot why the installation is not succeeding.
Table 6: DPADadmin tasks

Command
addschema checkschema setupdomain setupaccess
Description
Extend the Active Directory schema. Check that the schema extensions are all present. Sets up the DIGIPASS Configuration Container in the specified domain. Assign permissions to a Windows group including: Full read access to everything in the domain Full control over vasco-DPToken objects Full control over vasco-DPApplication objects Ability to create and delete vasco-DPToken objects Full write access to extension attributes on user objects This command can optionally be used to also add a machine to the group.
171
IDENTIKEY Server Data Store 18.1.7 Active Directory Replication

For more details of Active Directory Replication see Active Directory Replication Issues in the Administration Reference Guide.
18.2
ODBC Database
You may use the embedded PostgreSQL database supplied with IDENTIKEY Server, or another ODBC-compliant database.
18.2.1
What is Stored in the Data Store?

The following information is stored in the data store: DIGIPASS User accounts DIGIPASS and DIGIPASS Application records DIGIPASS configuration records (Policies, Components, Back-End Servers, Reports and Report Formats) IDENTIKEY Server Configuration information
18.2.2
Domains and Organizational Units
Image 56: Domains and Organizational Units
Domains and Organizational Units are included in the ODBC database in a way that mirrors the data structure used by Active Directory. Organizational Units are designed to hold User accounts and DIGIPASS records. They allow grouping of Users according to department, job function, or other criteria. They also allow DIGIPASS to be allocated for AutoIDENTIKEY Server Product Guide 172

Assignment to single or multiple groups of Users. Both Domains and Organizational Units can be used to limit administrators to a group of Users and/or DIGIPASS.
18.2.3
Location of DIGIPASS Records

When a DIGIPASS is assigned to a User, it is moved to the same Organizational Unit as the DIGIPASS User account to which it is assigned.
Note
When a User account is moved to an Organizational Unit, all DIGIPASS records assigned to it will also be moved. A DIGIPASS record assigned to a User cannot be moved - the User account must be moved. Unassigned DIGIPASS records may be allocated to various places in the Organizational Unit structure: Master Domain During installation, a default domain is created. DIGIPASS are imported to the Master Domain, and may then be moved to other domains and Organizational Units. Organizational Units If an Organizational Unit structure is used in the database, DIGIPASS can be moved either into the exact Organizational Units where the User accounts to which they will be assigned are located, or into a few key Organizational Units in the hierarchy where they may be assigned to Users in lower level Organizational Units. When looking for an available DIGIPASS to assign to a User, the IDENTIKEY Server will first look in the same Organizational Unit as the specific User account, if the User account belongs to an Organizational Unit. The Search Upwards in Organizational Unit hierarchy option, when enabled, allows the IDENTIKEY Server to search in parent Organizational Units and the DIGIPASS Pool container. This option may be set at the Policy level for system searches (eg. Auto-Assignment and Self-Assignment) or at the time of the search for manual assignment.
Note
The IDENTIKEY Server will always find or assign the closest available DIGIPASS record to the selected User record(s). If the User account being assigned a DIGIPASS does not belong to an Organizational Unit, the IDENTIKEY Server will look for an available DIGIPASS in the domain which does not belong to an Organizational Unit.
173

18.2.3.1 Typical DIGIPASS Location Models
Domain Root
DIGIPASS records may be stored in the Domain Root while unassigned. This option allows a centralised point of access for assignment of DIGIPASS. It also requires less calculation and high-level administration - DIGIPASS records are all stored in one area and there is no need to manually move records or calculate the exact number of DIGIPASS required for each Organizational Unit or group of Units. Administrators must belong to the Domain only (not an Organizational Unit) to assign DIGIPASS from the Domain Root.
Image 57: DIGIPASS Record Locations Domain Root
In the diagram above, the IDENTIKEY Server searches upwards through the Organizational Unit structure for available DIGIPASS to assign to a DIGIPASS User in the Organizational Unit B1. Because no available DIGIPASS are found in B1, it searches in B, then in the Domain root. The administrator account must be located in the domain root (no Organizational Unit) in order for this model to work successfully.
Note
174

This option is simplified if an Organizational Unit structure is not used in the database. User accounts and DIGIPASS records may all be stored in the Master Domain. The Search Upwards in Organizational Unit hierarchy option does not need to be enabled in this case.
Parent Organizational Units

Unassigned DIGIPASS can be kept in key Organizational Units, and made available to their lower level Organizational Units.
Image 58: DIGIPASS Record Location Parent Organizational Unit
In the diagram above, the IDENTIKEY Server can search in the parent Organizational Unit for available DIGIPASS. Administrators will need to belong to the parent Organizational Unit.
Note
175
IDENTIKEY Server Data Store Individual Organizational Units

DIGIPASS can be loaded or moved into each Organizational Unit where and when they are required. If all DIGIPASS in the Organizational Unit are assigned, more DIGIPASS will need to be moved in manually by a Domain Admin before they can be assigned.
Image 59: DIGIPASS Record Locations Individual Organizational Units
In the diagram above, unassigned DIGIPASS are stored in the exact Organizational Units in which they will be assigned. Administrator accounts belonging to the Organizational Units A1 and A2 have administration privileges in their own Organizational Unit only.
Note
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for this model.
Combination of models
DIGIPASS may be stored in the Master Domain as well as some or all Organizational Units. If no unassigned DIGIPASS records are found in the Organizational Unit, and the Search Upwards in Organization Unit hierarchy option is enabled, the IDENTIKEY Server will search upwards to the Domain Root and search in the DIGIPASS Pool for an available, unassigned DIGIPASS record.
18.2.4
Permissions Needed by the IDENTIKEY Server

IDENTIKEY Server will require either:
176

a database administrator account for the database, ownership of the VASCO tables, or permissions to insert, remove, read and modify rows in VASCO tables. See the Administrator Reference for more information. This is set up automatically in the case of the embedded database option.
18.2.5
Database Command Line Utility

This utility has to perform several tasks that are needed at various times during installation and upgrade, or afterwards for maintenance. Some of the commands are run automatically by the installation program, while others are run manually. The commands that are run automatically can be run manually also, for example to troubleshoot why the installation is not succeeding. Command
addschema checkschema dropschema
Description
Modify the database structure to create the required VASCO tables. Check that the required database modifications and/or table name remappings have been completed. Remove all database schema modifications from the database.
Table 7: DPDBadmin commands
177
IDENTIKEY Server Data Store 18.2.6 Additional ODBC Databases

A synchronized backup database may be set up for the IDENTIKEY Server. This helps to ensure continuous service if the main database fails. The synchronization can be a shadow database, a mirror or a replicated copy. The required synchronization must be set up according to the instructions provided by the database vendor. It is strongly recommended to minimize the synchronization delay. Once the database and any synchronization is set up, create a Data Source Name for the new database and add it to the IDENTIKEY Server Configuration GUI.
Image 60: Additional ODBC databases
See the Database Connection Handling topic in the Administrator Reference Guide for more information.
178
IDENTIKEY Server Data Store 18.2.7 Multiple IDENTIKEY Servers

If more than one IDENTIKEY Server is installed on the system, some additional setup may be required.
Multiple IDENTIKEY Servers Using Same Database

If more than one IDENTIKEY Server is using the one ODBC database, no additional setup steps are required. A backup database should be considered.
Image 61: Multiple IDENTIKEY Server Using Single Database
179
IDENTIKEY Server Data Store 18.2.8 Replication

When multiple IDENTIKEY Servers are in use each with their own database, they can be configured to replicate data changes between them, to keep all database synchronized.
18.2.8.1 Common Scenarios
Primary and Backup IDENTIKEY Servers

The most common, and most basic, replication setup is used when a company has two IDENTIKEY Servers one primary, to which all authentication requests are customarily sent, and a backup IDENTIKEY Server for use when the primary server is busy or unavailable. Replication is usually set to occur very frequently.
Image 62: Replication between a Primary and Backup IDENTIKEY Server
180
IDENTIKEY Server Data Store Primary, Backup and Disaster Recovery IDENTIKEY Servers
This scenario is often used when a company requires an offsite disaster recovery IDENTIKEY Server and database.
Image 63: Replication between Primary, Backup, and Disaster Recovery in IDENTIKEY Server
18.2.8.2
Other Scenarios
Other replication scenarios may also be used. For example, a company may have three IDENTIKEY Servers, all replicating to each other. This may keep data up to date better than a simpler replication chain.
181
Image 64: Replication between three IDENTIKEY Servers
Or, a company might require two Primary IDENTIKEY Servers, each with a backup IDENTIKEY Server, and add in an extra replication link to speed up data communications:
Image 65: Complex IDENTIKEY Server Replication Scenario
182

18.2.8.3 Using SSL with Replication
Security for replication can be further enhanced by enabling SSL. SSL can be enabled when defining the Replication destination server on the Configuration GUI. Use the destination server configuration page to provide the SSL certficate, SSL password, and CA Certificate store. For more information on enabling and configuring SSL for replication connections, refer to the Enabling SSL on Replication Connections section of the Administrator Guide.
183
Licensing
19
19.1
Licensing
Overview
VASCO products are licensed per Component record in the data store. The licensing relies upon a License Key which is checked when the IDENTIKEY Server starts. This License Key is tied to the location (IP address) where the IDENTIKEY Server is installed, and stored in the Component record for the IDENTIKEY Server. The IDENTIKEY Server will not authenticate a user without a correct License Key, except to permit administration. SOAP, RADIUS, and the Authorization, Signature Validation and Provisioning scenarios all require a License Key. Client modules such as the IIS 6 Module or Citrix Web Interface also require a License Key to be loaded into their Component record. The IDENTIKEY Servers to which they connect will otherwise reject all authentication requests from them.
Evaluation License
An evaluation license means that you can use its full functionality until the evaluation period runs out. At the end of this period, you will need to either uninstall the product or buy a permanent license. Contact your distributor or the appropriate VASCO Reseller representative to acquire the licences you will need. For your convenience, the evaluation serial number is embedded in the installation program. You will still need to obtain and load a license key. Client module licenses can also be evaluation (time-limited) licenses.
Note
Licenses for IDENTIKEY Server 3.1 and 3.2 are valid for IDENTIKEY Server 3.3.
19.2
Obtaining and Loading a License Key

The IDENTIKEY Server Configuration Wizard will guide you through the process of requesting and loading a License Key. However, if for some reason it is not possible to complete the licensing at installation time, the Web Administration Interface can be used to obtain and load a License Key for a Component. This process must be completed for each IDENTIKEY Server, and requires an active internet connection to open the Manage IDENTIKEY ServerPage.
184
Performance Monitoring
20
20.1
Performance Monitoring
Overview
Performance Monitoring allows you to monitor specific parts of IDENTIKEY Server processing to produce useful performance statistics. Performance Monitoring is disabled, enabled, and managed using the IDENTIKEY Server Configuration utility.
20.2
Filters
The Performance Monitoring tool uses filters to determine which specific parts of IDENTIKEY Server processing should be monitored. IDENTIKEY Server processing is defined to the Performance Monitoring tool as performance transactions, and these are what should be referred to in the filters tool. Wildcards may be used in the filter definition to widen the monitoring field.
20.3
Plugins
The plugins for the Performance Monitoring tool allow you to define the form of the output provided by the Performance Monitoring tool.
20.3.1
CSV Plugin
The CSV plugin allows you to define a comma-separated variable (CSV) file to write the results to. See the Performance Monitoring chapter of the Administrator Reference for the format of the CSV file .
20.3.2
Counter Plugin
The counter plugin records statistics on transactions specified in the filter. The counters are available via SNMP on both Windows and Linux.
20.3.3
ARM4 Plugin
This plugin allows you to define an Application Response Measurement application. For more information about ARM4, refer to http://www.opengroup.org/management/arm/.
185
System Monitoring
21
21.1
System Monitoring
Overview
System Monitoring allows you to monitor IDENTIKEY Server processing to provide alerts when specific events occur. System Monitoring watches audit messages and creates an alert when specified messages appear. Use the IDENTIKEY Server Configuration utility or the Administration Web Interface to configure, enable, or disable system monitoring. The Configuration utility is also used to define which audit messages to monitor, along with the notification destination and format.
21.2
Filters
System Monitoring requires filters to to specify which IDENTIKEY Server events should be monitored. Filter details must include: a name a target, specifying which notification method is to be used what kind of audit message type to monitor a specific field a condition a value for the specified field The fields listed herein are monitored from the vdsauditmsg table, which stores audit messages.
21.3
Targets
The System Monitoring tool requires one or more targets to be defined to specify the output format. The available target formats are: SNMP SMS Email
21.3.1
SNMP
IDENTIKEY Server System Monitoring tool supports SNMPV2c, and SNMPV3. SNMPV3 is preferred. The SNMP target requires: a name SNMP type Inform, TRAP, TRAPV2c Host IP address
186
System Monitoring
Security name for SNMPV3 Authentication protocol type Authentication Secret Privacy type Privacy secret
21.3.2
SMS
Notification can be provided via SMS. The SMS Target requries: a name a mobile phone number
21.3.3
Email
Notification can also be provided via Email The Email target requires: a name a source email address a target email address a subject line
187
Auditing and Tracing
22
22.1
Auditing and Tracing

Audit System
The VASCO Audit System consists of a number of auditing modules which save audit messages to a specific format (eg. text file or database) and an Audit Viewer which can open, display and filter audit messages from various sources.
Image 66: Audit System Overview
Audit messages are primarily generated by the IDENTIKEY Server, and include RADIUS accounting data. They may be recorded by a number of different methods: Windows Event Log (to be viewed in the Event Log Viewer) Syslog (In Linux environments) Text file ODBC-compliant database Audit messages may also be passed directly to an Audit Viewer as a live feed.
22.1.1
Configure Auditing Output

Auditing output from the IDENTIKEY Server can be configured using the IDENTIKEY Server Configuration. See the Configuration section of the Administrator Reference for more information.
188
Auditing and Tracing 22.1.2 Audit Viewer
Image 67: Audit Viewer
The Audit Viewer can retrieve messages from several different sources and display audit messages from each in separate windows. Audit messages may be filtered by message type, date and time, or the contents of specific fields.
22.1.3
Starting the Audit Viewer Windows

Use the Start menu (by default, Programs -> VASCO -> IDENTIKEY Server -> Audit Viewer) or go to the IDENTIKEY Server installation/bin directory.
Linux
1. 2. Navigate to the IDENTIKEY Server installation directory (by default, /opt/vasco/Identikey). Start the Audit Viewer by entering these commands:
vds_chroot <IK install directory> /bin/bash dpauditviewer
189
Auditing and Tracing 22.1.4 Audit message types

Type
Error Warning Information Success Failure RADIUS
Description
The message contains details about a system, configuration, licensing or some internal error. Errors do not include normal processing events such as failed logins. Warning messages contain details about potential problems within the system. This could include details such as a failed connection attempt to a database Informational messages provide details about events within the system that need to be recorded but do not indicate errors or potential errors. Success messages contain details about processing events that were correctly processed. This may include successful authentications or successful administration commands. Failure messages contain details about processing events that failed. This may include rejected authentications, or administration actions that failed. RADIUS accounting message.
Table 8: Audit message types
22.1.5
Active Directory Auditing

Active Directory auditing may be enabled and configured to record access and modifications to DIGIPASS-related data used by the IDENTIKEY Server. See the Active Directory Auditing topic in the Administrator Reference for more information.
22.2
Secure Auditing
An option is available to enable Secure Auditing during installation of IDENTIKEY Server. Secure Auditing provides the following: Integrity protection Using a non-viewable encrypted signature added to each line of an audit file, or each row of an audit data store. Prevents any operator from making untraceable manual changes to the audit file. Independent verification Each audit file or data store can be verified using the Verfication Tool provided with Secure Auditing. Non-repudiation Verification by comparing each signed line or row of audit data with the previous and subsequent entries in the audit data. Secure Auditing works with an HSM, (see 8 Hardware Security Modules for more details about HSM) or on a system without an HSM.
190
Auditing and Tracing 22.2.1 How Secure Auditing Works

Secure Auditing adds a cryptographic signature to each audit line written to the output. The cryptographic signature relates each entry to the previous and subsequent entries. The relationship between the entries is verifiable using the Verification Tool. The object of the encrypted signature is to prevent manual removal or addition of entries. The Verification Tool will verify the entire file and ensure that each entry is related to the previous and subsequent entries. Each entry belongs to an epoch, which is a period delimited either by time or by number of audit lines. At the end of each epoch the encryption key is changed. A message is written to the audit file to indicate that an epoch has ended, and another message is written to indicate that a new epoch has begun. A new epoch always begins when a new day starts. Each start of epoch message contains information required by the Verification Tool to decrypt the signatures for that epoch.
22.3
Tracing
The level of tracing for the IDENTIKEY Server can be configured using the IDENTIKEY Server Configuration utility. Tracing messages will be recorded to a text file. Trace log files can be rotated depending on age or size. See the Tracing section in the Administrator Reference for more information, and instructions on configuring tracing for the IDENTIKEY Server.
191
Message Delivery Component
23
23.1
Message Delivery Component

What is the Message Delivery Component?
The Message Delivery Component (MDC) interfaces with an SMS gateway or mail server to send a One Time Password or other message to a Users mobile phone or email address. The MDC acts as a service, accepting messages from the IDENTIKEY Server, which are then forwarded to a text message gateway via the HTTP/HTTPS protocol. Multiple SMS gateways and/or mail servers may be configured, one per Profile. See the Configuration section of the Administrator Guide for more information. You can enable client and server SSL certificates over the link between the MDC and IDENTIKEY Server, and you can customise rotation of the trace log file (if desired).
23.2
Starting the Message Delivery Component

Windows
The Virtual Digipass MDC service can be started and stopped through the Windows Service Manager Console.
Linux
To start the MDCserver daemon: 1. 2. 3. Enter the chroot environment:
vds_chroot <IK install directory> /bin/bash
Navigate to usr/share/vasco/init.d Enter the command:

./mdcserver start
23.3
Enabling SSL on the Message Delivery Component

To enable SSL over the link between the MDC and IDENTIKEY Server, you must configure certificates at both ends. You can do this by entering details in the MDC configuration window and the server configuration wizard. For details, see the Administrator Guide.
192
User Self Management Web Site
24
24.1

What is the User Self Management Web Site?
The User Self Management Web Site allows Users to perform functions which are unavailable during a usual login either because the functionality is disabled within the IDENTIKEY Server configuration, or because CHAP or another protocol is in use which does not allow the functionality: User Registration and Auto-Assignment Self-Assignment Password Synchronization PIN Change Login Test The site can also be used to help Users get started with their DIGIPASS while they are still in the office and help is available.
Image 68: User Self Management Web Site
193
Important Note
The User Self Management Web Site is intended for RADIUS environments, and uses the RADIUS protocol to communicate with the IDENTIKEY Server. If the IDENTIKEY Server is not licensed for RADIUS, you will not be able to use the User Self Management Web Site.
24.2
Customizing the User Self Management Web Site

The User Self Management Web Site can be customized by modifying the pages provided with the installation. You may wish to: change the colors and graphics to match your corporate colors/logos. integrate the pages into a larger web site. translate or customize the text Any cosmetic part of the web pages may be modified. Completely new web pages may be used, provided that the correct form fields are posted to the CGI program, and query string variables are interpreted correctly. Server scripting languages such as PHP or ASP, or any other way of generating HTML, can be used. See the Web Sites section of the Administrator Reference for more information.
194
Index
Index
Activation Code....................................................................................100 Active Directory......................................................................................66 Active Directory.......................................................................................... Active Directory User........................................................................44 ADAM....................................................................................................71 Audit......................................................................................................... Active Directory Auditing................................................................190 Audit System.................................................................................188 Audit Viewer..................................................................................189 Authentication............................................................................................ Local.............................................................................................. 51 Auto-Assignment..................................................................... 49, 55, 193 Back-End Authentication........................................................................ 77 Back-End Protocol..................................................................................63 Back-End Server........................................................................................ Back-End Server record...................................................33, 164, 172 Backup Virtual DIGIPASS...................................................................... 136 Challenge..............................................................................................53 Challenge/Response...........................................................13, 77, 78, 133 1-Step Challenge/Response.............................................................55 2-Step Challenge/Response.............................................................55 Non-time-based............................................................................ 134 Time-based...................................................................................133 Challenge/Response ..............................................................................16 CHAP.......................................................................21, 22, 24-26, 76, 77 Check Digit..........................................................................................134 Citrix Web Interface................................................................................42 Command-Line Administration..............................................................119 Communicator.......................................................................................19 Component................................................................................................ Component record...........................................................32, 164, 172 Configuration.......................................................................................120 Configuration Wizard..............................................................................31 Context Menu...................................................................................... 118 Customize............................................................................................194 Data field...............................................................................................13 Database Synchronization.....................................................................178 Deferred Signature Validation..................................................................80 DIGIPASS...............................................................................................13 Account........................................................32, 34, 43, 48, 129, 173 Account Creation...........................................................................124 Assign.......................................................................................... 127 Backup Virtual DIGIPASS..................................................................33 DIGIPASS..................................................................................12, 53 DIGIPASS Application.................................................................13, 33 DIGIPASS Assignment....................................................................119 DIGIPASS for Mobile........................................................................ 16 DIGIPASS for Web............................................................................16 DIGIPASS PIN................................................................................133 DIGIPASS record............................. 32, 118, 128, 130, 165, 172, 174 DIGIPASS Record Administration.....................................................119 Hardware DIGIPASS.........................................................................14 Linked.............................................................................................52 Lookup............................................................................................51 Search..........................................................................................119 Serial Number...............................................................................128 Software DIGIPASS....................................................................16, 84 Test DIGIPASS Application..............................................................131 Unlock DIGIPASS...........................................................................131 Virtual DIGIPASS....................................................12, 53, 56, 57, 138 DIGIPASS Extension for Active Directory Users and Computers................118 DIGIPASS TCL Command-Line Administration..........................................30 Digipass User............................................................................................. Account........................................................................118, 164, 172 Digital Signature.........................................................................12, 13, 15 Digital signatures................................................................................... 79 Domain..........................................................................................65, 173 Domain...................................................................................................... Active Directory...............................................................................33 Default Domain................................................................................44
195
Index
ODBC........................................................................................... 126 DUR.................................................................................................... 124 Dynamic User Registration................................................................49, 63 EAP.......................................................................................................24 EAP-TTLS..............................................................................................24 EMV-CAP.............................................................................................107 Engine...................................................................................................35 Event ....................................................................................................80 Event Based Signature............................................................................80 Event Value..........................................................................................135 Event-based.........................................................................................133 Generate digital signatures..................................................................... 79 Grace Period............................................................................53, 55, 128 Group Check....................................................................................47, 51 Group Check.............................................................................................. Back-End........................................................................................48 Pass Back.......................................................................................47 'Reject............................................................................................48 Hardware Security Module....................................................................110 IDENTIKEY Server Configuration.............................................................. 31 IIS.........................................................................................................29 IIS Module Component Check.................................................................42 Internet Information Services...................................................................27 Licensing.............................................................................................184 Evaluation License.........................................................................184 License Key.............................................................................32, 184 Local Authentication.........................................................................48, 51 Message Delivery Component...............................................................192 MPPE....................................................................................................76 MS-CHAP........................................................................................76, 77 MS-CHAP2......................................................................................76, 77 MS-CHAPv1.........................................................................21, 22, 24, 25 MS-CHAPv2.........................................................................21, 22, 24, 25 Multi-Mode......................................................................................13, 16 Novell e-Directory...................................................................................68 Offline Delivery.......................................................................................85 One Time Password.......................................................12, 13, 15, 16, 57 Length..........................................................................................134 Online delivery.......................................................................................85 Organizational Unit...............................................................................173 Organizational Unit..................................................................................... Active Directory...............................................................................34 ODBC........................................................................................... 126 OTP.....................................................................................23, 25, 26, 27 OTP Request Site...................................................................................58 Outlook Web Access.............................................................................. 42 PAP...............................................................................21, 22, 24-26, 76 Password................................................................................................... Password Autolearn...........................................................65, 77, 125 Password Replacement....................................................................63 RADIUS...........................................................................................28 Static password.......................................................26, 28, 29, 58, 63 Stored Password Proxy.................................................................... 64 Stored Static Password....................................................................64 Windows...................................................................................28, 29 PCI-DSS Compliance..............................................................................38 PEAP.....................................................................................................24 PIN............................................................................................................ Digipass PIN....................................................................................15 Force PIN Change..........................................................................131 Server PIN...............................................................................53, 136 Policy............................................................................................51, 147 Effective Settings...........................................................................148 Inheritance....................................................................................147 Policy record...................................................................33, 164, 172 ......................................................................................................... Pre-loaded..............................................................................150 Privileges.............................................................................................170 Provisioning...........................................................................................84 RADIUS............................................................................................21, 35 Attributes..................................................................................21, 63 CHAP..............................................................................................35
196
Index
Client..............................................................................................42 Default RADIUS Client................................................................42 MPPE..............................................................................................35 MS-CHAP........................................................................................35 MS-CHAP2......................................................................................35 PAP................................................................................................35 Server...........................................................................24, 25, 26, 28 RADIUS Back-End Authentication............................................................66 RADIUS Client Component Check............................................................42 Real Time Signature Validation................................................................79 Replication...................................................................................180, 182 Reporting................................................................................................... Archiving Strategy......................................................................... 159 Report Permissions........................................................................156 Report Type...................................................................................155 Reset......................................................................................................... Reset Application...........................................................................130 Reset Application Lock...................................................................131 Reset PIN......................................................................................131 Response Only.........................................................................13, 16, 133 Scenario................................................................................................19 SEAL.....................................................................................................19 Secure Auditing................................................................................... 190 Self-Assignment........................................................ 49, 63, 77, 127, 193 Server PIN............................................................................................. 77 Set............................................................................................................ Set Event Counter..........................................................................131 Set PIN......................................................................................... 131 Sign transaction.....................................................................................79 Simple Name Resolution.........................................................................43 Smartcard..............................................................................................16 SOAP.................................................................................................... 34 Software DIGIPASS.................................................................................12 Provisioning.................................................................................... 84 Stored Password Proxy.............................................................64, 77, 125 Task Scheduling...................................................................................141 Time .....................................................................................................80 Time based signature.............................................................................80 Time Shift............................................................................................135 Time Step......................................................................................80, 135 Time-based.........................................................................................133 Tivoli.....................................................................................................72 Tracing................................................................................................191 User Self Management Web Site...................................................193, 194 Virtual DIGIPASS....................................................................................... Backup Virtual DIGIPASS............................................................17, 56 Primary Virtual DIGIPASS..................................................................17 Virtual DIGIPASS........................................................................................ Backup Virtual DIGIPASS........................................................138, 140 Keyword..........................................................................................58 OTP................................................................................................56 Request Method..............................................................................58 Windows Name Resolution..................................................................... 43 Wireless........................................................................................23, 160
197

Identikey Server Product Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Identikey Server Product Guide

Uploaded by

Copyright:

Available Formats

IDENTIKEY Server

Date last modified: 26/07/11

User Authentication Process......................................................................................................................... 40

3.10 Unsupported by IDENTIKEY Server..................................................................................................................... 77

Signature Validation Process......................................................................................................................... 79

IDENTIKEY Server Product Guide

Software DIGIPASS Provisioning.................................................................................................................... 84

DIGIPASS Authentication for Windows Logon............................................................................................... 103

Hardware Security Modules........................................................................................................................ 110

IDENTIKEY Server Product Guide

9.10 User CGI Configuration..................................................................................................................................... 122

10 DIGIPASS User Accounts............................................................................................................................. 124

12 Task Scheduling......................................................................................................................................... 141

13 Client Components..................................................................................................................................... 144

IDENTIKEY Server Product Guide

Table of Contents 14 Server Components.................................................................................................................................... 146

17 Wireless RADIUS......................................................................................................................................... 160

18 IDENTIKEY Server Data Store...................................................................................................................... 164

20 Performance Monitoring............................................................................................................................. 185

21 System Monitoring...................................................................................................................................... 186

22 Auditing and Tracing................................................................................................................................... 188

IDENTIKEY Server Product Guide

Table of Contents 23 Message Delivery Component..................................................................................................................... 192

24 User Self Management Web Site................................................................................................................. 193

IDENTIKEY Server Product Guide

IDENTIKEY Server Product Guide

IDENTIKEY Server Product Guide

Who should read this guide?

IDENTIKEY Server documentation suite

IDENTIKEY Server Product Guide

IDENTIKEY Server Product Guide

IDENTIKEY Server Product Guide

IDENTIKEY Server Product Guide

Overview 2.3.1 Hardware DIGIPASS

DIGIPASS without keypads

Image 6: DIGIPASSS Nano

IDENTIKEY Server Product Guide

Overview DIGIPASS with keypads

Image 9: DP 270 Xpress

Image 10: DP 310 Comfort Voice

IDENTIKEY Server Product Guide

Overview Smartcard reader DIGIPASS

Image 11: DP 810

Image 12: DP 855

DIGIPASS for Web

DIGIPASS for Mobile

IDENTIKEY Server Product Guide

Overview 2.3.3 Hardware/Software DIGIPASS

Image 13: DP 110

IDENTIKEY Server Product Guide

Structure of IDENTIKEY Server

Image 14: Structure of IDENTIKEY Server

IDENTIKEY Server Product Guide

Overview 2.4.1 Customer Web Applications

Remote Access Clients

IDENTIKEY Server Product Guide

Hardware Security Module

IDENTIKEY Server Product Guide

IDENTIKEY Server in a RADIUS Environment

Stand-alone: No RADIUS Attributes Required

Stand-alone: RADIUS Attributes from DIGIPASS User Account

IDENTIKEY Server Product Guide

IDENTIKEY Server Product Guide