Vasco Personal aXsGUARD Product Manual
Advertisement
Advertisement
Product Guide aXsGUARD
AXSGuard
ConfigurationTool
0
2009
Product Guide aXsGUARD Identifier aXsGUARD Identifier aXsGUARD Identifier
DIGIPASS
ConfigurationTool v1.5
0.1
aXsGUARD Identifier
Product Guide
3.0.2.0
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
© 2009 VASCO Data Security 2
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
Table of Contents
INTRODUCTION SECTION.............................................................................................................................. 13
USER AUTHENTICATION SECTION.................................................................................................................. 25
© 2009 VASCO Data Security 3
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
ADMINISTRATIVE INTERFACES SECTION....................................................................................................... 57
© 2009 VASCO Data Security 4
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
CONFIGURATION TOOL SECTION................................................................................................................... 62
© 2009 VASCO Data Security 5
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
© 2009 VASCO Data Security 6
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
ADMINISTRATION WEB INTERFACE SECTION............................................................................................... 100
© 2009 VASCO Data Security 7
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
© 2009 VASCO Data Security 8
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
RESCUE TOOL SECTION.............................................................................................................................. 143
© 2009 VASCO Data Security 9
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
Illustration Index
Image 1: VASCO's Authentication Solution.................................................................................................................................................................... 17
Image 2: aXsGUARD Identifier Architecture ................................................................................................................................................................... 19
Image 3: Connection between the aXsGUARD Identifier and VASCO Service Center........................................................................................................ 24
Image 4: Authentication Process Overview.................................................................................................................................................................... 26
Image 5: User ID and Domain Resolution....................................................................................................................................................................... 29
Image 6: Dynamic User Registration Process................................................................................................................................................................ 31
Image 7: Multiple DIGIPASS Assignment....................................................................................................................................................................... 34
Image 8: Response Only Login and Authentication Process............................................................................................................................................ 36
Image 9: 1-step (left) and 2-step (right) Challenge/Response Login................................................................................................................................ 38
Image 10: Virtual DIGIPASS Login................................................................................................................................................................................. 39
Image 11: Static Password Authentication Flow............................................................................................................................................................ 42
Image 12: Password Replacement with an IIS Module................................................................................................................................................... 46
Image 13: Steps in the Retrieval of RADIUS Attributes................................................................................................................................................... 47
Image 14: Back-end Authentication Process with RADIUS............................................................................................................................................. 49
Image 15: Back-end Authentication Process with Microsoft Active Directory.................................................................................................................. 51
Image 16: Back-end Authentication Process with Novell e-Directory.............................................................................................................................. 54
Image 17: Data Transmission from the Syslog Utility to the Live Log Viewer and Remote Syslog..................................................................................... 72
Image 18: Example Screen Shot Showing the Live Log Viewer....................................................................................................................................... 73
Image 19: Log Filter Fields .......................................................................................................................................................................................... 74
Image 20: Live Audit Viewer and Filter.......................................................................................................................................................................... 76
Image 21: Audit Filter Fields ........................................................................................................................................................................................ 77
Image 22: Process Statistics......................................................................................................................................................................................... 79
Image 23: Disk Usage Statistics.................................................................................................................................................................................... 79
Image 24: CPU Statistics.............................................................................................................................................................................................. 80
Image 25: Interface Statistics....................................................................................................................................................................................... 80
Image 26: Show CPU Usage for a Specific Service......................................................................................................................................................... 80
Image 27: CPU Time for Administration Web Interface................................................................................................................................................... 81
Image 28: Virtual DIGIPASS Process using aXsGUARD Identifier MDC Component (clockwise from the top)..................................................................... 82
Image 29: Administration Web Interface > Users > User 'annelies'> User Attributes...................................................................................................... 88
Image 30: LDAP Synchronization to create or update an User Account.......................................................................................................................... 89
Image 31: Possible source and destination hierarchy mapping with a single Synchronization Profile............................................................................... 92
Image 32: Example source and destination hierarchy mapping with three Synchronization Profiles................................................................................. 92
Image 33: Deleting a Synchronization Profile ID for a User Account................................................................................................................................ 93
Image 34: Replication between a First and Second aXsGUARD Identifier........................................................................................................................ 95
© 2009 VASCO Data Security 10
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
Image 35: Replication between a First, Second, and Disaster Recovery aXsGUARD Identifier.......................................................................................... 96
Image 36: 'System' Tab in the Administration Web Interface......................................................................................................................................... 99
Image 37: Replication Status Screen in the Administration Web Interface....................................................................................................................... 99
Image 38: User Account Link...................................................................................................................................................................................... 103
Image 39: Self-Assignment Process ........................................................................................................................................................................... 112
Image 40: Auto-Assignment Process .......................................................................................................................................................................... 114
Image 41: Manual Assignment Process ...................................................................................................................................................................... 115
Image 42: Reserving a DIGIPASS Record for a Specific User in the Administration Web Interface.................................................................................. 116
Image 43: Policy Inheritance....................................................................................................................................................................................... 127
Image 44: Domains and Organizational Units.............................................................................................................................................................. 129
Image 45: User ID and Domain Resolution................................................................................................................................................................... 131
Image 46: Possibilities for Moving User Accounts and DIGIPASS (ou = Organizational Unit)........................................................................................... 133
Image 47: DIGIPASS Record Location – Domain Root.................................................................................................................................................. 134
Image 48: DIGIPASS Record Location – Parent Organizational Unit............................................................................................................................... 135
Image 49: DIGIPASS Record Location – Individual Organizational Units........................................................................................................................ 136
Image 50: Reporting Structure.................................................................................................................................................................................... 137
Image 51: Report Grouping......................................................................................................................................................................................... 140
Image 52: Report Generation Process ........................................................................................................................................................................ 142
Image 53: Start and Network Menus with the Rescue Tool.......................................................................................................................................... 145
© 2009 VASCO Data Security 11
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Table of Contents
Index of Tables
Table 1: Values for Local Authentication Setting....................................................................................................................................... 32
Table 2: Values for Back-end Authentication Setting.................................................................................................................................44
Table 3: RADIUS User ID Formats for Back-end Authentication................................................................................................................. 48
Table 4: Microsoft Active Directory User ID formats for Back-end Authentication...................................................................................... 50
Table 5: Novell e-Directory User ID Formats for Back-end Authentication................................................................................................. 52
Table 6: User Attribute Settings................................................................................................................................................................ 55
Table 7: Default Administrative User Credentials.......................................................................................................................................58
Table 8: Log Levels.................................................................................................................................................................................. 74
Table 9: Log Filter Fields.......................................................................................................................................................................... 75
Table 10: Audit Message Types................................................................................................................................................................77
Table 11: Audit Filter Fields...................................................................................................................................................................... 78
Table 12: Server Settings Regulating Server PINs................................................................................................................................... 107
Table 13: DIGIPASS Record Actions supported in the Administration Web Interface.................................................................................109
Table 14: DIGIPASS Options....................................................................................................................................................................117
Table 15: Backup Virtual DIGIPASS Example Guidelines..........................................................................................................................120
© 2009 VASCO Data Security 12
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Introduction Section
Introduction............................................................. 1
aXsGUARD Identifier................................................. 2
© 2009 VASCO Data Security 13
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Introduction
1 Introduction
1.1
Audience and Purpose of this Document
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.
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.
aXsGUARD Identifier Configuration Tool, the Administration Web Interface and the Rescue Tool.
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.
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.
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.
© 2009 VASCO Data Security 14
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
1.2
1.3
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 www.vasco.com
Contact Information
Brussels (Europe / Middle East / Latin America)
+32 2 609 97 00 [email protected]
Boston (North America)
+1 508 366 3400 [email protected]
Sydney (Pacific / Japan / India)
+61 2 80613700 [email protected]
Singapore (Asia)
+65 6323 0906 [email protected]
© 2009 VASCO Data Security 15
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
aXsGUARD Identifier
2 aXsGUARD Identifier
2.1
2.2
Overview
In this chapter, we introduce the products and concepts which together provide VASCO's authentication solution with the aXsGUARD Identifier.
briefly describes VASCO's authentication solution.
introduces the aXsGUARD Identifier.
introduces the IDENTIKEY Server.
explains management of DIGIPASS devices and records.
describes the structure and components of the aXsGUARD Identifier.
outlines VASCO aXsGUARD Identifier licensing models.
describe the support procedure and VASCO Service Center.
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.
© 2009 VASCO Data Security 16
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
aXsGUARD Identifier
2.3
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.
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
© 2009 VASCO Data Security 17
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
2.4
2.5
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
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.
© 2009 VASCO Data Security 18
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 www.vasco.com
.
2.6
2.6.1
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.
© 2009 VASCO Data Security 19
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
aXsGUARD Identifier
2.6.2
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.
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.
© 2009 VASCO Data Security 20
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
2.6.3
2.7
2.7.1
2.7.2
2.7.3
aXsGUARD Identifier
Scenarios
Scenarios are the client applications and other functionalities supported by the aXsGUARD Identifier. They are
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)
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 6 .
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
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.
© 2009 VASCO Data Security 21
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
2.7.4
2.8
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 18 .
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: http://www.vasco.com/support .
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).
© 2009 VASCO Data Security 22
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
2.9
VASCO Service Center
aXsGUARD Identifier
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
for registration (see section 6
), 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.
© 2009 VASCO Data Security 23
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
© 2009 VASCO Data Security
User Authentication Section
Authentication Process Overview........................... 3.1
Identifying the Component Record......................... 3.2
Identifying a Policy................................................ 3.3
DIGIPASS User Account Lookup and Checks.......... 3.4
Local Authentication.............................................. 3.5
Back-end Authentication....................................... 3.6
Authorization Profiles/Attributes............................. 3.7
Host Code Generation............................................ 3.8
24
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
© 2009 VASCO Data Security
Image 4: Authentication Process Overview
25
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.2
3.3
3.4
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 18 .
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
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 .
DIGIPASS User Account Lookup and Checks
3.4.1
3.4.2
Overview
aXsGUARD Identifier performs a number of checks before proceeding to local authentication, including:
User ID and Domain Resolution, which is explained in section 3.4.2
DIGIPASS User Account Lookup, which is explained in section 3.4.3
Checking whether Dynamic User Registration is enabled for a user (if a DIGIPASS user account doesn't exist),
which is explained in section 3.4.4
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.
© 2009 VASCO Data Security 26
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 2.
2.
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 5.
3.
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 5.
4.
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 7.
6.
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
© 2009 VASCO Data Security
Image 5: User ID and Domain Resolution
27
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
3.4.3
3.4.4
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
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 3.5
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 17.4
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.
© 2009 VASCO Data Security 28
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
© 2009 VASCO Data Security
Image 6: Dynamic User Registration Process
29
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.5
Local Authentication
3.5.1
3.5.2
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
Default
None
DIGIPASS
Only
DIGIPASS/
Password
Explanation
Local Authentication is handled as configured in settings inherited from the parent policy. More
No Local Authentication takes place.
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
for information on DIGIPASS assignment options.)
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.
3.5.3
Authentication with DIGIPASS
3.5.3.1
Overview
In this section on authentication with a DIGIPASS device, we first explain DIGIPASS lookup and checks in section
processing can continue.
© 2009 VASCO Data Security 30
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.5.3.2
The three possible requests mechanisms are:
a Response only One Time Password (OTP: described in section 3.5.3.3
) a Challenge for Challenge/Response OTP generation (described in section 3.5.3.4
a Virtual DIGIPASS
OTP (described in section 3.5.3.5
Virtual DIGIPASS use, please
For more information on these authentication methods, see section 17.2.4
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
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.
© 2009 VASCO Data Security 31
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 16.3
. 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
) 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.
© 2009 VASCO Data Security 32
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
3.5.3.3
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).
User Authentication Process
3.5.3.4
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).
© 2009 VASCO Data Security 33
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
For more information on time- or event-based Challenge/Response DIGIPASS authentication methods, please see
For more information on Policies, please see section 20.2
1-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 3.5.3.6).
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.
© 2009 VASCO Data Security 34
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.5.3.5
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
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:
© 2009 VASCO Data Security 35
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 3.5.3.6).
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: t he User enters their password and OTP into the login window.
4.
The aXsGUARD Identifier authenticates the User.
Backup Virtual DIGIPASS
) 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
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
© 2009 VASCO Data Security 36
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.5.3.6
Request Method and Keyword
For 2-Step Challenge/Response and Virtual DIGIPASS , the method of requesting a Challenge or OTP respectively can be defined in the Policy. The methods for Primary Virtual DIGIPASS and Backup Virtual DIGIPASS are defined separately. The request methods are:
Password - the static password.
Keyword - a fixed keyword, which can be blank.
PasswordKeyword - the static password followed by a fixed keyword, with no whitespace or separating characters 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 3.5.4.1
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.
3.5.4
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.
© 2009 VASCO Data Security 37
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.5.4.1
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 2.
2.
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 4.
4.
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 back-
end authentication, please see section 3.6.2
)
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 6.
6.
If back-end authentication is not available, authentication fails. If back-end authentication is available, the request is passed on to step 7.
7.
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
© 2009 VASCO Data Security 38
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.5.4.2
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 3.5.4.1
© 2009 VASCO Data Security 39
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
3.6
3.6.1
3.6.2
User Authentication Process
Back-end Authentication
Overview
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
Static password verification for Users who do not have a DIGIPASS device and for Virtual DIGIPASS (see
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 20 .
© 2009 VASCO Data Security 40
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
3.6.3
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
3.6.3.1
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.
© 2009 VASCO Data Security 41
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.6.3.2
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.
3.6.3.3
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).
© 2009 VASCO Data Security 42
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.6.3.4
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.
© 2009 VASCO Data Security 43
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
User Authentication Process
3.6.4
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.
3.6.4.1
Fail-over Strategy
Each back-end server record is assigned a Priority . This comes into effect when multiple back-end servers are available, and the 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.
© 2009 VASCO Data Security 44
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.6.4.2
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
). 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.
3.6.5
RADIUS Back-end Authentication
aXsGUARD Identifier supports RADIUS back-end authentication (see also section 18.3.1
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
With domain
Without domain [email protected]
geraard
Example
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:
© 2009 VASCO Data Security 45
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
© 2009 VASCO Data Security 46
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.6.6
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 .
3.6.6.1
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
With domain
Without domain [email protected]
geraard
Example
© 2009 VASCO Data Security 47
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Authentication Process
User 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.
© 2009 VASCO Data Security 48
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
3.6.6.2
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
FqDN userid (Fully Qualified Distinguished Name)
RDN userid (Relative Distinguished Name)
FqDN [email protected]
Example
Geraard.Administration.Mechelen.CORP
Geraard
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.
© 2009 VASCO Data Security 49
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
2.
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 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 fail-
over (or replication) strategy (see section 3.6.4.1
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.6.4.2
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.
© 2009 VASCO Data Security 50
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
User Authentication Process
3.6.6.3
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 e-
Directory. The policies can be selected from the Policies tab of the aXsGUARD Identifier Administration Web
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.
© 2009 VASCO Data Security 51
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
3.7
User Authentication Process
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
3.8.1
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.
© 2009 VASCO Data Security 52
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
© 2009 VASCO Data Security 53
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Administrative Interfaces Section
Overview............................................................... 4.1
Default Administrative Users.................................. 4.2
Configuration Tool................................................. 4.3
Administration Web Interface................................. 4.4
Rescue Tool.......................................................... 4.5
© 2009 VASCO Data Security 54
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Administration Interfaces
4 Administration Interfaces
4.1
4.2
Overview
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.
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 sysadmin admin@master rescue
Factory default password sysadmin identikey
(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.
© 2009 VASCO Data Security 55
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
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
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).
procedure requires connection to the VSC).
Backup and Restore: the purpose and procedures for backup and restore functionality are explained in section
Auditing and Logging: information generated from the aXsGUARD Identifier can be searched using live viewers
System statistics: statistics are available on the aXsGUARD Identifier, the services, the disk, memory and
Message Delivery Component: this is the component supporting the use of the virtual DIGIPASS and is
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.
© 2009 VASCO Data Security 56
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
Policies: Policies specify various settings that affect request handling processes. Each request is handled
Back-end servers: b ack-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 Self-
Assignment
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
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.
© 2009 VASCO Data Security 57
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Administration Interfaces
4.5
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 16.7
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.
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
© 2009 VASCO Data Security 58
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
© 2009 VASCO Data Security
Configuration Tool Section
Installation Configurations........................................ 5
Registration.............................................................. 6
Updating.................................................................. 7
Backup and Restore................................................. 8
Logging.................................................................... 9
Auditing................................................................. 10
Statistics................................................................ 11
Message Delivery Component................................. 12
Remote Support..................................................... 13
LDAP User Synchronization..................................... 14
Replication............................................................. 15
59
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Installation Configurations
5 Installation Configurations
5.1
5.2
Overview
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.
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.
© 2009 VASCO Data Security 60
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Installation Configurations
5.3
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
.
4. Back-end Authentication for checking User Credentials with a RADIUS or LDAP Server (see
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.
© 2009 VASCO Data Security 61
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Registration
6 Registration
6.1
6.2
Overview
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.
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
The registration process comprises four main steps:
1.
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 email address aXsGUARD Identifier serial number and license number organization's contact details reseller name
...
2.
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
) are returned and stored on the aXsGUARD Identifier.
© 2009 VASCO Data Security 62
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Registration
6.3
6.4
6.5
6.6
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 5.4
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, as the license key remains available for that IP address unless the server component is removed manually.
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.
Replacement of aXsGUARD Identifier
In the rare event of an aXsGUARD Identifier failure, full first-time registration is required (see above).
© 2009 VASCO Data Security 63
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
6.7
6.8
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.
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
manual.
© 2009 VASCO Data Security 64
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Updating
7 Updating
7.1
7.2
7.3
Overview
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.
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.
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 www.vasco.com
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.
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 www.vasco.com
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.
© 2009 VASCO Data Security 65
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Backup and Restore
8 Backup and Restore
8.1
8.2
8.3
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
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.
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 ).
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 re-
registration completed (see section 6 ).
Caution:
Restoring a backup of a newer version of the aXsGUARD Identifier is not supported.
© 2009 VASCO Data Security 66
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Logging
9 Logging
9.1
9.2
Overview
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
Logging: this is the information generated about events in the Convenience Layer (see section 2.3
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 ).
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).
© 2009 VASCO Data Security 67
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
9.3
Logging
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.
9.4
9.5
Image 18: Example Screen Shot Showing the Live Log Viewer
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.
Log Levels
The Log system can be configured to generated log information at different levels. These levels are explained in the table below.
© 2009 VASCO Data Security 68
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
.
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
© 2009 VASCO Data Security 69
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Logging
Table 9: Log Filter Fields
Type Description
Date After
Date Before
Facility is
Level at least
Click on the icon to select a date from the calendar. Only records after the date specified are displayed.
Click on the icon to select a date from the calendar. Only records before the date are displayed.
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.
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.
© 2009 VASCO Data Security 70
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
10.2
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.
© 2009 VASCO Data Security 71
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Auditing
Table 10: Audit Message Types
Type
Error
Warning
Information
Success
Failure
Description
The message contains details about a system, configuration, licensing or some internal error. Errors do not include normal processing events such as failed logins.
Warning messages contain details about potential problems within the system. This could include details such as a failed connection attempt to a database
Informational messages provide details about events within the system that need to be recorded but do not indicate errors or potential errors.
Success messages contain details about processing events that were correctly processed. This may include successful authentications or successful administration commands.
Failure messages contain details about processing events that failed. This may include rejected authentications, or administration actions that failed.
10.4
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.
© 2009 VASCO Data Security
Image 21: Audit Filter Fields
72
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
Type is
Click on the icon to select a date from the calendar. Only records before the date are displayed.
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
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.
© 2009 VASCO Data Security 73
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 ).
11.2
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
© 2009 VASCO Data Security 74
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
CPU time
Statistics
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.
© 2009 VASCO Data Security
Image 26: Show CPU Usage for a Specific Service
75
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Image 27: CPU Time for Administration Web Interface
Statistics
© 2009 VASCO Data Security 76
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Message Delivery Component
12 Message Delivery Component
12.1
Overview
The Message Delivery Component (MDC) is necessary to support Virtual DIGIPASS authentication. For more
information on Virtual DIGIPASS authentication, see section 17.2.4
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).
© 2009 VASCO Data Security 77
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Message Delivery Component
12.2
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.
© 2009 VASCO Data Security 78
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Remote Support
13 Remote Support
13.1
Overview
Remote support allows VASCO experts to connect to your aXsGUARD Identifier to resolve difficulties (see also
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.
13.2
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
13.3
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
. 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
the connection.
© 2009 VASCO Data Security 79
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Remote Support
13.4
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).
© 2009 VASCO Data Security 80
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
LDAP User Synchronization
14 LDAP User Synchronization
14.1
Overview
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
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.
14.2
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 .
© 2009 VASCO Data Security 81
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
14.3
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'.
© 2009 VASCO Data Security 82
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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).
14.4
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.
© 2009 VASCO Data Security 83
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
LDAP User Synchronization
© 2009 VASCO Data Security
Image 30: LDAP Synchronization to create or update an aXsGUARD Identifier User Account
84
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
14.5
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.
14.6
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.
14.7
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 email 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
© 2009 VASCO Data Security 85
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
LDAP User Synchronization
had both values for the email 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.
14.8
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.
© 2009 VASCO Data Security 86
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
LDAP User Synchronization
Image 31: Possible source and destination hierarchy mapping with a single Synchronization Profile
© 2009 VASCO Data Security
Image 32: Example source and destination hierarchy mapping with three Synchronization Profiles
87
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
LDAP User Synchronization
14.9
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
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 .
© 2009 VASCO Data Security
Image 33: Deleting a Synchronization Profile ID for a User Account
88
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
for example when deleting a User Account fails.
© 2009 VASCO Data Security 89
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Replication
15 Replication
15.1
Overview
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.
15.2
Common Replications
15.2.1
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.
© 2009 VASCO Data Security
Image 34: Replication between a First and Second aXsGUARD Identifier
90
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Replication
15.2.2
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
, 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 .
© 2009 VASCO Data Security 91
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
15.4
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 .
15.5
Replication Process
15.5.1
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.
© 2009 VASCO Data Security 92
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Replication
15.5.2
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.
15.5.3
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.
15.5.4
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.
15.6
Replication Monitoring
15.6.1
Replication Auditing
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
© 2009 VASCO Data Security 93
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Replication
15.6.2
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
© 2009 VASCO Data Security
Image 37: Replication Status Screen in the Administration Web Interface
94
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Web Administration Interface Section
DIGIPASS User Accounts........................................ 16
DIGIPASS................................................................ 17
Client Components................................................. 18
Server Components................................................ 19
Policies.................................................................. 20
Organization........................................................... 21
Reporting............................................................... 22
© 2009 VASCO Data Security 95
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS User Accounts
16 DIGIPASS User Accounts
16.1
Overview
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.
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.
16.2
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).
16.2.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
© 2009 VASCO Data Security 96
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 .
16.2.2
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.
16.2.3
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
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 17.2.4
16.2.4
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,
16.3
Linked User Accounts
Normally, a DIGIPASS record can only be assigned to one User Account (see section 17.4.4
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).
© 2009 VASCO Data Security 97
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
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
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
© 2009 VASCO Data Security 98
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS User Accounts
during Challenge/Response authentication as Request Method (see section 3.5.3.6
) during Virtual DIGIPASS use as Request Method (see section 3.5.3.6
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 3.5.3.2
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 3.6.3.2
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.
16.7
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
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
© 2009 VASCO Data Security 99
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17 DIGIPASS
17.1
Overview
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.
17.2
DIGIPASS Properties
17.2.1
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.
© 2009 VASCO Data Security 100
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
17.2.2
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
PIN OTP: the normal login where a Server PIN is required and is entered in front of the OTP
PIN OTP newpin newpin: for changing the Server PIN: the new PIN is entered twice after the OTP
OTP newpin newpin: 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).
© 2009 VASCO Data Security 101
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
PIN Length
Whether a User is allowed to change their Server PIN for this DIGIPASS device.
The length of the current Server PIN.
PIN Minimum Length The minimum PIN length required by the Server.
17.2.3
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 Auto-
Assignment . 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 17.4
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 3.5.4.1
17.2.4
DIGIPASS Authentication Method
DIGIPASS authentication and login processes include:
Response only (described in section 3.5.3.3
Challenge/Response (described in section 3.5.3.4
Virtual DIGIPASS
Login (described in section 3.5.3.5
Virtual DIGIPASS use, please
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.
© 2009 VASCO Data Security 102
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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 3.5.3.4). 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.
17.3
DIGIPASS Management
17.3.1
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.
17.3.2
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
© 2009 VASCO Data Security 103
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
These processes are described in section 17.4
. DIGIPASS self- and auto-assignment methods can also be
combined with Dynamic User Registration
17.3.3
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.
17.3.4
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
Reset Application
Activate Application
Deactivate Application
Delete Application
Set Event Counter
Reset PIN
Force PIN Change
Set PIN
Explanation
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.
Activates a previously deactivated application for selected DIGIPASS records.
Deactivates a previously activated application for selected DIGIPASS records.
Deletes an application for selected DIGIPASS records.
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.
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.
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.
A User’s Server PIN can be set to a specific value and communicated to the User.
© 2009 VASCO Data Security 104
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
Name Explanation
Unlock DIGIPASS
Reset Application Lock
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
Move
Use these functions to assign or unassign a selected DIGIPASS record to or from a User
Account.
Use this function to move a selected DIGIPASS records to another domain or
organizational unit (see section 21.4
Edit
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.
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.
Delete
Use this function to edit (for example Backup Virtual DIGIPASS or Grace Period settings) for a single DIGIPASS record.
Use this function to delete a selected DIGIPASS record(s).
17.3.5
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).
© 2009 VASCO Data Security 105
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
17.4
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.
© 2009 VASCO Data Security 106
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.4.1
Self-Assignment
17.4.1.1
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
.
© 2009 VASCO Data Security
Image 39: Self-Assignment Process
107
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.4.1.2
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:
SERIALNUMBER password OTP – where a Server PIN is not required.
SERIALNUMBER password PIN OTP – where a Server PIN is required.
SERIALNUMBER password OTP newpin newpin – 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: SERIALNUMBER password
Step 2: OTP
Serial Number Format
The SERIALNUMBER may be entered in one of two formats, depending on the Serial No. Separator Policy setting.
No separator specified – the full 10 digit Serial Number must be entered, with no dashes (-) or spaces, for example 0097123456 .
Separator value specified – the Serial Number can be entered as written on the back of the DIGIPASS device, for example 9-712345-6 .
© 2009 VASCO Data Security 108
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.4.2
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.
© 2009 VASCO Data Security
Image 40: Auto-Assignment Process
109
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.4.3
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.
© 2009 VASCO Data Security
Image 41: Manual Assignment Process
110
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.4.4
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
.
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
(www.axsguard.com), 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.
© 2009 VASCO Data Security 111
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.5
Virtual DIGIPASS
17.5.1
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 3.5.3.5
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.
17.5.2
Virtual DIGIPASS Assignment Options
With the introduction of Virtual DIGIPASS (see section 17.2.4
), 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
DIGIPASS
Primary
DIGIPASS
DIGIPASS (temporarily disallowed)
Primary Virtual DIGIPASS
Backup
None User must log in using a DIGIPASS device.
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.
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.
N/A User is assigned a Virtual DIGIPASS and must log in using it.
17.5.3
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 12 .
© 2009 VASCO Data Security 112
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.5.4
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 3.5.3.5
For more information on Virtual DIGIPASS use during an authentication attempt, see section 3.5.3
17.5.5
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
© 2009 VASCO Data Security 113
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
DIGIPASS device again, the administrator must reset the time period to allow re-use of the Backup Virtual
DIGIPASS.
Max. Uses/User: s et 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.
© 2009 VASCO Data Security 114
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
DIGIPASS
17.5.6
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
Backup Virtual DIGIPASS disabled for all - enabled for individual Users as required.
Pro
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.
© 2009 VASCO Data Security 115
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Client Components
18 Client Components
18.1
Overview
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.
18.2
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)
© 2009 VASCO Data Security 116
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
18.3
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.
18.3.1
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.
© 2009 VASCO Data Security 117
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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-CHAP2.
18.3.2
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 authentica tion 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.
18.4
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,
© 2009 VASCO Data Security 118
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Server Components
19 Server Components
19.1
Overview
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
information.
19.2
Automatic Server Component Creation
19.2.1
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 3.6.3.3
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.
19.2.2
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 15 .
© 2009 VASCO Data Security 119
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Server Components
19.3
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
on how to modify a license. For more information on license types, please see section
For information on Client Licenses, please refer to section 18.4
© 2009 VASCO Data Security 120
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Policies
20 Policies
20.1
Overview
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
components respectively).
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.
20.2
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 3.4.4
DIGIPASS Policy settings, such as whether Auto- or Self-Assignment is possible and the Grace Period (see
Application settings for 1- and 2-step Challenge/Response authentication and for Virtual and Backup Virtual
Some Policy properties can be overruled in User or DIGIPASS records (see sections 16
aXsGUARD Identifier Administrator's Reference Guide for a full listing of the fields available for configuring policies.
© 2009 VASCO Data Security 121
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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:
© 2009 VASCO Data Security 122
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
© 2009 VASCO Data Security
Policies
123
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
21.2
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.
© 2009 VASCO Data Security 124
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
21.3
Master Domain and Practical Uses
21.3.1
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
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
© 2009 VASCO Data Security 125
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Organization
Image 45: User ID and Domain Resolution
21.3.2
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 = '[email protected]
': the resulting user ID is 'martin' while the domain is
'mycompany.com'.
© 2009 VASCO Data Security 126
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
information on policy inheritance.)
Please see the aXsGUARD Identifier Installation Guide for a listing of the default settings required.
21.4
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.
© 2009 VASCO Data Security 127
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
21.5
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).
© 2009 VASCO Data Security 128
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
© 2009 VASCO Data Security 129
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
© 2009 VASCO Data Security 130
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
© 2009 VASCO Data Security 131
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
22.2
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.
© 2009 VASCO Data Security 132
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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.
22.3
Custom Reports
22.3.1
Overview
Customizing reports requires configuring the following, which we explain further in the sections below:
Report Type
Data Source
Grouping Level
Query
Permissions
Template
© 2009 VASCO Data Security 133
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Reporting
22.3.2
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
22.3.3
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.
22.3.4
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.
© 2009 VASCO Data Security 134
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
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
© 2009 VASCO Data Security 135
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Reporting
22.3.5
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'
22.3.6
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.
© 2009 VASCO Data Security 136
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Reporting
22.3.7
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.
22.4
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
© 2009 VASCO Data Security 137
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
© 2009 VASCO Data Security
Rescue Tool Section
Overview............................................................. 23.1
Access................................................................ 23.2
Options............................................................... 23.3
138
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Rescue Tool
23 Rescue Tool
23.1
Overview
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.
23.2
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.
23.3
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 6.4
© 2009 VASCO Data Security 139
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
reboot or shut down the aXsGUARD Identifier.
Rescue Tool
© 2009 VASCO Data Security
Image 53: Start and Network Menus with the Rescue Tool.
140
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Index
Alphabetical Index
Accessing Further Reading...................................................................... 15
Administration Interfaces................................................................... 21, 58
Administration Web Interface....................................................... 21, 58, 60
Administrative Privileges....................................................................... 104
Administrative Users............................................................................... 58
Application Service Providers................................................................... 17
Auditing................................................................................................. 59
Audit Filter...................................................................................... 77
Audit Message Types....................................................................... 76
Live Audit Viewer............................................................................. 76
Authentication Process........................................................................... 26 aXsGUARD Identifier............................................................................... 17
Architecture.................................................................................... 20
Back-end Authentication......................................................................... 43
Active Directory .............................................................................. 50
Authentication Settings..................................................................... 44
Back-end Servers............................................................................ 60
Domain-Specific Back-end Servers................................................... 48
Fail-over Strategy............................................................................. 47
LDAP........................................................................................ 43, 50
Multiple Back-end Servers................................................................ 47
Novell e-Directory............................................................................ 52
Policies........................................................................................... 54
Protocol.......................................................................................... 43
RADIUS..................................................................................... 43, 48
RADIUS attributes............................................................................ 43
RADIUS Services.............................................................................. 49
Server Records................................................................................ 47
Backup and Restore......................................................................... 59, 71
Backup Virtual DIGIPASS.............................................................................
Guidelines for Use.......................................................................... 120
Changing Customer Information.............................................................. 68
Citrix Web Interface........................................................................ 27, 122
Client Component............................................................................. 27, 60
Client Component License..................................................................... 123
Client Components............................................................................... 121
Communication Protocols....................................................................... 21
Configuration Tool...................................................................... 21, 58, 59
Configuration Wizard.............................................................................. 64
Convenience Layer........................................................................... 17, 59
Creating User Accounts Manually........................................................... 101
Custom Reports................................................................................... 138
Default Domain Processing..................................................................... 28
DIGIPASS........................................................................... 17, 18, 60, 105
Actions......................................................................................... 109
Assigning...................................................................................... 108
Assignment Limitations.................................................................. 116
Auto-Assignment............................................................. 29, 107, 114
Client PIN...................................................................................... 105
Dynamic User Registration.............................................................. 102
Import Wizard................................................................................ 108
Importing...................................................................................... 108
Linked User Account...................................................................... 102
Location........................................................................................ 133
Lookup and Checks......................................................................... 33
Manual Assignment....................................................................... 115
Moving.......................................................................................... 132
Record.......................................................................................... 109
Runtime Information....................................................................... 110
Searching...................................................................................... 109
Self-Assignment............................................. 29, 42, 43, 60, 107, 112
Server PIN..................................................................................... 106
User Account................................................................................. 101
User Account Creation.................................................................... 101
User Account Lookup....................................................................... 29
User Account Management............................................................. 103
User accounts................................................................................. 60
Disaster Recovery................................................................................... 96
© 2009 VASCO Data Security 141
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Index
Domain......................................................................................... 60, 129
Domain Root........................................................................................ 134
Dynamic User Registration............................... 27, 29, 33, 43, 60, 102, 114
Electronic Signatures........................................................................ 16, 21
First Time Set-up................................................................................... 63
Further Reading..................................................................................... 14
Grace Period.......................................................... 35, 107, 112, 114, 115
Host Code........................................................................................ 16, 55
IDENTIKEY Server................................................................................... 18
IIS Authentication........................................................................... 21, 121
IIS Modules.................................................................................... 55, 123
Installation....................................................................................... 59, 63
IP address, change................................................................................. 67
LDAP User Synchronization...................................................... 59, 101, 102
LDAP User Synchronization.........................................................................
Creating and Updating User Account Properties.................................. 88
Deleting User Accounts.................................................................... 90
Frequency....................................................................................... 90
Multiple Synchronization Profiles....................................................... 90
Process.......................................................................................... 86
Profile ID......................................................................................... 87
Source and Destination Hierarchies................................................... 91
Special Cases.................................................................................. 93
Synchronization Profiles.................................................................... 86
Licence.....................................................................................................
Client............................................................................................ 123
Client Component............................................................................ 23
Commercial............................................................................... 22, 67
DEMO....................................................................................... 22, 67
Registration, without on-site Internet Access..................................... 67
Server Components........................................................................ 125
Upgrade.......................................................................................... 67
Linked User Account....................................................................... 34, 102
Local Authentication......................................................................... 29, 32
Logging.....................................................................................................
Live Log Viewer............................................................................... 73
Log Filter......................................................................................... 74
Log Levels....................................................................................... 73
Remote Syslog................................................................................ 73
Manual Configurations............................................................................ 64
Master Domain......................................................................... 28, 61, 130
Message Delivery Component............................................................ 59, 82
One Time Password............................................................................... 16
Challenge/Response................................................................. 36, 108
Request Method.............................................................................. 40
Response Only......................................................................... 35, 107
Virtual DIGIPASS...................................................................... 39, 117
Organizational Units........................................................................ 60, 129
Outlook Web Access....................................................................... 27, 122
Password Autolearn................................................................................ 45
Password Replacement............................................................... 43, 45, 60
Policy............................................................................................ 60, 126
Back-end Authentication.................................................................. 43
DIGIPASS Restrictions...................................................................... 34
Effective Settings........................................................................... 127
Identifying....................................................................................... 27
Inheritance.................................................................................... 127
Local Authentication......................................................................... 32
Properties..................................................................................... 126
Record.................................................................................... 27, 126
Port for connecting to VSC...................................................................... 24
RADIUS............................................................................ 27, 60, 122, 125
RADIUS Attributes.................................................................................. 46
RADIUS Authentication............................................................................ 21
Reboot.................................................................................................. 59
Registration........................................................................ 22, 59, 66, 124
Remote Support............................................................................... 59, 84
Replacement aXsGUARD Identifier........................................................... 68
Replication..................................................................................... 59, 124
Replication................................................................................................
Auditing.......................................................................................... 98
Connection Handling........................................................................ 98
© 2009 VASCO Data Security 142
aXsGUARD Identifier 3.0.2.0 Product Guide v1.5
Index
Firewalls......................................................................................... 97
Forwarding...................................................................................... 98
Multiple Changes............................................................................. 98
Process.......................................................................................... 97
Status............................................................................................. 99
Wizard............................................................................................ 96
Reporting....................................................................................... 60, 137
Data Source.................................................................................. 139
Formatting Templates.................................................................... 142
Grouping Level.............................................................................. 139
Query........................................................................................... 141
Report Generation.......................................................................... 142
Report Permissions........................................................................ 141
Report Type................................................................................... 139
Request Method..................................................................................... 40
Rescue Tool............................................................................... 21, 58, 61
Change and view network settings.................................................. 145
Reboot.......................................................................................... 145
Reset Sysadmin Password.............................................................. 144
Reset to Factory Default................................................................. 144
Reset Admin@master Password.............................................................. 59
Reset Sysadmin Password......................................................... 59, 61, 144
Reset to Factory Default.......................................................................... 61
Scenarios.............................................................................................. 22
SEAL..................................................................................................... 21
Server Components........................................................................ 60, 124
Shut Down..................................................................................... 59, 145
Simple Name Resolution......................................................................... 28
SOAP................................................................................ 21, 22, 60, 121
Software Provisioning............................................................................. 21
Static Password............................................................ 40, 43, 44, 60, 103
Statistics......................................................................................... 59, 79
Filtering.......................................................................................... 80
Stored Password Proxy........................................................................... 44
Support................................................................................................. 23
Sysadmin.............................................................................................. 61
System Actions...................................................................................... 59
Tracing.................................................................................................. 85
Updating.......................................................................................... 59, 69
User Attribute settings............................................................................ 55
User ID and Domain Resolution........................................................ 27, 130
User Records, Importing........................................................................ 102
VACMAN............................................................................................... 16
VASCO.................................................................................................. 15
Contact Information.......................................................................... 15
Service Center......................................................... 24, 59, 66, 69, 84
Virtual DIGIPASS................................................................. 33, 38, 82, 117
Backup.................................................................... 39, 117, 118, 120
Keyword.......................................................................................... 40
Limiting Use.................................................................................. 118
Wizard......................................................................................................
Configuration .................................................................................. 64
DIGIPASS Import............................................................................ 108
Registration..................................................................................... 66
Replication...................................................................................... 96
© 2009 VASCO Data Security 143
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
