Page 1 Product Guide aXsGUARD AXSGuard ConfigurationTool 2009 Product Guide aXsGUARD Identifier aXsGUARD Identifier aXsGUARD Identifier DIGIPASS ConfigurationTool v1.5 aXsGUARD Identifier Product Guide 3.0.2.0...
Page 2 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.
Page 3: Table Of Contents
About VASCO................................ 15 Contact Information.............................. 15 aXsGUARD Identifier............................. 16 Overview................................16 VASCO's Authentication Solution.......................... 1 6 What is the aXsGUARD Identifier? ........................17 What is the IDENTIKEY Server?..........................18 What is a DIGIPASS?............................. 18 Structure of the aXsGUARD Identifier........................1 9 2.6.1 Overview................................
Page 4 Table of Contents aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 3.5.1 Overview................................32 3.5.2 Local Authentication Policy Setting........................32 3.5.3 Authentication with DIGIPASS........................... 3 3 3.5.3.1 Overview................................33 3.5.3.2 DIGIPASS Lookup and Checks..........................33 3.5.3.3 Response Only............................... 35 3.5.3.4 Challenge/Response...............................36 3.5.3.5 Virtual DIGIPASS Login............................38 3.5.3.6...
Page 5 Change in IP Address............................6 7 Upgrade from a DEMO to Commercial License..................... 6 7 Replacement of aXsGUARD Identifier ........................68 Change of Customer Information.......................... 6 8 Restoring a backup from another aXsGUARD Identifier..................6 8 Updating............................... 69 Overview................................69 Updating Process..............................6 9 Updating Infrastructure............................
Page 6 14.9 Special Cases............................... 93 15 Replication..............................95 15.1 Overview................................95 15.2 Common Replications ............................95 15.2.1 First and Second aXsGUARD Identifiers......................9 5 15.2.2 First, Second and Disaster Recovery aXsGUARD Identifiers................96 15.3 Replication Wizard..............................96 15.4 Replication and Firewalls............................97 15.5 Replication Process..............................
Page 7 Table of Contents aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 15.5.3 Multiple Changes to a Single Data Record......................9 8 15.5.4 Connection Handling............................9 8 15.6 Replication Monitoring ............................98 15.6.1 Replication Auditing............................98 15.6.2 Replication Status............................9 9 ADMINISTRATION WEB INTERFACE SECTION....................100 16 DIGIPASS User Accounts..........................
Page 8 Table of Contents aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 17.4.4 DIGIPASS Assignment Limitations........................1 16 17.5 Virtual DIGIPASS..............................117 17.5.1 Overview................................ 117 17.5.2 Virtual DIGIPASS Assignment Options......................117 17.5.3 Virtual DIGIPASS Configuration ........................117 17.5.4 Implementation Decision..........................1 18 17.5.5 Limiting Use of Virtual DIGIPASS........................1 18 17.5.6 Backup Virtual DIGIPASS Guidelines for Use....................
Page 9 Table of Contents aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 22 Reporting..............................137 22.1 Overview................................137 22.2 Reporting Structure and Purposes........................1 37 22.3 Custom Reports..............................138 22.3.1 Overview................................ 138 22.3.2 Report Type..............................139 22.3.3 Data Source..............................139 22.3.4 Grouping Level............................... 139 22.3.5 Query................................
Page 10 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..........................
Page 11 Table of Contents aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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......................................
Page 12 Table of Contents aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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....................
Page 13: Introduction Section
Identifier 3.0.2.0 Product Guide v1.5 Introduction Section Introduction............. aXsGUARD Identifier..........© 2009 VASCO Data Security...
Page 14: Introduction
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.
Page 15: About Vasco
Identifier 3.0.2.0 Product Guide v1.5 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.
Page 16: 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.
Page 17: What Is The Axsguard Identifier
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...
Page 18: What Is The Identikey Server
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).
Page 19: Structure Of The Axsguard Identifier
For more information, please visit www.vasco.com. Structure of the aXsGUARD Identifier 2.6.1 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...
Page 20: Communication Protocols
Identifier aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 We have already described the aXsGUARD Identifier convenience layer and the IDENTIKEY in sections 2.3 and 2.4 respectively. The three user interfaces shown in Image 2 are the aXsGUARD Identifier: Configuration Tool for system administrators, for installation and maintenance.
Page 21: Scenarios
2.7.3 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.
Page 22: Client Component Licensing
If you are unable to solve your problem with the Knowledge Base, please contact the company which sold you the VASCO product. 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...
Page 23: Vasco Service Center
TCP 443 to sc.vasco.com. Your organization may prefer this port not to be permanently open for the automatic connection on boot-up of the aXsGUARD Identifier to the VASCO Service Center (see section 13). In this case, the port needs to be opened specially for connection, e.g.
Page 24: User Authentication Section
Identifier 3.0.2.0 Product Guide v1.5 User Authentication Section Authentication Process Overview......Identifying the Component Record......Identifying a Policy..........DIGIPASS User Account Lookup and Checks..Local Authentication..........Back-end Authentication........Authorization Profiles/Attributes......Host Code Generation..........© 2009 VASCO Data Security...
Page 25: User Authentication Process
Identifier 3.0.2.0 Product Guide v1.5 User Authentication Process 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.
Page 26: Identifying The Component Record
Identifier 3.0.2.0 Product Guide v1.5 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 –...
Page 27 User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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: If entry fields for the User ID and Domain are separate, name resolution ends and authentication continues.
Page 28: Digipass User Account Lookup
Identifier 3.0.2.0 Product Guide v1.5 3.4.3 DIGIPASS User Account Lookup The aXsGUARD Identifier checks that the User attempting to log in has a DIGIPASS User account in the aXsGUARD Identifier data store. The User ID and Domain Resolution described above determines the search criteria to look up the DIGIPASS User account.
Page 29 User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Image 6: Dynamic User Registration Process © 2009 VASCO Data Security...
Page 30: Local Authentication
Overview Local Authentication is a term used to describe the aXsGUARD Identifier authenticating a User based on information in its data store. Typically the DIGIPASS One Time Password (OTP) is required, but in other cases a static password may be sufficient.
Page 31: Digipass Lookup And Checks
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.
Page 32 User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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.
Page 33: Response Only
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.
Page 34 1-Step Login With 1-step Challenge/Response OTP Login (illustrated to the left in the image below): A random Challenge (of length configured for all users) generated by the aXsGUARD Identifier is presented in the client application login window. The User enters the Challenge into their DIGIPASS device.
Page 35: Virtual Digipass Login
User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Image 9: 1-step (left) and 2-step (right) Challenge/Response Login 3.5.3.5 Virtual DIGIPASS Login We explain here the authentication process with a Virtual DIGIPASS. For more information on Virtual DIGIPASS, see also section 17.5.
Page 36 Method and Request Keyword settings explained in section 3.5.3.6). 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).
Page 37: Request Method And Keyword
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.
Page 38: Static Password Verification
User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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, cross- referencing the numbers in the image: If a User account does not exist, the request is passed on to the Dynamic User Registration check in step 5.
Page 39: Self-Assignment
User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Image 11: Static Password Authentication Flow 3.5.4.2 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.
Page 40: Back-End Authentication
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...
Page 41: Back-End Authentication And Static Password
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.
Page 42: Password Autolearn
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.
Page 43: Stored Static Password And Radius Attributes
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).
Page 44: Back-End Server Records
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.
Page 45: Domain-Specific Back-End Servers
Back-end server records may be configured for use with a specific Domain. This may be useful when multiple back-end servers exist with different groups of User records on each. When the aXsGUARD Identifier needs to choose a back-end server, it searches for records in the domain identified by the User ID and Name Resolution process (see section 3.4.2).
Page 46 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.
Page 47: Ldap Back-End Authentication
Identifier for LDAP back-end authentication are: Microsoft Active Directory Novell e-Directory. These are explained in the following sections. 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.
Page 48 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.
Page 49: Novell E-Directory Back- End Authentication
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...
Page 50 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).
Page 51: Policies
3.6.6.3 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 interface (see section on the administration interfaces).
Page 52: Authorization Profiles/Attributes
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.
Page 53: Using A Host Code
User Authentication Process aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 3.8.2 Using a Host Code A DIGIPASS Host Code is computed as follows: The DIGIPASS device generates a One Time Password, and splits it into two parts. The first part is used for end user authentication.
Page 54: Administrative Interfaces Section
Identifier 3.0.2.0 Product Guide v1.5 Administrative Interfaces Section Overview............... Default Administrative Users........Configuration Tool..........Administration Web Interface......... Rescue Tool............© 2009 VASCO Data Security...
Page 55: Administration Interfaces
Identifier 3.0.2.0 Product Guide v1.5 Administration Interfaces Overview In chapters 1 and 2 we introduced the VASCO authentication solution and the structure and functionality of the aXsGUARD Identifier. In chapter 3, we have explained the authentication process in depth.
Page 56: Configuration Tool
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 (see sections and 9).
Page 57: Administration Web Interface
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.
Page 58: Rescue Tool
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.
Page 59: Configuration Tool Section
Identifier 3.0.2.0 Product Guide v1.5 Configuration Tool Section Installation Configurations........Registration.............. Updating..............Backup and Restore..........Logging..............Auditing..............Statistics..............Message Delivery Component......... Remote Support............. LDAP User Synchronization........Replication............. © 2009 VASCO Data Security...
Page 60: Installation Configurations
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: Changing a client workstation IP address to within the specified IP address range for the aXsGUARD Identifier.
Page 61: Configuration Wizard
Identifier 3.0.2.0 Product Guide v1.5 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:...
Page 62: Registration
Registration 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.
Page 63: Registration Without On-Site Internet Access
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.
Page 64: Change Of Customer Information
Restoring a backup created by a different appliance requires re-registration. The backup must first be restored, and then re-registration completed. For practical guidance on restoring a backup, please refer to the aXsGUARD Identifier Installation Guide, 'Backup and Restore' section. For an explanation of the concepts of Backup and Restore, please refer to section in this manual.
Page 65: Updating
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.
Page 66: Backup And Restore
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.
Page 67: Logging
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.
Page 68: Local: Live Log Viewer
Identifier 3.0.2.0 Product Guide v1.5 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).
Page 69: Log Filter
Logging aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Table 8: Log Levels Type Description Critical A system-critical warning that services may not be running. Please follow the support procedure in section 2.8 ) Error Error condition: action required, although services may still be running.
Page 70: Table 9: Log Filter Fields
Level at least Click on the drop down menu to select one of the levels, e.g. error or warning. Only logs referencing this level are displayed. For a list of the log levels, please refer to the aXsGUARD Identifier Administration Reference Guide.
Page 71: 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.
Page 72: Audit Filter
Auditing aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Table 10: Audit Message Types Type Description Error The message contains details about a system, configuration, licensing or some internal error. Errors do not include normal processing events such as failed logins. Warning Warning messages contain details about potential problems within the system.
Page 73: Table 11: Audit Filter Fields
Enter an error code. Only records with a matching error code are displayed. For a list of possible error Code contains 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.
Page 74: Statistics
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 ©...
Page 75: Statistics Filtering
Statistics aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 CPU time Image 24: CPU Statistics Interface Image 25: Interface Statistics 11.3 Statistics Filtering Filtering specific information from some of the statistics data is also possible. For example, the following two images demonstrate the CPU usage for the Administration Web Interface and a specific service.
Page 76 Statistics aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Image 27: CPU Time for Administration Web Interface © 2009 VASCO Data Security...
Page 77: Message Delivery Component
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.
Page 78: Configuration
(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...
Page 79: Remote Support
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.
Page 80: Tracing
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).
Page 81: Ldap User Synchronization
Configuration Tool and supports automatic creation and LDAP User Synchronization 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,...
Page 82: Synchronization Profile Ids
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.
Page 83: Creating And Updating User Accounts
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). The User Account does not exist on the aXsGUARD Identifier. In this case the User Account is created and the Synchronization Profile ID added.
Page 84 LDAP User Synchronization aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Image 30: LDAP Synchronization to create or update an aXsGUARD Identifier User Account © 2009 VASCO Data Security...
Page 85: Deleting User Accounts
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).
Page 86: Managing Source And Destination Hierarchies
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.
Page 87 LDAP User Synchronization aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Image 31: Possible source and destination hierarchy mapping with a single Synchronization Profile Image 32: Example source and destination hierarchy mapping with three Synchronization Profiles © 2009 VASCO Data Security...
Page 88: Special Cases
(i.e. as in point 1 above). 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).
Page 89 LDAP User Synchronization aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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'.
Page 90: Replication
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.
Page 91: First, Second And Disaster Recovery Axsguard Identifiers
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.
Page 92: Replication And Firewalls
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.
Page 93: 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.
Page 94: 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).
Page 95 Identifier 3.0.2.0 Product Guide v1.5 Web Administration Interface Section DIGIPASS User Accounts........DIGIPASS..............Client Components..........Server Components..........Policies..............Organization............Reporting............... © 2009 VASCO Data Security...
Page 96: Digipass User Accounts
Identifier 3.0.2.0 Product Guide v1.5 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.
Page 97: Importing User Records
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.
Page 98: User Account Settings
DIGIPASS User Accounts aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 DIGIPASS record Attached to main User account DIGIPASS User DIGIPASS User User Account Link account 1 account 2 User can log into either account using the same DIGIPASS Image 38: User Account Link 16.4...
Page 99: Searching For User Accounts
Only DIGIPASS User Accounts with administrative permissions can use the Administration Web Interface to configure the aXsGUARD Identifier. Administrative privileges are assigned to DIGIPASS User Accounts and therefore a DIGIPASS User Account is needed for each administrator. The default administrative accounts are listed in section 4.2.
Page 100: 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.
Page 101: Server Pin
DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 PIN Change allows a User to change their PIN as desired. 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.
Page 102: Grace Period
DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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).
Page 103: 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...
Page 104: Searching For Digipass Records
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.
Page 105: Viewing Digipass Runtime Information
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.
Page 106: Digipass Assignment Options
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.
Page 107: Self-Assignment
Account. The User must log in and include the serial number, static password and One Time Password. This informs the aXsGUARD Identifier of the assignment, and provided that the User enters the details correctly, a link is made between the DIGIPASS record and the User Account (see image below). A Grace Period is not used for this method (see section 17.2.3).
Page 108: Self-Assignment Data
DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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...
Page 109: Auto-Assignment
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.
Page 110: Manual Assignment
DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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.
Page 111: Digipass Assignment Limitations
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.
Page 112: Virtual Digipass
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 .
Page 113: Implementation Decision
DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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.
Page 114 DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 DIGIPASS device again, the administrator must reset the time period to allow re-use of the Backup Virtual DIGIPASS. Max. Uses/User: set a maximum number of times a User may request an OTP using the Backup Virtual DIGIPASS.
Page 115: Backup Virtual Digipass Guidelines For Use
DIGIPASS aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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?
Page 116: 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.
Page 117: Component Lookup And Verification
Identifier 3.0.2.0 Product Guide v1.5 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.
Page 118: Iis Module
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 authentication request to the aXsGUARD Identifier. For an IIS Module Component the following component checks are made:...
Page 119: 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.
Page 120: 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.
Page 121: Policies
Some Policy properties can be overruled in User or DIGIPASS records (see sections and 17). Please refer to the aXsGUARD Identifier Administrator's Reference Guide for a full listing of the fields available for configuring policies. © 2009 VASCO Data Security...
Page 122: Policy Inheritance
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.
Page 123 Policies 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...
Page 124: 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.
Page 125: Master Domain And Practical Uses
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).
Page 126: Practical Use
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. User ID = 'martin@mycompany.com': the resulting user ID is 'martin' while the domain is 'mycompany.com'.
Page 127: Moving Digipass User Accounts And Digipass
Master Domain being used when a domain name cannot be found in the aXsGUARD Identifier. The default domain needs to be configured in the Base Policy of the aXsGUARD Identifier. All policies below the Base Policy automatically inherit this setting. (Changes to the default domain setting in any policy are inherited by child policies unless overruled;...
Page 128: Location Of Digipass Records
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 Search Upwards in Organizational Unit hierarchy Unit.
Page 129: Typical Digipass Location Models
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.
Page 130 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.
Page 131 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.
Page 132: 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 Administration Interfaces) using the live audit viewer.
Page 133: Custom Reports
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.
Page 134: Report Type
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.
Page 135 Reporting aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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...
Page 136: Query
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.
Page 137: Formatting Templates
Reporting aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 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.
Page 138: Rescue Tool Section
Identifier 3.0.2.0 Product Guide v1.5 Rescue Tool Section Overview............. 23.1 Access..............23.2 Options............... 23.3 © 2009 VASCO Data Security...
Page 139: Rescue Tool
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...
Page 140 Rescue Tool aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 reboot or shut down the aXsGUARD Identifier. Image 53: Start and Network Menus with the Rescue Tool. © 2009 VASCO Data Security...
Page 141 Index aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Alphabetical Index Accessing Further Reading..............15 Client Component License..............123 Administration Interfaces..............21, 58 Client Components................121 Administration Web Interface............21, 58, 60 Communication Protocols............... 21 Administrative Privileges............... 104 Configuration Tool..............21, 58, 59 Administrative Users................
Page 142 Index aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Domain..................60, 129 Log Filter..................74 Domain Root..................134 Log Levels..................73 Dynamic User Registration....... 27, 29, 33, 43, 60, 102, 114 Remote Syslog................73 Electronic Signatures................ 16, 21 Manual Configurations................64 First Time Set-up................... 63 Master Domain.................
Page 143 Index aXsGUARD Identifier 3.0.2.0 Product Guide v1.5 Firewalls..................97 SOAP................21, 22, 60, 121 Forwarding..................98 Software Provisioning................21 Multiple Changes................98 Static Password............40, 43, 44, 60, 103 Process..................97 Statistics..................59, 79 Status..................... 99 Filtering..................80 Wizard.................... 96 Stored Password Proxy................

Vasco aXsGUARD Product Manual

1 Introduction

2 Axsguard Identifier

3 User Authentication Process

4 Administration Interfaces

5 Installation Configurations

6 Registration

7 Updating

8 Backup and Restore

9 Logging

10 Auditing

11 Statistics

12 Message Delivery Component

13 Remote Support

14 LDAP User Synchronization

15 Replication

16 DIGIPASS User Accounts

17 Digipass

18 Client Components

19 Server Components

20 Policies

21 Organization

22 Reporting

23 Rescue Tool

Quick Links

Need help?

Questions and answers

Subscribe to Our Youtube Channel

Related Manuals for Vasco aXsGUARD

Summary of Contents for Vasco aXsGUARD

Table of Contents