axsguard Identifier Product Guide Product Guide axsguard AXSGuard ConfigurationTool

Transcription

1 Product Guide axsguard AXSGuard ConfigurationTool Product Guide axsguard Identifier axsguard Identifier axsguard Identifier DIGIPASS ConfigurationTool v axsguard Identifier Product Guide

2 Legal Notice VASCO Products VASCO Data Security, Inc. and/or VASCO Data Security International GmbH are referred to in this document as VASCO. VASCO Products comprise Hardware, Software, Services and Documentation. This document addresses potential and existing VASCO customers and has been provided to you and your organization for the sole purpose of helping you to use and evaluate VASCO Products. As such, it does not constitute a license to use VASCO Software or a contractual agreement to use VASCO Products. Disclaimer of Warranties and Limitations of Liabilities VASCO Products are provided as is without warranty or conditions of any kind, whether implied, statutory, or related to trade use or dealership, including but not limited to implied warranties of satisfactory quality, merchantability, title, non-infringement or fitness for a particular purpose. VASCO, VASCO DISTRIBUTORS, RESELLERS AND SUPPLIERS HAVE NO LIABILITY UNDER ANY CIRCUMSTANCES FOR ANY LOSS, DAMAGE OR EXPENSE INCURRED BY YOU, YOUR ORGANIZATION OR ANY THIRD PARTY (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF DATA) ARISING DIRECTLY OR INDIRECTLY FROM THE USE, OR INABILITY TO USE VASCO SOFTWARE, HARDWARE, SERVICES OR DOCUMENTATION, REGARDLESS OF THE CAUSE OF THE LOSS, INCLUDING NEGLIGENCE, EVEN IF VASCO HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR IF THEY WERE FORESEEABLE. OUR MAXIMUM AGGREGATE LIABILITY TO YOU, AND THAT OF OUR DISTRIBUTORS, RESELLERS 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. THIS SECTION WILL NOT APPLY ONLY WHEN AND TO THE EXTENT THAT APPLICABLE LAW SPECIFICALLY REQUIRES LIABILITY DESPITE THE FOREGOING EXCLUSIONS AND LIMITATIONS. Intellectual Property and Copyright VASCO Products contain proprietary and confidential information. VASCO Data Security, Inc. and/or VASCO Data Security International GmbH own or are licensed under all title, rights and interest in VASCO Products, updates and upgrades thereof, including copyrights, patent rights, trade secret rights, mask work rights, database rights and all other intellectual and industrial property rights. No part of these Products may be transferred, disclosed, reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise, for any purpose, except as expressly permitted by VASCO or its authorized licensee in writing. This document is protected under US and international copyright law as an unpublished work of authorship. No part of it may be transferred, disclosed, reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise, for any purpose, except as expressly permitted in writing by VASCO or its authorized licensee. Trademarks VASCO, VACMAN, IDENTIKEY, axsguard, DIGIPASS, and the logo are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries. Other company brand or product names or other designations, denominations, labels and/or other tags, titles, as well as all URLs (Internet addresses) linked to such designations or communications (irrespective of whether protected by intellectual property law or not), mentioned in VASCO Products may be the trademarks or registered trademarks or be part of any other entitlement of their respective owners. Radius Disclaimer Information on the RADIUS server provided in this document relates to its operation in the axsguard Identifier environment. We recommend that you contact your NAS/RAS vendor for further information. Copyright March 2009 VASCO Data Security, Inc, VASCO Data Security International GmbH. All rights reserved. 2

3 Table of Contents Table of Contents INTRODUCTION SECTION Introduction Audience and Purpose of this Document About VASCO Contact Information...15 axsguard Identifier Overview VASCO's Authentication Solution What is the axsguard Identifier? What is the IDENTIKEY Server? What is a DIGIPASS? Structure of the axsguard Identifier Overview Communication Protocols Scenarios Licensing Overview Commercial Licensing DEMO Licensing Client Component Licensing Support Procedure VASCO Service Center...24 USER AUTHENTICATION SECTION User Authentication Process Authentication Process Overview Identifying the Component Record Identifying a Policy DIGIPASS User Account Lookup and Checks Overview User ID and Domain Resolution DIGIPASS User Account Lookup Dynamic User Registration Local Authentication

4 Overview Local Authentication Policy Setting...32 Authentication with DIGIPASS Table of Contents Overview DIGIPASS Lookup and Checks...33 Response Only Challenge/Response...36 Virtual DIGIPASS Login Request Method and Keyword...40 Authentication without DIGIPASS Static Password Verification Self-Assignment Back-end Authentication Overview Back-end Server Policy Settings Back-end Authentication and Static Password Back-end Server Records Fail-over Strategy Domain-specific Back-end Servers...48 RADIUS Back-end Authentication...48 LDAP Back-end Authentication Stored Password Proxy...44 Password Autolearn Password Replacement (IIS Modules) Stored Static Password and RADIUS Attributes...46 Microsoft Active Directory Back-end Authentication Novell e-directory Back- end Authentication Policies...54 Authorization Profiles/Attributes Host Code Generation Concept Using a Host Code...56 ADMINISTRATIVE INTERFACES SECTION Administration Interfaces Overview Default Administrative Users Configuration Tool Administration Web Interface Rescue Tool

5 Table of Contents CONFIGURATION TOOL SECTION Installation Configurations Overview First Time Set-up Configuration Wizard Manual Configurations...64 Registration Overview First Time Registration Registration without on-site Internet Access Change in IP Address Upgrade from a DEMO to Commercial License Replacement of axsguard Identifier Change of Customer Information Restoring a backup from another axsguard Identifier...68 Updating Overview Updating Process Updating Infrastructure...69 Backup and Restore Overview Backup Restore Logging Overview Infrastructure Local: Live Log Viewer Remote Syslog Log Levels Log Filter Auditing Overview Live Audit Viewer

6 Table of Contents 10.3 Audit Message Types Audit Filter Statistics Overview System Information Available Statistics Filtering Message Delivery Component Overview Configuration Remote Support Overview Support Procedure Remote Support Tracing LDAP User Synchronization Overview LDAP Synchronization Profiles Synchronization Profile IDs Creating and Updating User Accounts Deleting User Accounts Synchronization Frequency Multiple Synchronization Profiles Managing Source and Destination Hierarchies Special Cases Replication Overview Common Replications First and Second axsguard Identifiers First, Second and Disaster Recovery axsguard Identifiers Replication Wizard Replication and Firewalls Replication Process Queuing and Sending Replication Forwarding

7 Table of Contents Multiple Changes to a Single Data Record Connection Handling Replication Monitoring Replication Auditing Replication Status...99 ADMINISTRATION WEB INTERFACE SECTION DIGIPASS User Accounts Overview Creating User Accounts Creating Users Manually Importing User Records Dynamic User Registration LDAP User Synchronization Linked User Accounts User Account Settings DIGIPASS User Account Static Password Searching for User Accounts Administration Privileges DIGIPASS Overview DIGIPASS Properties DIGIPASS Client PIN Server PIN Grace Period DIGIPASS Authentication Method DIGIPASS Management Importing DIGIPASS Assigning DIGIPASS Searching for DIGIPASS Records DIGIPASS Actions Viewing DIGIPASS Runtime Information DIGIPASS Assignment Options Self-Assignment Self-Assignment Process Self-Assignment Data Auto-Assignment Manual Assignment

8 Table of Contents DIGIPASS Assignment Limitations Virtual DIGIPASS Overview Virtual DIGIPASS Assignment Options Virtual DIGIPASS Configuration Implementation Decision Limiting Use of Virtual DIGIPASS Backup Virtual DIGIPASS Guidelines for Use Client Components Overview Standard Component Properties Component Lookup and Verification RADIUS Client IIS Module Client Component Licensing Server Components Overview Automatic Server Component Creation Registration Process Replication Licenses Policies Overview Policy Properties Policy Inheritance Organization Overview Domains and Organizational Units Master Domain and Practical Uses Master Domain Concepts Practical Use Moving DIGIPASS User Accounts and DIGIPASS Location of DIGIPASS Records Typical DIGIPASS Location Models

9 Table of Contents 22 Reporting Overview Reporting Structure and Purposes Custom Reports Overview Report Type Data Source Grouping Level Query Permissions Formatting Templates Report Generation Process RESCUE TOOL SECTION Rescue Tool Overview Access Options

10 Table of Contents Illustration Index Image 1: VASCO's Authentication Solution Image 2: axsguard Identifier Architecture Image 3: Connection between the axsguard Identifier and VASCO Service Center Image 4: Authentication Process Overview Image 5: User ID and Domain Resolution Image 6: Dynamic User Registration Process Image 7: Multiple DIGIPASS Assignment Image 8: Response Only Login and Authentication Process Image 9: 1-step (left) and 2-step (right) Challenge/Response Login Image 10: Virtual DIGIPASS Login Image 11: Static Password Authentication Flow Image 12: Password Replacement with an IIS Module Image 13: Steps in the Retrieval of RADIUS Attributes Image 14: Back-end Authentication Process with RADIUS Image 15: Back-end Authentication Process with Microsoft Active Directory Image 16: Back-end Authentication Process with Novell e-directory Image 17: Data Transmission from the Syslog Utility to the Live Log Viewer and Remote Syslog Image 18: Example Screen Shot Showing the Live Log Viewer Image 19: Log Filter Fields Image 20: Live Audit Viewer and Filter Image 21: Audit Filter Fields Image 22: Process Statistics Image 23: Disk Usage Statistics Image 24: CPU Statistics Image 25: Interface Statistics Image 26: Show CPU Usage for a Specific Service Image 27: CPU Time for Administration Web Interface Image 28: Virtual DIGIPASS Process using axsguard Identifier MDC Component (clockwise from the top) Image 29: Administration Web Interface > Users > User 'annelies'> User Attributes Image 30: LDAP Synchronization to create or update an User Account Image 31: Possible source and destination hierarchy mapping with a single Synchronization Profile Image 32: Example source and destination hierarchy mapping with three Synchronization Profiles Image 33: Deleting a Synchronization Profile ID for a User Account Image 34: Replication between a First and Second axsguard Identifier

11 Table of Contents Image 35: Replication between a First, Second, and Disaster Recovery axsguard Identifier Image 36: 'System' Tab in the Administration Web Interface Image 37: Replication Status Screen in the Administration Web Interface Image 38: User Account Link Image 39: Self-Assignment Process Image 40: Auto-Assignment Process Image 41: Manual Assignment Process Image 42: Reserving a DIGIPASS Record for a Specific User in the Administration Web Interface Image 43: Policy Inheritance Image 44: Domains and Organizational Units Image 45: User ID and Domain Resolution Image 46: Possibilities for Moving User Accounts and DIGIPASS (ou = Organizational Unit) Image 47: DIGIPASS Record Location Domain Root Image 48: DIGIPASS Record Location Parent Organizational Unit Image 49: DIGIPASS Record Location Individual Organizational Units Image 50: Reporting Structure Image 51: Report Grouping Image 52: Report Generation Process Image 53: Start and Network Menus with the Rescue Tool

12 Table of Contents Index of Tables Table 1: Values for Local Authentication Setting Table 2: Values for Back-end Authentication Setting...44 Table 3: RADIUS User ID Formats for Back-end Authentication Table 4: Microsoft Active Directory User ID formats for Back-end Authentication Table 5: Novell e-directory User ID Formats for Back-end Authentication Table 6: User Attribute Settings Table 7: Default Administrative User Credentials...58 Table 8: Log Levels Table 9: Log Filter Fields Table 10: Audit Message Types Table 11: Audit Filter Fields Table 12: Server Settings Regulating Server PINs Table 13: DIGIPASS Record Actions supported in the Administration Web Interface Table 14: DIGIPASS Options Table 15: Backup Virtual DIGIPASS Example Guidelines

13 Introduction Section Introduction... 1 axsguard Identifier

14 1 Introduction 1.1 Audience and Purpose of this Document Introduction This axsguard Identifier Product Guide is part of a set of guides on the axsguard Identifier. It is intended for technical experts interested in learning about the axsguard Identifier. It describes the structure of the product, the concepts underpinning authentication and how the axsguard Identifier can support authentication within your IT infrastructure. In this first chapter, we introduce VASCO and provide some contact details. In chapter 2, we explain VASCO's authentication solution and its different components, the structure of the axsguard Identifier, and the licensing and support systems. In chapter 3, we describe the user authentication process. In chapter 4, we introduce the functionality which can be managed through the three administration interfaces: the axsguard Identifier Configuration Tool, the Administration Web Interface and the Rescue Tool. Chapters 5 to 15 cover each of the main functionalities managed by the axsguard Identifier Configuration Tool, including installation configurations, registration, updating, backup and restore, auditing, the Message Delivery Component (MDC), remote support, LDAP User Synchronization and replication. Chapters 16 to 22 cover each of the main functionalities managed by the Administration Web Interface, including user accounts, DIGIPASS instances, client and server components, policies, organization and reporting. Chapter 23 describes the third interface, the Rescue Tool. An index at the end of the document will help you to find specific information you are searching for. Other documents in the set of axsguard Identifier documentation include: The axsguard Identifier Installation Guide, which supports planning for and installation of the axsguard Identifier. axsguard Identifier Administration Reference Guide. This document provides lists of field explanations and other reference data for technical experts using the axsguard Identifier and is intended for reference only. Information is provided in table format for quick reference. The axsguard Identifier SDK Programmer's Guide, which provides in-depth information required for development work using the SDK. This document is only relevant to SOAP Authentication, Electronic Signatures and Provisioning, which are not currently available with the axsguard Identifier. Access to the axsguard Identifier guides is provided via the axsguard Identifier Configuration Tool. The axsguard Identifier Installation Guide is also provided with delivery of the axsguard Identifier. 14

15 1.2 Introduction About VASCO VASCO is a leading supplier of strong authentication and Electronic Signature solutions and services specializing in Internet Security applications and transactions. VASCO has positioned itself as global software company for Internet Security serving customers in more than 100 countries, including many international financial institutions. VASCO s prime markets are the financial sector, enterprise security, e-commerce and e-government. Over 50 of VASCO s client authentication technologies, products and services are based on VASCO s one and unique core authentication platform: VACMAN. VASCO solutions comprise combinations of the VACMAN core authentication platform, IDENTIKEY authentication server, axsguard authentication appliances, DIGIPASS client Password and Electronic Signature software and DIGIPASS PLUS authentication services. For further information on these security solutions, please see Contact Information Brussels (Europe / Middle East / Latin America) info-europe@vasco.com Boston (North America) info-usa@vasco.com Sydney (Pacific / Japan / India) info-australia@vasco.com Singapore (Asia) info-asia@vasco.com 15

16 2 axsguard Identifier 2.1 Overview axsguard Identifier In this chapter, we introduce the products and concepts which together provide VASCO's authentication solution with the axsguard Identifier. Section 2.2 briefly describes VASCO's authentication solution. Section 2.3 introduces the axsguard Identifier. Section 2.4 introduces the IDENTIKEY Server. Section 2.5 explains management of DIGIPASS devices and records. Section 2.6 describes the structure and components of the axsguard Identifier. Section 2.7 outlines VASCO axsguard Identifier licensing models. Finally, sections 2.8 and 2.9 describe the support procedure and VASCO Service Center. 2.2 VASCO's Authentication Solution DIGIPASS devices provide the client component of VASCO s authentication solution, issued by the Application Service Provider (ASP) to end users (the DIGIPASS holders), to support: One Time Passwords, to authenticate end users to the ASP, to protect access to services and resources Host Codes, to authenticate the ASP to end users Electronic Signatures, to protect the integrity and authenticity of financial transactions or other security-critical communications (not currently available with the axsguard Identifier). The DIGIPASS client component uses a variety of cryptographic algorithms to calculate One Time Passwords, Host Codes and Electronic Signatures. Each DIGIPASS device is pre-programmed by VASCO with a unique secret value, which is used to generate One Time Passwords and Electronic Signatures, so that these are unique to each DIGIPASS. VACMAN is the server side component of VASCO s authentication solution, installed on the computer or back-end system of the ASP. This VACMAN software can be installed as an appliance, a server component, a middleware component, or an Application Programming Interface (API). One Time Passwords and Electronic Signatures generated by the DIGIPASS client devices are verified by the VACMAN software. 16

17 axsguard Identifier Image 1: VASCO's Authentication Solution Application Service Providers assign DIGIPASS client devices to holders, based on the serial number of the DIGIPASS and the holder s ID. Each DIGIPASS device is delivered in a controlled way to the holder, together with a manual and (optionally) the PIN code. To use the DIGIPASS, the holder needs to be in possession of the DIGIPASS, to know the PIN to access applications run by the DIGIPASS, and to have a connection to the VACMAN software. The VACMAN software knows which secret is loaded in each DIGIPASS. These secrets are transported initially in an encrypted way to the ASP and then stored in a database run together with the VACMAN software. In this process the DIGIPASS serial number is used as reference for the DIGIPASS secrets. 2.3 What is the axsguard Identifier? The axsguard Identifier secures internal and remote access to network applications, and remote access to applications offered on line. It is a stand-alone authentication solution based on IDENTIKEY, a version of the VACMAN software which is compatible with both LINUX and Windows environments. Together with DIGIPASS technology providing the client side component, the solution delivers strong two factor authentication. The axsguard Identifier is a simple and cost-effective solution, which can easily be integrated into existing IT infrastructures to support authentication in small to medium sized enterprises. The product integrates new usability features described as a 'convenience layer' together with the IDENTIKEY software, including: simple installation and maintenance remote support from VASCO experts semi automatic updating (proactively prompting update, but still within the control of the administrator) simple registration backup and restore functionality real time feedback on system status with statistics 17

18 2.4 axsguard Identifier What is the IDENTIKEY Server? The IDENTIKEY server supports the deployment, use and administration of VASCO DIGIPASS technology. It is designed to be easily usable with online applications and has a web based Administration interface. IDENTIKEY in the axsguard Identifier supports: DIGIPASS One Time Password authentication Administration and reporting Auditing Customized reporting Authentication management through a web based interface Later versions of the axsguard Identifier will also support: DIGIPASS Electronic Signatures DIGIPASS Software provisioning 2.5 What is a DIGIPASS? A DIGIPASS is a device for providing One Time Passwords to an end user. It is the client component of VASCO s authentication solution, issued by the Application Service Provider (ASP) to end users (the DIGIPASS holders), to support One Time Passwords and Host Codes with the axsguard Identifier. A DIGIPASS can be provided by an organization to everyone authorized to log on to their system using a One Time Password (OTP). The DIGIPASS holder obtains an OTP from the DIGIPASS to use instead of, or in addition to a static password when logging on. The DIGIPASS family comprises four groups of client side solutions: DIGIPASS Software: products in this group run on existing non-vasco platforms, such as PCs, mobile phones and palm tops etc. DIGIPASS Software includes DIGIPASS for Web (fully browser based), DIGIPASS for Windows (client based), DIGIPASS for Mobile Phone (JAVA based) and the Virtual DIGIPASS (server based authentication). These products thus re-use existing and familiar end user devices. DIGIPASS Keys: products in this group are VASCO specific USB connected devices that can be used to generate One Time Passwords. They also support Electronic Signature features and can extend the use of VASCO products to digital signing for a Public Key Infrastructure (PKI) environment. DIGIPASS Hardware: products in this group are VASCO specific hardware platforms preprogrammed individually with secret values. DIGIPASS Hardware does not re-use existing infrastructures or smart cards, and can therefore be implemented by any organization. 18

19 axsguard Identifier DIGIPASS Readers: products in this group include connected and unconnected models. DIGIPASS Readers combine secret values, which are stored in the smart cards, with DIGIPASS algorithms pre-programmed into the DIGIPASS reader, which also provides the user interface. These products optimize investment in smart card technology, by extending smartcard use to include One Time Passwords and Electronic Signatures. For more information, please visit Structure of the axsguard Identifier Overview Image 2: axsguard Identifier Architecture The axsguard Identifier comprises the IDENTIKEY, the convenience layer, an internal database, and three user interfaces. Image 2 shows the main components. 19

20 axsguard Identifier We have already described the axsguard Identifier convenience layer and the IDENTIKEY in sections 2.3 and 2.4 respectively. The three user interfaces shown in Image 2 are the axsguard Identifier: Configuration Tool for system administrators, for installation and maintenance. Administration Web Interface, for system administrators to manage the daily use of the system. Rescue Tool, intended for administrators to manage some limited settings. These three interfaces and the functionality they support are explained in more detail in section 4. The axsguard Identifier supports client applications including: SOAP Authentication (currently in development, to be included in a future release) RADIUS Authentication IIS Authentication (SEAL) DIGIPASS Software Provisioning (SOAP) (currently in development, to be included in a future release) Electronic Signature Validation (SOAP) (currently in development, to be included in a future release) Additionally the axsguard Identifier can call on back-end authentication with RADIUS or LDAP (Active Directory or e-directory) Communication Protocols Communication protocols are shown in orange in Image 2 and include: SOAP RADIUS, and SEAL These are enabled by default if included in the license. SOAP and RADIUS require a license option; SEAL does not. Note RADIUS support is present for authentication by client applications (Access-Requests) using PAP, CHAP, MS-CHAP and MS-CHAP2. MPPE keys are generated for MS-CHAP and MS-CHAP2. 20

21 2.6.3 axsguard Identifier Scenarios Scenarios are the client applications and other functionalities supported by the axsguard Identifier. They are shown with blue shading in Image 2. Scenarios are enabled by default subject to support in the license. Scenarios include: SOAP (not currently available), RADIUS and SEAL Authentication Provisioning (not currently available) Electronic signatures (not currently available) Administration Reporting (functionality available through the Administration Web Interface) Auditing (functionality available through the Configuration Tool) Replication (functionality available through the Configuration Tool) 2.7 Licensing Overview The axsguard Identifier can be supplied under a commercial or DEMO license. We explain the two licensing mechanisms here. We also briefly introduce the concept of loading License Keys for client components. For more information on registration, please see section Commercial Licensing With the purchase of a commercial license, the axsguard Identifier needs to be registered with the license and serial numbers. Registration is the process of identifying an issued axsguard Identifier to the VASCO Service Center for the issue of a license key to make the appliance fully operational. Registration happens during installation using the Registration Wizard (see section 6). Once the axsguard Identifier is registered, full functionality is available DEMO Licensing With a DEMO license, the axsguard Identifier also needs to be registered, but with a 'DEMO' license type, and with no license or serial number. Full functionality is available for a registered DEMO version of the axsguard Identifier for 30 days. After thirty days, the axsguard Identifier services are made unavailable, although the Configuration Tool and Administration Web Interfaces are accessible for configuration and management. 21

22 2.7.4 axsguard Identifier Client Component Licensing Certain Client modules such as the IIS Modules also require a License Key to be loaded into their Client component record. Otherwise, the axsguard Identifiers to which they connect reject their authentication requests. Client component licenses can also be evaluation (time-limited) licenses. For more information on client component licensing, please see section Support Procedure If you encounter problems with a VASCO product, please follow the steps below: 1. Check if your problem has been resolved in the online Knowledge Base at: 2. If you are unable to solve your problem with the Knowledge Base, please contact the company which sold you the VASCO product. 3. If your supplier is unable to solve your query, they will automatically contact the appropriate VASCO expert. If necessary, VASCO experts can access your axsguard Identifier remotely to solve any problems. Remote support and access to your axsguard Identifier are achieved through the VASCO Service Center and the infrastructure described in the following section (see also section 13 on remote support). 22

23 2.9 axsguard Identifier VASCO Service Center Image 3: Connection between the axsguard Identifier and VASCO Service Center The VASCO Service Center server handles registration, updating and remote support for the axsguard Identifier. The connection between the axsguard Identifier and the VASCO Service Center requires the appliance site firewall to be configured to allow an outgoing connection on port TCP 443 to sc.vasco.com. Your organization may prefer this port not to be permanently open for the automatic connection on boot-up of the axsguard Identifier to the VASCO Service Center (see section 13). In this case, the port needs to be opened specially for connection, e.g. for registration (see section 6), updating (see section 7), and remote support (see section 13). Please see the axsguard Identifier Administration Reference Guide for more information on the firewall ports used on the axsguard Identifier. The axsguard Identifier must be able to resolve the VASCO Service Center address (sc.vasco.com) to an IP address. Please see section 5 for instructions on DNS server settings. 23

24 User Authentication Section Authentication Process Overview Identifying the Component Record Identifying a Policy DIGIPASS User Account Lookup and Checks Local Authentication Back-end Authentication Authorization Profiles/Attributes Host Code Generation

25 User Authentication Process 3 User Authentication Process 3.1 Authentication Process Overview In this chapter we describe in detail the User authentication process. axsguard Identifier authenticates logins in two basic ways: Local Authentication, using information from its data store Back-end Authentication, asking a RADIUS server or LDAP back-end system for verification of information The exact authentication process used by the axsguard Identifier varies depending on settings in the applicable Policy, DIGIPASS User account and DIGIPASS records. The diagram below shows the basic authentication process. More details on the concepts used throughout this chapter are available in sections 16 to 21. Image 4: Authentication Process Overview 25

26 3.2 User Authentication Process Identifying the Component Record A record must exist in the database for any client application sending an authentication request to the axsguard Identifier. This client component is identified using: Component Type 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 vary slightly according to the type of component. For more information please see section Identifying a Policy Policies specify various settings that affect all request handling processes. Each request is handled according to a Policy, which is identified by the applicable server and client records (see also sections 19 and 18 on Server and Client Components respectively). For more information on Policies, please see section 20. For a full listing of possible Policy settings and the pre-loaded policies available with the axsguard Identifier, please refer to the axsguard Identifier Administration Reference Guide. 3.4 DIGIPASS User Account Lookup and Checks Overview axsguard Identifier performs a number of checks before proceeding to local authentication, including: User ID and Domain Resolution, which is explained in section DIGIPASS User Account Lookup, which is explained in section Checking whether Dynamic User Registration is enabled for a user (if a DIGIPASS user account doesn't exist), which is explained in section User ID and Domain Resolution Caution Using NT4-style domain qualification in front of the User ID: DOMAIN\userid is not allowed on the axsguard Identifier. 26

27 User Authentication Process In the axsguard Identifier, DIGIPASS User accounts are identified using a User ID and a Domain. This process is shown in the image below and explained here, cross-referencing the numbers in the image: 1. If entry fields for the User ID and Domain are separate, name resolution ends and authentication continues. Otherwise Simple Name Resolution continues in step If login uses a similar format to User-Principal-Name: user@domain, Simple Name Resolution continues to step 3. Otherwise, Default Domain Processing proceeds in step The axsguard Identifier searches for a Domain record with the name given after the '@' sign. If the Domain record is found, name resolution continues to step 4. Otherwise, Default Domain Processing proceeds in step The User ID and domain parts are separated out, name resolution ends and authentication continues. 5. If the Default Domain field has been configured for the Policy, name resolution continues in step 6. Otherwise, domain processing continues in step The User ID is used as entered, with the Default Domain from the Policy. Domain resolution ends and authentication continues. 7. The Master Domain is used, Domain resolution ends and authentication continues. More information on the Master Domain is available in section Image 5: User ID and Domain Resolution 27

28 3.4.3 User Authentication Process DIGIPASS User Account Lookup The axsguard Identifier checks that the User attempting to log in has a DIGIPASS User account in the axsguard Identifier data store. The User ID and Domain Resolution described above 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, Policy settings determine whether the axsguard Identifier continues processing or rejects the authentication request: If Local Authentication is required, a DIGIPASS User account must exist. It is therefore only possible to proceed if the Dynamic User Registration feature is enabled. This is explained below. If Local Authentication is not required, authentication 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 DIGIPASS/Password or DIGIPASS Only, Local Authentication is required. More information on the different Local Authentication settings is available in section Dynamic User Registration Dynamic User Registration (DUR) allows DIGIPASS User accounts to be created automatically if their credentials are validated by Back-end Authentication. The correct static password is 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 with: the DIGIPASS Auto-Assignment feature, which assigns the next available DIGIPASS to the new DIGIPASS User account as it is created, or the DIGIPASS Self-Assignment feature, which allows the new User to assign a DIGIPASS to their account as part of the login process The image below shows a typical DUR process and how Auto- and Self-Assignment may be integrated. For more information on the various DIGIPASS assignment possibilities, please see section Note: The User IDs and Domains detected during an authentication attempt are automatically converted to lower case to prevent the creation of multiple DIGIPASS User Accounts for a single user. For example, if a User logs in with jsmith on one occasion, and JSmith on another, only one DIGIPASS User Account is created jsmith. 28

29 User Authentication Process Image 6: Dynamic User Registration Process 29

30 User Authentication Process 3.5 Local Authentication Overview Local Authentication is a term used to describe the axsguard Identifier authenticating a User based on information in its data store. Typically the DIGIPASS One Time Password (OTP) is required, but in other cases a static password may be sufficient. In this section we explain authentication with and without a DIGIPASS device Local Authentication Policy Setting The Local Authentication Policy setting indicates whether to perform Local Authentication, and if so, whether a static password is permitted. This setting is overruled by the same setting in the DIGIPASS User account, unless the value in the DIGIPASS User account is 'Default', in which case the Policy setting is used. Local Authentication is only set at DIGIPASS User account level for special case Users. The possible values for the Local Authentication setting are shown in the table below. Table 1: Values for Local Authentication Setting Setting Explanation Default Local Authentication is handled as configured in settings inherited from the parent policy. More information on Local Authentication in relation to policies and inheritance can be found in section 20. None No Local Authentication takes place. DIGIPASS Only A DIGIPASS One Time Password must be verified. Users without a DIGIPASS device cannot log in. However, DIGIPASS Self-Assignment is still possible, as an OTP is used as part of the process (see section 17.4 for information on DIGIPASS assignment options.) 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 device, they may continue to authenticate with their static password Authentication with DIGIPASS Overview In this section on authentication with a DIGIPASS device, we first explain DIGIPASS lookup and checks in section Following successful DIGIPASS lookup and checks, with at least one DIGIPASS record returned, request processing can continue. 30

31 User Authentication Process The three possible requests mechanisms are: a Response only One Time Password (OTP: described in section ) a Challenge for Challenge/Response OTP generation (described in section ) a Virtual DIGIPASS OTP (described in section ; for further information on Virtual DIGIPASS use, please see section 17.5) For more information on these authentication methods, see section DIGIPASS Lookup and Checks 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 records assigned to the DIGIPASS User Account. However, if no DIGIPASS User Account is found, a DIGIPASS is not searched for. This can occur if Dynamic User Registration is enabled: see section 3.4. When a DIGIPASS User Account is found, the search for DIGIPASS records may be affected by policy restrictions, linked user accounts and a DIGIPASS Grace Period as explained below. Having taken these restrictions into account, it is possible that multiple DIGIPASS records and/or multiple applications enabled for a DIGIPASS may be identified. In this case, the axsguard Identifier checks all available applications. Any one of them can validate the OTP. Validation only needs to be completed with one application, after which the axsguard Identifier stops checking through the available applications. Image 7: Multiple DIGIPASS Assignment 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: Application Names - a list of named applications. Only DIGIPASS with one or more of the named applications are usable. 31

32 User Authentication Process Application Type - either Response Only, Challenge/Response or Multi-Mode. Only DIGIPASS with the Application Type are usable, except Multi-Mode which matches all application types. DIGIPASS Type - a list of models such as DP GO3, DP 260. Only DIGIPASS from the listed models are usable. It is therefore possible that a DIGIPASS User account with a DIGIPASS assigned cannot use the DIGIPASS to log in, when a certain Policy applies. In this case, the User is regarded as not having a DIGIPASS device. With a different kind of login, a different Policy may apply with no restrictions. In this case the User is treated as having a DIGIPASS device. Example Consider a company using both GO 3 DIGIPASS (DP GO 3) and Primary Virtual DIGIPASS. The Outlook Web Access login could permit both, so its Policy would not restrict DIGIPASS Types. However the RADIUS VPN login might require the GO 3, so its Policy would specify DIGIPASS Type = DPGO3. Searching for a Linked User Account User accounts can be linked allowing a DIGIPASS device to be shared between two user accounts. This is achieved with the Linked User Account property, explained in section When an authenticating DIGIPASS user account is linked to another, the other account is searched 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. However, when DIGIPASS User account 2 logs in, the DIGIPASS search is also for DIGIPASS User account 1. Grace Period A Grace Period (see section ) 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 DP 300 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 DP 300, he uses only his User ID and static password to log in. As he is still within the Grace Period for the DP 300, the login is valid. 32

33 User Authentication Process Response Only The Response only login and authentication process involves the following steps: the User generates an OTP with their DIGIPASS device the User enters their User ID and the OTP in the login window the axsguard Identifier authenticates the User (see image below). Image 8: Response Only Login and Authentication Process Challenge/Response There are two processes possible for a Challenge/Response OTP login: 1-step login: this is useful for client applications which can only support a single login screen, e.g. RADIUS without support for Challenge/Response or Web HTTP Basic Authentication. The Challenge generated by the axsguard Identifier is not specific to any DIGIPASS device, but is presented in the login window when the User attempts to access the client application. 2-step login: this is possible with applications which support two login screens, e.g. Citrix Web Interface and RADIUS with support for Challenge/Response. The User first requests a Challenge, submitting identification data. The Challenge generated by the axsguard Identifier is then specific to the User's DIGIPASS device. This adds an extra security layer to the login and authentication process. Some Policy settings are possible for Challenges: Challenge length: the length of the challenge for all users can be pre-defined (please see the on line help for more information). Challenge Check digit: Challenges may include 'check digits' computed from the structure of the Challenge, which enable a DIGIPASS device to reject an incorrectly typed (and therefore invalid) Challenge (please see the on line help for more information). Challenge Check Mode: this setting is for advanced control over time-based Challenge/Response authentication (please see the on line help for more information). 33

34 User Authentication Process For more information on time- or event-based Challenge/Response DIGIPASS authentication methods, please see section For more information on Policies, please see section Step and 2-Step Login proceesses are explained here: 1-Step Login With 1-step Challenge/Response OTP Login (illustrated to the left in the image below): 1. A random Challenge (of length configured for all users) generated by the axsguard Identifier is presented in the client application login window. 2. The User enters the Challenge into their DIGIPASS device. 3. The DIGIPASS generates the Response, i.e. the OTP. 4. Single Login Step: the User enters their User ID and the OTP into the login window. 5. The axsguard Identifier authenticates the User. Caution: This mode is suitable for time-based Challenge/Response, but is less secure for non-time based Challenge/Response. If an attacker manages to capture some valid Responses, they can repeatedly request new Challenges until one they know the Response for comes up again. 2-Step Login With 2-step Challenge/Response OTP Login (illustrated to the right in the image above): 1. Login Step 1: the User logs in with a User ID and password and/or keyword and requests a Challenge to be generated. (The Policy defines how this request should be made, with the Request Method and Request Keyword settings explained in section ). 2. The axsguard Identifier checks the User credentials, and if OK, generates a DIGIPASS-specific Challenge which is presented in the client application login window. 3. The User enters the Challenge into their DIGIPASS device. 4. The DIGIPASS generates the Response, i.e. the OTP. 5. Login Step 2: the User enters their User ID and the OTP into the login window. 6. The axsguard Identifier authenticates the User. 34

35 User Authentication Process Image 9: 1-step (left) and 2-step (right) Challenge/Response Login Virtual DIGIPASS Login We explain here the authentication process with a Virtual DIGIPASS. For more information on Virtual DIGIPASS, see also section Using a Virtual DIGIPASS requires two login steps: requesting an OTP to be sent to the User's mobile phone entering the OTP. 2-step login for OTP request and OTP entry is possible with applications which support two login screens, e.g. Citrix Web Interface and RADIUS with support for Challenge/Response. The process is illustrated in the image below and the steps are explained here: 35

36 User Authentication Process 1. Login Step 1: the User logs in with a User ID and password and/or keyword and 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 explained in section ). 2. The axsguard Identifier checks the User credentials, and if OK, generates an OTP, which is sent to the User's mobile phone using the Message Delivery Component (MDC, explained in section 12). 3. Login Step 2: the User enters their password and OTP into the login window. 4. The axsguard Identifier authenticates the User. Backup Virtual DIGIPASS (see section ) have additional restrictions on use, to keep the cost of text messages down. These restrictions are verified by the axsguard Identifier before an OTP is generated and are described in section Image 10: Virtual DIGIPASS Login If 2-step login is not supported, e.g. RADIUS without support for Challenge/Response or Web HTTP Basic Authentication, there are two possible work-arounds: An OTP Request website can be provided, where Users can request an OTP to be sent to their mobile phone. The OTP can then be entered with the User ID in a single login window. A single login window can be used twice: the first login fails (without an OTP), but initiates an OTP request. In the second login attempt, the user enters the OTP. For further information on Virtual DIGIPASS use, please see section

37 User Authentication Process 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 in between. KeywordPassword - a fixed keyword followed by the static password, with no whitespace or separating characters in between. None - no method, the feature is disabled. The static password in the request method is compared against the DIGIPASS User account's password value. For more information on the static password check during an authentication attempt, see section The methods of requesting these three login processes (2-step Challenge/Response, Primary and Backup Virtual OTP request) can be the same. When the axsguard Identifier recognizes a request, it verifies whether there is a DIGIPASS capable of the login process: if not, it ignores the request. Example 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 log in with a keyword otp, the axsguard Identifier generates a Backup Virtual DIGIPASS OTP, because the User does not have a Primary Virtual DIGIPASS 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 a DIGIPASS record. Static password verification and Self-Assignment are explained here. 37

38 User Authentication Process Static Password Verification Static Password Verification calls on the Static Password defined in the DIGIPASS User Account record. This password is also used for other purposes (see section 16.5). Static Password authentication passes through the steps shown in the image below and described here, crossreferencing the numbers in the image: 1. If a User account does not exist, the request is passed on to the Dynamic User Registration check in step 5. If a User account exists, the request continues to the User account check in step If a static password is not set in the User account, the request is passed on to the back-end authentication check in step 6. If a static password is set in the User account, the request continues to local authentication (step 3). 3. If local authentication with the static password is not successful, the request is passed on to the back-end authentication availability check in step 6. If local authentication is successful, the request continues to the Policy check in step If local authentication is successful and back-end authentication is not mandatory, the User is authenticated. If local authentication is successful, but back-end authentication is mandatory, the request is passed on to the back-end authentication availability check in step 6. (For more information on Policy settings for backend authentication, please see section ) 5. If DUR is not permitted, authentication fails. If DUR is permitted, the request is passed on to the back-end authentication availability check in step If back-end authentication is not available, authentication fails. If back-end authentication is available, the request is passed on to step If back-end authentication is not successful, authentication fails; if back-end authentication succeeds, the User is authenticated. Note: 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 (see the following section and section ). 38

39 User Authentication Process Image 11: Static Password Authentication Flow Self-Assignment A User is able to assign a DIGIPASS device to their DIGIPASS User account using the Self-Assignment mechanism, if permitted by the Policy settings. The Self-Assignment process is possible during Dynamic User Registration. It is also possible when the Local Authentication setting is DIGIPASS Only. For information on the self-assignment process, please see section

40 3.6 Back-end Authentication Overview User Authentication Process Back-end Authentication is a term used to describe the process of checking User credentials with another system. With axsguard Identifier this could mean a RADIUS server or an LDAP-based back-end server. It is used for various purposes, including: Enabling automatic management features such as Dynamic User Registration and Self-Assignment (see section 3.4) Static password verification for Users who do not have a DIGIPASS device and for Virtual DIGIPASS (see sections and ) Retrieval of RADIUS attributes from a RADIUS server (explained below) Password Replacement - allowing the User to log in with just a One Time Password, in an environment where the Windows password is required, e.g. Outlook Web Access (explained below) First we introduce the back-end server policy settings, and then explain how a static password is used during back-end authentication. We then describe back-end server records and their specific types Back-end Server Policy Settings 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 this has the value Default. However, this setting in the DIGIPASS User account would typically only be used for rare special case Users. The possible values for the back-end authentication setting are listed in the table below. The Back-end Protocol setting indicates whether back-end authentication uses RADIUS (a RADIUS server) or LDAP to authenticate towards the back-end server. For more information on Policy settings, see section

41 User Authentication Process Table 2: Values for Back-end Authentication Setting Setting Explanation Default Back-end authentication is handled as configured in settings inherited from the parent policy. More information on policies and inheritance can be found in section 20. None The axsguard Identifier does not use back-end authentication. If needed Back-end authentication is only used in situations where Local Authentication is not sufficient and to support certain features: Dynamic User Registration Self-Assignment Password Autolearn Requesting a Challenge or Virtual DIGIPASS One Time Password (OTP), when the Request Method includes a Password Static password authentication, when verifying a Virtual DIGIPASS password-otp combination or during the Grace Period Always The axsguard Identifier uses back-end authentication for every authentication request. This is necessary if you require RADIUS attributes for each login. Back-end Authentication and Static Password The table above lists scenarios supported by back-end authentication. To use these scenarios requires a DIGIPASS User Account static password. In this section, we explain options for manipulating the static password field during the authentication process. For more information on DIGIPASS User Accounts and static password handling, please see section Stored Password Proxy When the Stored Password Proxy setting is enabled in the Policy, and the User authenticates using a DIGIPASS OTP only, the axsguard Identifier retrieves the Stored Static Password from the DIGIPASS User account, which can then be used: for authentication towards a back-end server. This means that the User does not need to type in the static password at each login; they only need enter the OTP. A practical use of this setup is forwarding RADIUS attributes from a back-end server (see section below). to support Password Replacement. Back-end authentication is used to learn the static password so that it can be replayed to the host system (e.g. Outlook Web Access) when a successful OTP is given (see section below). However, if the User enters a static password before their OTP, the static password entered takes precedence over the Stored Static Password. In this case, the Stored Static Password is not used at all for the login. When the Stored Password Proxy setting is not enabled in the Policy, the Stored Static Password is not used for back-end authentication. If back-end authentication is required for a login, the User must enter the static password, before 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 must enter the static password. 41

42 User Authentication Process Password Autolearn A back-end server static password can be specified in addition to a DIGIPASS OTP, during an authentication attempt. If the Password Autolearn option is enabled, the static password is automatically stored in the DIGIPASS User Account, if authentication with a back-end server succeeds. Use of the Stored Password Proxy functionality is then possible. Any changes to a User's back-end server password need to be communicated to the axsguard Identifier. 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 axsguard Identifier, it can be verified with the back-end server. If correct, the axsguard Identifier stores the new static password for future use and authenticates the User. When the Password Autolearn option is disabled, initial and modified static passwords must be entered manually in the Administration Web Interface, to support the Stored Password Proxy functionality Password Replacement (IIS Modules) The IIS Module is an add-on for the axsguard Identifier, which is installed on the Microsoft IIS Server, for example, configured with Microsoft Outlook Web Access. The IIS Module supports use of the DIGIPASS OTP for access to the Outlook Web service. After installing the module on the Microsoft Server, DIGIPASS OTP authentication requests are intercepted and forwarded to the axsguard Identifier. After successful authentication on the axsguard Identifier, the stored static password is forwarded to the Outlook Web Access application, allowing completion of the authentication process (see image below). The Microsoft Outlook Web Access password (the static password) only needs to be supplied by the User on firsttime use, and when modified on the Microsoft infrastructure, because it is stored in the DIGIPASS User Account on the axsguard Identifier. This setup requires the following server-side configuration actions: Creation of a client component, type SEAL. Assigning the Policy, IDENTIKEY Microsoft AD Password Replacement, to the client component. In this Policy, the Password Autolearn and Stored Password Proxy options are enabled. Uploading the Client License into the client component record. A Wizard is available during installation of the IIS Module, on the Microsoft Server, which automatically performs the steps described above on the axsguard Identifier (see the IIS Module related documentation for more information). 42

43 User Authentication Process Image 12: Password Replacement with an IIS Module Stored Static Password and RADIUS Attributes The purpose of this setup is to enforce DIGIPASS OTP authentication to an existing RADIUS client and server infrastructure, without losing the RADIUS attribute functionality. This is achieved by configuring the RADIUS client to authenticate towards the axsguard Identifier and configuring a RADIUS back-end server record on the axsguard Identifier for the RADIUS server. After these configurations, the DIGIPASS OTP authentication requests from the RADIUS client are verified by the axsguard Identifier. After successful authentication on the axsguard Identifier, the stored static password is forwarded to the RADIUS back-end server, and the required RADIUS attributes are retrieved. These attributes are forwarded by the axsguard Identifier to the RADIUS client, which completes the authentication request (see image below). The RADIUS Server password (the static password) only needs to be supplied by the User on first-time use, and when modified, because it is stored in the DIGIPASS User Account on the axsguard Identifier. 43

44 User Authentication Process This setup is achieved by configuring the following Policy options: Local authentication: DIGIPASS or DIGIPASS/Password Back-end authentication: Always Back-end authentication protocol: RADIUS Password autolearn: On Stored Password Proxy: On Image 13: Steps in the Retrieval of RADIUS Attributes Back-end Server Records If a back-end server is to be used by the axsguard Identifier for authentication, it must be registered in the axsguard Identifier. 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 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 axsguard Identifier must decide which to use for a back-end authentication request. The axsguard Identifier attempts to connect to the back-end server with the highest Priority rating. If it is not available after the set No. of Retries, the axsguard Identifier attempts to connect to the back-end server with the next highest Priority rating. 44

45 User Authentication Process The time between retries is a few minutes, i.e. long enough to ensure that a temporary delayed response due to a peak load does not prevent a back-end server from being used. A consistent lack of response for the set number of retries causes the back-end server not be used for a pre-defined length of time, if an alternative is available. After this pre-defined length of time, the axsguard Identifier retries once again 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 axsguard Identifier needs to choose a back-end server, it searches for records in the domain identified by the User ID and Name Resolution process (see section 3.4.2). If any are found, it only uses the back-end servers for that domain. If none are found, it uses the back-end servers which are not assigned to a domain RADIUS Back-end Authentication axsguard Identifier supports RADIUS back-end authentication (see also section ). A RADIUS back-end server record contains connection information for the RADIUS server, including location details and the RADIUS Shared Secret. It also allows a Timeout and No. of Retries to be configured. User ID Formats User ID formats possible with RADIUS back-end authentication are shown in the table below. Table 3: RADIUS User ID Formats for Back-end Authentication User ID Format Example With domain geraard@domain.com Without domain geraard Authentication Process There are two steps to back-end authentication with RADIUS (see image below): 1. First the back-end server for authentication needs to be identified. A User ID can be provided for authentication with or without inclusion of the domain reference (i.e. the '@domain.com' part). If the domain is included and exists, the back-end server for the domain is identified. If the domain is not included, or is included but does not exist, and a default domain is specified in the policy for the client, the back-end server for the default domain is identified. If the domain is not included, or is included but does not exist, and a default domain is not specified in the policy for the client, the back-end server for the Master domain is identified. 2. Once the back-end server is identified, back-end authentication can be completed using the User ID and password provided with the authentication request: 45

46 User Authentication Process If back-end authentication succeeds, the user authentication on the axsguard Identifier is successful. If back-end authentication fails, user authentication on the axsguard Identifier fails. Image 14: Back-end Authentication Process with RADIUS RADIUS Services The RADIUS protocol can support three services (RADIUS AAA): RADIUS Authentication is supported by the axsguard Identifier (described above). RADIUS Accounting is is supported by the axsguard Identifier. With a RADIUS back-end server, Accounting requests are forwarded to the back-end server and handled by proxy. Without back-end authentication, audit messages are generated. RADIUS Authorization handles requests for an authentication client to use a particular service and is only possible with a RADIUS back-end server. RADIUS Authorization cannot be supported by the axsguard Identifier without a RADIUS back-end server. 46

47 User Authentication Process LDAP Back-end Authentication axsguard Identifier supports LDAP back-end authentication. The directory services supported by axsguard Identifier for LDAP back-end authentication are: Microsoft Active Directory Novell e-directory. These are explained in the following sections. Tip For instructions on how to configure LDAP back-end authentication, please refer to the axsguard Identifier Installation Guide Microsoft Active Directory Back-end Authentication User ID Formats User ID formats possible with Microsoft Active Directory back-end authentication are shown in the table below. Table 4: Microsoft Active Directory User ID formats for Back-end Authentication User ID Format Example With domain Without domain geraard 47

48 User Authentication Process Authentication Process Image 15: Back-end Authentication Process with Microsoft Active Directory There are two steps (see image above) to back-end authentication with Microsoft Active Directory : 1. First the back-end server for authentication needs to be identified. A User ID can be provided for authentication with or without inclusion of the domain reference (i.e. the '@domain.com' part). If the domain is included and exists, the back-end server for the domain is identified. If the domain is not included, or is included but does not exist, and a default domain is specified in the policy for the client, the back-end server for the default domain is identified. If the domain is not included, or is included but does not exist, and a default domain is not specified in the policy for the client, the back-end server for the Master domain is identified. 2. Once the back-end server is identified, binding (i.e. back-end authentication), can be completed using the User ID and password provided with the authentication request: If the bind on the back-end server succeeds, the user authentication on the axsguard Identifier is successful. If the bind on the back-end server fails, the authentication on the axsguard Identifier fails. 48

49 User Authentication Process Limitations Windows 2000 is not supported. The version of Windows used with LDAP back-end authentication must be Windows 2003 or higher. Note: 1) The 'SAMAccountName' attribute is used by Microsoft Active Directory to identify the User ID. 2) axsguard Identifier only supports SASL.Digest-MD5 binding as the client authentication mechanism for binding with the supported back-end authentication servers Novell e-directory Back- end Authentication User ID Formats User ID formats possible with Novell e-directory back-end authentication are shown in the table below. Two formats are Fully Qualified Distinguished Names (FqDNs) and two are Relative Distinguished Names (RDNs). Table 5: Novell e-directory User ID Formats for Back-end Authentication User ID Format Example FqDN userid (Fully Qualified Distinguished Name) Geraard.Administration.Mechelen.CORP RDN userid (Relative Distinguished Name) Geraard FqDN RDN Authentication Process There are three steps (see image below) to authentication with Novell e-directory: 1. First the back-end server for authentication needs to be identified. A User ID can be provided for authentication with or without inclusion of the domain reference (i.e. the '@domain.com' part). If the domain is included and exists, the back-end server for the domain is identified. If the domain is not included, or is included but does not exist, and a default domain is specified in the policy for the client, the back-end server for the default domain is identified. If the domain is not included, or is included but does not exist, and a default domain is not specified in the policy for the client, the back-end server for the Master domain is identified. 49

50 2. User Authentication Process Secondly, the user account needs to be located for authentication. With an FqDN, sufficient information is already provided to find the user account for authentication. With an RDN, the principal name and password are used to bind and search for the user account. Searching starts from the base DN, e.g. 'Administration.Mechelen.CORP', specified in the axsguard Identifier Configuration Tool. 3. Once a user account is located, binding (i.e. back-end authentication), can be completed. If the bind on the back-end server succeeds, the user authentication on the axsguard Identifier is successful. If the bind on the back-end server fails, the authentication on the axsguard Identifier fails. Limitations There are some limitations to Novell e-directory back-end authentication: Windows 2000 is not supported. The version of Windows used with LDAP back-end authentication must be Windows 2003 or higher. The version of Novell e-directory used for LDAP back-end authentication must be version 8.7 or higher. The base DN, principal name and password need to be specified in the Configuration Tool (see section 4 on the administration interfaces) for binding (see step 2 above) to search for a RDN user account. The base DN serves as the starting point for searches in the LDAP hierarchy. Only one set of principal name, password and base DN (for binding) can be added in the axsguard Identifier Configuration Tool. This restricts authentication to a single back-end server for Relative Distinguished Names (RDN). Authentication for Fully Qualified Distinguished Names (FqDN) can be supported by multiple back-end servers. Note: 1) A single domain can have multiple back-end servers, because they can be operating in failover (or replication) strategy (see section ). 2) If there is no back-end server for a specific domain, a back-end server with no domain specified is used (see section ). 3) axsguard Identifier only supports SASL.Digest-MD5 binding as the client authentication mechanism for binding with the supported back-end authentication servers. Caution: With Dynamic User Registration, if a user attempts to authenticate at different times with an RDN and FqDN, two user accounts are created for a single user. 50

51 User Authentication Process Image 16: Back-end Authentication Process with Novell e-directory Policies Policies are included with axsguard Identifier, which can be used to allow the use of Active Directory or Novell edirectory. The policies can be selected from the Policies tab of the axsguard Identifier Administration Web interface (see section 4 on the administration interfaces). The LDAP back-end authentication policies are: IDENTIKEY Microsoft AD Password Replacement IDENTIKEY Novell e-directory Password Replacement IDENTIKEY Microsoft AD Auto Assignment IDENTIKEY Novell e-directory Auto Assignment IDENTIKEY Microsoft AD Self Assignment IDENTIKEY Novell e-directory Self Assignment. 51

52 User Authentication Process 3.7 Authorization Profiles/Attributes Some IIS Modules, e.g. IIS module for basic authentication, utilize User attributes to allow a website to retrieve authorization information from local accounts following successful authentication. For more information, please refer to relevant IIS module documentation. Individual User attributes may be set for a DIGIPASS User account. The axsguard Identifier returns these attributes to the Web Application during authentication, if requested. User Attribute settings are listed in the table below. User attributes are only supported by SOAP and SEAL requests. Table 6: User Attribute Settings Setting Explanation Attribute Name A name for the attribute as expected by the Web Application. Attribute Group An Attribute Group is specified by the Web Application as a parameter to the authorization request. When multiple IIS Modules are in use, the specified Attribute Group ensures that only attributes required by the specific Web Application are used. Usage Basic indicates that the attribute is for use by the IIS Modules for Basic Authentication. Value The Value set for an attribute is the required value of the named attribute. 3.8 Host Code Generation Concept A DIGIPASS Host Code is a One Time Password generated by the server, and verified by the end user. Host Codes are used to authenticate the server to the end user, and therefore protect against server spoofing. Spoof servers simulate a server, leading end users to believe they are the valid server, and attempt to acquire end user identity credentials. The DIGIPASS Host Code helps to protect against spoof servers, which are unable to generate valid Host Codes. Host Codes offer: Spoof server detection: end users can detect connection to a spoof server and terminate the connection, if the correct Host Code is not generated. Spoof server tracing: spoof servers can still deceive end users by requesting the valid server to generate the Host Code and sending this code to the end user. However, once the spoof server has contacted the valid server, the latter has a record of the connection in its log files, which can be used to trace the spoof server. Once the spoof server has been traced, any further connections can be rejected by the valid server. 52

53 3.8.2 User Authentication Process Using a Host Code A DIGIPASS Host Code is computed as follows: 1. The DIGIPASS device generates a One Time Password, and splits it into two parts. The first part is used for end user authentication. The second part is the Host Code and is used for authentication of the server. 2. The end user sends the first part to the server as proof of identity and keeps the second part secret. 3. The server verifies the One Time Password for end user authentication. If valid, the end user is authenticated to the server. The server then computes the second part of the One Time Password, i.e. the Host Code. 4. The server sends the Host Code to the end user, who verifies (visually) whether it matches the Host Code generated by the DIGIPASS device. 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 device is Host Code capable Required - DIGIPASS device must be Host Code capable or the request will fail Note: Host code generation is only supported by SOAP. 53

54 Administrative Interfaces Section Overview Default Administrative Users Configuration Tool Administration Web Interface Rescue Tool

55 Administration Interfaces 4 Administration Interfaces 4.1 Overview In chapters 1 and 2 we introduced the VASCO authentication solution and the structure and functionality of the axsguard Identifier. In chapter 3, we have explained the authentication process in depth. In this chapter we describe the three administration interfaces available with the axsguard Identifier. These are the: Configuration Tool, for installation and maintenance Administration Web Interface, for system administrators to manage the daily use of the system Rescue Tool, for administrators to manage some limited settings axsguard Identifier concepts which underpin the management possibilities through these interfaces are also introduced. Following this overview chapter, the management possibilities through the interfaces are elaborated on in more detail in the subsequent chapters. 4.2 Default Administrative Users Each administration interface has its own default administrative user with the following user credentials: Table 7: Default Administrative User Credentials Interface Configuration Tool Administration Web Interface Rescue Tool User name Factory default password sysadmin sysadmin admin@master identikey rescue (none required) Passwords for the Configuration Tool and Administration Web Interface default administrative users can be reset to the above factory default values using the System Actions menu in the Configuration Tool. Instructions on how to do this are provided in the axsguard Identifier Installation Guide. 55

56 4.3 Administration Interfaces Configuration Tool The Configuration Tool interface supports installation and management of the axsguard Identifier and is intended for use by system administrators. In section 2.3, we introduced the concept of the convenience layer, which comprises the functionality supported through the axsguard Identifier Configuration Tool. Some of the functionalities managed through the Configuration Tool require connection to VASCO's Service Center (VSC). The VCS is explained in section 2.9. The convenience layer comprises the following functionality, supported through the Configuration Tool: Installation configurations: a Configuration Wizard supports installation configurations and is explained in depth in section 5. Manual configurations are also possible after completion of the Configuration Wizard, using the Configuration Tool (see section 5.4). Registration: all axsguard Identifiers need to be registered. The standard procedure and exceptions are explained in section 6 (the registration procedure requires connection to the VSC). Semi-automatic updating (pro-actively prompting update, but still within the control of the administrator). Downloading and installing updates to the axsguard Identifier are explained in section 7 (the updating procedure requires connection to the VSC). Backup and Restore: the purpose and procedures for backup and restore functionality are explained in section 8. Auditing and Logging: information generated from the axsguard Identifier can be searched using live viewers (see sections 10 and 9). System statistics: statistics are available on the axsguard Identifier, the services, the disk, memory and interface (see section 11). Message Delivery Component: this is the component supporting the use of the virtual DIGIPASS and is explained in section 12. Remote support: remote support can be provided by VASCO experts and is explained in section 13 (remote support requires connection to the VSC). LDAP User Synchronization: synchronization supports automatic creation and updating of User Account records from an LDAP Server to the axsguard Identifier (see section 14.1). Replication: the purpose and possibilities with replication are explained in section 15. System actions: reboot, shut down, and resetting default administrative user passwords are actions possible using the System Actions menu in the Configuration Tool. Instructions on how to use these options are provided in the axsguard Identifier Installation Guide. Note: Please note that only the system administrator with the name 'sysadmin' can access the Configuration Tool. During installation, the system administrator's ('sysadmin') password must be changed. Installation cannot be completed without changing the password. This is a security precaution. 56

57 4.4 Administration Interfaces Administration Web Interface The Administration Web Interface supports the daily administration of the axsguard Identifier and is intended for use by help desks and system administrators. This interface allows management of: User accounts: each DIGIPASS holder is registered in the axsguard Identifier database, with a DIGIPASS user account. Managing user accounts is explained in section 16. DIGIPASS deployment: each DIGIPASS device is registered in the axsguard Identifier database. Managing DIGIPASS devices and records is explained in section 17. Client Components: authentication and administration clients are also registered in the axsguard Identifier. Managing client components is explained in section 18. System: Server components are also registered in the axsguard Identifier. Managing server components is explained in section 19. Policies: Policies specify various settings that affect request handling processes. Each request is handled according to a Policy that is identified by the applicable component record. Policies are explained in section 20. Back-end servers: back-end authentication is the process of checking User credentials with another system. With the axsguard Identifier this could mean an LDAP Active Directory/e-Directory or RADIUS server. It is used for various purposes, including Enabling automatic management features such as Dynamic User Registration and SelfAssignment Static password verification for Users who do not have a DIGIPASS device 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 (e.g. Outlook Web Access). Back-end server records are also registered on the axsguard Identifier. For in depth details on back-end authentication with the axsguard Identifier, please see section 3.6. Domains and Organizational Units: User accounts and DIGIPASS records can be grouped in the axsguard Identifier using two structures: domains and Organizational Units. Managing domains and Organizational Units is explained in section 21. Reports: the axsguard Identifier reporting functionality allows you to create reports from the database information and from the audit information. Reporting is explained in section 22. The Administration Web Interface uses the axsguard Identifier SOAP administration interface to manage data. 57

58 Administration Interfaces Note: Please note that with a factory default axsguard Identifier, only the system administrator with the name 'admin@master' has access to the Administration Web Interface. By default there are two system administrators registered in the Master Domain, which should never be removed: one for system operation ('system') and one for the axsguard Identifier system administrator ('admin@master'). Please see section 21 for more information. It is possible to create new system administrator accounts, in addition to the two default accounts. User permissions are explained in section Rescue Tool The Rescue Tool allows Administrators to access a limited number of settings through a menu. Note that this is not a TCL (Tool Command Language) Command Line. A TCL Command Line does exist within the axsguard Identifier, but is only accessible by VASCO experts. See section 23 for further information. The Rescue Tool can be used to: Reset axsguard Identifier configuration settings to factory default settings. Reset the 'sysadmin' password for Configuration Tool administration Change and view network settings, e.g. changing the IP address Reboot or shut down the system 58

59 Configuration Tool Section Installation Configurations... 5 Registration... 6 Updating... 7 Backup and Restore... 8 Logging... 9 Auditing Statistics Message Delivery Component Remote Support LDAP User Synchronization Replication

60 5 Installation Configurations 5.1 Overview Installation Configurations Installation is the process of linking the axsguard Identifier to your organization's network and configuring general settings. Installation and registration are both necessary to use axsguard Identifier services. In this section we describe installation; registration is explained in section 6. For a detailed explanation on how to install the axsguard Identifier, please refer to the axsguard Identifier Installation Guide, delivered with the axsguard Identifier. For explanations of fields in the Configuration Tool, please refer to the axsguard Identifier Administration Reference Guide, accessible in the Configuration Tool. 5.2 First Time Set-up Installation of the axsguard Identifier requires temporarily isolating a client workstation from the network and linking it to the axsguard Identifier, in order to set the axsguard Identifier IP address within the range of the network. This involves: 1. Changing a client workstation IP address to within the specified IP address range for the axsguard Identifier. 2. Connecting the client workstation to the axsguard Identifier with a cable. 3. Using a browser on the client workstation to access the axsguard Identifier Configuration Tool. The axsguard Identifier automatically detects that this is a first-time installation and launches the Configuration Wizard. During this Configuration Wizard a new IP address within your network range can be configured on the axsguard Identifier (see below). 4. The new IP address provided during the Configuration Wizard is stored on the axsguard Identifier. Both the original default IP address, and the newly entered IP address can be used at this stage. 5. The client workstation IP address needs to be changed back to one within the range of the network. The axsguard Identifier Configuration Tool can now be contacted using the new IP address. The system administrator can now remove the old IP address, by clicking on the 'removal' option. As an alternative, rebooting the system automatically removes the old IP address. The axsguard Identifier is now integrated within your set-up. 60

61 5.3 Installation Configurations Configuration Wizard The Configuration Wizard is launched when a new axsguard Identifier Configuration Tool is accessed. The Configuration Wizard must be completed to allow full access to the Configuration Tool, for manual configurations (see below). The wizard guides the system administrator through a minimal number of settings: Password change Network settings: IP address within your network including the net mask, and the default gateway to access the Internet Host name, DNS suffix, DNS server NTP (time) server If a proxy server is to be used, the IP address, user name and password General settings, e.g. the time zone. UTC (=Greenwich Mean Time) is offered as the default For detailed descriptions of the above configurations possible with the Configuration Wizard, please see the axsguard Identifier Administration Reference Guide accessible via the Configuration Tool. Tip The above major settings are completed during the Configuration Wizard, but additional features also need to be configured, including: 1. Message Delivery Component to support Virtual DIGIPASS authentication (see section 12). 2. Replication for synchronization of data between multiple axsguard Identifiers (see section 15). 3. LDAP Synchronization to synchronize User Account records from an LDAP Active Directory (see section 14.1). 4. Back-end Authentication for checking User Credentials with a RADIUS or LDAP Server (see section 3.6). For guidance on how to configure these features, please refer to the relevant sections in the axsguard Identifier Installation Guide. 5.4 Manual Configurations Completing the Configuration Wizard is mandatory before manual changes are possible in the Configuration Tool. Manual configurations are necessary: to alter default settings which were not offered during the Configuration Wizard to alter settings after initial installation (the Configuration Wizard is only offered on a factory default system). For detailed descriptions of the manual configurations possible with the Configuration Tool, please see the axsguard Identifier Administration Reference manual available from VASCO. 61

62 6 Registration 6.1 Overview Registration Registration is the process of identifying an issued axsguard Identifier to the VASCO Service Center for the issue of a license key to make the appliance fully operational. After installation, and before registration, the Configuration Tool and Administration Web Interfaces are accessible for configuration and management, but no services, such as authentication, are available. The registration procedure is supported by a Registration Wizard. The Registration Wizard is accessible through the axsguard Identifier Configuration Tool (see section 4 on the Administration Interfaces). First time registration and certain exceptions to the first time registration are described in this chapter. 6.2 First Time Registration The Registration Wizard supports a request-response dialog between the axsguard Identifier and the VASCO Service Center. The VASCO Service Center server handles registration, updating and remote support for the axsguard Identifier. The infrastructure and how to access the VASCO Service Center are explained in section 2.9. The registration process comprises four main steps: 1. When the axsguard Identifier is accessed for the first time following installation (see section 5), a warning message in the Configuration Tool advises the system administrator that the appliance is not registered, and provides a link to launch the Registration Wizard. The Registration Wizard requests a series of data, including: IP address at the appliance site (auto detected) the administrator's address axsguard Identifier serial number and license number organization's contact details reseller name The administrator needs to enter the requested data. 3. The Registration Wizard saves these data together with other system data and sends them to the VASCO Service Center. 4. The data is validated by the VASCO Service Center. If valid, the axsguard Identifier license key and support certificate (see section 13.3) are returned and stored on the axsguard Identifier. 62

63 6.3 Registration Registration without on-site Internet Access An axsguard Identifier is registered for a specific IP Address. Without the License referencing the correct IP address, services such as authentication are not operational. Registration to acquire the License requires an Internet connection to the VASCO Service Center. If the network where the axsguard Identifier will be operational has no Internet connection, the axsguard Identifier needs to be temporarily located on a network with Internet connection to complete registration. The IP address to be entered during registration, however, is the IP Address where the axsguard Identifier will be operational, not the temporary location. After registration, the IP address of the axsguard Identifier can be modified back to the IP address where it will be operational, using manual configuration as explained in section Change in IP Address A change in IP address of the axsguard Identifier renders the license invalid. The Configuration Tool and Administration Web Interfaces are accessible for configuration and management, but no services, such as authentication, are available. The axsguard Identifier automatically detects that the IP address has changed and that the license is no longer valid. A warning message is displayed in the Configuration Tool, with a link to the reregistration wizard. In this case registration only requires the IP address to be changed. Information already entered during first time registration does not need to be re-entered. The data is sent to the VASCO Service Center and a license key returned, which is automatically assigned to the axsguard Identifier. The old IP address is removed as explained in the first time set-up (see section 5). The old license key remains stored in the server component (see section 19). The old IP address can be reassigned to the axsguard Identifier, as the license key remains available for that IP address unless the server component is removed manually. 6.5 Upgrade from a DEMO to Commercial License Upgrading from a demo to a commercial license requires re-registration with the Registration Wizard. The 'Commercial License' type needs to be specified during the Registration Wizard, and the license and serial numbers entered. Information already entered during first time registration does not need to be re-entered. The data is sent to the VASCO Service Center and a license key returned, which is automatically assigned to the axsguard Identifier. 6.6 Replacement of axsguard Identifier In the rare event of an axsguard Identifier failure, full first-time registration is required (see above). 63

64 6.7 Registration Change of Customer Information To change customer information in the axsguard Identifier, administrators can initiate the re-registration wizard manually through the Configuration Tool, and make the necessary changes. Information already entered during first time registration does not need to be re-entered. 6.8 Restoring a backup from another axsguard Identifier Restoring a backup created by the same appliance does not require re-registration, as the License is stored in the backup. Restoring a backup created by a different appliance requires re-registration. The backup must first be restored, and then re-registration completed. For practical guidance on restoring a backup, please refer to the axsguard Identifier Installation Guide, 'Backup and Restore' section. For an explanation of the concepts of Backup and Restore, please refer to section 8 in this manual. 64

65 7 Updating 7.1 Overview Updating VASCO are constantly improving their products, to solve problems or to address new needs. These improvements are distributed to the axsguard Identifier through the updating process. Updating is included in the axsguard Identifier maintenance contracts. Updating is managed through the axsguard Identifier Configuration Tool (see section 4 on Administration Interfaces). The updating process and supporting infrastructure are described in the following sections. For further instructions on the updating procedure, please refer to the axsguard Identifier Installation Guide, delivered with the axsguard Identifier and also available through the Help button in the Configuration Tool. 7.2 Updating Process Updating is supported by an Update Wizard in the axsguard Identifier Configuration Tool and can be: off-line using an update file. Please visit for more information. on-line, through a connection to the VASCO Service Center. An available update can be downloaded during the Update Wizard. On completion of the Update Wizard for an on- or off-line update, the axsguard Identifier automatically reboots. During reboot, services are temporarily unavailable. After reboot, the system administrator needs to log back into the Confguration Tool. Feedback on the update is presented on the Status screen A fail-over system reverts the axsguard Identifier to the previous operational version if there is a power failure during updating. For instructions on how to use the Update Wizard, please refer to the axsguard Identifier Installation Guide, accessible through the Help button in the Configuration Tool. 7.3 Updating Infrastructure The VASCO Service Center server handles registration, updating and remote support for the axsguard Identifier. On-line updating described above requires an https secure connection between the axsguard Identifier and the VASCO Service Center. Connection to the VASCO Service Center is explained in section 2.9. For off-line updating, please visit for more information. Note: Updating is only possible after an axsguard Identifier has been registered. This means that if an unregistered appliance has been stored for a while and is no longer configured with the most up to date software, it must first be registered before the software can be updated. 65

66 8 8.1 Backup and Restore Backup and Restore Overview Backup and restore functionality means that administrators can keep reserve appliances and upload configuration settings, which have previously been backed up to their network, onto a new axsguard Identifier. The backup and restore functionality is managed through the axsguard Identifier Configuration Tool (see section 4 on Administration Interfaces). In the following sections, we explain the backup and restore functionality, and the feedback provided. How to use this functionality is explained in the axsguard Identifier Installation Guide delivered with the axsguard Identifier, and also available through the Help button in the Configuration Tool. 8.2 Backup Backup is a simple manual functionality provided through the Configuration Tool, for administrators to back up the axsguard Identifier database data and configuration settings. The backup includes all configurations of the Administration Web Interface and Configuration Tool and all database information, such as DIGIPASS runtime information. The backup does not include audit and logging data. Audit data can be backed up, however, using a replication setup, in which case audit data is replicated to another axsguard Identifier (see section 15). 8.3 Restore The restore function provided through the Configuration Tool allows administrators to upload configuration settings and data, which have been backed up from the same or another appliance, to the axsguard Identifier internal database. The file to be restored is first verified as a valid restore file. The axsguard Identifier needs to be rebooted before the restore is completed. When the file has been restored, feedback on the backup restore is displayed on the Status screen in the Configuration tool. If restored to the same appliance, perhaps following a configuration error or loss of data, the settings and data simply overwrite those currently in the appliance, without the need for re-registration. If restored to another appliance, the existing License on the axsguard Identifier is removed without restoring the License in the backup. Re-registration is therefore required. The backup must first be restored, and then reregistration completed (see section 6). Caution: Restoring a backup of a newer version of the axsguard Identifier is not supported. 66

67 9 Logging 9.1 Overview Logging There are two separate sources of information generated on the axsguard Identifier: Reporting and Auditing: this is the information generated about events in the IDENTIKEY component and includes amongst others, information about administration events, and authentication attempts. An example event might be: 'User successfully authenticated'. (Future versions of the axsguard Identifier will also generate events on electronic signatures and provisioning.) Auditing is explained in section 10. Reporting is explained in section 22. Logging: this is the information generated about events in the Convenience Layer (see section 2.3) and includes information about functionalities such as updating, backup and restore. An example log line might be: 'Backup was created successfully'. We explain logging in this section. Logging is based on the syslog utility which supports local and remote storage and processing of logs. Settings can be configured in the Configuration Tool manually or using the Configuration Wizard (see section 5). 9.2 Infrastructure Image 17: Data Transmission from the Syslog Utility to the Live Log Viewer and Remote Syslog Each component of the Convenience Layer on the axsguard Identifier sends information to the syslog. ('Syslog' is a standard log message system on a Linux server and can forward log messages in an IP network.) The syslog utility handles the information, which can be stored locally or remotely. Both are possible at the same time. Local logging is always active and cannot be disabled. Syslog data is made available in the live log viewer. Remote syslog can be activated and needs configuration. The syslog audit levels are configured through the axsguard Identifier Configuration Tool (see table below). 67

68 Logging 9.3 Local: Live Log Viewer A live log viewer in the axsguard Identifier Configuration Tool allows monitoring of Convenience Layer events. Live log views can be customized to present 'filtered data' using log levels and/or words (see below). Local Syslog data is cleaned based on availability of storage space. Image 18: Example Screen Shot Showing the Live Log Viewer 9.4 Remote Syslog Remote syslog must be activated in the axsguard Identifier Configuration tool and requires configuration of: the IP address of the remote syslog server to send data to, and the syslog level of information to send A syslog compliant application can then use the data for log viewing. 9.5 Log Levels The Log system can be configured to generated log information at different levels. These levels are explained in the table below. 68

69 Logging Table 8: Log Levels Type Description Critical A system-critical warning that services may not be running. Please follow the support procedure in section 2.8). Error Error condition: action required, although services may still be running. Warning Not an error, but an indication that an error may occur if action is not taken. Notice Events which are unusual but not error conditions. No immediate action required. Informational Normal operational messages, may be collected for reporting etc. no action required. Debug Information useful to debug the application. Not useful during operations. 9.6 Log Filter The log filter helps system administrators to search for relevant records. Messages can be filtered: for a string contained in any field. Entering the search string in the filter field above the log viewer (see image above) and clicking on the 'magnifying' icon initiates the search. Records which do not match the search string are filtered out. for a matching string in a certain field, e.g. by date or message type. Clicking on the arrow to the right of the filter field opens the filter dialog (see image below). How to search using any of these fields is explained in the table below. Image 19: Log Filter Fields 69

70 Logging Table 9: Log Filter Fields Type Description Date After Click on the icon to select a date from the calendar. Only records after the date specified are displayed. Date Before Click on the icon to select a date from the calendar. Only records before the date are displayed. Facility is Click on the drop down menu to select one of the facility types, e.g. kern, user, or mail. Only logs referencing this facilty are displayed. Level at least Click on the drop down menu to select one of the levels, e.g. error or warning. Only logs referencing this level are displayed. For a list of the log levels, please refer to the axsguard Identifier Administration Reference Guide. Program contains Enter a search string. Only records with a program matching the search string are displayed. Message contains Enter a search string. Only records with a message matching the search string are displayed. 70

71 Auditing 10 Auditing 10.1 Overview There are two separate sources of information generated on the axsguard Identifier from the Convenience Layer and from the IDENTIKEY component. Information sourced from the Convenience layer supports logging (explained in section 9). Information sourced from the IDENTIKEY component supports reporting and auditing: Reporting provides standard and customized reports based on the data stored in the axsguard Identifier configuration and audit databases. Reporting is explained in chapter 22. Auditing can be managed through the axsguard Identifier Configuration Tool (see section 4 on Administration Interfaces) using the live audit viewer. Auditing happens in real time, allowing administrators to view a limited number of recent events. In this chapter, we explain auditing Live Audit Viewer Events generated by the IDENTIKEY component for auditing are stored in the internal database, and can be consulted using the live audit viewer (see image below). Audit data is cleaned based on availability of storage space. Image 20: Live Audit Viewer and Filter 10.3 Audit Message Types The table below lists the different message types. A full list of audit messages, status and error codes is available in the axsguard Identifier Administration Reference Guide available from VASCO. 71

72 Auditing Table 10: Audit Message Types Type 10.4 Description Error 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 Warning messages contain details about potential problems within the system. This could include details such as a failed connection attempt to a database Information Informational messages provide details about events within the system that need to be recorded but do not indicate errors or potential errors. Success Success messages contain details about processing events that were correctly processed. This may include successful authentications or successful administration commands. Failure Failure messages contain details about processing events that failed. This may include rejected authentications, or administration actions that failed. Audit Filter The audit filter helps system administrators to search for relevant records. Messages can be filtered: for a string contained in any field. Entering the search string in the filter field above the audit viewer (see image above) and clicking on the 'magnifying' icon initiates the search. Records which do not match the search string are filtered out. for a matching string in a certain field, e.g. by date or message type. Clicking on the arrow to the right of the filter field opens the filter dialog (see image below). How to search using any of these fields is explained in the table below. Image 21: Audit Filter Fields 72

73 Auditing Table 11: Audit Filter Fields Type Description Date After Click on the icon to select a date from the calendar. Only records after the date specified are displayed. Date Before Click on the icon to select a date from the calendar. Only records before the date are displayed. Type is Click on the drop down menu to select one of the message types described in the table above. Only records referencing this message type are displayed. Source contains Searching on this field is only relevant if you have a Replication Setup (see section 15). Enter the name of the relevant IDENTIKEY Server. Only records generated from this server are displayed. Category contains Enter a category type, e.g. Administration or Authentication. Only records with a category matching the category entered in this field are displayed. Code contains Enter an error code. Only records with a matching error code are displayed. For a list of possible error codes, please refer to the axsguard Identifier Administration Reference Guide. Host contains Enter an IP address. Only records with a matching IP address are displayed. Hostname contains Enter a hostname. Only records with a matching host name are displayed. Description contains Enter a string. Only records with a matching string in the Description field are displayed. Field...contains Click on the drop down menu to select a field. All possible fields which can be searched on are listed. Select a field, and enter the matching string to be searched for. Only matching records are displayed. 73

74 Statistics 11 Statistics 11.1 Overview Statistics present information in visual charts or graphs about the system usage over time. This information is available in the axsguard Identifier Configuration Tool (see section 4) System Information Available Statistics are available on the axsguard Identifier, the services, the disk, memory and interfaces. For example: Processes and threads Image 22: Process Statistics Disk Image 23: Disk Usage Statistics 74

75 Statistics CPU time Image 24: CPU Statistics Interface Image 25: Interface Statistics 11.3 Statistics Filtering Filtering specific information from some of the statistics data is also possible. For example, the following two images demonstrate the CPU usage for the Administration Web Interface and a specific service. Image 26: Show CPU Usage for a Specific Service 75

76 Statistics Image 27: CPU Time for Administration Web Interface 76

77 12 Message Delivery Component 12.1 Overview Message Delivery Component The Message Delivery Component (MDC) is necessary to support Virtual DIGIPASS authentication. For more information on Virtual DIGIPASS authentication, see section The MDC interfaces with a gateway service to send a One Time Password to a User s mobile phone. The MDC acts as a service, accepting messages from the axsguard Identifier which are then forwarded to a text message gateway via the HTTP/HTTPS protocol. The diagram below illustrates this procedure. Since every gateway uses different submission parameters, certain settings are required, which can be configured through the axsguard Identifier Configuration Tool. The configurations required are listed in the following section. Image 28: Virtual DIGIPASS Process using axsguard Identifier MDC Component (clockwise from the top). 77

78 12.2 Message Delivery Component Configuration To configure gateway settings you need to enter into the axsguard Identifier configuration tool: the URL, port and protocol to access the gateway server the required query string the query method (GET or POST) required by the gateway the User name and password for the gateway account (optionally) your preference for more user-friendly system messages (e.g. failure notification of an SMS transmission) For explanations of the fields to be configured for MDC, please refer to the axsguard Identifier Administration Reference Guide, accessible via the Configuration Tool. 78

79 13 Remote Support 13.1 Overview Remote Support Remote support allows VASCO experts to connect to your axsguard Identifier to resolve difficulties (see also section 2.8 on VASCO's full support system). Remote support can be managed through the axsguard Identifier Configuration Tool. We explain here the remote support infrastructure offered by VASCO Support Procedure VASCO's support procedure is described in section 2.8. Remote support and access to your axsguard Identifier are achieved through the VASCO Service Center, which is described in section Remote Support On successful registration (see section 6) of the axsguard Identifier, a support certificate based on the Public Key Infrastructure is returned to the appliance. This certificate enables connection to the VASCO Service Center (see section 2.9). Connection between the axsguard Identifier and the VASCO Service Center via secure https can be achieved in one of two ways: The system administrator pro-actively connects the axsguard Identifier to the VASCO Service Center via the configuration tool. This should only be done under supervision of the VASCO Supplier help desk or other VASCO expert. How to manually activate remote support is explained in the axsguard Identifier Installation Guide, which is delivered with the axsguard Identifier and also accessible via the Configuration Tool. On booting the axsguard Identifier, an automatic temporary connection is made to the VASCO Service Center for a short time. After this time, the connection is automatically closed. This short-term connection offers a window of time during which the VASCO experts can keep the connection open. This means that even if the configuration tool is inaccessible, rebooting the appliance allows the VASCO experts to connect to the appliance for support purposes. Note: If your company policy does not allow the automatic remote support connection, the connection can be blocked using your company's firewall. Please see section 2.9 for more information on the connection. 79

80 13.4 Remote Support Tracing Tracing provides extra troubleshooting information for VASCO experts. Tracing can be activated by system administrators or VASCO experts using the axsguard Identifier Configuration Tool. If a VASCO expert cannot use the remote support function, the system administrator needs to activate the tracing option in the Configuration Tool, download the tracing information and forward it to the VASCO expert (see the axsguard Identifier Installation Guide for more information). 80

81 14 LDAP User Synchronization 14.1 Overview LDAP User Synchronization LDAP User Synchronization can be configured in the Configuration Tool and supports automatic creation and updating of User Accounts on the axsguard Identifier from records stored on an LDAP Server. (Other methods of User Account creation using the Administration Web Interface include creating User Accounts manually, importing User Accounts, and Dynamic User Registration: see section 16). LDAP User Synchronization is the process of synchronizing records from an LDAP Server, not the process of authenticating with an LDAP Back-end Server. For information on LDAP Back-end Authentication please see section Replication is the process of replicating data between separate axsguard Identifiers. For information on Replication, please see section 15. In the following sections, we explain the concepts of: Synchronization Profiles Synchronization Profile IDs Creating and updating User Accounts Deleting User Accounts Synchronization frequency Using multiple Synchronization Profiles Managing source and destination hierarchies, and Some special cases which require attention. LDAP User Synchronization is not server-specific and therefore requires configuring specifically for different LDAP Servers. Example configurations (e.g. for Microsoft Active Directory 2003 or 2008 and Novell e-directory) are described in the axsguard Identifier Installation Guide LDAP Synchronization Profiles To set up a synchronization requires: configuration of general synchronization settings creating a filter to retrieve the source User Accounts to be synchronized mapping of (source) LDAP User Account Attributes to the appropriate (destination) axsguard Identifier User Account properties. These configurations define the Synchronization Profile in the Configuration Tool. 81

82 LDAP User Synchronization LDAP Synchronization Profiles define: where the source LDAP Server is located which User Accounts from the source need to be synchronized (filtering) whether existing User Accounts on the axsguard Identifier can be updated with data from the source LDAP Server the destination for the new or updated User Accounts on the axsguard Identifier the frequency of synchronizations how to map LDAP Server User Account Attributes to axsguard Identifier Properties. (Please note that User Account settings are called source Attributes in the LDAP Server and destination Properties in the axsguard Identifier.) For a full listing and explanations of the fields for LDAP Synchronization Profiles, please refer to the axsguard Identifier Administration Reference Guide, 'Configuration Tool: Field Listings' section. Example mappings of LDAP Server User Account Attributes to axsguard Identifier User Account Properties are listed in the axsguard Identifier Installation Guide. Note: For most LDAP Servers, the LDAP User password attribute cannot be mapped to an axsguard Identifier User Account password due to security settings on the LDAP Server. Once the appropriate settings and mappings have been configured, synchronization is automatic. LDAP Synchronization of User Accounts is from the LDAP Server (source) towards the axsguard Identifier (destination) and is not bidirectional Synchronization Profile IDs The Synchronization Profile ID is used to track the source status of a User Account, i.e. whether the User Account was created through a synchronization or by another method. Each Synchronization Profile has a unique ID. User Accounts created or updated by a Synchronization Profile have the corresponding Synchronization Profile ID added. The specific axsguard Identifier User Account Properties which are updated or created by the synchronization depend on the Attribute Mapping entries in the Synchronization Profile. The 'User Attributes' screen in the axsguard Identifier (see image below) identifies User Accounts which have been synchronized from an LDAP Server. Example In the example shown in the image below, the User Account 'annelies' has been synchronized by a Synchronization Profile with the ID, 'AD2003'. 82

83 LDAP User Synchronization Image 29: Administration Web Interface > Users > User 'annelies'> User Attributes Synchronization Profiles can also be configured to Update Existing User Accounts (i.e. User Accounts which do not have the corresponding Synchronization Profile ID) Creating and Updating User Accounts Synchronization involves searching in the LDAP Server for User Accounts which match the filter definitions and are located at the Search Base defined in the Synchronization Profile. User Accounts and the Attributes listed for mapping in the profile are retrieved from the LDAP Server. For retrieved User Accounts, the synchronization process may identify one of the following possibilities on the axsguard Identifier (also shown in the image below): 1. The User Account exists on the axsguard Identifier in the destination domain and organizational unit: with the same Synchronization Profile ID. In this case the User Account is updated. without the same Synchronization Profile ID. In this case, synchronization behavior depends on the Synchronization Profile Update Existing setting: if enabled, properties are updated and the Synchronization Profile ID added. if disabled, there is no action, but an informational message is logged. 2. The User Account exists on the axsguard Identifier in the destination domain but in a different organizational unit: with the same Synchronization Profile ID. In this case the User Account is moved and the properties are updated. without the same Synchronization Profile ID. In this case, no account is created and an error is logged (User Accounts must be unique within a domain in the axsguard Identifier: see section 21). 3. The User Account does not exist on the axsguard Identifier. In this case the User Account is created and the Synchronization Profile ID added. 83

84 LDAP User Synchronization Image 30: LDAP Synchronization to create or update an axsguard Identifier User Account 84

85 LDAP User Synchronization Notes: 1. Missing LDAP Attributes and LDAP Attributes with empty values initiate different synchronization behaviors. If a mapped Attribute is missing on the LDAP Server, the axsguard Identifier Property is not updated (i.e. the existing value remains). If a mapped Attribute is present on the LDAP Server with an empty value, the axsguard Identifier Property is updated with the empty value, (i.e. any existing value is overwritten). 2. If an axsguard Identifier User Account has a Synchronization Profile ID, any manual changes made by the administrator to properties which are mapped to LDAP Attributes in the profile are overwritten during synchronization Deleting User Accounts An activated Synchronization Profile deletes a User Account on the axsguard Identifier if it has the Synchronization Profile ID, but the corresponding User Account cannot be found on the LDAP Server. This may occur under the following circumstances: the User Account has been removed from the LDAP Server the User Account on the LDAP Server has been moved from the Search Base defined in the profile the User Account on the LDAP Server has been changed and no longer matches the profile's filter Synchronization Profile settings have been changed, e.g. the Search Base or filter entries Synchronization Frequency Synchronization frequency can be configured up to 24 times per day and happens at 14 minutes past the hour, (at intervals depending on the frequency setting). The axsguard Identifier also checks at five minute intervals whether any Synchronization Profiles have been changed, and if so initiates a synchronization immediately Multiple Synchronization Profiles Multiple Synchronization Profiles can be configured. This has three purposes: 1. To manage synchronizations from multiple LDAP Servers to different domains on a single axsguard Identifier. 2. To filter User Accounts on more than one value of a particular LDAP Server Attribute, e.g. to synchronize User Accounts for which the address attribute matches both 'able.be' or 'skynet.be' endings. Entering both these specifications for a filter match in a single Synchronization Profile would only retrieve accounts which 85

86 LDAP User Synchronization had both values for the address attribute. Retrieving accounts which have one or the other value therefore requires two profiles. 3. To help manage source and destination organizational hierarchies (see next section). With multiple Synchronization Profiles, synchronizations are completed in series, i.e. not simultaneously, and are grouped according to their LDAP Server and Bind DN to optimize re-use of connections and authentications. If a server cannot be contacted, further synchronizations from the same server are skipped until the next scheduled synchronization. More than one Synchronization Profile can be applied to a particular User Account record, although this is not recommended, because it may cause User Account Properties on the axsguard Identifier to alternate between different values synchronized from the different profiles Managing Source and Destination Hierarchies LDAP Synchronization of User Accounts does not map the LDAP hierarchical structure onto the axsguard Identifier. User Accounts from the Search Base in the LDAP Server hierarchy are synchronized to a single destination address in the axsguard Identifier hierarchy as defined in the Synchronization Profile. The Synchronization Profile can be configured to either synchronize all User Accounts at and below the Search Base, or only User Accounts one level below the Search Base. User Accounts can be synchronized to different destination domains and/or organizational units in the axsguard Identifier through separate definitions of Synchronization Profiles as shown in the example below. Example Synchronization Profiles 1 and 2 in the image below are both configured to synchronize from the LDAP Server Search Base 'Domain A, Organizational Unit A1', to the axsguard Identifier destination address 'Domain A, Organizational Unit A1'. With Profile 1, the option to synchronize all User Accounts at and below the Search Base is configured. Users 1 to 9 are synchronized to the single destination address in the axsguard Identifier hierarchy. No sub organizational units are created below the Organizational Unit A1 at the destination. With Profile 2, the option to synchronize only User Accounts at one level below the Search Base is configured. Users 1 to 3 are synchronized to the single destination address in the axsguard Identifier hierarchy. Users 4 to 9 are not synchronized and no sub organizational units are created below the Organizational Unit A1 at the destination. To create the sub organizational units A1a and A1b requires the following two Synchronization Profiles to be configured as shown in the second image below: With Profile 3, the option to synchronize all User Accounts at and below the Search Base is configured. User Accounts 4 to 6 from the LDAP Server Search Base 'Domain A, Organizational Unit A1, Sub organizational Unit A1a' are synchronized to the same destination address on the axsguard Identifier. With Profile 4, the option to synchronize all User Accounts at and below the Search Base is configured. User Accounts 7 to 9 from the LDAP Server, Search Base 'Domain A, Organizational Unit A1, Sub organizational Unit A1b' are synchronized to the same destination address on the axsguard Identifier. 86

87 LDAP User Synchronization Image 31: Possible source and destination hierarchy mapping with a single Synchronization Profile Image 32: Example source and destination hierarchy mapping with three Synchronization Profiles 87

88 14.9 LDAP User Synchronization Special Cases Special attention is required when: 1. A User Account does not exist in the Destination organizational unit specified for a synchronization, but exists within the same destination domain, without the Synchronization Profile ID. As User Accounts must be unique within an axsguard Identifier domain (see section 21), no duplicate User Account is created and an error is logged. 2. A User Account does not exist in the Destination organizational unit specified for a synchronization, but exists within the same destination domain, with the Synchronization Profile ID. The User Account is updated and moved to the new destination organizational unit (see also section 14.4). 3. The Destination domain for a Synchronization Profile is changed. User Accounts created or updated through earlier synchronizations remain in the old destination domain. Synchronization now creates new User Accounts in the new destination domain. If necessary, User Accounts in the old destination domain must be manually removed using the Administration Web Interface. 4. The Destination organizational unit for a Synchronization Profile is changed to within the same domain. User Accounts created or updated through earlier synchronizations (i.e. with the same Synchronization Profile ID) are moved to the new destination organizational unit. If an administrator manually moves a User Account to a different organizational unit within the same domain, and does not remove the Synchronization Profile ID, synchronization moves the User Account back to the destination defined in the profile. If an administrator manually moves a User Account to a different organizational unit within the same domain and removes the Synchronization Profile ID, no duplicate User Account is created with synchronization and an error is logged (i.e. as in point 1 above). 5. A User Account on the axsguard Identifier should no longer be updated by a Synchronization Profile. In this case, the Synchronization Profile ID must be removed from the User Account. The ID can be deleted in the Administration Web Interface by navigating to User List, clicking on the User name, User Attributes tab, selecting the ID and clicking on the Delete button (see image below). The Update Existing option must also be disabled in the Synchronization Profile, in the Configuration Tool. Image 33: Deleting a Synchronization Profile ID for a User Account 88

89 LDAP User Synchronization Tip For troubleshooting, first consult the Logging, which records errors such as a failed server connection or erroneous Synchronization Profile settings (see section 9). Logs relevant to the synchronization process can be filtered using the name of the program which executes LDAP User Synchronization: 'ldap2ikeyd'. For further help, please refer to Auditing, which records all events logged by the IDENTIKEY Server (see section 10). These records are helpful to understand the reasons for failure of a certain action, for example when deleting a User Account fails. 89

90 15 Replication 15.1 Overview Replication Multiple axsguard Identifiers can be configured to synchronize by replicating data changes between them. This process is called replication, and can be set up using the Replication Wizard (explained below). Following synchronization, all services are identical on both axsguard Identifiers with modified data replicated in both directions. Replication ensures that each database is up to date with the latest data changes. In this chapter we provide examples of replication configurations, introduce the Replication Wizard, and describe the replication process and how it is monitored Common Replications First and Second axsguard Identifiers The most common, and most basic, replication setup is used when a company has two axsguard Identifiers, allowing a redundant setup in case of hardware failure. Following initial synchronization, all services are identical on both axsguard Identifiers with modified data replicated in both directions. Image 34: Replication between a First and Second axsguard Identifier 90

91 Replication First, Second and Disaster Recovery axsguard Identifiers This scenario is often used when a company requires an off-site disaster recovery axsguard Identifier and database. Image 35: Replication between a First, Second, and Disaster Recovery axsguard Identifier 15.3 Replication Wizard Replication is configured using a wizard in the axsguard Identifier Configuration Tool. IP addresses of the source and target axsguard Identifiers need to be specified in both: all further configuration is automated with the target becoming a replication of the source axsguard Identifier. Following synchronization, all services are identical on both axsguard Identifiers with modified data replicated in both directions. Auditing data is also replicated. The Host name specified in the Configuration Tool during the first time Configuration Wizard or manually (see section 5), is used to identify the correct axsguard Identifier in the replication setup. This Host name is used: for selecting the correct axsguard Identifier to log on to using the Administration Web Interface as an identifier in the logging to determine the source of the log line (see section 9) How to complete the Replication Wizard is explained in the axsguard Identifier Installation Guide. 91

92 Replication Caution: 1) Creating a loop in the replication setup is not supported. An axsguard Identifier already included in a replication setup cannot be configured as a replication target for another axsguard Identifier. 2) A third axsguard Identifier cannot be configured as a source when added to a replication setup where two axsguard Identifiers are already replicating. The wizard autodetects that an axsguard Identifier is already replicating and defines this axsguard Identifier as the source. The new axsguard Identifier being added to the replication setup must be defined as a target Replication and Firewalls Replication and replication setup between two or more axsguard Identifiers is performed using three separate TCP connections: replicating audit data replicating configuration and runtime data one-time replication setup using the Configuration Wizard These connections need to be permitted if replicating axsguard Identifiers are separated by a company firewall. For more information on the exact ports used, please see the axsguard Identifier Administration Reference Guide Replication Process Queuing and Sending Writing a data update to the replication queue (creating a replication entry) and sending a replication entry to another axsguard Identifier are two separate processes: Writing to the replication queue: the process which writes to the replication queue is run before any data changes are committed to the database. If the data change cannot be written to the replication queue usually because the replication queue file has exceeded the maximum size allowed the data change is not committed to the database. Sending a replication queue entry: this process sends replication entries from a replication queue to the required axsguard Identifier. If the target axsguard Identifier cannot write the change to its database, it returns a failure message. The axsguard Identifier is configured to retry automatically. 92

93 Replication Replication Forwarding Replication forwarding is required and activated automatically where more than two axsguard Identifiers are replicating. The ID of the source axsguard Identifier and the target axsguard Identifier(s) to which it is sending the information are added to the replication entry. This allows the receiving axsguard Identifier to check which other axsguard Identifiers have already been sent the replication entry. It only forwards the entry to axsguard Identifiers which are not listed Multiple Changes to a Single Data Record The replication method used by the axsguard Identifier involves replication of entire records, for example all settings of a specific DIGIPASS User Account, rather than an individual User Account setting, such as a password. This means that data clashes can occur when a single record is updated at the same time from different sources. If this occurs, the later change is written to the database and earlier changes are ignored Connection Handling When the Identikey Server service is started, the axsguard Identifier establishes a connection to each destination axsguard Identifier configured for replication. It keeps this connection open until the service is stopped or the connection is broken. If the connection is broken, it attempts to reconnect after a standard minimum reconnect interval has elapsed. If this fails, it continues to attempt reconnection at increasing time intervals until it reaches a maximum reconnect interval. It then continues to attempt reconnection at the maximum reconnect interval, until it succeeds. The axsguard Identifier ceases replication efforts to the target axsguard Identifier until the connection is reestablished. This means that entries in the queue are not lost because of a broken connection. Replications to other axsguard Identifiers are not affected, i.e. each replication link is independent Replication Monitoring Replication Auditing Audit messages (viewable in the live audit viewer of the Configuration Tool, see section 10) are recorded when: connections succeed or fail a replication send is successful a replication send fails a replication is received and the receiving server returns a data update success message a replication is received and the receiving server returns a data update failure message 93

94 Replication Replication Status The replication status (viewable under the 'System' tab in the Administration Web Interface: see first image below) shows the current status of replication for an axsguard Identifier and the number of entries currently in the replication queue (see second image below). Image 36: 'System' Tab in the Administration Web Interface Image 37: Replication Status Screen in the Administration Web Interface 94

95 Web Administration Interface Section DIGIPASS User Accounts DIGIPASS Client Components Server Components Policies Organization Reporting

96 16 DIGIPASS User Accounts 16.1 Overview DIGIPASS User Accounts All Users requiring authentication with the axsguard Identifier must have their records registered in the axsguard Identifier for: DIGIPASS devices to be assigned to Users User-specific parameters to be stored Privileges to be assigned, and Policy settings to be overruled at a user level. User Accounts can be created, managed and searched for using the Administration Web Interface (see section 4 on Administration Interfaces) and we explain these operations below. We strongly recommend that you read section 3 first, to better understand the User Account concept Creating User Accounts A DIGIPASS User Account can be created using the Administration Web Interface in the following ways: by creating User records manually using the Administration Web Interface. by importing User records (singly or in bulk) from a file using the Administration Web Interface. dynamically during authentication processing if Dynamic User Registration is enabled. We explain these methods in the following sections. Note: User Account records can also be synchronized with LDAP Servers (see section 14.1) Creating Users Manually Users can be created manually by the system administrator. The following records need to be defined to create a user: User ID, domain and optionally an organizational unit (see section 21) Static password (optional) Local and back-end authentication settings Whether the account is enabled and/or locked 96

97 DIGIPASS User Accounts Further management possibilities with User Accounts are listed below. For explanations of the User property fields, please refer to the axsguard Identifier Administration Reference Guide Importing User Records Multiple User Accounts can be imported into the axsguard Identifier in a comma separated values (.csv) text file through the User/Import screen of the Administration Web Interface. Details for structuring the comma separated values within a text file are listed in the axsguard Identifier Administration Reference Guide, 'Importing users using Comma Separated Value Files' section Dynamic User Registration When the axsguard Identifier receives an authentication request for a user without a DIGIPASS User Account, it can check the credentials with the back-end authenticator (e.g. RADIUS). If the authentication is successful with the back-end authenticator, the axsguard Identifier 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. For more information on Dynamic User Registration, see section DUR is commonly used with Auto-Assignment, so that the new account is immediately assigned a DIGIPASS. For more information on Auto-Assignment, please see section LDAP User Synchronization LDAP User Synchronization supports automatic creation and updating of User Accounts on the axsguard Identifier from records stored on one or more LDAP Servers. Synchronization needs to be configured in the Configuration Tool, by defining a Synchronization Profile for your specific LDAP Server(s). For more information, please see section Linked User Accounts Normally, a DIGIPASS record can only be assigned to one User Account (see section ). However, if someone has two DIGIPASS User Accounts, for example an administrative account and a 'normal user' account, the accounts can be linked to share a DIGIPASS device. The DIGIPASS record for the device is assigned to one account, to which the other account is then linked (see image below). 97

98 DIGIPASS User Accounts DIGIPASS record Attached to main User account DIGIPASS User account 1 User Account Link DIGIPASS User account 2 User can log into either account using the same DIGIPASS Image 38: User Account Link 16.4 User Account Settings User Account settings which can be managed through the Administration Web Interface include: the User ID, the domain and possibly organizational unit they belong to are defined on creation; users can also be moved from one organizational unit to another, but cannot be moved between domains (see section 21.4) the account status can be enabled, disabled, locked or deleted a static password can be enabled and set (see section 16.5) whether policy settings for local or back-end authentication may be overruled for a user can be specified whether the user has a linked User Account can be specified (see section 16.3) DIGIPASS records can be assigned or unassigned to a user parameters, such as a user's mobile phone number for using a Virtual DIGIPASS, can be stored user attributes, which may need returning to applications when requested, can be stored (see section 3.6) privileges can be assigned to a user, e.g. for administration (see section 16.7) 16.5 DIGIPASS User Account Static Password The DIGIPASS User Account has one static password field, which can be used in different ways: local static password verification for users who do not have a DIGIPASS device (see section 3.5.4) 98

99 DIGIPASS User Accounts during Challenge/Response authentication as Request Method (see section ) during Virtual DIGIPASS use as Request Method (see section ) password replacement and autolearn (see section 3.6.3) back-end authentication e.g. for retrieval of RADIUS attributes (see section 3.6.3) static password authentication during the Grace Period (see section ) There are two different mechanisms to set and update static passwords: by the Administrator in the Administration Web Interface, and by the User using the password autolearn functionality (see section ) 16.6 Searching for User Accounts The Administration Web Interface allows you to search for User Account records in a number of ways: You can search directly by entering the User ID You can search for the User who a DIGIPASS device 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 wild card (*). A list of results is presented, from which you can select the User you require Administration Privileges Only DIGIPASS User Accounts with administrative permissions can use the Administration Web Interface to configure the axsguard Identifier. Administrative privileges are assigned to DIGIPASS User Accounts and therefore a DIGIPASS User Account is needed for each administrator. The default administrative accounts are listed in section 4.2. Administrative permissions may be assigned based on: Type of permission (e.g. Read, Create) Type of object (e.g. DIGIPASS record, Policy) The Domain and Organizational Unit in which the administrator account is located determines the range of administration access: If the account belongs to an Organizational Unit, the administrator can administrate User Accounts and DIGIPASS records belonging to that Organizational Unit. If the account does not belong to an Organizational Unit, the administrator can administrate all DIGIPASS records and User Accounts in the Domain to which they belong. If the account belongs to the Master Domain, the administrator may be able to administrate all DIGIPASS records 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. More information on the Master Domain and Organizational Units is available in section

100 17 DIGIPASS 17.1 Overview DIGIPASS All DIGIPASS instances need to be registered in the axsguard Identifier with relevant data for the axsguard Identifier to support authentication requests which use One Time Passwords generated from the DIGIPASS. Some DIGIPASS settings are pre-programmed into the DIGIPASS devices during manufacture, some are assigned to DIGIPASS through policies and others can be assigned specifically to a DIGIPASS using the DIGIPASS records. Both policies and DIGIPASS records are configurable in the Administration Web Interface. The Administration Web interface supports DIGIPASS management including: Importation of DIGIPASS records Assignment of DIGIPASS records to User Accounts Searching for DIGIPASS records Various DIGIPASS actions, and viewing of runtime information In this section, we introduce some key DIGIPASS properties, explain the DIGIPASS management possibilities, the DIGIPASS assignment options and finally, Backup Virtual DIGIPASS options. We strongly recommend that you read section 3 first, to better understand DIGIPASS management DIGIPASS Properties DIGIPASS Client PIN A DIGIPASS (client) PIN is a digit-based secret, known by the User, which needs to be entered into the DIGIPASS device for a One Time Password (OTP) to be generated. This implies 2-factor authentication: the person logging in must be in possession of the DIGIPASS device (something you have) and know the DIGIPASS PIN (something you know) to generate an OTP. This option requires a DIGIPASS device with a keypad for the PIN to be entered, and is therefore not possible with one-button DIGIPASS models. An alternative solution for 2-factor authentication with a one-button DIGIPASS model is explained in the next section. PIN change can be offered to users through pre-programmed PIN modification settings (see specific DIGIPASS model User Guides): An Initial PIN can be set for a DIGIPASS device. The PIN must then be sent to the User of the DIGIPASS, typically separate from the DIGIPASS delivery. First Use PIN Modification requires PIN change from the User on first use of the DIGIPASS device. 100

101 DIGIPASS PIN Change allows a User to change their PIN as desired. The PIN Length can be set for a DIGIPASS device. DIGIPASS Lock sets the number of consecutive faulty PIN entries allowed before the DIGIPASS device is locked Server PIN The DIGIPASS Client PIN described in the previous section is not possible with one-button DIGIPASS models (i.e. the DIGIPASS GO Range models). The Server PIN is an alternative solution for 2-factor authentication only available with one-button DIGIPASS models. A Server PIN can be used together with the OTP generated by the DIGIPASS device, as part of the on line authentication process. The Server PIN is a digit-based secret, typed in by the User into the login password field in front of the OTP and is checked by the authenticating server. The server only permits verification of the OTP if submitted with a valid Server PIN. The additional Server PIN thus provides an extra layer of security, a 2-factor security solution. To authenticate, the holder needs to have a connection to the authenticating server, to know the Server PIN (something you know), and to be in possession of the DIGIPASS device (something you have) to generate an OTP. The following permutations of OTP and Server PIN are possible: OTP: the normal login where a Server PIN is not required PINOTP: the normal login where a Server PIN is required and is entered in front of the OTP PINOTPnewpinnewpin: for changing the Server PIN: the new PIN is entered twice after the OTP OTPnewpinnewpin: for setting the Server PIN on first use, when no initial PIN was programmed: the new PIN is entered twice after the OTP. This is also necessary after an administrative PIN reset. Server PIN runtime information is provided through the Administration Web Interface by selecting a specific DIGIPASS record (see table below). 101

102 DIGIPASS Table 12: Server Settings Regulating Server PINs Setting Explanation PIN Supported Factory default built-in technology to support use of a Server PIN (only active if PIN enabled). PIN Enabled Factory default setting forcing a Server PIN to be used for login (only possible if PIN Supported). PIN Change Forced Whether PIN Change will be forced on next logon (see Forced PIN Change action in section ). PIN Change On Whether a User is allowed to change their Server PIN for this DIGIPASS device. PIN Length The length of the current Server PIN. PIN Minimum Length The minimum PIN length required by the Server Grace Period Each DIGIPASS device may be given a Grace Period when it is assigned to a DIGIPASS User Account. The Grace Period allows some time for Users to continue using their static password before they receive the DIGIPASS device and learn how to use it. The first time that the User logs in successfully with their DIGIPASS, the Grace Period ends. After the Grace Period has ended, they must use the DIGIPASS. The Grace Period is time limited, so that the User is not able to delay too long before starting to use the DIGIPASS. The Grace Period can be set during manual administrative assignment of DIGIPASS records as well as during AutoAssignment. However, it is not applicable to Self-Assignment, because the User must use the DIGIPASS device to complete the Self-Assignment process. For more information on assignment options, see section 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. For more information on the static password check during an authentication attempt, see section DIGIPASS Authentication Method DIGIPASS authentication and login processes include: Response only (described in section ) Challenge/Response (described in section ), and Virtual DIGIPASS Login (described in section ). For further information on Virtual DIGIPASS use, please see section Response Only authentication can be: Time-based, in which case the OTP is based on the current time and changes after a time step, usually every 36 seconds, whether or not an OTP has been requested from the DIGIPASS device. Event-based, in which case a new OTP is displayed each time a request for an OTP is made. 102

103 DIGIPASS Challenge/Response authentication can be: Time-based, in which case the OTP is based on a Challenge and the current time. The common time step used is 9 hours ('slow challenge'). This means that if exactly the same Challenge is given to a DIGIPASS device within a 9 hour period, the DIGIPASS application generates the same OTP. However, Challenges are very rarely repeated within such a time period. Non-time-based: a non-time-based Challenge/Response application generates an OTP based only on the Challenge. Note: Challenge/Response login requires modifications to client application login pages for both 1- and 2-step logins (see section ). For example, with 1-step login for Outlook Web Access, a random Challenge needs to be displayed on the login page; with 2-step login, after the first login page, the IIS Module redirects the User to a 'Challenge' page. More information on modifying the login pages is available in the appropriate IIS client module documentation. Template login pages are included in the approppriate IIS module software packages DIGIPASS Management Importing DIGIPASS DIGIPASS records may be imported into the axsguard Identifier via the axsguard Identifier Administration Web interface. Records can either be imported one at a time or many can be imported at one time. The DIGIPASS records to be imported must be downloaded to a file in the.dpx format. The DIGIPASS Import Wizard guides you through the steps for importing DIGIPASS records from the.dpx file. You can specify the applications available with the imported DIGIPASS, and whether the imported DIGIPASS are set as Active or Inactive on import. You can also specify whether existing DIGIPASS records are updated with the data from the.dpx import file Assigning DIGIPASS DIGIPASS records can be assigned to User Accounts, unassigned, moved or deleted via the Administration Web Interface. There are three assignment processes possible for DIGIPASS: Self-Assignment Auto-Assignment Manual assignment 103

104 DIGIPASS These processes are described in section DIGIPASS self- and auto-assignment methods can also be combined with Dynamic User Registration (see section 3.4.4) Searching for DIGIPASS Records The Administration Web interface allows you to search for DIGIPASS records in a number of ways: You can search directly for the DIGIPASS record by entering the DIGIPASS Serial Number You can search for DIGIPASS records assigned to a User by searching for the User and then double clicking on the DIGIPASS record on the User Details Screen You can enter the first few numbers of the DIGIPASS Serial Number followed by a wild card (*). This provides a list from which you can select the DIGIPASS record you require DIGIPASS Actions A number of actions are possible for managing DIGIPASS records including assigning and unassigning DIGIPASS to Users. These are typically required for maintenance, e.g. for a User who has forgotten their Server PIN or when a DIGIPASS device has been locked and needs unlocking. These are listed in the table below, with explanations. Some of these actions can be applied to a single application for a specific DIGIPASS device, for example, or applied globally to a certain application for multiple DIGIPASS devices. Table 13: DIGIPASS Record Actions supported in the Administration Web Interface Name Explanation 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. The 'reset' widens the allowable time window for the next login, allowing the User to log in and the axsguard Identifier to calculate the current time shift. Activate Application Activates a previously deactivated application for selected DIGIPASS records. Deactivate Application Deactivates a previously activated application for selected DIGIPASS records. Delete Application Deletes an application for selected DIGIPASS records. Set Event Counter If the event count for an event-based application has become unsynchronized between the DIGIPASS device and the server, this function can be used to set the server event count to the event count on the DIGIPASS device. Reset PIN If a User s Server PIN needs to be changed (usually because the User has forgotten it), 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 record. 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. Set PIN A User s Server PIN can be set to a specific value and communicated to the User. 104

105 DIGIPASS Name Explanation Unlock DIGIPASS If a User incorrectly enters their DIGIPASS Client PIN into their DIGIPASS device a predetermined number of times, the DIGIPASS locks. Once locked, an administrator's help is required to unlock it. This function allows an administrator to provide the User with an Unlock Code to enter into their DIGIPASS device. 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. 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. Reset Activation Use this function to reset the Event Counter, Activation time and Activation location on a DIGIPASS. This functionality will support Provisioning, which is currently under development and will be available in a future release of axsguard Identifier. Assign/Unassign Use these functions to assign or unassign a selected DIGIPASS record to or from a User Account. Move Use this function to move a selected DIGIPASS records to another domain or organizational unit (see section 21.4). Edit Use this function to edit (for example Backup Virtual DIGIPASS or Grace Period settings) for a single DIGIPASS record. Delete Use this function to delete a selected DIGIPASS record(s). Viewing DIGIPASS Runtime Information Four types of (read only) runtime information are viewable in the Administration Web Interface: PIN information Virtual DIGIPASS information Pre-programming, and Usage information Some examples are explained below. PIN Supported (PIN information): indicates whether a DIGIPASS PIN is supported, Yes/No. Virtual Token Supported (Virtual DIGIPASS information): indicates whether a Virtual DIGIPASS is supported, Yes/No. Time Step Used (pre-programmed) this is the time step used by the DIGIPASS Application. Last Time Shift (usage information): the Time Shift records any misalignments between the time recorded on the DIGIPASS device 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 axsguard Identifier and the User can still log in. If the time drift exceeds the allowable time window between User logins, the DIGIPASS record needs to be reset (this allows for recalculation of the time drift). 105

106 DIGIPASS 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 device is recorded. The next time the User logs in, the expected OTP is calculated based on the time shift. Last Event Value (usage information): the current number of uses of the DIGIPASS Application, according to the DIGIPASS device. This can get out of sync with the number of uses recorded by the axsguard Identifier when: login failures occur for other reasons than incorrect OTP the DIGIPASS device has been used without a login (e.g. children have been playing with it) the DIGIPASS device 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 axsguard Identifier to track any shifts between the event count recorded by itself and the DIGIPASS device DIGIPASS Assignment Options DIGIPASS Records 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 devices may find it easier to simply distribute them and request Users to go through Self-Assignment or Auto assignment. For more information on DIGIPASS assignment throughout your organizational structure (with domains and organizational units) and the restrictions, please see section 21. Note DIGIPASS records must be imported into the data store before being assigned to Users. 106

107 DIGIPASS Self-Assignment Self-Assignment Process Users may assign a DIGIPASS record for a device which has been supplied to them to their DIGIPASS User Account. The User must log in and include the serial number, static password and One Time Password. This informs the axsguard Identifier of the assignment, and provided that the User enters the details correctly, a link is made between the DIGIPASS record and the User Account (see image below). A Grace Period is not used for this method (see section ). Image 39: Self-Assignment Process 107

108 DIGIPASS Self-Assignment Data Certain settings and data entry are required for Self-Assignment: The Assignment Mode Policy setting must be Self-Assignment. 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 Data Entry For a DIGIPASS device 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 Data Entry For a DIGIPASS device 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 Separator value specified the Serial Number can be entered as written on the back of the DIGIPASS device, for example

109 DIGIPASS Auto-Assignment The axsguard Identifier can automatically assign an available DIGIPASS record when a DIGIPASS User Account is created using Dynamic User Registration (DUR). The correct DIGIPASS device 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 40: Auto-Assignment Process 109

110 DIGIPASS Manual Assignment A selected DIGIPASS record is manually assigned to a specific DIGIPASS User Account. The DIGIPASS device must then be sent out to the User. A Grace Period is typically set, during which the User may still log in using only their static password. Image 41: Manual Assignment Process 110

111 DIGIPASS DIGIPASS Assignment Limitations DIGIPASS assignment limitations include: A DIGIPASS record can only be assigned to one User Account (except when using linked User Accounts, see section 16.3). Multiple DIGIPASS records can be assigned to a single User Account. A specific DIGIPASS record can also be reserved for manual assignment, i.e. the reserved DIGIPASS record cannot be self- or auto-assigned (see image below). Image 42: Reserving a DIGIPASS Record for a Specific User in the Administration Web Interface Note: For readers who are also familiar with the VASCO product axsguard Gatekeeper ( please note that the DIGIPASS-User Account relationship varies between the two products. With the Gatekeeper product, a DIGIPASS record can be assigned to multiple User Accounts, although only one DIGIPASS record is possible per User Account. 111

112 DIGIPASS 17.5 Virtual DIGIPASS Overview With Virtual DIGIPASS login, the user requests an OTP to be issued to their mobile phone, thus removing the need for a hardware or software DIGIPASS (see also section 2.5; for information on authentication with a Virtual DIGIPASS, please see section ). Virtual DIGIPASS are assigned as either: a Primary Virtual DIGIPASS, which is always used by a User; the User does not have a hardware or software DIGIPASS. a Backup Virtual DIGIPASS, which is only used as a backup device when the User's hardware or software device is unavailable Virtual DIGIPASS Assignment Options With the introduction of Virtual DIGIPASS (see section ), 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. Table 14: DIGIPASS Options Primary Backup DIGIPASS None User must log in using a DIGIPASS device. DIGIPASS Backup Virtual DIGIPASS User usually logs in using a DIGIPASS device, but may utilize the Backup Virtual DIGIPASS feature where required. Use of the feature may be limited. DIGIPASS (temporarily disallowed) Backup Virtual DIGIPASS User must log in using the Backup Virtual DIGIPASS feature. This might be used while a User s DIGIPASS device is lost, until it is recovered. Primary Virtual DIGIPASS N/A User is assigned a Virtual DIGIPASS and must log in using it. Virtual DIGIPASS Configuration To use a Virtual DIGIPASS, your company will need the use of a text message gateway (Message Delivery Component: MDC) and an account with the gateway. The MDC will need configuration information for the gateway and the Username and password for the account. Your VASCO supplier can assist with this process. Further information regarding configuration of the MDC is available in section

113 DIGIPASS Implementation Decision Several factors need careful consideration before implementing a Virtual DIGIPASS system: Cost: your company will probably need to pay an amount for each text message sent. In some countries, mobile phone owners may need to pay an amount for each text message received on their mobile phones. These costs need to be taken into consideration when deciding how to implement Virtual DIGIPASS functionality. Security: hardware DIGIPASS devices provide the highest level of security. Virtual DIGIPASS provide a lower, although still high level of security. This needs to be weighed against other considerations before deciding whether and how to implement Virtual DIGIPASS. Convenience: a Virtual DIGIPASS is more convenient than a hardware DIGIPASS for many Users. Only the User's 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 1 or GO 3 more convenient. Additionally, having Backup Virtual DIGIPASS enabled might result in User's getting important work done at home rather than needing to go to work to collect a forgotten DIGIPASS device. 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 device 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 is 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 also section ). For more information on Virtual DIGIPASS use during an authentication attempt, see section Limiting Use of Virtual DIGIPASS Use of Primary and Backup Virtual DIGIPASS may be limited by: Using Backup Virtual DIGIPASS only. Minimizing the number of Users assigned a Primary Virtual DIGIPASS. A User s 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 device at home, or for other reasons do not have access to it. Use of this feature can be limited for each DIGIPASS device by: Time limit (days): 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 are rejected. If the User is still unable to use their DIGIPASS device, the time period must be extended by an administrator. Once the User has started using their 113

114 DIGIPASS DIGIPASS device again, the administrator must reset the time period to allow re-use of the Backup Virtual DIGIPASS. Max. Uses/User: set a maximum number of times a User may request an OTP using the Backup Virtual DIGIPASS. When the User has reached this number of uses, any further OTP requests are rejected. If the User still needs to use the Backup Virtual DIGIPASS, an administrator must reset the number of permitted uses. These settings may be set both at the Policy level and at the DIGIPASS record level. Configuring the setting at policy level implements organizational-wide regulations for all Virtual DIGIPASS use. Configuring the setting at DIGIPASS level implements an exception. Global settings affect all DIGIPASS records with an individual option set to 'Default'. Global options are defined in the Policy which controls authentication. Using multiple Policies, therefore, provides some additional flexibility. Some Policy settings (see below) may be used to automatically set DIGIPASS settings which are blank when the Backup Virtual DIGIPASS is first used by the User. If Backup Virtual DIGIPASS is enabled for a DIGIPASS record and set to Time Limited, and the Enabled Until field in the DIGIPASS property sheet is blank, the time limit begins when the Backup Virtual DIGPASS is first used. The expiry date (today s date + Time Limit) is then 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 the User property sheet is blank, on first use of the Backup Virtual DIGIPASS, a number (Max Uses/User) is automatically entered into the Uses Remaining field and immediately decremented by 1. Note If a User has Backup Virtual DIGIPASS enabled with the Enabled Until date set and the Uses Remaining set (automatically or manually), whichever expires first disables the Backup Virtual DIGIPASS. Example: 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. On first use of the Backup Virtual DIGIPASS, Enabled Until is set to a date 3 days hence and Uses Remaining set to 4. During the next 48 hours, the User logs in 4 more times. Although the User s time limit does not run out for another 24 hours, Uses Remaining is now 0 and the Backup Virtual DIGIPASS is disabled. 114

115 DIGIPASS Backup Virtual DIGIPASS Guidelines for Use Some questions to guide implementation of Backup Virtual DIGIPASS are: Will any users have access to Backup Virtual DIGIPASS? If so, will all users have access to Backup Virtual DIGIPASS? Will use of Backup Virtual DIGIPASS be limited? If so, how? Time-limited Limited number of uses The table below offers some possible guidelines. Table 15: Backup Virtual DIGIPASS Example Guidelines Guideline Pro Backup Virtual DIGIPASS disabled for all enabled for individual Users as required. Low text message costs Backup Virtual DIGIPASS enabled for all - either time/number of uses limit set. Backup Virtual DIGIPASS enabled for all - no limits set. Predictable text message costs Lighter administration load Con Manually enabled for each User and circumstance. Possible heavy administration load. Administrator may need to reset limits frequently medium administration load. Possible high text message costs. 115

116 18 Client Components 18.1 Overview Client Components Each application in the network which needs to access axsguard Identifier services, must be registered on the axsguard Identifier as a client component for access to be allowed. Client component registration also specifies the applicable policy for handling a request. More information regarding client component and policy verification during an authentication attempt is available in section 3. The Administration Web Interface allows you to create, manage, and delete Client Records, and allows the assignment of: Permissions for authentication requests from a client to be handled Policies to be assigned to authentication requests Secrets to be shared between RADIUS Clients and the axsguard Identifier In this section, we describe the client components necessary for the administration program, the RADIUS client and the IIS module. We strongly recommend that you read section 3 first, to better understand client component use Standard Component Properties Four properties common to all client components are: Application type (explained below) Location: the source of the request Protocol: communication protocol to use (see section 2.6.2) Policy: the applicable policy for handling a request (see section 20) There are six client application types which interact with the axsguard Identifier: RADIUS Authentication IIS Authentication Administration Program: an administration program client component record is added by default for the Administration Web Interface. This component record includes a policy to allow connections from this program. SOAP Authentication (currently in development, to be included in a future release) DIGIPASS Software Provisioning (currently in development, to be included in a future release) Electronic Signature Validation (currently in development, to be included in a future release) 116

117 Client Components Caution Modifying the IP address of the axsguard Identifier in the Configuration Tool, results in the creation of a new administration program client component record. The older records can be erased: however, do not erase the client component configured for the current IP address, because this prevents access to the Administration Web interface Component Lookup and Verification The component making a request is identified using: Component Type 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 vary according to the type of component, as outlined below RADIUS Client The RADIUS protocol can support three services (RADIUS AAA): RADIUS Authentication is supported by the axsguard Identifier (described in section 3.6.5). RADIUS Accounting is is supported by the axsguard Identifier. With a RADIUS back-end server, Accounting requests are forwarded to the back-end server and handled by proxy. Without back-end authentication, audit messages are generated. RADIUS Authorization handles requests for an authentication client to use a particular service and is only possible with a RADIUS back-end server. RADIUS Authorization cannot be supported by the axsguard Identifier without a RADIUS back-end server. A RADIUS Client Component record is required for clients sending authentication requests to the axsguard Identifier using the RADIUS protocol. 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. 117

118 Client Components Any RADIUS Client which does not have an explicit Component record is handled using the default RADIUS Client Component, if it exists. A default RADIUS Client Component record is automatically created during installation of axsguard Identifier. This can be deleted and specific records created for each location. Note 1) The default RADIUS Client created during installation is given a Shared Secret of default. 2) RADIUS support is present for authentication by client applications (Access-Requests) using PAP, CHAP, MS-CHAP and MS-CHAP2. MPPE keys are generated for MS-CHAP and MS-CHAP IIS Module A Component record is required for any IIS Modules used with axsguard Identifier. The Component record is checked whenever the IIS Module sends an authentication request to the axsguard Identifier. 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 The Component record needs to contain a valid License Key for a Client module. The following client types fall under this category: Citrix Web Interface Outlook Web Interface IIS 6 Module Client Component Licensing Some client components require licenses to be operational, e.g. IIS Modules. Client Component Licenses can be uploaded and viewed through the Administration Web Interface client component records. For more information on axsguard Identifier Client Component Licensing, see section

119 19 Server Components 19.1 Overview Server Components Each axsguard Identifier in your setup needs to be licensed to be operational. To verify whether a valid license is present, a server component needs to be registered for the axsguard Identifier to which its license can be assigned. Server components are registered in, managed and viewed through the Administration Web Interface System tab (see section 4). You can add or remove axsguard Identifier server components and view detailed license information Automatic Server Component Creation Registration Process During the registration process in the axsguard Identifier Configuration Tool (see section 6), a server component record including a valid license is automatically created. Whenever the IP address is changed in the Configuration Tool, a new registration is mandatory, and a new server component is automatically created including a valid license for the new IP address. Caution: Do not modify the policy assigned to the server record as this may cause problems during installation of IIS modules in your setup (see section for more information on IIS Modules). This setting should only be modified by VASCO experts. Tip: The old server component is not erased automatically allowing re-use of the old IP address without the need to re-register, since the license is still stored in the record Replication A component record is created for each axsguard Identifier in a replication setup. This is automatically configured through the Replication Wizard. More information on replication is available in section

120 19.3 Server Components Licenses A server component holds the License Key for a specific axsguard Identifier. This component record is checked for a valid license when the axsguard Identifier is started. If the License Key is missing, invalid or expired, the Configuration Tool and Administration Web Interfaces are accessible for configuration and management, but no services, such as authentication, are available. The following items need to be supported in the License Key for the authentication service to be available: RADIUS Authentication scenario Licenses can only be viewed in the server component record through the System tab in the Administration Web Interface. See section 6.2 on how to modify a license. For more information on license types, please see section 2.7. For information on Client Licenses, please refer to section

121 20 Policies 20.1 Overview Policies Policies specify various settings that affect all request handling processes. Each request is handled according to a Policy identified by the applicable client and server records (see also sections 18 and 19 on client and server components respectively). Policy records can be edited, copied or deleted using the Administration Web Interface (see section 4 on Administration Interfaces). In this section, we explain policy properties. In addition we explain the concept of policy inheritance and provide example settings for the axsguard Identifier RADIUS Self-Assignment Policy. We strongly recommend that you read section 3 first, to better understand how policies influence the authentication process Policy Properties There are many policy settings which can be defined through the Administration Web Interface: General Policy settings, such as: whether local authentication requires an OTP generated from a DIGIPASS device, or whether a password (or both) is required (see section 3.5) whether back-end authentication is to be used (never, always or if needed), and if so the back-end protocol, e.g. RADIUS, Novel e-directory or Microsoft Active Directory (see section 3.6) User Policy settings, such as whether Dynamic User Registration is permitted, Password Autolearn and Stored Password Proxy (see sections and ) DIGIPASS Policy settings, such as whether Auto- or Self-Assignment is possible and the Grace Period (see section 17.4) Application settings for 1- and 2-step Challenge/Response authentication and for Virtual and Backup Virtual DIGIPASS (see section ) Some Policy properties can be overruled in User or DIGIPASS records (see sections 16 and 17). Please refer to the axsguard Identifier Administrator's Reference Guide for a full listing of the fields available for configuring policies. 121

122 Policies 20.3 Policy Inheritance Many Policies are already provided in the axsguard Identifier. Amongst these, the 'Base Policy' can be used as a starting template, from which to adapt certain settings for new policies. This concept is called Policy inheritance. Policies may be set up in a hierarchy, where one Policy inherits most of its attributes from a parent Policy, but with some modifications for a slightly different scenario. In the example below, all settings are inherited from the parent Policy, except those explicitly set. Image 43: Policy Inheritance 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 Administration Web Interface presents separate columns showing settings explicitly set in a policy, and effective settings (i.e. both settings specific to the policy and those inherited from parent policies). The text below shows the effective settings for the IDENTIKEY Server RADIUS Self-Assignment Policy. The settings include those set in Policies from which the IDENTIKEY Server RADIUS Self-Assignment Policy inherits: 122

123 Policies 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 Event Window : 20 Initial Time Window : 6 Identification Threshold : 0 Check Challenge Flag : 1 Allowed Inactive Days : 0 123

124 Organization 21 Organization 21.1 Overview User Accounts and DIGIPASS records can be grouped in the axsguard Identifier using two structures: domains and Organizational Units, which are managed using the axsguard Identifier Administration Web interface. In this section, we first introduce axsguard Identifier domains and Organizational Units, and their similarities and differences. We then explain the Master Domain concept and uses, moving DIGIPASS User Accounts and location of DIGIPASS records. Finally we illustrate some typical DIGIPASS location models Domains and Organizational Units Image 44: Domains and Organizational Units Domains and Organizational Units are included in the internal database in a way that mirrors the hierarchical organization of your company. Domains and Organizational Units are used to: separate users and/or groups limit administrator activities to the administrator's own domain (delegated administration) or to an Organizational Unit to allocate DIGIPASS records to different domains or Organizational Units, for example to mirror the geographic location of the devices. 124

125 Organization However, there are two differences between domains and Organizational Units: All DIGIPASS User Accounts and DIGIPASS records must belong to a domain. DIGIPASS User Accounts and DIGIPASS records do not have to belong to an Organizational Unit. The domain is used to identify User Accounts, whereas Organizational Units are not (as explained below). As a consequence, two User Accounts with the same name can only exist if they are in different domains Master Domain and Practical Uses Master Domain Concepts When the axsguard Identifier is installed, a single domain is created in the database, the Master Domain. By default, all new DIGIPASS User Accounts and DIGIPASS records are created in the Master Domain. The Master Domain serves three important purposes: for initial access and configuration of the axsguard Identifier. Two system administrators exist on the Master Domain, one for system operation, which should never be removed, and one for the axsguard Identifier system administrator (see section 4.4). all DIGIPASS instances are imported by default into the Master Domain although different domains or Organizational Units can be chosen during importation. Example relocation models are shown in section for whenever a domain cannot be found for an authentication request (explained below). If a separate domain field is provided on login, this is used with the User ID. If a separate domain field is not provided, but the user name is in the form userid@domain, and there is a domain with the given domain name, that domain is used. In this case, the user name has the '@domain' part removed. Otherwise, the user name remains as userid@domain and no domain is identified. If no domain is identified, the applicable Policy is checked for a Default Domain. The Default Domain is used if it is specified in the Policy. Otherwise, the Master Domain is used as a default (see image below and also section 3.4.2). 125

126 Organization Image 45: User ID and Domain Resolution Practical Use Authentication requests require the user name to be resolved and the appropriate DIGIPASS User Account to be located. Domain management is therefore required to support this process. For example, let's consider a company using the domain name 'mycompany.com'. The system administrator has added a domain, 'mycompany.com' and multiple users below this domain. One of these users is the DIGIPASS User Account 'martin'. Imagine the following two user IDs being provided by an end user, and the consequences shown in the flowchart (see above). 1. User ID = 'martin', the resulting user ID is 'martin' while the domain is 'Master', because the factory default axsguard Identifier does not have a default domain configured in the policies. 2. User ID = 'martin@mycompany.com': the resulting user ID is 'martin' while the domain is 'mycompany.com'. 126

127 Organization The first user ID will not be resolved, since the DIGIPASS User Account 'martin' doesn't exist in the Master Domain (users were only added in the 'mycompany.com' domain). The second user ID will be resolved because the DIGIPASS User Account 'martin' exists in the 'mycompany.com' domain. To allow both user IDs to be identified requires the following management: setting up a domain conforming to the network domain name. adding users below this domain (i.e. not below the Master Domain), so that user names can be resolved when authentication requests are made. configuring a default domain for name resolution to avoid the Master Domain being used when a domain name cannot be found in the axsguard Identifier. The default domain needs to be configured in the Base Policy of the axsguard Identifier. All policies below the Base Policy automatically inherit this setting. (Changes to the default domain setting in any policy are inherited by child policies unless overruled; see section 20 for more information on policy inheritance.) Please see the axsguard Identifier Installation Guide for a listing of the default settings required Moving DIGIPASS User Accounts and DIGIPASS A domain must be chosen for a DIGIPASS User Account when it is created, as the domain makes up part of the identification for the account. A DIGIPASS User Account may not be moved to a different domain. It must be deleted and recreated in the required domain. Unassigned DIGIPASS records may be moved to the required domain after importation. A DIGIPASS record assigned to a DIGIPASS User Account must belong to the same domain as the account. You therefore need to ensure that the correct numbers of DIGIPASS records are allocated to the different domains. A DIGIPASS record assigned to a DIGIPASS User Account must belong to the same Organizational Unit as the User Account. If a DIGIPASS record is assigned to a User Account in another Organizational Unit, it is moved there automatically. A DIGIPASS record assigned to a user cannot be moved. DIGIPASS User Accounts can be moved between Organizational Units within the same domain whenever required, in which case the assigned DIGIPASS records are automatically moved with them. 127

128 Organization Image 46: Possibilities for Moving User Accounts and DIGIPASS (ou = Organizational Unit) Note When a User Account is moved to an Organizational Unit, all DIGIPASS records assigned to it are also moved. A DIGIPASS record assigned to a user cannot be moved - the User Account must be moved Location of DIGIPASS Records When searching for an available DIGIPASS record for a device to assign to a user, the axsguard Identifier first searches in the same Organizational Unit as the User Account, if the User Account belongs to an Organizational Unit. The Search Upwards in Organizational Unit hierarchy option, when enabled, allows the axsguard Identifier to search in parent Organizational Units and the DIGIPASS Pool container. This option may be set at the Policy level for system searches (e.g. Auto-Assignment and Self-Assignment: see section 17.4) or at the time of the search for manual assignment. If the User Account being assigned a DIGIPASS record does not belong to an Organizational Unit, the axsguard Identifier searches for an available DIGIPASS record which does not belong to an Organizational Unit, i.e. for an available record stored directly in the domain. Note The axsguard Identifier always finds or assigns the closest available DIGIPASS record to the selected user record(s). 128

129 Organization 21.6 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 records. 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. Image 47: DIGIPASS Record Location Domain Root In the diagram above, the axsguard Identifier searches upwards through the Organizational Unit structure for an available DIGIPASS record to assign to a DIGIPASS user in the Organizational Unit B1. Because no available DIGIPASS records are found in B1, it searches in B, then in the Domain Root. The administrator account manually assigning the DIGIPASS records must be located in the Domain Root (no Organizational Unit) for this model to work successfully. 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 Domain Root. The Search Upwards in Organizational Unit hierarchy option does not need to be enabled in this case. Note The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly. 129

130 Organization Parent Organizational Units Unassigned DIGIPASS records can be kept in key Organizational Units, and made available to their lower level Organizational Units. Image 48: DIGIPASS Record Location Parent Organizational Unit In the diagram above, the axsguard Identifier can search in the parent Organizational Unit for available DIGIPASS records. The administrator account manually assigning the DIGIPASS records must belong to the parent Organizational Unit. Note The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly. 130

131 Organization Individual Organizational Units DIGIPASS records can be loaded or moved into each Organizational Unit when and where they are required. If all DIGIPASS in an Organizational Unit have been assigned, more DIGIPASS records need to be moved in manually by a domain administrator, before they can be assigned. Image 49: DIGIPASS Record Location Individual Organizational Units In the diagram above, unassigned DIGIPASS records 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 records may be stored in the Domain Root and also in 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 axsguard Identifier will search upwards to the Domain Root and search in the DIGIPASS Pool for an available, unassigned DIGIPASS record. 131

132 Reporting 22 Reporting 22.1 Overview There are two separate sources of information generated on the axsguard Identifier from the Convenience Layer and from the IDENTIKEY component. Information sourced from the Convenience layer supports logging (explained in section 9). Information sourced from the IDENTIKEY component supports auditing and reporting: Auditing can be managed through the axsguard Identifier Configuration Tool (see section 4 on Administration Interfaces) using the live audit viewer. Auditing happens in real time, allowing administrators to view a limited number of recent events. Auditing is explained in section 10. Reporting provides standard and customized reports based on the data stored in the axsguard Identifier configuration and audit databases. The Administration Web Interface allows you to run existing reports and to create new reports. Reporting is explained in this section Reporting Structure and Purposes Image 50: Reporting Structure The axsguard Identifier Reporting facility allows you to create reports from the axsguard Identifier database information, and from the Audit information. 132

133 Reporting The main uses for reports are: Troubleshooting User Troubleshooting: administrators can generate reports to enable them to troubleshoot authentication failures for specific users. System Troubleshooting: system administrators can generate axsguard Identifier reports to analyse and solve system problems System Audits System administrators can generate reports to carry out audits of DIGIPASS records for devices or administrator actions. Security Audits System administrators can generate reports to analyse suspicious activity. Accounting Reports can be generated to count the number of authentication requests per user or organizational unit. Standard reports are provided in the axsguard Identifier for the most common adminstration tasks. For a list of the standard reports available please refer to the the axsguard Identifier Administration Reference Guide. Note: The domain referenced for a report in the Administration Web Interface refers to the permissions for editing the report, not the domain for which the data is reported. See sections and. Custom reports can be defined to fulfil requirements not met by the standard reports. Custom reports are based on the standard report types with a report query defined to suit your organization's requirements. How Custom reports are defined is explained in the following section Custom Reports Overview Customizing reports requires configuring the following, which we explain further in the sections below: Report Type Data Source Grouping Level Query Permissions Template 133

134 Reporting Report Type There are four report types. List Analysis Report: lists all items that match the criteria specified in the report definition, e.g. a list of users with no DIGIPASS records assigned. Detailed Analysis Report: shows detail of the events specified in the report definition, e.g. a detailed list of failed authentications for a User. Distribution Analysis Report: shows counts of events and objects, e.g. the number of failed authentications for a domain. Trend Analysis Report: shows a trend over a period of time for the objects specified in the report definition. For Trend Analysis Reports there is an extra parameter. The period of time needs to be specified and can be: Hour Day Month Year Data Source Reports are generated from data available on the axsguard Identifier: audit data, the Data Store, or both. Data Source possibilities are as follows: Users: this generates a report based on the User information from the axsguard Identifier Data Store. Users + Audit Data: this generates a report based on the User information mentioned above, and the Audit Data from the axsguard Identifier. DIGIPASS: this generates a report based on the DIGIPASS information from the axsguard Identifier Data Store. DIGIPASS + Audit Data: this generates a report based on the DIGIPASS information mentioned above, and the Audit Data from axsguard Identifier. Audit Data only: this generates a report based on the Audit data only Grouping Level Data in reports can be grouped by defining the Grouping Level. The Grouping Level choices are: Client Domain Organizational Unit User DIGIPASS If a Detail or List report is set at Grouping Level of User, each user is 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 are summed and represented only once under the Organizational Unit. 134

135 Reporting In the example below, the Grouping Level has been set to User: each User has an individual row on the report. Image 51: Report Grouping 135

136 Reporting Query Queries specify the search criteria for extracting data to create a report. Queries consist of: a Datafield, which is a field from the database. an Operator, which is the operation to be performed on the datafield. a Value, which is the value the datafield will be compared against. A value is not necessary with all operators. Two or more values after the operator are interpreted as if the word 'and' was between them. For more information on the data fields and operators available for building queries, please refer to the axsguard Identifier Administration Reference Guide. Example: To generate a report for a specific Audit message, such as 'Authentication' or 'DP4WEB', you can specify in your Query: Audit Message = 'Authentication' Only information on 'Authentication' Audit Messages is reported. Queries can also combine criteria, for example: Audit Message = 'Authentication', User Name = 'User5' Permissions Each report definition has an owner. The owner is usually the administrator who created the report, but ownership can be transferred to another administrator in the same domain. Permissions associated with each report control: Use: Who can run and view the report. Use can be restricted to the report owner or can be granted to other administrators. Update: Who can update the report definitions. The ability to change the report format and details can be restricted to the report owner or can be granted to other administrators. Permissions are configured separately for use and updating. Three permission options are possible: 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 who belong to the domain where the report was defined. Standard reports available in the axsguard Identifier have Public use permissions and Private update permissions. 136

137 Reporting Formatting Templates Report data is always generated into XML, then an XSLT transformation is applied to give the output. The XSLT transformation requires a formatting template. Each report definition requires at least one template so that it can be produced in the format required. Each report definition can have more than one Formatting Template. The template to be used can be selected when running the report Report Generation Process Report generation relies on a number of components. An SQL query must be defined to retrieve the data that is required for the report. A report type must be selected from the list available. The result of the SQL query and the report type are combined into an XML report (see image below). The XML report and the report format template are combined to produce the finished report in the required format. Image 52: Report Generation Process 137

138 Rescue Tool Section Overview Access Options

139 23 Rescue Tool 23.1 Overview Rescue Tool The Rescue Tool allows administrators to access a limited number of settings through a command line menu. Functionality available through the Rescue Tool is described below. Note: The Rescue Tool is not the DIGIPASS Command Line Administration (DPCLA). DPCLA is an extension of the TCL8.4 scripting language, which allows interactive command line and scripted administration of DIGIPASS related data. The DPCLA is only accessible to VASCO experts Access The Rescue Tool serves as a 'rescue tool' allowing options described in the following section. As a rescue tool, only the user name, 'rescue', is necessary, and no password. Access to the tool is achieved (local to the axsguard Identifier) by: plugging a screen and keyboard directly into the axsguard Identifier, or connecting a workstation or laptop computer to the axsguard Identifier using a 'Serial Null Modem Cable' plugged into a serial port on both devices. This requires configuration specific to the operating system of the workstation or laptop computer. For instructions on how to connect to the Rescue Tool, please refer to the axsguard Identifier Installation Guide Options The Rescue Tool can be used to: Reset axsguard Identifier configuration settings to factory default settings. This means that licenses are removed, configuration data is lost and even network settings are re-set. The same conditions apply as with first time installation (see section 5). Reset the 'sysadmin' password. If the Rescue Tool is used to delete the current system administrator password, the password defaults to 'sysadmin'. When the axsguard Identifier is accessed, the Configuration Wizard detects that only the 'sysadmin' password needs to be changed and only presents this page of the Configuration Wizard for completion. The Configuration Tool is not accessible until the password has been changed. Change and view network settings, e.g. changing the axsguard Identifier IP address. After the Rescue Tool has been used to change the IP address, the same conditions apply as described in section

140 Rescue Tool reboot or shut down the axsguard Identifier. Image 53: Start and Network Menus with the Rescue Tool. 140