IG 91 Deployment Guide

Entrust®
IdentityGuard 9.1
Deployment Guide
Document issue: 1.0
Date of Issue: August 2008

Copyright © 2008 Entrust. All rights reserved.
Entrust is a trademark or a registered trademark of Entrust,

Inc. in certain countries. All Entrust product names and
logos are trademarks or registered trademarks of Entrust,
Inc. in certain countries. All other company and product
names and logos are trademarks or registered trademarks
of their respective owners in certain countries.
This information is subject to change as Entrust reserves

the right to, without notice, make changes to its products
as progress in engineering or manufacturing methods or
circumstances may warrant.
Export and/or import of cryptographic products may be

restricted by various regulations in various countries.
Export and/or import permits may be required.
2 IdentityGuard 9.1 Deployment Guide

TOC
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Documentation conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Note and Attention text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Obtaining documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Documentation feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Obtaining technical assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Telephone numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Email address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
About Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Why use Entrust IdentityGuard? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Challenges of first-factor authentication . . . . . . . . . . . . . . . . . . . . . . 19
Benefits of multifactor authentication . . . . . . . . . . . . . . . . . . . . . . . . 19
Identities become difficult to steal . . . . . . . . . . . . . . . . . . . . . . . 19
Stolen identities become difficult to reuse . . . . . . . . . . . . . . . . . 19
Authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
First-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Second-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . 20
Mutual authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Entrust IdentityGuard components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Entrust IdentityGuard server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Entrust IdentityGuard Authentication service . . . . . . . . . . . . . . . 25
Entrust IdentityGuard Administration service . . . . . . . . . . . . . . . 26
Administration interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Properties editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Master user shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
First-factor authentication application . . . . . . . . . . . . . . . . . . . . . . . 27
Entrust IdentityGuard Radius proxy . . . . . . . . . . . . . . . . . . . . . . . . . 27
Entrust IdentityGuard Desktop for Microsoft Windows . . . . . . . . . . 28
Entrust IdentityGuard Remote Access Plug-in . . . . . . . . . . . . . . . . . . 29
Entrust IdentityGuard ISAPI filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Client applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Entrust IdentityGuard users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Microsoft Windows desktop users . . . . . . . . . . . . . . . . . . . . . . . 31
Routing and Remote Access Service (RRAS) users . . . . . . . . . . . 31
VPN users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Web users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Overview of available authentication methods . . . . . . . . . . . . . . . . . . . . . . 34
First-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Radius server authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
External authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Second-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Grid authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Determining the grid challenge size . . . . . . . . . . . . . . . . . . . . . . 45
Passcode lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Knowledge-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
One-time password (OTP) authentication . . . . . . . . . . . . . . . . . . . . 49
One-time password delivery systems . . . . . . . . . . . . . . . . . . . . . 51
Mutual authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Grid serial number or grid location replay . . . . . . . . . . . . . . . . . . . . . 52
Image and message replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Computer registration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Sources of machine fingerprint data . . . . . . . . . . . . . . . . . . . . . . . . . 57
Basic Web browser without client-side software. . . . . . . . . . . . . 57
Basic Web browser with client-side software . . . . . . . . . . . . . . . 60
4 IdentityGuard 9.0 Deployment Guide Document issue: 1.0

Web application (server-side) . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Setting risk policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Setting authentication policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
IP geolocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Blacklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Temporary PIN authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Using personal verification numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Planning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Planning: initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Entrust IdentityGuard policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
System monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Other precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Planning administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Assigning master users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Assigning administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Planning user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Alias and user ID requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Aliases in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . 76
Training users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Providing services to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Locking out users based on authentication method . . . . . . . . . . . . . 77
Suspending users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Group requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Groups in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . . . 79
Groups in an enterprise deployment . . . . . . . . . . . . . . . . . . . . . . . . 79
Analyzing your company’s group needs . . . . . . . . . . . . . . . . . . . . . . 80
Group implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5
Deployment considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Web integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Microsoft Windows integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
VPN remote access integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Wireless Access Portal integration . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Application considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Integrating with existing user management systems . . . . . . . . . . . . . 87
Using shared secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Selecting a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Directory repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Database repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Performance and maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Performance testing strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Backing up, restoring and migrating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
High availability and disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Entrust IdentityGuard Server hot-standby or load-balancing . . . . . . . 94
Hot-standby scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Load-balancing scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Repository failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Local repository failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Geographically-dispersed repository failover . . . . . . . . . . . . . . . 97
Radius server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Switching over to Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Deploying grid authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

Grid requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Grid size and format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Grid size impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Grid format impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Grid lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Varying the grid challenge size . . . . . . . . . . . . . . . . . . . . . . . . . 107
Challenge algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Grid card production models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Produce-and-assign model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Produce-and-assign grids for existing users . . . . . . . . . . . . . . . 110
Produce-and-assign grids for new users. . . . . . . . . . . . . . . . . . 112
Preproduction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Forcing grid card activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Physical grid card security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Physical grid card production options . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
In-house grid card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Typical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Outsourced grid card production . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Typical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Entrust IdentityGuard grid card production . . . . . . . . . . . . . . . . . . 121
Typical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Grid card production cost factors . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Secure file transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Secure email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Secure FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Automating processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Deploying token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Using tokens for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Token lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Entering token values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Token deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Assigning tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Token self-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Forcing token activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Physical token security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7
Deploying knowledge-based authentication . . . . . . . . . . . . . . . . . . . . . . . .129
Question requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Sources of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Creating good questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Selecting a set of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Challenge accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Setting how many correct answers are required . . . . . . . . . . . . 135
Setting the accuracy of answers . . . . . . . . . . . . . . . . . . . . . . . . 135
Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
User life cycle management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

Life cycle management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
User enrollment from LDAP user repository . . . . . . . . . . . . . . . . . . 142
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Delivery and activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Remove cancelled grid cards and tokens . . . . . . . . . . . . . . . . . . . . 151
Remove inactive grid cards and tokens . . . . . . . . . . . . . . . . . . . . . . 151
Remove unassigned grid cards and tokens . . . . . . . . . . . . . . . . . . . 151
Synchronize with the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Update images used for mutual authentication . . . . . . . . . . . . . . . 152
Update personal verification numbers . . . . . . . . . . . . . . . . . . . . . . 152
Update IP geographical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Entrust IdentityGuard baseline architectures . . . . . . . . . . . . . . . . . . . . . . . .153

Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Web access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Web access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Web access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Web access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
VPN remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
VPN remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
VPN remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
VPN remote access - high availability . . . . . . . . . . . . . . . . . . . . . . . 162
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Wireless access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Wireless access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Wireless access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Wireless access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Microsoft Windows remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Microsoft Windows remote access - evaluation . . . . . . . . . . . . . . . 168
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Microsoft Windows remote access - standard . . . . . . . . . . . . . . . . 169
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Microsoft Windows remote access - high availability . . . . . . . . . . . 170
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Generic remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Generic remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . 172
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Generic remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Generic remote access - high availability . . . . . . . . . . . . . . . . . . . . 174
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9
Microsoft Windows desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Microsoft Windows desktop - evaluation . . . . . . . . . . . . . . . . . . . . 176
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Microsoft Windows desktop - standard . . . . . . . . . . . . . . . . . . . . . 177
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Microsoft Windows desktop - high availability . . . . . . . . . . . . . . . . 178
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Grid card usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181

Entrust IdentityGuard grid card usability study . . . . . . . . . . . . . . . . . . . . . 182
Usability test summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Usability test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
General guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Grid card design and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Use of color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Design of the grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Grid authentication implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Web login challenge method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Mutual authentication (through displaying a authentication secret) 187
Temporary PIN length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189

About
About this guide

This guide discusses how to deploy Entrust IdentityGuard in an enterprise or
consumer environment.
Note: The guide is not intended to be an exhaustive list of all the activities and
tasks required to deploy Entrust IdentityGuard. It acts as a guide for the team
responsible for deployment.
This chapter contains the following topics:

• “Documentation conventions” on page 12
• “Related documentation” on page 13
• “Obtaining documentation” on page 14
• “Obtaining technical assistance” on page 15
11
Documentation conventions
Table 1 contains the typographic conventions that appear in this guide:
Table 1: Typographic conventions
Convention Purpose Example

Bold text Indicates graphical user Click Next.
(other than interface elements and
headings) wizards
Italicized text Used for book or Entrust TruePass 7.0 Deployment Guide
document titles
Blue text Used for hyperlinks to Entrust TruePass supports the use of many types
other sections in the of digital ID.
document
Underlined blue Used for Web links For more information, visit our Web site at
text www.entrust.com.
Courier type Indicates installation Use the entrust-configuration.xml file
paths, file names, to change certain options for Verification Server.
Windows registry keys,
commands, and text you
must enter
Angle brackets Indicates variables (text By default, the entrust.ini file is located in
you must replace with <install_path>/conf/security/entrust.
<>
your organization’s ini.
correct values)
Square brackets Indicates optional dsa passwd [-ldap]
parameters
[courier type]
Note and Attention text

Throughout this guide, there are paragraphs set off by ruled lines above and
below the text. These paragraphs provide key information with two levels of
importance, as shown below.
Note: Information to help you maximize the benefits of your Entrust product.
Attention: Issues that, if ignored, may seriously affect performance, security, or

the operation of your Entrust product.

Feedback on guide
Related documentation
Entrust IdentityGuard is supported by a complete documentation suite:
• For instructions about installing and configuring the Entrust IdentityGuard
Server, see the Entrust IdentityGuard Installation Guide.
• For instructions about administering Entrust IdentityGuard users and groups,
see the Entrust IdentityGuard Administration Guide.
• For information about deploying Entrust IdentityGuard, see the Entrust
IdentityGuard Deployment Guide.
• For information about configuring Entrust IdentityGuard to work with a
supported LDAP repository—Microsoft Active Directory, Microsoft Active
Directory Application Mode, Critical Path InJoin Directory, IBM Tivoli
Directory, Novell eDirectory, Oracle Directory, or Sun ONE Directory—see
the Entrust IdentityGuard Directory Configuration Guide.
• For information about configuring Entrust IdentityGuard to work with a
supported JDBC database—IBM DB2 Universal Database, Microsoft SQL
Server, MySQL, PostgreSQL, or Oracle Database—see the Entrust
IdentityGuard Database Configuration Guide.
• For information about Entrust IdentityGuard error messages, see the Entrust
IdentityGuard Error Messages.
• For information about new features, limitations and known issues in the
latest release, see the Entrust IdentityGuard Release Notes.
• For information about integrating the authentication and administration
processes of your applications with Entrust IdentityGuard, see the Entrust
IdentityGuard Programming Guide that applies to your development
platform (either Java Platform or .NET).
• For Entrust IdentityGuard product information and a data sheet, go to
http://www.entrust.com/strong-authentication/identityguard/index.htm
• For information on identity theft protection seminars, go to
http://www.entrust.com/events/identityguard.htm
About this guide 13

Feedback on guide
Obtaining documentation
Entrust product documentation, white papers, technical notes, and a comprehensive
Knowledge Base are available through Entrust TrustedCare Online. If you are
registered for our support programs, you can use our Web-based Entrust TrustedCare
Online support services at:
https://www.entrust.com/trustedcare
Documentation feedback
You can rate and provide feedback about Entrust product documentation by
completing the online feedback form. You can access this form by
• clicking the Feedback on guide link located in the footer of Entrust’s PDF
documents (see bottom of this page).
• following this link: http://www.entrust.com/products/feedback/index.cfm
Feedback concerning documentation can also be directed to the Customer Support
email address.
support@entrust.com

Feedback on guide
Obtaining technical assistance
Entrust recognizes the importance of providing quick and easy access to our support
resources. The following subsections provide details about the technical support and
professional services available to you.
Technical support
Entrust offers a variety of technical support programs to help you keep Entrust
products up and running. To learn more about the full range of Entrust technical
support services, visit our Web site at:
http://www.entrust.com/
If you are registered for our support programs, you can use our Web-based support
services.
Entrust TrustedCare Online offers technical resources including Entrust product
documentation, white papers and technical notes, and a comprehensive Knowledge
Base at:
https://www.entrust.com/trustedcare
If you contact Entrust Customer Support, please provide as much of the following
information as possible:
• your contact information
• product name, version, and operating system information
• your deployment scenario
• description of the problem
• copy of log files containing error messages
• description of conditions under which the error occurred
• description of troubleshooting activities you have already performed
Telephone numbers
For support assistance by telephone call one of the numbers below:
• 1-877-754-7878 in North America
• 1-613-270-3700 outside North America
Email address
The email address for Customer Support is:
support@entrust.com
About this guide 15

Feedback on guide
Professional Services
The Entrust team assists e-businesses around the world to deploy and maintain secure
transactions and communications with their partners, customers, suppliers and
employees. We offer a full range of professional services to deploy our e-business
solutions successfully for wired and wireless networks, including planning and design,
installation, system integration, deployment support, and custom software
development.
Whether you choose to operate your Entrust solution in-house or subscribe to hosted
services, Entrust Professional Services will design and implement the right solution for
your e-business needs. For more information about Entrust Professional Services
please visit our Web site at:
http://www.entrust.com

Feedback on guide
1
About Entrust IdentityGuard

Entrust IdentityGuard is a versatile authentication platform that enhances security
and verifiability by providing multifactor authentication methods. It allows users to
prove their identity when accessing sensitive resources from a variety of locations,
including the Microsoft Windows desktop, remotely through a VPN connection, or
over the Web. Some organizations are levering Entrust IdentityGuard over their IVR
systems for true cross-channel authentication.
This chapter contains the following sections:
• “Why use Entrust IdentityGuard?” on page 18
• “Authentication choices” on page 20
• “Entrust IdentityGuard components” on page 23
17
Why use Entrust IdentityGuard?
As online fraud and compliance regulations become more prevalent, standard user
name and password authentication no longer offers sufficient security for your
organization’s sensitive resources.
Strong authentication is a tool that your organization likely uses in some form today.
Whether it is for VPN remote access, Microsoft® Windows® security, or Web-based
applications, you need to provide strong and flexible authentication to a wide range
of users and transactions, based on the risk associated with those transactions.
Entrust IdentityGuard provides multiple authentication factors (also referred to as
“methods”) which your organization can use (with or without other user name and
password authentication methods) to increase security. The various authentication
methods Entrust IdentityGuard offers allows you to adjust the strength of the
authentication to the sensitivity of the resource or transaction.
For example, as Figure 1 demonstrates, a company could apply Entrust IdentityGuard
grid authentication when a remote employee logs in using a VPN connection. The
system could include an existing user name and password authentication resource or
could use Entrust IdentityGuard to handle this first-factor authentication duty.
Figure 1: Multifactor authentication with Entrust IdentityGuard
User name and password

authentication resource
Company VPN
User that requires device
multifactor Entrust IdentityGuard
authentication Server
Company Employee repository

firewall
This section contains the following topics:

• “Challenges of first-factor authentication” on page 19
• “Benefits of multifactor authentication” on page 19

Feedback on guide
Challenges of first-factor authentication
Authentication is the process of determining whether someone or something is, in
fact, who or what it represents itself to be. In private and public computer networks,
authentication is commonly done through the use of a user name and password. The
user enters their password to authenticate to the application. This method is referred
to as “first-factor authentication”.
However, the widespread incidents of online identity theft shows that user names and
passwords alone — which are easy to steal and easy to reuse — are not much defense
against the ever-increasing sophistication of identity attacks. You need one or more
second-factor authentication methods to be safe.
Benefits of multifactor authentication

“Multifactor authentication” is a solution that adds as many authentication methods
as required based on the security context. For example, after employees log in using
a user name and password, you can require that they answer a grid challenge, while
at the same time, have the authentication application check the computers they use
to ensure they are registered.
Identities become difficult to steal

With multifactor authentication, it is difficult, if not impossible, for an attacker to steal
login data in large numbers. While it is possible to physically steal some
authentication data on an individual basis, attackers are usually interested in mass
theft. They will get frustrated by the effort. Also, an organization can authenticate
itself to its users, making it easier for users to detect redirection to a fraudulent site.
The user can then take immediate countermeasures against the likely theft.
Stolen identities become difficult to reuse

Your organization can combine multiple authentication methods in ways that make
the theft of a single factor useless to the attacker. Without the additional
authentication methods, the attacker has either no access to a user’s confidential
information or can only view trivial information. Also, authentication can be
performed at the transaction level using different authentication methods, depending
on the risk associated with the transaction.
About Entrust IdentityGuard 19

Feedback on guide
Authentication choices
Entrust IdentityGuard offers several ways to set up first-factor authentication. Once
the user has logged in, you can apply one or more second-factor authentication
methods, and apply additional authentication steps for higher-risk transactions.
First-factor authentication choices

You can set up Entrust IdentityGuard to do first-factor authentication, or you can
integrate Entrust IdentityGuard with an existing authentication resource. Entrust
IdentityGuard supports the following types of first-factor authentication:
• password authentication based on a user name and password stored by
Entrust IdentityGuard in the user entry of your repository
• external authentication based on domain or directory credentials that a user
already has
In addition, Entrust IdentityGuard can integrate with other first-factor authentication
methods provided by Web, desktop, or VPN authentication applications. For
example, you can integrate Entrust IdentityGuard with Web authentication products
such as:
• Entrust GetAccess
• Entrust TruePass
• IIS Web server and Internet Security and Acceleration (ISA) Server
• other third-party applications
You can also integrate Entrust IdentityGuard with Virtual Private Network (VPN)
authentication products such as:
• Cisco ASA 5500 Series appliances
• Nortel VPN Routers
Optionally, you can choose to skip first-factor authentication altogether. If you do so,
ensure that you have carefully examined the risks and benefits.
The first-factor authentication methods are described in more detail in “First-factor
authentication methods” on page 39.
Second-factor authentication choices

Entrust IdentityGuard provides several second-factor authentication methods,
including:
• card (grid and passcode list) authentication
• token authentication
• one-time password authentication (typically delivered by an out-of-band
mechanism, such as email or voice message delivery)

Feedback on guide
• knowledge-based (question and answer) authentication
• temporary PIN authentication
The second-factor authentication methods are described in detail in “Second-factor
authentication methods” on page 41. For grid cards, tokens, and temporary PINs,
you can include the use of a personal verification number (PVN). See “Using personal
verification numbers” on page 66 for more information.
Mutual authentication choices

Mutual authentication (also called organization authentication) is a way to verify your
organization to users as legitimate. Entrust Identity Guard provides two methods of
verifying your organization to users:
• grid serial number or grid location replay
• image and message replay
The mutual authentication methods are described in detail in “Mutual authentication
methods” on page 52.
Machine authentication
Entrust IdentityGuard allows you to verify a user by comparing current properties of
the user’s machine against a previously stored copy of those same properties.
Machine authentication is also a feature of risk-based authentication.
See “Machine authentication” on page 55 for a detailed description of machine
authentication.
Risk-based authentication
Entrust IdentityGuard allows you to determine situations where second-factor
authentication is applied, based on a user’s location or machine information. For
example, second-factor authentication may not be required when users log in from
the desktop computer they use all the time. However, if users log in from remote
locations or are using computers they have never used before, you may want Entrust
IdentityGuard to send them a second-factor challenge. Using risk-based
authentication allows you to choose when second-factor authentication is applied
based on risks relevant to your company.
There are two authentication features associated with risk-based authentication:
• machine authentication
The risk is assessed based on the attributes associated with a particular
computer.

Feedback on guide
• IP geolocation authentication
The risk is assessed based on the geographical location (derived from the IP
address) of the user.
See “Risk-based authentication” on page 62 for a detailed description of risk-based
authentication.

Feedback on guide
Entrust IdentityGuard components
The following diagrams show how Entrust IdentityGuard can fit into your existing
authentication system or become your sole authentication system.
Figure 2: Entrust IdentityGuard with an existing authentication system
User
First-factor
authentication Entrust IdentityGuard
application Server
Repository
Figure 3: Entrust IdentityGuard as the sole authentication system
User Repository
Entrust IdentityGuard
Server

• “Entrust IdentityGuard server” on page 24
• “Repository” on page 26
• “First-factor authentication application” on page 27
• “Entrust IdentityGuard Radius proxy” on page 27

Feedback on guide
• “Entrust IdentityGuard Desktop for Microsoft Windows” on page 28
• “Entrust IdentityGuard Remote Access Plug-in” on page 29
• “Client applications” on page 30
• “Entrust IdentityGuard users” on page 31
Entrust IdentityGuard server

The Entrust IdentityGuard server is the main component of the Entrust IdentityGuard
system. You can run more than one Entrust identityGuard server in your system, and
the servers can access different replicas of the repositories configured for use. See
“Repository” on page 26 for more information.
Each Entrust IdentityGuard server includes the following applications and interfaces:
• authentication and administration Web services with Java Platform and C#
APIs
• administration interface, properties editor, and master user shell
• a sample Web application that demonstrates Entrust IdentityGuard’s
capabilities
These applications and interfaces are required to authenticate and manage users and
their authentication data.
Figure 4 illustrates the higher level Entrust IdentityGuard components and shows how
they integrate with your existing authentication application.

Feedback on guide
Figure 4: Entrust IdentityGuard components
Entrust IdentityGuard Server
Master user shell
Repository
Client Application server
administration SOAP
(with SSL) Administration service Directory
application
Entrust Database
Web administration
IdentityGuard application
HTML/
Administration
HTTPS
interface and
Properties Authentication service
editor
SOAP SOAP SOAP

(SSL is optional) (SSL is optional) (SSL is optional)
Entrust IdentityGuard Client

Desktop for Microsoft authentication Radius proxy
Windows application
Entrust IdentityGuard Authentication service

The Entrust IdentityGuard Authentication service (also referred to as the
Authentication API), is a set of Web services used for retrieving challenge requests
and authenticating user responses. It is designed to easily integrate with your existing
authentication applications to provide multifactor authentication.
You can create an application that calls the Authentication API using its Web service,
Java Platform or .NET interfaces to authenticate users. For more information, see the
Entrust IdentityGuard Programming Guide that applies to your programming
language (Java Platform or .NET).
Optionally, you can use the Secure Sockets Layer (SSL) protocol to secure user
responses between any Entrust IdentityGuard authentication client and the Entrust
IdentityGuard Authentication service.

Feedback on guide
Entrust IdentityGuard Administration service
The Entrust IdentityGuard Administration service (also referred to as the
Administration API), is a servlet running on the Entrust IdentityGuard server that
manages groups, policies, administrators, users, grid cards, tokens, PINs, and other
authentication data.
You can create an application that calls the Administration API using its Web service,
Java Platform or .NET interfaces to automate Entrust IdentityGuard user
administration tasks. For more information, see the Entrust IdentityGuard
Programming Guide that applies to your programming language (Java Platform or
.NET).
Administration interface
Administrators use the Web-based Administration interface to perform system and
user administration operations that define how Entrust IdentityGuard will work in
your organization.
Properties editor
Administrators use the Properties editor to set or review the properties that govern
the behavior of Entrust IdentityGuard and its components.
Master user shell

The master user shell is a command line interface installed on the Entrust
IdentityGuard server. Master users use the master user shell to perform many of the
same tasks that the Administration interface offers. A small number of tasks are
available only through the master user shell.
Repository
Entrust IdentityGuard uses your existing repository or multiple repositories to store
user, unassigned token, and preproduced card data in an existing LDAP-compliant
directory, a JDBC-compliant database, or both. Multiple Entrust IdentityGuard servers
can access different replicas of the repositories, if required.
When a grid or other authentication data is generated for a user, sensitive data is
written in encrypted form to the repository. During second-factor authentication,
data is retrieved from the repository.
Users reside in groups. You can assign groups to one or more repositories, and those
repositories can be in databases, in directories, or both.
Each directory search base is treated as a separate repository, and has the capability
of using a different directory server and different directory user credentials. The
default configuration uses a single search base.

Feedback on guide
For grid or token authentication, unassigned token information and preproduced
grids are stored in the Entrust IdentityGuard repository. You can store this information
as a as a flat file on the Entrust IdentityGuard Server (default) or in a separate
database (if storing over 100,000 grid cards or tokens). For more information on the
file-based repository options, see the Entrust IdentityGuard Installation Guide. When
the grid or token is assigned to a user, the information is then copied into the user's
repository entry.
For more information about repositories, see “Selecting a repository” on page 89.
You can also set up all key connections in a failover scenario. For a database or
directory, you can use the Properties Editor to add multiple URLs to the Entrust
IdentityGuard properties file. Entrust IdentityGuard attempts to connect to the
repositories in the order they are listed. In the same way, you can list multiple URLs
for Radius proxy connections and external authentication connections.
For more information on failover, see “High availability and disaster recovery” on
page 94.
First-factor authentication application

You have three choices for first-factor (user login) authentication:
• You can integrate Entrust IdentityGuard with your existing authentication
application. This authentication application can be a Remote Authentication
Dial In User Service (Radius) server, a domain controller, a Web-based access
control product, the Microsoft Windows Login feature, an LDAP-compliant
directory, and so on. Depending on the type of application, you may need to
customize it. For more information, see “Deployment considerations” on
page 83.
• You can configure Entrust IdentityGuard to manage user logins through the
password feature. In this case, the repository stores password credentials.
Administrators can manage the passwords through the Administration
interface.
• You can configure Entrust IdentityGuard (when using the Radius proxy) to
skip first-factor authentication and move directly to second-factor
authentication.
Entrust IdentityGuard Radius proxy

The Entrust IdentityGuard Radius proxy component installs with the Entrust
IdentityGuard Server to enable multifactor authentication for Virtual Private Network
(VPN) users and users on Wireless Access Points (WAP).
The Radius proxy intercepts messages between the VPN server and the first-factor
authentication resource. That resource may be a Radius server, a Windows domain
controller, an LDAP-compliant directory, or Entrust IdentityGuard itself (using

Feedback on guide
password authentication). If the resource is a domain controller or directory, you must
use external authentication (see “External authentication” on page 40). For more
information, see the Entrust IdentityGuard Administration Guide.
In the case of the Radius proxy being used with a wireless access point, all you need
is Entrust IdentityGuard—no Radius server or Windows domain controller is required.
The Radius proxy supports second-factor authentication using a grid, a token,
questions and answers (knowledge-based), or one-time password (OTP). All of these
authentication methods, except knowledge-based authentication, can also include a
personal verification number (PVN). A PVN is similar to a PIN, except it is not tied to
one authentication method.
Entrust IdentityGuard Desktop for Microsoft Windows

Entrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that
communicates with the Entrust IdentityGuard Server. Table 2 describes the features
of Entrust IdentityGuard Desktop for Windows.
Table 2: Features of Entrust IdentityGuard for Microsoft Windows
Feature Feature environment Feature description

Windows Login Microsoft Windows The Windows Login feature of the Entrust
2000 or Windows XP IdentityGuard Desktop for Microsoft
desktop (online or Windows allows users to use grid
offline) authentication when they log in to their
Microsoft Windows desktop computer.
Note: You can use only grid authentication
with the Windows Login feature.
Remote Access Network access through The Microsoft Routing and Remote Access
dial-up, wireless, or VPN Service (RRAS) feature of the Entrust
remote access IdentityGuard Desktop for Microsoft
Windows enables users to remotely access a
network through dial-up or VPN connectivity.
When RRAS is installed on the Microsoft
Windows desktop computer, a separate
product called the Remote Access Plug-in for
Microsoft Windows Server must be installed
on a Microsoft Server machine.
Note: You can use only grid or token
authentication with the Remote Access
Plug-in for Microsoft Windows Server.
Entrust IdentityGuard Desktop for Windows is deployed using a Windows installer

(MSI) file. You can customize the installer file by applying a transform (MST) file,

Feedback on guide
which is a collection of changes applied to a base MSI file. A central administrator
creates a custom installation file and configures the Entrust IdentityGuard options in
accordance with your organization’s policies and practices.
In this scenario, each user in your company has a grid card and may have a temporary
PIN. When the computer boots up, Microsoft Windows challenges each user for a
Windows user name and password. After the user responds correctly, Entrust
IdentityGuard Desktop for Windows pops up a challenge box.
• If the user enters the correct response, the users is granted access to the
computer.
• If the user enters several incorrect responses and exceeds the lockout limit,
the user is locked out of the computer.
• If the user does not have a grid card (for example, the user lost it), the user
can enter a temporary PIN, which Entrust IdentityGuard Desktop validates.
• If the user is offline, the user can enter an offline temporary PIN, which
Entrust IdentityGuard Desktop validates against the shared secret stored (in
encrypted format) in its repository.
For more information, see the Entrust IdentityGuard Desktop for Microsoft Windows
Administration Guide.
Entrust IdentityGuard Remote Access Plug-in

The Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server
communicates with the Entrust IdentityGuard Desktop for Microsoft Windows
Remote Access feature.
For the Remote Access feature to connect to a Remote Access Server, the Entrust
IdentityGuard Remote Access Plug-in for Microsoft Windows Server must be installed
on one of the following supported servers:
• Microsoft Routing and Remote Access Service (RRAS)
• Microsoft Internet Authentication Service (IAS)
Usually, the RRAS and IAS are on the same computer. If your setup requires these to
be on separate computers, it is recommended that you install the Remote Access
Plug-in on the computer hosting the IAS.
When the Remote Access Plug-in for Microsoft Windows Server is installed, an
Entrust IdentityGuard Desktop for Microsoft Windows Remote Access client has the
ability to connect to the Entrust IdentityGuard Server for second-factor
authentication.
See the Entrust IdentityGuard Desktop for Microsoft Windows Administration Guide
for more information.

Feedback on guide
Entrust IdentityGuard ISAPI filter
Entrust IdentityGuard can also protect Web applications (such as Microsoft Outlook
Web Access) with the Entrust IdentityGuard ISAPI filter. You can install the ISAPI
(Internet Server Application Programming Interface) filter on an ISA server or an IIS
server.
The Entrust IdentityGuard ISAPI filter, combined with any Entrust IdentityGuard
authentication method, ensures that only valid users have access to the Web
application.
Client applications
Client applications use the Authentication API and the Administration API to access
Entrust IdentityGuard’s multifactor authentication abilities on behalf of your users. To
access these APIs, the client applications require appropriate administrative privileges.
Table 3 provides some examples of what client applications can do.
Table 3: Sample activities of client applications
Client applications can By

Register new users • Obtaining user information (user ID, email address, image replay
(Administration API) information, and so on) from a user through a user registration
page
• Setting other required attributes, such as group affiliation and
authentication method
• Passing this information to Entrust IdentityGuard, which then
creates a user entry in the repository
Authenticate users • Presenting them with an initial authentication page (user name
(Authentication API) and password) when they attempt to access your site
• Challenging them with a second-factor authentication page,
using challenges created by Entrust IdentityGuard
Note: The client application is responsible for enforcing the limits for
a challenge response. This is especially important when using grid
authentication. Limits are set by Entrust IdentityGuard policies.
• Providing the challenge response to Entrust IdentityGuard for
validation
• Returning Entrust IdentityGuard’s response to the user

Feedback on guide
Table 3: Sample activities of client applications (continued)
Client applications can By

Allow self-administration • Presenting a page that allows them to change user information
of users (for example, to change their email address or phone number)
• Presenting a page that allows them to alter their questions and
answers, or image and text replay options
• Passing the responses to Entrust IdentityGuard so that it can
update the user entry for the next time the user logs in
To create your own client applications, see the Entrust IdentityGuard Programming
Guide that applies to your programming language (Java Platform or .NET).
The Entrust IdentityGuard Administration interface, Entrust IdentityGuard Desktop
for Microsoft Windows, and the sample Web application included in the installation
package are all examples of client applications.
Entrust IdentityGuard users

Entrust IdentityGuard users are divided into different categories, based on how they
access your organization’s resources. See “Entrust IdentityGuard baseline
architectures” on page 153 for diagrams showing how Entrust IdentityGuard
interacts with these users.
Microsoft Windows desktop users

Microsoft Windows desktop users are internal users who, after logging in to your
domain using their Windows user name and password, are then presented with a
second-factor authentication challenge (such as a grid challenge). For more
information about these users, see the Entrust IdentityGuard Desktop Client for
Microsoft Windows Administration Guide.
Routing and Remote Access Service (RRAS) users

RRAS users are Microsoft Windows users internal to your organization who access
your domain remotely through a dial-up, wireless, or VPN connection and use the
Microsoft Routing and Remote Access Service. After logging in to your domain, they
are then presented with a second-factor authentication challenge (such as a grid
challenge). For more information about these users, see the Entrust IdentityGuard
Desktop Client for Microsoft Windows Administration Guide.

Feedback on guide
VPN users
VPN users are internal and external users who log into your domain using a VPN
connection. First-factor authentication (user name and password) can be provided
by:
• an existing Radius server
• an existing LDAP directory
• an existing Windows domain controller
• Entrust IdentityGuard password authentication
Entrust IdentityGuard then challenges these users for a second factor of
authentication. For more information, see “VPN remote access integration” on
page 85.
Web users
Web users are internal or external users to your organization who access your intranet
or Internet site by logging in through a Web browser. First-factor authentication (user
name and password) is completed by a Web access product or Entrust IdentityGuard
using password authentication. Entrust IdentityGuard can then provide additional
authentication methods as required by the sensitivity of the operation. For more
information, see “Web integration” on page 84.

Feedback on guide
2
Authentication methods
Entrust IdentityGuard provides authentication methods for authenticating users,
performing mutual and risk-based authentication, and registering computers.
This chapter describes the implementation considerations for each method.
Note: While reading this chapter, consider the frequency of the authentication
events to which you want to add multifactor authentication. Gather statistics
from your authentication applications and resources, and develop a usage profile
for each of the transactions. You can then find an appropriate balance between
user convenience, resistance to attack, and the administrative overhead for
managing multifactor authentication.

• “Overview of available authentication methods” on page 34
• “First-factor authentication methods” on page 39
• “Second-factor authentication methods” on page 41
• “Mutual authentication methods” on page 52
• “Machine authentication” on page 55
• “Risk-based authentication” on page 62
• “Temporary PIN authentication” on page 65
• “Using personal verification numbers” on page 66
33
Overview of available authentication methods
This section describes and compares the authentication methods available through
Entrust IdentityGuard.
Entrust IdentityGuard divides the authentication methods into the following
categories:
• first-factor authentication
In first-factor authentication, users must identify themselves, typically by
supplying a user name and password. You can rely on a separate application
to do this, such as a Remote Authentication Dial In User Service (Radius)
server, a domain controller, a Web-based access control product, or the
Microsoft Windows Login feature. Alternatively, you can use Entrust
IdentityGuard’s password feature.
Figure 5: First-factor authentication
• second-factor authentication
In second-factor authentication, users verify their authenticity to your
organization, using one of the following methods:
– token authentication
– grid authentication
– passcode list authentication
– knowledge-based authentication
– one-time password authentication delivered through an out-of-band
mechanism

Feedback on guide
Figure 6: Second-factor authentication methods
For added security, a personal verification number can be used with cards
(grids and passcode lists), tokens, and one-time-passwords. For more
information, see “Using personal verification numbers” on page 66.
• mutual authentication (organization authentication)
In mutual authentication, your organization proves itself as authentic.
Mutual authentication can involve different types of replay authentication.
Authentication methods 35
Feedback on guide
Figure 7: Mutual authentication methods
Serial replay authentication Image replay

(grid card serial number ) authentication
(user selected image )
Grid location replay authentication

(grid locations shown specific to Message replay
user) authentication
(user entered
message)
• machine authentication
In machine authentication, the user’s identity is verified based on various
properties of the user’s computer.
• risk-based authentication
In risk-based authentication, the authentication method presented depends
on the risk. Risk varies based on user qualities, such as
– the machine used
– the user’s geographic location
Risk can be based on the nature of the transaction. Some examples which
might qualify as high-risk transactions include:
– large money transfers
– new account creation
– large purchases
• temporary PIN authentication
In temporary PIN authentication, the user enters a temporary PIN in place of
a temporarily unavailable card (grid or passcode list) or token.

Feedback on guide
The Entrust IdentityGuard Server installs with a sample Web application that
demonstrates how the various authentication methods work, and how you can set
up your own applications to integrate with the Entrust IdentityGuard system. The
Entrust IdentityGuard Installation Guide includes a tutorial that describes the Web
application.
To deploy the authentication methods, Entrust IdentityGuard includes policies that
allow you to determine the characteristics of the authentication methods for groups
of users. For more information, see “Entrust IdentityGuard policies” on page 69 and
the Entrust IdentityGuard Administration Guide.
Table 4 provides a brief comparison of the Entrust IdentityGuard authentication
methods.
Table 4: Comparison of available authentication methods
Authentication Physical Renewal options1 Sample use

method requirements for
users
Token Token hardware When device is lost or Requiring strong
battery dies (6 years or second-factor
more) authentication
Grid Card Based on use or time Requiring strong
second-factor
authentication
Passcode list Printed list Based on use or time Requiring infrequent
authentication
Temporary PIN None Based on use or time Grid, passcode list, or
token is temporarily
unavailable
Knowledge-based None N/A Registering users and/or
machines
One-time password None2 One-time use only One-time, highly sensitive
delivered by an operation
out-of-band
mechanism
Machine (can be part N/A Based on each login, Users access site from
of risk-based length of time, or when personally-owned
authentication) users change computers computers
IP geolocation N/A N/A Users access site from a
(risk-based) variety of locations
Feedback on guide
Table 4: Comparison of available authentication methods (continued)
Authentication Physical Renewal options1 Sample use

method requirements for
users
Replay (organization) Card, if using grid N/A Verification of
location or serial organization
number replay
1. An administrator or application can force a renewal at any time.
2. Users need a telephone number, SMS information, or email account to receive the one-time password by out-of-band
delivery.

Feedback on guide
First-factor authentication methods
You can use Entrust IdentityGuard to directly manage first-factor authentication; that
is, to check if a user’s first-factor credentials (user name and password) is valid.
Alternatively, you can configure Entrust IdentityGuard to use an external
authentication mechanism, such as a Windows domain controller. You can always
integrate Entrust IdentityGuard with your existing authentication application using
the Entrust IdentityGuard authentication and administration Web services.
Password authentication
Entrust IdentityGuard administrators with the applicable role permissions can set and
manage the passwords of Entrust IdentityGuard users through the Administration
interface. For new passwords, administrators can enter passwords of their choosing
or auto-generate random passwords. Administrators can also manage policy settings
related to passwords, such as the length, composition (letters, numbers, case, and
special characters), expiry date, and reuse history. The policy settings ensure that user
passwords conform to your organization’s password requirements.
Radius server authentication

For first-factor authentication of your VPN users, Entrust IdentityGuard provides the
ability to use the Radius authentication protocol with a VPN server and optionally, a
Radius server.
When you integrate Entrust IdentityGuard with your VPN server, the Entrust
IdentityGuard Radius proxy intercepts messages between the VPN server and the
first-factor authentication resource.
Entrust IdentityGuard supports these first-factor authentication methods for VPN
users:
• Entrust IdentityGuard forwards a request to a Radius server which completes
the first-factor authentication.
• Entrust IdentityGuard forwards a first-factor authentication request to either
an LDAP-compliant directory or Windows domain controller. This is referred
to as external authentication. For more information on external
authentication, see “External authentication” on page 40.
• Entrust IdentityGuard itself completes the password authentication.
Regardless of the method, the VPN server still believes it is communicating with a
Radius server. It is actually communicating with the Entrust IdentityGuard Radius
proxy.
You can configure your VPN servers to use different first-factor authentication
resources for first-factor authentication. For example, one VPN server can use a
Radius server, and another VPN server can use an LDAP-compliant directory.
Feedback on guide
Note: You can also configure the Radius proxy to skip first-factor authentication
entirely and present users with a second-factor authentication challenge
immediately.
External authentication
The external authentication feature, provided with Entrust IdentityGuard is useful
when deploying in a Remote Access or VPN environment. This feature lets you use
Entrust IdentityGuard to manage first-factor authentication through an LDAP
directory or Windows domain controller through Kerberos, without having to deploy
a Radius server.
Use external authentication when your users and their password information are
stored in an external resource (such as Active Directory or an LDAP-compliant
directory).
Also, in an environment where user password information is stored in an external
resource (for example, Active Directory) and Entrust IdentityGuard information
(grids, tokens, policies, and so on) is stored in a database, you can have Entrust
IdentityGuard forward first-factor authentication to the external resource if the
external authentication is through Kerberos.
Note: When using external authentication, users in the first-factor resource are
not automatically synchronized with the second-factor resource (the Entrust
IdentityGuard repository). You must manually synchronize all data between the
different resources.
For a sample architecture, see “Web access - evaluation” on page 156. Also see the
Entrust IdentityGuard Installation Guide for more information.

Feedback on guide
Second-factor authentication methods
Your organization can choose one or more second-factor authentication methods.
The choice of authentication method depends on the risk of a given transaction or
the sensitivity of your resources. The greater the risk of misrepresentation and fraud,
the greater the need for additional authentication. While first-factor authentication
uses information the user knows, second-factor authentication challenges often also
require something the user is holding, a grid card or token, for instance.
Second-factor authentication is also used in step-up authentication. A user may be
authenticated, and working in the application, but then they request a higher risk
transaction. If step-up authentication is enabled, the user is challenged again before
being able to complete the transaction.
As an additional level of security, Entrust IdentityGuard includes details of the
transaction in challenge requests of this type, and then authenticates these
transaction details as the user is authenticate. This is mitigates the risk of
“man-in-the-middle” attacks, in which an attacker intercepts a transaction and
modifies it before it is authenticated.
Entrust IdentityGuard keeps these attackers from being successful by verifying that
the transaction hasn’t changed between the request and the authentication.
In transaction authentication, the transaction details are compared to those contained
in the challenge, and the authentication is successful only if the two sets of
transaction details match. When the authentication is successful, a transaction receipt
is returned to the application. The transaction receipt may be signed, depending upon
the policies set in Entrust IdentityGuard.
The following second-factor authentication methods are available:
• “Token authentication” on page 41
• “Grid authentication” on page 42
• “Passcode lists” on page 45
• “Knowledge-based authentication” on page 47
• “One-time password (OTP) authentication” on page 49
Token authentication
Using tokens, your users can authenticate themselves using a dynamic password after
completing first-factor authentication.
By default, Entrust IdentityGuard supports the Entrust IdentityGuard Mini Token and
the Entrust IdentityGuard Pocket Token. The Mini Token is available in an AT version
(time+event synchronous) and an OE version (OATH compliant). Entrust
IdentityGuard also supports tokens from other vendors.
In addition, you can configure the Entrust IdentityGuard APIs to use any tokens from
a supported token vendor. Different token types can be assigned to your users, and
Feedback on guide
a user can have two tokens from different vendors, though the tokens cannot have
the same token state. For more on token states, see the Entrust IdentityGuard
Tokens represent a strong second-factor authentication method because they
combine possession (the token) and knowledge (the dynamic password or PIN).
Because the token password changes frequently, it is difficult for a hacker to record it
and use it later to log in to the system.
Entrust IdentityGuard supports tokens that use response-only mode and tokens that
use challenge-response mode.
Table 5: Token authentication advantages and considerations
Advantages • It is easy to use.

• It is impossible for an attacker to reuse passwords, making it a
very secure second-factor authentication method.
Considerations • It is not as cost efficient to buy, maintain, and renew as other
methods (such as grids). Entrust tokens are more cost efficient
than tokens from other vendors.
• You need to determine how to roll out tokens and train users.
• For time-based tokens, the Entrust IdentityGuard Server clock
must be accurate to UTC within a 30-second range.
Deployment types • Web access
• Microsoft Windows remote access
• VPN remote access
Grid authentication
With grid authentication, you provide each user with a printed Entrust IdentityGuard
card that contains rows and columns of characters. Authentication works as follows:
1 The user completes first-factor authentication (user name and password)
successfully.
2 Entrust IdentityGuard presents the user with a challenge based on the grid on
their card, as illustrated in Figure 8.
3 The user enters the values from their grid card corresponding to the requested
cell locations in the challenge. In Figure 8, the challenge asks the user to enter the
numbers in grid coordinates B1, E4, and G5, which are “7 8 4”.
4 Entrust IdentityGuard validates the entered values and authenticates the user. By
entering the correct response, users demonstrate that they possess the grid card,
thus providing a second factor of authentication.

Feedback on guide
Figure 8: Entrust IdentityGuard challenge sample
IGuser1
******
******
You can set up grid challenges in one of the following ways:

• In one-step authentication, you combine first and second-factor
authentication on a single page. For example, you include the prompt for a
user name, a password and a grid challenge on one page. In this approach,
the application does not know the user’s identity until after login and
authentication; that is, the user is anonymous until both first and
second-factor authentication are complete. For an example, see Figure 9.
Figure 9: One-step authentication example
Feedback on guide
• In two-step authentication, the user logs in as usual and is then shown a
second dialog box containing the Entrust IdentityGuard grid challenge.
Because the user has already passed first-factor authentication, the user’s
identity is known. This lets you add other Entrust IdentityGuard features,
such as serial number replay or grid location replay (see “Mutual
authentication methods” on page 52). For an example, see Figure 10.
Figure 10: Two-step authentication example
Table 6 lists the advantages and considerations of grid authentication.
Table 6: Grid authentication advantages and considerations
Advantages • It is easy to use (see “Entrust IdentityGuard grid card usability

study” on page 182).
• It is inexpensive to set up, maintain and renew.

Feedback on guide
Table 6: Grid authentication advantages and considerations (continued)
Considerations • The standard size of a grid card is a 5 x 10 grid, which contains

19,600 three-cell challenge sets. This size provides both security
and usability. You can customize the grid size to meet your unique
deployment, usability, and security requirements.
• Replace grid cards on a regular basis. Determine the frequency of
grid replacement based on your users’ needs and your security
requirements.
• Determine whether you need one-step or two-step
authentication options (two-step is recommended).
• Microsoft Windows desktop
Deployment risks and • Through mechanisms such as phishing or pharming, an attacker
mitigation can capture one or more grid authentications made by a user and
attempt to authenticate to the legitimate application. Setup your
lockout policy to ensure a limit on the number of attempts, and
replace grid cards regularly to help mitigate this risk.
• Grids must be processed and delivered securely to the user so that
no grid information is copied before the user obtains the grid.
Consider using Entrust IdentityGuard Card Production Service
(available through Entrust TrustedCare online) to ensure that grid
card security is maintained throughout the deployment process.
Determining the grid challenge size

There may be cases where you want to present a different number of grid coordinates
based on the type of access or transaction the user requires. For example, access to a
company information portal could require two grid coordinates while access to a
online investment site could require four coordinates.
You set the minimum and maximum number of required grid coordinates in Entrust
IdentityGuard policy, and then set the exact number of coordinates for each
authentication scenario in your application. The application must present a number
of coordinates between the minimum and maximum number of required coordinates.
Passcode lists
Passcode list authentication is a grid authentication that uses a list of passcodes or
transaction numbers (TANs) rather than a grid. Each passcode can be used just once.
Feedback on guide
With this approach, you provide users with a list of randomly generated passcodes
for second-factor authentication.
Some organizations view passcode lists as easier for their users to use than grid cards,
though our usability study proved that grid card use is quick to learn. (See “Grid card
usability study” on page 181.)
Typically, you distribute these lists to users on a printed sheet of paper similar to
Figure 11. You can also distribute scratch-off grid cards that make it easy for users to
see what codes they have already used.
Figure 11: Sample passcode list
Then, when a passcode is required, you prompt for the passcode next to a number in
the list as in Figure 12.
Figure 12: Sample passcode prompt
The user types the passcode printed on the paper next to the requested number. To
reduce susceptibility to phishing or malware attacks, each passcode is used just once.
This renders the entered passcode useless should it be captured by an attacker.

Feedback on guide
To help users remember they can use each passcode only once, and to help them
keep track of when they need a new passcode card, recommend that they strike used
passcodes from the list. Alternatively, create your passcode list as a scratch card,
which only reveals the passcode once a covering is scratched off.
Table 7: Passcode list authentication advantages and considerations
Advantages • Single use of a password makes it impossible for attackers to reuse

authentication data.
• You can create multiple passcodes at once, lowering overhead.
Considerations • Much like the grid production process, you need to produce and
distribute the passcode lists to your users. Unlike grids, however,
you will typically want to send users more than one list at a time.
Research your past authentication histories to determine how fast
the average user will exhaust a list and send an appropriate
number of lists to ensure that users can always authenticate.
• Additional consideration should be given to the way a passcode
list is produced, such as whether it will be a simple list of
uncovered passcodes or a covered list much like a lottery scratch
card. Cost is the primary difference between these two options.
• The number of characters in each passcode should be between
five and nine to maintain a balance between security and
usability.
• Choose between numeric or alphanumeric passcodes.
Deployment type • Web access
Deployment risks and • Some phishing attacks target this form of authentication.
mitigation There are simple ways to increase the security of a passcode list.
For example, prompt for passcodes in a random order instead of
from first to last, or add another form of authentication (such as
machine authentication) along with a passcode list.
Alternatively, consider deploying grid authentication instead of a
passcode list.
Knowledge-based authentication
A simple mechanism for identifying users is to challenge them to provide information
that an attacker likely cannot provide. The organization can present questions to the
user based on information (referred to as authentication secrets) that was supplied by
the user at registration or based on previous transactions or relationships.
In turn, the users recognize the secret questions they set up during registration and
they know that they have reached a legitimate site.
Feedback on guide
During enrollment the user may select and provide answers to easily-remembered
questions, such as What year did you buy your first car?, Which historical figure do
you most admire?, Name your most memorable cartoon character?, and so on.
Questions can be drawn from previous user interactions with the organization. For
example: What was the balance on your last statement?. It is difficult for attackers to
harvest answers to these questions through other information sources.
Entrust IdentityGuard allows organizations to select a number of such authentication
secrets or facts for each user and prompt for all answers or just a subset of them to
increase second-factor authentication strength.
Figure 13: Sample question-and-answer prompt
By maintaining a large set of authentication secrets, organizations can select a subset

that makes it more difficult for an attacker to gather impersonating information based
on previous authentications.
To make it easier on users, you can use questions and answers for additional
authentication rather than as your main second-factor authentication method. For
example, use machine authentication for the user’s normal login location and reserve
the questions for when the user logs in from a different machine.
Table 8: Knowledge-based authentication advantages and considerations
Advantages • There are no physical requirements for users (such as grid cards or
tokens).
• You can leverage previous interactions between the user and your
organization.

Feedback on guide
Table 8: Knowledge-based authentication advantages and considerations (continued)
Considerations • Consider how you will generate knowledge-based questions,

such as generated codes or pre-populated lists. See “Sources of
questions” on page 130.
• Good questions follow the criteria for privacy, security, and
usability. See “Creating good questions” on page 131.
• Users do not like answering a large number of questions.
• Allowing inexact answers by using a word map file can
compensate for users entering some incorrect values (such as
“St.” instead of “Street”).
• If the user must answer a large set questions to authenticate, you
may wish to allow a few incorrect responses.
• Select how many questions a user must answer based on your
security needs. More sensitive activities may require more
questions.
Deployment risks and • User-generated question-and-answer sets are not always secure.
mitigation When prompted to create their own questions and answers, users
can enter questions and answers that are easy to guess or easy to
find. Consider providing the user with a stock list of questions
instead.
• Users do not always enter secure answers to questions.
Even when providing the user with a stock list of questions to
answer, users can enter answers that are not secure (such as
sequential keyboard sequences or repeated answers). Be sure to
validate the answer set so it meets security needs. Alternately,
consider using a different method for generating questions
(“Sources of questions” on page 130).
One-time password (OTP) authentication

There are situations where you want to provide users with an authentication method
that, for security reasons, must be outside of the user’s current online session. For
example, a user attempts to execute a high-risk transaction (such as transferring
funds to a foreign bank), and you want to provide extra authentication. By using
means other than the primary communication channel (the user’s computer and your
network), you make it more difficult for an attacker or fraud attempt to succeed. This
is referred to as Out-Of-Band (OOB) authentication.
Entrust IdentityGuard supports this capability by generating a one-time password you
can send to the user.
Feedback on guide
You can send one-time passwords directly using email, text message (SMS), or voice
to a preregistered phone number. The user gets the one-time password by one of
these means, enters it into the application, and the transaction is approved.
To decide how to send the one-time password, consider the following:
• What information is already stored about the user and is the information
reliable? For example, a cell phone service provider would likely use SMS
with its digital cell service users. This way, the service provider can manage
any service level agreement (SLA).
• If previously collected information is not reliable enough for one-time
password authentication, you can register users. The online registration
process allows authenticated users to enter, validate, and correct their
delivery information (email address, voice phone number, and cell phone
number), and out-of-band authentication preferences. This also allows users
to personalize the way their one-time password is delivered to them.
• If you are using email delivery of one-time passwords, you can also send
details of the requested transaction with the OTP. This allows the user to
confirm the transaction details before authenticating. You can configure
Entrust IdentityGuard so that, when the user authenticates, a transaction
receipt is returned. The returned transaction receipt may be signed,
depending on how the policies are set.
Table 9: Out-of-band authentication advantages and considerations
Advantages • It is effective at guarding against attacks such as

man-in-the-middle attacks, where a legitimate session may be
used to piggy-back fraudulent transactions.
• It can use channels that already exist, including SMS to a cell
phone or email to a computer or mobile device. These channels
allow the user to confirm a particular transaction using a channel
already registered with the organization.
Considerations • When sending the password, ensure that you also provide a
context as to what the user is getting the password for.
• Consider the sensitivity of the transaction details, as users may
not always delete the message immediately, and it may be sent
unprotected.
• The expiry time for the password should balance your need for
security and the amount of time it would take for a user to receive
your message and enter the password.

Feedback on guide
One-time password delivery systems
Entrust IdentityGuard, straight out of the box, can generate and deliver one-time
passwords through email or through automated voice calls using Authentify. You can
also develop your own out-of-band (OOB) delivery methods using Entrust’s
programming environment. See Entrust IdentityGuard Programming Guide for the
.NET Framework and Entrust IdentityGuard Programming Guide for the Java
Platform for more information.
In a typical user registration process, your application should ask for an email address
and one or more phone numbers (home, work, cell). Once you have contact
information, your application can deliver a one-time password by email, by text
message to a cell phone, or by an automated voice message to a standard phone or
cell phone. If you have developed your own, custom OOB delivery method, you can
register users with the appropriate contact information, and configure Entrust
IdentityGuard to automatically generate and deliver OTPs using your custom delivery
method.
For an automated voice message, you must interact with a third-party service, such
as Authentify®. For information, visit http://www.authentify.com. For delivery by
email or a text message (SMS) to a cell phone, you can use Entrust IdentityGuard to
send the one-time password to one or more numbers.
Feedback on guide
Mutual authentication methods
Your organization needs to have confidence in the user’s identity. Likewise, users must
be confident that they are transacting with their organization or intended online site,
and not a fraudulent organization or spoofed site. Mutual authentication provides a
way for your organization and your users to prove themselves as legitimate. Entrust
IdentityGuard provides several mutual authentication methods.
Mutual authentication works as follows:
1 The user completes first-factor authentication successfully.
2 Entrust IdentityGuard presents the user with an authentication challenge.
3 The challenge presents an image or information to the user that only the valid
site could have.
4 The user recognizes the image or information, and responds to the challenge.
5 Entrust IdentityGuard validates the entered values and authenticates the user.
Mutual authentication is also called organization authentication. The following
options are available:
• “Grid serial number or grid location replay” on page 52
• “Image and message replay” on page 53
Grid serial number or grid location replay

Grid authentication not only provides a secure, low cost and easy way to authenticate
users, it also includes built-in mechanisms for mutual authentication.
• Each grid card or passcode list has a unique serial number that is known only
to the user and the organization that issued it. During login, you can display
this number to the user before prompting for second-factor authentication.
Before entering a password or grid challenge response, users confirm that the
serial number displayed on the screen matches the one on their grid card or
list. If it does, users can be confident they are accessing the legitimate site.
• Another mechanism available with the grid card is to replay or show specific
grid coordinates. That is, you tell users what values are in specific cells on
their grid cards. This confirms that you know the grid’s contents and,
therefore, you must be legitimate.
Table 10: Grid serial number and location replay authentication advantages and
considerations
Advantages • Helps users determine if they are at a valid site before they
provide sensitive authentication data.
• Easy to use when grid authentication is enabled.

Feedback on guide
Table 10: Grid serial number and location replay authentication advantages and
considerations (continued)
Considerations • It requires two-step authentication (See “Grid authentication” on

page 42 for more information on two-step authentication).
• You can take additional security measures to make this
information difficult to harvest. For example, you can conceal
entries by avoiding machine-readable characters; that is, display
them as images instead of text.
• Microsoft Windows desktop
Image and message replay

Another replay method supported by Entrust IdentityGuard is image and message
replay. As part of the registration process, the user selects an image from a gallery and
enters a custom image caption. During future logins, the user is shown the selected
image and their caption, as shown in Figure 14 on page 53.
Figure 14: Choosing a custom image and caption
Feedback on guide
You can provide your own collection of images for users to choose from, you can
allow users to upload their own images, or you can make use of the image collection
available from Entrust TrustedCare website.
Whatever source users choose their image from, it will be familiar to them. Image and
text replay makes it easy for users to know they are on a legitimate site.
Table 11: Image and text replay authentication advantages and considerations
Advantages • Allows a user to determine the site’s legitimacy.

• Not dependent on a specific authentication method.
Considerations • Plan for image data size implications because images require lots
of storage space. Images in your collection should be highly
optimized and limited in size to manage space requirements in the
Entrust IdentityGuard repository.
• Have many images available and let the users choose an image
they identify with.
• If you decide to allow users to upload their own images, take
special care to manage the amount of disk space budgeted for
this feature. Entrust IdentityGuard includes policy settings for a
maximum file size that you can set to ensure that users don’t
upload high-resolution images. Your organization can also deploy
a conversion utility to convert high resolution images into an
appropriate size (both file size and pixel size).

Feedback on guide
Machine authentication
Machine authentication provides validation of a user’s computer to secure the user
against a variety of threats when users usually access their accounts from the same
computer. It allows for seamless authentication without any noticeable impact on the
user experience.
To establish the computer identity, your application generates at least one of the
following (as specified by Entrust IdentityGuard policy):
• Machine tag. A machine tag is stored in a persistent object (such as a cookie
or a flash object) in the user’s Web browser. A machine tag includes at least
one of the following.
– machine nonce
This is an arbitrary number generated only during machine registration.
– sequence nonce
This is a number generated each time the machine is authenticated. A
sequence nonce ensures that the machine secret is only valid until the next
login attempt. The sequence nonce increases security by preventing an
attacker from authenticating with an older version of the machine secret.
• Machine fingerprint.
This is a collection of machine data (called application data) specific to the
user’s computer, such as the browser version or operating system. The
application provides the machine fingerprint each time the user attempts to
authenticate.
Note: If the application does not generate a machine nonce, then the
application must provide machine fingerprint data.
After generating a machine tag or machine fingerprint (or both), Entrust

IdentityGuard stores a copy of the information in the repository as a machine secret.
For maximum security, it is recommended that your application generate both a
machine fingerprint and a machine tag (with both the machine nonce and sequence
nonce).
If your user machines do not allow persistent objects (such as cookies or flash objects)
to be stored, your application can provide just the machine fingerprint data. In this
case, it is recommended that the application collect as much application data as
necessary to differentiate between similar computers.
Using machine fingerprints alone provides a lower level of security than using
machine tags, especially in homogenous environments. When all or most of the users
in your organization use the same software, with the same options, and the same
version numbers, the machine fingerprint is less likely to be unique for each user. In
Feedback on guide
this case, it is strongly recommended that you use persistent objects such as cookies
to uniquely identify the user logging in.
The recommended algorithm for the use of machine secrets is to use persistent data
whenever possible, and machine fingerprints when storing cookies or flash objects is
not possible is:
• If cookies are enabled, then store cookies
• If cookies are not enabled, then store flash objects
• If cookies and flash objects are not enabled, then provide fingerprint data
Computer registration process

The computer registration process is similarly performed for all computers a user
wants to register. In Figure 15, selecting Remember me on this machine sets machine
authentication into action.
Figure 15: Login page with machine authentication
During subsequent logins:

1 The application retrieves the machine tag and regenerates the machine
fingerprint.
2 Entrust IdentityGuard compares the machine tag and machine fingerprint to the
machine secret stored in the repository.
3 If the machine tag and machine fingerprint match the machine secret, Entrust
IdentityGuard authenticates the user.
4 The application changes the sequence nonce and Entrust IdentityGuard stores an
updated version of the machine secret in the repository.
Entrust IdentityGuard’s machine authentication provides protection for users even if
they have had other authentication data stolen by attackers. Because it is unlikely that

Feedback on guide
an attacker would enter the stolen credentials from the user’s computer, the machine
authentication fails and the attacker cannot obtain access.
Sources of machine fingerprint data

There are several ways to create a fingerprint of a particular computer. The choice
depends on the method chosen to gather fingerprint data.
Basic Web browser without client-side software

This requires a Web browser only. From the user’s perspective, it is the least invasive
method of gathering the information for a machine fingerprint.
Your program needs to set a cookie within the browser for subsequent authentication
comparisons of the user’s machine fingerprint. This may not always be possible; some
users set their browsers so that cookies cannot be saved.
There are two ways of gathering data from a Web browser without requiring
client-side software. You can use the browser Get request or JavaScript.
Through a Web browser Get request, the application can identify a browser using the
HTTP headers present in the browser’s request to the server. Unfortunately, all data
returned is quite predictable, even to an attacker who has never seen a particular
browser’s request. Figure 16 shows a sample Get request.
Figure 16: Sample browser Get request

GET /cgi-bin/inputdump.exe HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: anyserver.anybank.com
Connection: Keep-Alive
Cookie: intranetredirectURL=; GA_SHOW_TABS=; LASTSITE=intranet
Due to the predictability of standard Get requests from a browser, it is recommended
that you do not use these fields on their own. Some fields (such as user-agent) may
be useful as part of a broader machine fingerprint. Use other methods described in
this section to create a unique machine fingerprint.
Instead of Get requests, your Web application can use standard JavaScript calls to
gather information. This involves a minor modification to the application’s login page
to collect the wider range of data needed for the machine fingerprint. All the
following pieces of information are available through standard Javascript calls without
requiring any client-side software.
Feedback on guide
Note: The properties in Table 12 were collected using JavaScript on an Internet
Explorer browser running on Windows. Similar properties are available on other
browsers, but the names and values may be different.
Table 12: General properties
Property Value
navigator.appCodeName Mozilla
navigator.appName Microsoft Internet Explorer
navigator.appMinorVersion ;SP2;
navigator.cpuClass x86
navigator.platform Win32
navigator.systemLanguage en-us
navigator.userLanguage en-us
navigator.appVersion 4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; .NET CLR 1.1.4322; .NET CLR
2.0.50727)
navigator.userAgent Mozilla/4.0 (compatible; MSIE 6.0; Windows
NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR
2.0.50727)
navigator.onLine true
navigator.cookieEnabled true
screen.availHeight 1170
screen.availWidth 1600
screen.bufferDepth 0
screen.colorDepth 32
screen.deviceXDPI 96
screen.deviceYDPI 96
screen.fontSmoothingEnabled true
screen.height 1200
screen.logicalXDPI 96
screen.logicalYDPI 96
screen.updateInterval 0

Feedback on guide
Table 12: General properties (continued)
Property Value
screen.width 1600
Note: The properties in Table 13 and Table 14 show just a portion of the MIME
and plug-in information available. They were collected using JavaScript on a
Firefox browser running on Microsoft Windows. Similar properties are available
on other browsers, but the names and values may be different.
Table 13: MIME properties (partial list)
Property Value
navigator.mimeTypes[0].description Mozilla Default Plug-in
navigator.mimeTypes[0].suffixes *
navigator.mimeTypes[0].type *
navigator.mimeTypes[1].description Java
navigator.mimeTypes[1].enabledPlugin. NPOJI610.dll
filename
Table 14: Plug-in information (partial list)
Property Value
navigator.plugins[0].description Default Plug-in
navigator.plugins[0].filename npnul32.dll
navigator.plugins[0].length 1
navigator.plugins[0].name Mozilla Default Plug-in
navigator.plugins[1].description Java Plug-in 1.5.0 for Netscape
Navigator (DLL Helper)
Given the wide range of information available, some of which may be too common
to be useful, it is recommended that organizations consider the use of a combination
of elements gathered through JavaScript such as:
• browser version
• browser plug-ins present
• browser language being used
Feedback on guide
• browser platform (user’s operating system)
• screen size of user’s computer (height and width)
• screen color depth
Basic Web browser with client-side software

You can deploy signed Java applets or ActiveX controls that leave the Java sandbox
and allow the applet to access the system directly. This involves the user seeing and
accepting security notifications on a regular basis. While more secure, it is less than
ideal for large-scale deployments. However, there may be instances where this is the
best practice since it allows organizations to gather more detailed physical machine
data for use in a machine fingerprint.
Elements that could be gathered in this scenario include:
• media access control (MAC) address of the user’s Ethernet card
• exact operating system (OS) information including the service pack and
patch level
• system information including native byte order and number of available
processors
• hardware information (manufacturer, model, version, and so on) of various
hardware devices (network card, video card, hard drive, CD reader/writer,
processor type)
• CPU processor ID (if enabled)
• user information (account name and home directory)
You can combine these elements with other available elements to create the machine
fingerprint.
Web application (server-side)

You can augment the information available through JavaScript and client-side
software with data available from the Web application. Figure 17 shows information
gathered by a simple server-side CGI.
Figure 17: Sample Web application data

HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.10) Gecko/20050716 Firefox/1.0.6
HTTP_ACCEPT=text/xml,application/xml,application/xhtml+xml,text/ht
ml;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5
HTTP_ACCEPT_ENCODING=gzip,deflate
HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7

Feedback on guide
HTTP_KEEP_ALIVE=300
HTTP_CONNECTION=keep-alive
HTTP_COOKIE=LASTSITE=anybank;
intranetredirectURL=https%3A//anyserver.anybank.com/download/cnbc.
htm; GA_SHOW_TABS=0%2C1%2C2%2C4
REMOTE_ADDR=10.4.132.9
REMOTE_PORT=1294
Much of this information is derived from the HTTP headers in the Get request (see
Figure 16 on page 57). This list includes a port and IP address for the user. Port
information may change each time and is not a useful property for a machine
fingerprint. You can also use a user’s IP address to look up geolocation information.
Entrust IdentityGuard can store additional application data specified by your
organization, including data that may be gathered with standard APIs through
external data sources. (For example, geolocation services can estimate the
geographic location of the user based on the IP address of the PC.)
Table 15: Machine authentication advantages and considerations
Advantages • It provides users with a seamless login experience.

Considerations • Determine whether users ever access your site through a public
computer (such as from a library). Using machine authentication
on public computers is a security risk and is not recommended.
• Determine how many machine secrets users can have. Users may
have more than one machine secret if they access your site from
more than one computer. For example, a user may access your
site from a work computer and from a laptop.
• Determine whether your application will generate a machine tag
or machine fingerprint, or both.
• Determine how to obtain the machine information (depending on
the browser type, a client-side application, and so on). See the
Entrust IdentityGuard Programming Guide for more information.
• If generating machine fingerprints, determine what application
data you want to collect.
• Determine how many elements in the machine fingerprint must
successfully match the machine secret for successful
authentication.
For example, if one of the elements is the browser version and in
a subsequent authentication that version has changed (the user
upgraded the browser), it may still make sense to allow that user
access.
Feedback on guide
Risk-based authentication
There are situations in which you want to present users with an extra authentication
challenge or reject the users outright for security reasons. Alternatively, you may want
to automatically authenticate users who pose no risk.
Setting risk policies

You can set two risk assessment policies—normal and enhanced—in Entrust
IdentityGuard that determine how your application reacts in the five risk scenarios
below:
1 A user logs in from a different computer than usual and machine authentication
fails. For more information, see “Machine authentication” on page 55.
2 A user logs in from an IP address that is not in the user’s location history list (IP
addresses the user authenticated from recently). For more information, see “IP
geolocation” on page 63.
3 A user logs in from two separate geographic locations in a suspiciously short
period of time. This is known as a velocity test. For more information, see “IP
geolocation” on page 63
4 A user logs in from an IP address that is on the IP blacklist. For more information,
see “Blacklists” on page 63.
5 A user logs in from a country that is on the country blacklist. For more
information, see “Blacklists” on page 63.
For example, your normal security policy might reject the user in the case of 4 and 5,
and issue an authentication challenge in the other three cases. In comparison, the
enhanced security policy might reject the user in all cases but 1 and 2.
Setting authentication policies

For any user not rejected by the risk policies described above, you can set other
policies that determine when those users can enter a site without an authentication
challenge. The choices are:
1 If either machine authentication or IP authentication pass, automatically
authenticate the user.
2 If just IP authentication passes, automatically authenticate the user.
3 If just machine authentication passes, automatically authenticate the user.
4 If both IP authentication and machine authentication pass, automatically
authenticate the user.
5 Always present the user with a challenge.

Feedback on guide
These five choices are logically ordered in strength from weakest (1) to strongest (5).
The policy you set for the enhanced level must be equal to or stronger than the
normal policy.
The challenge or challenges presented to the user can be any of those described
previously in this chapter: grid, passcode list, token, knowledge-based (question-and-
answer) and one-time password.
IP geolocation
Entrust IdentityGuard includes a mechanism to determine the approximate
geographical location of the IP address of any user who attempts to access your site.
The location data consists of the country, region, city, Internet service provider (ISP),
latitude, and longitude.
With this data, Entrust IdentityGuard determines if the user passes your risk and
authentication policies.
• Compare the current location with the list of expected locations. If there is a
match, the user passes the expected location test.
• Compare the current location with the list of locations previously associated
with the user. If that location matches one on the list, the user passes the
location history test.
• Compare the current location with the last location associated with the user.
If the user changes locations faster than physically possible, the user fails the
velocity test. For example, if the user logs in from Toronto at 10:00 a.m. and
then logs in from New York a few minutes later, it is likely that one of the
logins is not legitimate.
• Compare the current location with all locations on the IP and country
blacklists. If a user's location is on a blacklist, the user is rejected.
Blacklists
Through the Administration interface or the master user shell, you can review and
update blacklists containing country codes and IP addresses.
You can have multiple country blacklists. This way, you can apply different lists to
different groups of users. A country blacklist consists of the two-character Internet
domain codes assigned to each country. The default list included with Entrust
IdentityGuard contains A1 codes, which are addresses that belong to anonymous
proxy services, and A2 codes, which relate to satellite-based Internet providers that
conceal the country of origin.
You can have a single, system-wide IP blacklist that applies to all users. To keep the
list compact and easy to maintain, each entry you add to the blacklist can specify a
range of IP addresses. For example the entry “100.1.1.1 100.1.1.10” represents 10
Feedback on guide
IP addresses. (The blacklist supports only version 4 IP addresses.) By default, the IP
blacklist has no entries.
Table 16: Risk-based authentication advantages and considerations
Advantages • Provides a flexible risk-assessment mechanism.

• Lets you block users from high-risk Internet domains or
geographic locations.
• Lets you match the authentication methods to the risk level of the
user or groups of users.
• Lets you automatically authenticate low-risk users.
Considerations • The IP location data relies on third-party data sources. Entrust
IdentityGuard supports Maxmind. (For more information, visit
http://www.maxmind.com.) You can customize the interface to
support other data providers.
• You need to update IP location data on a regular basis—at least
monthly. Downloads are available on the Entrust TrustedCare
Online Web site.
• Determine how many entries you want for the location history
list.
• Set a standard for the velocity test.
• Make sure your Web application can supply valid IP addresses to
Entrust IdentityGuard.

Feedback on guide
Temporary PIN authentication
In situations where the user does not have their grid card, token, or passcode list, you
can issue a temporary PIN, either for a specific number of uses or for a limited period
of time. Examples of this situation include lost grid cards or tokens, or a newly
registered user waiting for their grid card or token to arrive. Temporary PINs are only
available for grid card or token authentication.
Temporary PINs are issued with limits on the number of uses and expiry dates to limit
exposure to attacks. These values are configured by administrators, who need to take
into consideration how long it will take to deliver a replacement grid card or token to
the user.
Table 17: Temporary PIN authentication advantages and considerations
Advantages • It allows users to log in even if they have forgotten or lost their
grid card or token.
Considerations • It is only available if using token or card authentication (either grid
or passcode list).
• It requires policy considerations such as: expiry mode (either time
or use-based), minimum length, characters to use, character
replacements, challenge size, and automatic deletion when a user
begins using their grid card or token.
• You should only use this method as a temporary second-factor
authentication solution and not as a permanent second-factor
authentication solution.
Feedback on guide
Using personal verification numbers
For additional security, you can require a user to enter a personal verification number
(PVN) during an authentication challenge. For example, when a user enters grid
coordinates, you can also prompt for their PVN number to validate the grid card user.
A PVN can be used with a card (grid or passcode list), token, temporary PIN, or
one-time-password authentication challenge.
Each user can have just one PVN. The PVN is a numeric value whose length is set by
policy. Users can pick their own PVNs or administrators can auto-generate random
PVNs and assign them to users.

Feedback on guide
3
Planning your deployment

This chapter discusses items to address prior to, or during, the deployment of Entrust
IdentityGuard.
• “Planning: initial considerations” on page 68
• “Planning administrative tasks” on page 73
• “Planning user requirements” on page 75
• “Group requirements” on page 79
67
Planning: initial considerations
This section identifies, at a high level, both the technical and nontechnical aspects
that need to be addressed for a successful deployment. These aspects can be
categorized into the following five areas:
• authentication methods
This refers to the authentication methods supported by Entrust
IdentityGuard and that your organization requires to verify user identities.
Examples include considering the requirements for second-factor and mutual
authentication, and how to implement the methods into your existing
authentication structure.
See “Authentication methods” on page 33.
• policies and practices
This refers to the specific security policies supported by Entrust IdentityGuard
and the practices used by your organization to implement these polices.
Examples of policies for Entrust IdentityGuard include the size of the grid or
passcode list, the length of a challenge, the number of authentication factors,
the use of a personal verification number (PVN), the inclusion of blacklists,
and the number of incorrect attempts before lockout.
See “Entrust IdentityGuard policies” on page 69.
• people
This refers to the personnel required to deploy, operate and support Entrust
IdentityGuard.
See “People” on page 70.
• architecture and technology
This refers to the technical aspects of supporting Entrust IdentityGuard, such
as the networking environment, operating systems, hardware and software,
and application integration. Examples include the environment in which
Entrust IdentityGuard is deployed, and the applications that Entrust
IdentityGuard protects.
See “Entrust IdentityGuard components” on page 23 and “Entrust
IdentityGuard baseline architectures” on page 153.
• operations
This refers to the ongoing operational aspects of Entrust IdentityGuard and
the procedures needed to support, administer, and operate Entrust
IdentityGuard. Examples include the initial deployment of grid cards or
tokens, and the distribution and activation of replacement grid cards or
tokens.
See “Operations” on page 71.

Feedback on guide
• “Entrust IdentityGuard policies” on page 69
• “People” on page 70
• “Operations” on page 71
Entrust IdentityGuard policies

Organizations generally have existing polices and practices around the identification
and authentication of users. The processes used for user identification and
authentication to the existing application will apply to Entrust IdentityGuard
configuration and deployment.
Entrust IdentityGuard, through its policy set, defines the permissible behavior of
users, administrators, and authentication methods. When deploying an Entrust
IdentityGuard system, you need to decide what types of policies you need and how
many you need based on user and authentication requirements.
Policies are associated with groups in Entrust IdentityGuard. This means you can
create different policies for your system, based on the different requirements of
different user groups (“Group requirements” on page 79).
For example, Entrust IdentityGuard uses policies to determine:
• password rules for administrators when logging into the administration
interface.
• what grid cards should look like (for grid authentication).
• how users interact with Entrust IdentityGuard (for example, how many
invalid password attempts users can make before being locked out, and what
authentication methods are available to them).
• when to include a PVN with a challenge.
• temporary PIN rules (for grid, passcode list or token authentication only—
you can assign a temporary PIN to a user when a grid card or token is lost or
forgotten).
Organizations should:
• Set up security policies that contain statements regarding appropriate user
security measures, such as keeping grids, passcode lists, or tokens out of
sight when not in use and memorizing PVNs, answers, and other
information.
• Train users on the importance of protecting their Entrust IdentityGuard
authentication information and keeping it confidential. This can be done
through security awareness training and internal communications.
• Consider the requirements for identity verification during enrollment and for
grid card and token replacement. These requirements will be driven primarily
by the business value of the applications being protected with the Entrust
Planning your deployment 69

Feedback on guide
IdentityGuard authentication methods. Choosing to add Entrust
IdentityGuard authentication to the application indicates that there is a
substantial value involved.
For information on specific policies, see the Entrust IdentityGuard Administration
Guide.
People
As with any system, Entrust IdentityGuard’s deployment and ongoing operation
requires the participation of people from different parts of your organization.
Although many people are required only on a part-time basis, identifying them and
communicating their roles and responsibilities early in the planning process can help
avoid delays later.
Table 18: People required for the deployment and operation of Entrust IdentityGuard
Person or people Job description

Overall project manager Act as a single point of contact for the project and have the authority
(recommended) to secure additional resources.
Technical lead Bring knowledge of the organization’s technical environment to the
project. Throughout deployment (along with other personnel), obtain
the necessary knowledge to support the production implementation
into the operational phase.
Directory administrator Administrate the directory (if integrating with an LDAP-compliant
directory).
Database administrator Administrate the database (if integrating with a JDBC-compliant
database).
Network and systems Provide support during the planning and installation phases.
administrators
Application Provide support for the application integration.
development personnel
Operations personnel Provide support for the operational requirements after deployment.
Customer Support and Integrate support services for Entrust IdentityGuard into the existing
Help Desk personnel support mechanisms.
Hardware procurement Obtain any necessary hardware (such as servers, grid cards, and
personnel tokens).
System support Carry some of the responsibility for the ongoing support of Entrust
personnel IdentityGuard.
Note: These people may be representatives from other groups in your
organization.

Feedback on guide
Operations
Operation planning encompasses back-end operational aspects such as server
administration and operations, backup and recovery, and maintenance and upgrades.
It also includes the systems required for customer support. Entrust IdentityGuard is
added to an existing application infrastructure; in most cases, only minor updates to
existing system administration procedures are required.
Entrust IdentityGuard maintains log files to assist administrators in troubleshooting
activities. For more information on these logs, see the Entrust IdentityGuard
Backup and recovery

Update your regular backup and recovery procedures with new information about
the Entrust IdentityGuard Server and its operation.
• If Entrust IdentityGuard is integrated with an existing directory or database,
repository backup and recovery will be handled through the existing
processes for these repositories.
• If a new repository is implemented for Entrust IdentityGuard, backup and
recovery processes should be established and documented in accordance
with your organization’s existing standards for data backup.
• Update your organization’s disaster recovery plan to include Entrust
IdentityGuard.
The Entrust IdentityGuard Administration Guide provides information about backing
up Entrust IdentityGuard Server application files, along with information about
recovery steps.
System monitoring
Entrust IdentityGuard operation generates a series of audit messages that can be
written to a file or stored in a database. These audits should be examined periodically
as a way of understanding the kinds of activities that are most common, and as a way
to monitor system health. There are three types of audits written: INFO, WARNING,
and ERROR. In the WARNING and ERROR cases, messages are also written to the
system logs.
You can also choose to send selected audit data to a database, either your Entrust
IdentityGuard database, or a separate database that you configure for audit data.
This allows you to generate scheduled or on-demand audit reports. If your Entrust
IdentityGuard installation uses an LDAP repository, you must configure a database for
audit reporting.
As an added benefit, your Entrust IdentityGuard installation can also be configured to
send selected audits as traps to your SNMP manager. This allows your support staff

Feedback on guide
to be notified immediately of system or performance problems, improving their
response time.
Other precautions
Locate the Entrust IdentityGuard Server and related systems in a secure facility
designed and constructed to support the hosting of IT systems infrastructure. Such
hosting facilities are typically equipped with perimeter security barriers, surveillance,
air conditioning, uninterrupted power supply and fire protection. Implement physical
access controls to ensure that only those authorized to perform operations or support
services are allowed to enter the Entrust IdentityGuard region, which may be a
separate room or a lockable cabinet.
Depending on your organization’s approach to deploying applications into
production, additional implementations of Entrust IdentityGuard into test or staging
environments may be required.

Feedback on guide
Planning administrative tasks
Besides the people required to deploy Entrust IdentityGuard (see “People” on
page 70), you need to plan for people who will administer Entrust IdentityGuard and
its users.
You must assign the following Entrust IdentityGuard roles:
• Master User 1, Master User 2, and Master User 3. Assign a different person
to each of these three roles. These people are required during the initial
installation of Entrust IdentityGuard and after an upgrade or restore.
Administrators perform most other duties.
• One or more administrators. Assign administrative privileges to people in
your organization so that they can manage the Entrust IdentityGuard system
and users. You should have one administrator super user, who can do
everything, and other administrators to manage groups and roles, configure
Entrust IdentityGuard, and manage policies.
Note: In Entrust IdentityGuard, any user can become an administrator if you

assign that user one or more roles.

• “Assigning master users” on page 73
• “Assigning administrators” on page 74
Assigning master users

Assign one of the master user roles to the deployment project technical lead. Master
users can perform the following activities using the Entrust IdentityGuard master user
shell:
• initialize the system
• export the master keys
• create and manage administrators
Consider the following when assigning the three master user roles:
• The master user role allows extensive administrative capabilities. Assigning
staff to these roles should be in compliance with existing policies on
administration staff.
• Identify who your master users will be before installing Entrust
IdentityGuard. Ensure the master users are scheduled for the installation and
that they have a password ready. During the initialization process, Entrust
IdentityGuard prompts the three master users to enter their passwords for
the user names Master1, Master2, and Master3. The passwords must be a

Feedback on guide
minimum of eight characters in length, and contain upper and lowercase
characters and a numerical value.
• For security reasons, master users do not have administrator privileges within
the Administration interface. An administrator who is also a master user
requires two identities. See the Entrust IdentityGuard Installation Guide and
the Entrust IdentityGuard Administration Guide for more information.
• Once you identify the master users, provide appropriate training. Update
existing documents (such as operational procedures, administration guides,
and training materials) or create new documentation as required.
Assigning administrators
Administer Entrust IdentityGuard and its users through the Administration interface.
This interface allows administrators to manage Entrust IdentityGuard policies, groups,
users, grid cards, tokens, configuration, and so on, and to handle day-to-day
interaction with the users (for example, requests for temporary PINs). You can enter
user information individually or by importing a file of user IDs.
Consider the following when determining the number and levels of administrators
you require:
• Each administrator is assigned a particular role or set of roles, which defines
which operations they can perform. Roles include a set of permissions that
govern what actions an administrator can perform.
For example, you can restrict an administrator who works at your Help Desk
to
– reset user accounts once they’ve been locked out
– manage temporary PINs
– view user account information
For more information about roles, see the Entrust IdentityGuard
• Administrators access the administration interface using password
authentication. You can optionally add grid or token authentication as well.
• Each administrator is assigned a set of user groups to manage.
• Administrators belong to a group, which determines their policy settings.
This group does not have to be a group they manage. See “Group
requirements” on page 79.
• The Properties editor gives administrators with applicable permissions to
access all Entrust IdentityGuard properties. Only administrators with a very
good understanding of Entrust IdentityGuard should be given access to the
Properties editor.

Feedback on guide
Planning user requirements
Users are separated into different categories:
• the authentication methods you require they use
• how they are accessing your site
• how they are grouped
• the number of user names they have

• “Alias and user ID requirements” on page 75
• “Training users” on page 76
• “Providing services to users” on page 77
• “Locking out users based on authentication method” on page 77
• “Suspending users” on page 78
Alias and user ID requirements

Users must have a user ID (usually their user name in the first-factor authentication
system) and can have one or more aliases (additional user names) so that different
applications can share one Entrust IdentityGuard authentication method. For
example, one may use a Windows domain user name while another may use the
user's email address. Entrust IdentityGuard allows a user to have a single
authentication method such as a grid card for authentication to all these applications.
To set this up, an administrator can specify a list of aliases as well as a user ID for a
user. When performing authentication or administration operations on the user, your
application can return either the user ID or an alias.
A user ID consists of the user name and group name, written in group/username
format. For example, if the user’s name is alicel who is in the group gold, the
information passed from the application to Entrust IdentityGuard can be in the form
gold/alicel. Entrust IdentityGuard processes it as follows:
• If the user ID contains the group name, Entrust IdentityGuard has a unique
match and uses the associated user account.
• If the user name does not contain the group name, Entrust IdentityGuard
searches for all users with the given name as their user name or an alias
following these rules:
– Search all repositories for all users with the given user name. For an
LDAP-compliant directory, look in all search bases.
– If no user entries are found, return an error.
– If one user entry is found, use that entry.

Feedback on guide
– If multiple user entries are found, check if one of those entries is in the
default group. If it is, return that entry. If not, return an error.
If you are using groups, it is recommended that client applications send both the
group and user name to Entrust IdentityGuard. See “Group requirements” on
page 79.
User names and aliases must be unique within a group. For example, two users in the
same group cannot use the same alias, even if the alias is used with different
applications.
If you plan to allow aliases, consider the following:
• Determine all user access points that will be protected by Entrust
IdentityGuard.
• If the same user has multiple user names, determine the maximum number
of aliases each user requires.
• Ensure that, when dividing users into groups, the user names and aliases are
different in each group.
• If you have similar user names and aliases across different groups, ensure that
your applications return the user ID in group/username format.
Aliases in a consumer deployment

Related Web applications often use different user IDs for the same person, such as
banks with brokerage and credit card divisions. Users typically have different
identifying credentials for their bank account, online broker, and bank-issued credit
card. In some cases, they have different user IDs for their checking and savings
accounts. When the user logs in to the bank’s Web site, users want a seamless
interface to all their financial records and transactions. They want to flip between
their bank accounts, credit card purchase list, and stock portfolio.
Entrust IdentityGuard allows a user to have a single means of authentication (such as
a grid card or token) for all these applications. It permits an administrator to specify
more than one ID for a user. This consists of the primary user ID and a list of aliases.
When performing authentication operations on users, the users can specify either
their user ID or an alias.
Training users
When deploying Entrust IdentityGuard, you must train your users to use the new
authentication methods and have them register as required. Also, if you have
Microsoft Windows desktop users, they must install the Entrust IdentityGuard
Desktop Client for Microsoft Windows.
When planning training for users, consider the following:
• Inform users of Entrust IdentityGuard and your company’s plans for
implementation before deployment.

Feedback on guide
• Create a flash demo or similar video that illustrates how to use the new
authentication methods.
• Ensure that the login page that includes the Entrust IdentityGuard challenge
is visually clear and uncluttered, with easy-to-navigate help links.
• Educate users on appropriate handling of tokens, grid cards, and PVNs.
The interaction points with the users will vary depending on how the user life cycle
management processes are implemented. See “Life cycle management overview” on
page 140 for more information.
Providing services to users

An organization can implement any or all of the following approaches in providing
services to their Entrust IdentityGuard users:
• over-the-counter
Users physically visit a Service Desk to request enrollment into Entrust
IdentityGuard, or to request a replacement grid card or token. All processes
are completed with the user present. This approach is useful during pilot
phases where a small number of users (for example, less than 100) are
enrolled, and enrollment can be automated in parallel with the pilot.
• self-service
Users access an online application to request enrollment into Entrust
IdentityGuard, or to request a replacement grid card or token. Upon
acceptance of the request, one of the following can happen:
– For grid or token authentication, the users are sent an Entrust
IdentityGuard grid or token (or pickup instructions) with activation
instructions.
– For other authentication methods (such as knowledge-based
authentication), the application can automatically enroll the user or replace
the user’s authentication data.
• central service
An administrator initiates enrollment into Entrust IdentityGuard, or replaces
grid cards or tokens, and issues Entrust IdentityGuard authentication data for
many users at once using bulk operations. This approach is strongly
recommended for rollout to a large user community.
Locking out users based on authentication method

Entrust IdentityGuard includes a locking mechanism that preserves the usability of an
authentication method. Challenges are locked until correctly answered—this is to
prevent attackers from requesting new challenges until they see one they can answer.

Feedback on guide
Users are locked out after a defined number of failed authentication attempts (the
default is three). This prevents a brute force attack whereby the attackers keep
guessing until they get the correct response. Attackers often use automated systems
to perform brute force attacks, so success can be accomplished effortlessly in a short
period of time, unless security precautions are built in.
When the lock out period expires, Entrust IdentityGuard presents users with the same
challenge they failed to answer before lock out. This makes it impossible for attackers
to cycle through a series of challenges until they guess a correct response.
Users can be rejected even before they attempt to authenticate if they fail established
risk-assessment policies. See “Risk-based authentication” on page 62.
Suspending users
Administrators with applicable permission can suspend users. Suspended users
cannot use any Entrust IdentityGuard authentication method to gain access to your
applications.
View suspension as a temporary measure—an action taken while a problem with the
user is investigated and sorted out. To disable a user permanently, delete the user.

Feedback on guide
Group requirements
Entrust IdentityGuard incorporates the concept of groups into the management of
users and policies. Groups are used to subdivide the population of users and
administrators into smaller units, where each unit shares a common set of
authentication and security policies. See “Entrust IdentityGuard policies” on page 69
for more information.
You can also apply different levels of risk assessment (normal or enhanced) to groups
using a policy setting. See “Risk-based authentication” on page 62.
Attention: While you can change a group’s policy settings after the creation of
the group, take care not to invalidate pre-existing grid cards or other
authentication data. For example, if the grid size is increased from five rows to
10 rows after grid cards have been issued, subsequent challenges might include
cell coordinates from the additional five rows that do not exist on the original grid
cards.

• “Groups in a consumer deployment” on page 79
• “Groups in an enterprise deployment” on page 79
• “Analyzing your company’s group needs” on page 80
• “Group implementation” on page 81
Groups in a consumer deployment

There are many ways groups apply to “classes” of users in consumer environments.
Credit card holders may be separated into bronze, silver, or gold classifications.
Loyalty card users may be separated into regular, special, and elite classifications. The
policy for each group can include different authentication methods.
Configure the application to send both the group and user ID to Entrust
IdentityGuard. For example, if the user’s ID is alicel who is in the group gold, the
information passed from the application to Entrust IdentityGuard should be in the
form gold/alicel.
Groups in an enterprise deployment

There are many ways groups apply to users in enterprise environments:
• how they access your site (Windows desktop users or Web users)
• what privileges they have to sensitive information, and therefore, what
authentication methods they require
• functional or geographical similarities

Feedback on guide
• which resources or applications they access
• how they are administered
For example, a business with offices in Tokyo, New York, London and Ottawa may
decide to divide their users into four geographical groups. Within those groups, the
business may divide the users further into remote or office employees. Or, as another
example, you may want to provide only some users with tokens, and group them
accordingly.
Analyzing your company’s group needs

Create a summary of Entrust IdentityGuard groups. Groups affect users,
administrators, and authentication data, so consider the following when defining
groups:
Table 19: Things to consider when creating Entrust IdentityGuard groups
Considerations Comments
What types of users do you • Do you have users in defined groups connecting to your
have that require multifactor company through VPN servers?
authentication?
You will need to enable either the Entrust IdentityGuard
Radius proxy or another VPN server authentication method.
• Do you have distinct groups of Windows users that require
multifactor authentication when logging in to their
computer?
You will need to install and configure the Entrust
IdentityGuard client for Windows.
• Do you have users who access your site using a Web portal?
You can put these users in a separate group with mutual
authentication enabled.
• Which applications will you create, and what types of users
will access each application?
You can group users by the applications they access.
How will you subdivide • What sorts of multifactor authentication do these users need?
these groups?
• Do some users who access your applications require stronger
multifactor authentication than others? Do some require
step-up authentication?
• Should users be grouped across functions, within
departments, or both?

Feedback on guide
Table 19: Things to consider when creating Entrust IdentityGuard groups (continued)
Considerations Comments
How will you administer • Will each group have specific administrators?
these groups?
• Will one central group of administrators administer
everything?
• Will some administrators administer multiple groups?
• Will you have different levels of administration? For example,
will help desk administrators unlock passwords and assign
temporary PINs, and full administrators set up authentication
methods, and so on?
Group implementation
Entrust IdentityGuard implements groups in the following way:
• Groups are defined for both users and administrators.
• A single group is defined as default using a default flag. This group is used
whenever a group is not explicitly defined.
• Grid cards and tokens are associated with specific groups. In order to assign
the grid card or token to a user, the user must belong to the same group as
the grid card or token.
If your system contains only unique user names, then your client applications do not
have to include group names in a user identification request.
When Entrust IdentityGuard needs to verify a user and the application does not
return the group information, Entrust IdentityGuard tries to match the user with the
correct group following these rules:
• First search all repositories for all users with the given user name. For an
LDAP-compliant directory, look in all search bases. See “Repository” on
page 26 for more information on the connection between search bases and
groups.
• If no user entries are found, return an error.
• If one user entry is found, use that entry.
• If multiple user entries are found, check if one of those entries is in the default
group. If it is, return that entry. If not, return an error.
Note: If you are using groups with VPN users, see the Entrust IdentityGuard
Administration Guide for more information on how groups are implemented.

Feedback on guide
Feedback on guide
4
Deployment considerations
This chapter provides information you should consider when deploying Entrust
IdentityGuard in your organization.
• “Application integration” on page 84
• “Application considerations” on page 87
• “Selecting a repository” on page 89
• “Performance testing strategies” on page 91
• “Backing up, restoring and migrating” on page 93
• “High availability and disaster recovery” on page 94
• “Switching over to Entrust IdentityGuard” on page 101
83
Application integration
You can integrate Entrust IdentityGuard with many applications, including Web portal
applications, remote access applications and Microsoft Windows login. Several of
these applications have already been integrated, tested and documented by Entrust
with more to be added over time.
For the latest information on integrated solutions, contact Entrust. See “Obtaining
technical assistance” on page 15 for contact information.
• “Web integration” on page 84
• “Microsoft Windows integration” on page 85
• “VPN remote access integration” on page 85
• “Wireless Access Portal integration” on page 86
Web integration
The Entrust IdentityGuard Authentication API is used to retrieve challenge requests
and authenticate user responses. It is designed to easily integrate with your existing
authentication applications to provide multifactor authentication.
You can create a client application that calls the Authentication API using its Web
service, Java Platform, or .NET interfaces to authenticate users. For more information,
see the Entrust IdentityGuard Programming Guide for your programming language.

Feedback on guide
Figure 18: Web integration using Authentication API
Microsoft Windows integration

Entrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that
communicates with the Entrust IdentityGuard Server. It provides strong multifactor
authentication to the Microsoft Windows desktop (online, offline and remote) and
the network. You can set up integration with Microsoft Windows in two ways:
• for local desktop users (Figure 47 on page 176)
• for remote users (Figure 41 on page 168)
If your deployment includes remote users, you need to add the Remote Access
Plug-in. For more information, see “Entrust IdentityGuard components” on page 23.
VPN remote access integration

Entrust IdentityGuard supports integration with remote access VPN devices to
provide multifactor authentication. This is accomplished through integration with the
Entrust IdentityGuard Radius proxy. The Radius proxy manages communications
between a VPN server and a first-factor authentication resource, which can be a
Remote Authentication Dial In User Service (Radius) server, a Windows domain
Deployment considerations 85
Feedback on guide
controller, an LDAP-compliant directory, or Entrust IdentityGuard. You then use
Entrust IdentityGuard to provide multifactor authentication.
Regardless of the resource you use, the VPN server thinks it is communicating with a
Radius server. It is actually communicating with the Entrust IdentityGuard Radius
proxy. Figure 36 on page 161 illustrates the integration approach. No changes are
required for the VPN client.
With the Entrust IdentityGuard Radius proxy, you can configure some of your VPN
servers to use a Radius server and some to use a different first-factor authentication
resource. You can direct different groups of users to different first-factor
authentication resources. Users who do not exist in Entrust IdentityGuard are
authenticated by the first-factor authentication mechanism only.
See the Entrust IdentityGuard Administration Guide for details on how to configure
the Radius proxy.
Wireless Access Portal integration

Entrust IdentityGuard supports integration with wireless access devices to provide
multifactor authentication. This is accomplished through integration with the Entrust
IdentityGuard Radius proxy. The Radius proxy manages communications between a
wireless access point and Entrust IdentityGuard. You then use Entrust IdentityGuard
to provide multifactor authentication.
Regardless of the resource you use, the wireless access point thinks it is
communicating with a Radius server. It is actually communicating with the Entrust
IdentityGuard Radius proxy. Figure 39 on page 166 illustrates the integration
approach.
See the Entrust IdentityGuard Administration Guide for details on how to configure
the Radius proxy.

Feedback on guide
Application considerations
Define a policy that addresses all the security aspects of the Entrust IdentityGuard
authentication data (whether tokens, grids, passwords, or replay information). These
security aspects need to be defined as a whole, since changing any one of these
aspects affects the overall security of the system. To maximize resistance to attacks,
you can do the following to make it difficult to capture second-factor authentication
data:
• Implement strong session security using SSL or TLS to protect the
transmission of challenges and responses.
• Do not display the challenge values as machine-readable characters.
Machine-readable characters can be easily read by text sniffers and other
attacker tools. Consider converting challenges to images instead of text.
• If you are using grid authentication, implement two-step authentication.
In two-step authentication, users must enter first-factor credentials on one
screen, then enter the grid coordinates on the second screen. Because the
identity of the user is known, Entrust IdentityGuard presents a set grid
challenge. This ensures the challenge remains constant until it is successfully
answered.
• Add an extra challenge for the user’s personal verification number (PVN) to
make sure the grid card or token user is valid.
• Use a mutual authentication method to provide the user with a visual cue
that the site being accessed is legitimate.
For example, display an authentication secret (for example, grid serial
number or image) to the user during login. The absence of the number or
image would suggest the site is fraudulent. See “Mutual authentication
methods” on page 52.
• Use temporary PINs when users have lost or not received their grid, token,
or passcode list.
• Determine which authentication method Entrust IdentityGuard should use, if
the application doesn’t specify.
Integrating with existing user management systems

If you already have a user management system, you can incorporate Entrust
IdentityGuard administration tasks into the application using the Administration API.
The Administration API is the Java Platform or .NET API that you can use to integrate
your applications with the Administration service in Entrust IdentityGuard. The
Entrust IdentityGuard Administration interface is an example of an application using
the Administration API.
Feedback on guide
For more information about implementing the Entrust IdentityGuard Administration
API, see the Entrust IdentityGuard Programming Guide.
Using shared secrets

Entrust IdentityGuard includes a feature called “shared secrets”. Shared secrets are
name and value pairs associated with an Entrust IdentityGuard user and used by a
client application. Shared secrets are not used by Entrust IdentityGuard, but you can
manage them through Entrust IdentityGuard interfaces. They are stored in encrypted
format in the repository.
There are several uses for shared secrets. For example, Entrust IdentityGuard Desktop
for Microsoft Windows uses shared secret information to store the offline temporary
PIN.
Note: Do not confuse shared secrets with authentication secrets or machine

secrets (see “Mutual authentication methods” on page 52 and “Machine
authentication” on page 55).

Feedback on guide
Selecting a repository
Entrust IdentityGuard stores data in a repository. A repository is either an
LDAP-compliant directory or a JDBC-compliant database. An Entrust IdentityGuard
system can contain one or more repositories, including a combination of both
directories and databases.
Whenever an Entrust IdentityGuard operation requires a user's information, Entrust
IdentityGuard searches the repository. Entrust IdentityGuard updates user
information when required by administrative tasks, such as adding a new
authenticator (such as a grid), or during authentication events that involve a
challenge (such as grid coordinates).
When selecting a repository, consider where you currently store first-factor user
credentials (user name and password). Typically you install Entrust IdentityGuard to
augment first-factor user credentials for access to an application, such as a VPN or a
Web-based system. Entrust IdentityGuard is designed to extend the information
stored in existing repositories so you do not have to implement additional technology.
However, directories and databases operate differently and can affect your decision
about which type of repository to select for your system.
Other considerations for choosing between JDBC databases and LDAP directories in
your Entrust IdentityGuard deployment include:
• Reporting audits from a database: If your deployment includes generating
reports of Entrust IdentityGuard audits, you must have at least one JDBC
database deployed in your system. If you are planning to use a JDBC
database for your Entrust IdentityGuard users, grid cards, and tokens, you
can use the same database to store your system audits. If your user repository
is an LDAP directory, you must configure a separate JDBC database for your
Entrust IdentityGuard audit records. See “System monitoring” on page 71
for more information about this feature.
• Using the user enrollment feature to create new users into Entrust
IdentityGuard: User enrollment is supported only for LDAP repositories, so if
you plan to deploy this Entrust IdentityGuard feature, you must use an LDAP
repository for your installation. If your deployment contains both LDAP and
JDBC repositories, only users entered in the LDAP repositories are eligible for
user enrollment into Entrust IdentityGuard. See “User enrollment from LDAP
user repository” on page 142 for more information about this feature.
Entrust IdentityGuard provides a complete Administrative API that you can use (see
“Entrust IdentityGuard Administration service” on page 26), so any differences
between directories and databases can be hidden from users and administrators.
Directory repositories
User entries must exist in the directory before you can populate any Entrust
IdentityGuard attributes. Entrust IdentityGuard cannot create any user entries in a
Feedback on guide
directory. You must create users in the directory with your existing directory
management tool.
Entrust IdentityGuard cannot store unassigned grid patterns and token serial numbers
in a directory, but stores them in either a local file system or a local database. In a
configuration with a directory and a local file system, only a single Entrust
IdentityGuard server can host the local file system, and all assignments of grids or
tokens must be performed on that server. Availability of that server affects your
organization's ability to assign grids or tokens. Using a local database to store
unassigned grids and tokens supports a high availability configuration (see “High
availability and disaster recovery” on page 94).
Entrust IdentityGuard supports many widely-used directories. For more information,
see the Entrust IdentityGuard Directory Configuration Guide.
Database repositories
For databases, no existing user entries need to exist before you can populate any
Entrust IdentityGuard attributes. Entrust IdentityGuard can create new user entries in
a database for you.
Entrust IdentityGuard stores unassigned grid patterns and token serial numbers in
separate tables in a database. Using a database to store unassigned grids and tokens
supports a high availability configuration (see “High availability and disaster
recovery” on page 94).
Entrust IdentityGuard supports many widely-used databases. For more information,
see the Entrust IdentityGuard Database Configuration Guide.
Performance and maintainability

The performance of a repository can be a factor in environments with hundreds of
thousands of users, or in environments where the existing user system is already
heavily loaded. While your choice of repository does not affect Entrust
IdentityGuard's performance, you need to consider the impact of the additional load
on your repository.
You may have your own preferences for a repository based on the level of skill within
your organization to support and maintain it. You should choose a repository that
your organization is equipped to properly support and manage with the required
response timing.
Entrust IdentityGuard supports a combination of both databases and directories,
where each repository can support a different group of users. Your Entrust
IdentityGuard system can use the mix of technologies that best meets the needs of
your users and your organization.

Feedback on guide
Performance testing strategies
You can perform tests to validate the performance characteristics of Entrust
IdentityGuard in your environment. To perform these tests, use a commercial
automated testing tool that allows for the creation of custom scripts that drive the
testing process.
To perform Entrust IdentityGuard performance testing, create a script that simulates
a user receiving a challenge and responding with the appropriate Entrust
IdentityGuard response. The testing tool can then run this script as many times as
needed to create a simulated load of the required size on the Entrust IdentityGuard
Server.
To prepare the Entrust IdentityGuard Server for performance testing

1 Create test users.
2 Set up the test users with their appropriate authentication methods.
• If you are testing performance with grids, ensure the grids are generated,
exported, and assigned to users. However, you do not need to print the grids.
The script needs to have the values from each grid loaded into an array so
that it can provide the correct response.
• If you are testing performance with tokens, ensure the tokens are loaded.
To run the Entrust IdentityGuard performance testing script

After the Entrust IdentityGuard Server is ready for performance testing, you can run
the script. The script must perform the following steps:
1 Load the grid cells, one-time passwords, or tokens into an array.
2 Capture the start time for a transaction.
3 Send a request to the Entrust IdentityGuard Server requesting a challenge.
4 If you are using grids:
a Receive the challenge and parse it for the requested coordinates on the grid.
b Look up the correct values for the response in the grid cells.
c Optional. Pause for “think time” to simulate a person providing the response
to the challenge.
5 Send a request to the Entrust IdentityGuard Server with the values of the grid,
token, or one-time passwords.
6 Receive the response back from the server.
7 Capture the time that the transaction is completed and calculate the elapsed time
since the request.
8 Report the elapsed time of the request to the screen, printer or file, as required.
Feedback on guide
After this script has been run a number of times and under different levels of load,
you can tabulate the results into a report showing the performance of the overall
Entrust IdentityGuard authentication system.
For information about repository size requirements, see either the Entrust
IdentityGuard Directory Configuration Guide or the Entrust IdentityGuard Database
Configuration Guide.

Feedback on guide
Backing up, restoring and migrating
It is strongly recommended that you have a backup strategy in place before you install
or upgrade Entrust IdentityGuard. Backing up your Entrust IdentityGuard system
provides insurance in case something unexpected happens to the servers (such as a
hardware failure). You must use a separate server or separate physical disk to host the
backup files in case of a hard disk failure.
Your strategy should include the following:
• Selecting the type of backup to perform. In Entrust IdentityGuard, there are
two backup options: full backups and partial backups.
– Full backups contain all information required to restore the configuration,
logs, and file-based repository.
– Partial backups contain enough information to restore a replica system.
• Backing up your repository on a regular basis, especially before installing or
upgrading Entrust IdentityGuard. Entrust IdentityGuard does not back up
your data repository for you.
• Backing up and restoring all repositories together if the data is split over
multiple repositories.
• Saving copies of the JDBC driver JAR files you used during installation, if you
use a database repository.
• Backing up the masterkeys.enc file. This file contains the encryption keys
that protect the repository.
• Backing up your logs on a regular basis.
A properly backed-up system can be successfully restored. See the Entrust
IdentityGuard Installation Guide for restore instructions.
The backup and restore mechanism built into Entrust IdentityGuard lets you migrate
from a UNIX platform to a Windows platform, or from a Windows platform to a UNIX
platform.
To perform a platform migration

1 Backup your system configuration using the existing backup mechanism.
2 Copy the backup file to the new platform.
3 Install Entrust IdentityGuard on the new platform and, as part of the
configuration steps, select to restore the configuration from a backup file.
4 Restore the configuration from the backup file.
This migration functionality was introduced in Entrust IdentityGuard 9.0. Older
versions of Entrust IdentityGuard must be upgraded before migrating to another
platform.
Feedback on guide
High availability and disaster recovery
Entrust IdentityGuard offers a failover scheme to ensure there are backup systems in
place in the event that a primary system fails. This scheme addresses high availability
and disaster recovery issues as described here:
• “Entrust IdentityGuard Server hot-standby or load-balancing” on page 94
• “Repository failover” on page 96
• “Radius server failover” on page 100
For procedures for configuring these failover scenarios, see the Entrust IdentityGuard
All data sources (databases, directories, Radius servers, external authentication
sources) that Entrust IdentityGuard uses are listed in specific properties in the Entrust
IdentityGuard properties file. To set up a common failover mechanism, you use the
Properties editor to list two or more URLs for each applicable property. The URLs
point to the data sources or servers.
When Entrust IdentityGuard needs to access a server or data source, it tries the first
URL in the list (known as the primary). If the connection succeeds, Entrust
IdentityGuard uses it until it fails. When the primary fails or is unavailable, Entrust
IdentityGuard tries the second URL in the list. If it fails or is unavailable, Entrust
IdentityGuard tries the next URL, and so on. In failure cases, Entrust IdentityGuard
always restarts at the primary source and traverses the URL list until it makes a valid
connection. During the traversal, the connection that caused the original failure is
skipped.
Entrust IdentityGuard Server hot-standby or load-balancing

You can set up multiple Entrust IdentityGuard servers to operate in load-balanced
mode, or you can set up a separate Entrust IdentityGuard server as a hot-standby in
case the primary server becomes unavailable.
Hot-standby scenario
The hot-standby scenario is shown in Figure 20. The solid line shows the primary
connection, while the dotted line shows the hot-standby connection.

Feedback on guide
Figure 19: Hot-standby scenario
Load-balancing scenario
The load-balancing scenario is shown on the right side of Figure 20.
There are two ways to set up load-balancing:
• Both authentication and administration processes can be load-balanced if
they share the same repository, or their repositories are kept synchronized.
• If authentication and administration are not sharing a repository, only the
authentication service can be load-balanced.
Feedback on guide
Figure 20: Entrust IdentityGuard server load-balancing scenarios
Repository failover
You can configure repository failover to ensure there are backups if the primary
repository fails. To configure failover, use the Properties Editor to specify multiple
repository URLs—either LDAP-compliant directories or databases—in the Entrust
IdentityGuard properties file.
To configure failover for an LDAP-compliant directory or a database, see the Entrust
IdentityGuard Administration Guide.
There are two repository failover scenarios:
• local
• geographically dispersed

Feedback on guide
Local repository failover
In this scenario, the users are usually in one office or city. You can use two databases
or two LDAP-compliant directories in this scenario, but using one of each is not
recommended.
There is a primary repository and a secondary repository. The two repositories are
kept synchronized. If the primary repository fails, traffic is redirected to the secondary
repository.
Figure 21: An example of a local repository failover scenario
Geographically-dispersed repository failover

This scenario demonstrates how you can deploy failover for Entrust IdentityGuard
users in two different cities (for example, Los Angeles and New York). Each city’s
Entrust IdentityGuard Server is connected to its own repository. If the repository in
Los Angeles fails, the Entrust IdentityGuard Server in Los Angeles can connect to the
New York repository.
Feedback on guide
Standard multi-site failover configuration
In the standard configuration, each Entrust IdentityGuard server works from its own
repository, but the two repositories must be perfect replicas of each other.
Note that when you use geographically-dispersed Entrust IdentityGuard servers, both
servers can perform authentication tasks, but the primary Entrust IdentityGuard
server must provide the Administration services.
In Figure 22, the solid lines show the normal operating connections, and the dotted
lines show possible failover connections.
Figure 22: An example of a standard geographically-dispersed failover scenario

Feedback on guide
Advanced multi-site failover configuration
You can also set up separate storage for user, unassigned token, and preproduced
grid data, both in the same repository or in separate repositories.
One site must maintain the master repository, containing and maintaining all of the
data for the full Entrust IdentityGuard systems. The secondary repository maintains
its own local data, which must be uploaded to the master repository at regular
intervals.
Using the example in Figure 23 on page 99, users in Los Angeles would still have
access to their applications and be able to authenticate using the New York server.
In this more advanced configuration, the master repository contains all of the data
and policy information, while the secondary repository contains only local data. This
allows high availability without worrying about the same data being changed in both
repositories. Organizational procedures ensure that the local data in each site is
read-only from the other site, while maintaining all the data from the entire Entrust
IdentityGuard system in the master repository.
Figure 23: An example of an advanced multi-site failover scenario
Feedback on guide
Radius server failover
Configure Radius server failover on the Entrust IdentityGuard Radius proxy to ensure
that there are backup Radius servers if the primary system fails. If a timeout occurs
while waiting for a response from the Radius server—and Radius server failover is
configured—Entrust IdentityGuard Radius proxy uses the next URL address in a list
(for the next request that it receives) and the current request times out. When the
Entrust IdentityGuard Radius proxy reaches the end of the list of URL addresses, it
starts at the beginning of the list again.
To create the list of Radius server IP addresses, see the Entrust Administration Guide.
Figure 24: An example of a Radius server failover scenario

Feedback on guide
Switching over to Entrust IdentityGuard
During migration of an application from single-factor authentication to multifactor
authentication, there will be a mix of users with and without Entrust IdentityGuard
authentication methods. In this case, only users with Entrust IdentityGuard
credentials should be prompted with the additional authentication challenges.
Optionally, you can use an “out-of-band” or alternate activation channel —
something that is separate from the first-factor authentication application. You can
implement this alternate channel as a Web application on the organization’s Intranet
or as an Interactive Voice Response (IVR) system.
If you are using an LDAP repository for your users, you can use the user enrollment
feature to create Entrust IdentityGuard users. For details, see “User enrollment from
LDAP user repository” on page 142.

Feedback on guide
Feedback on guide
5
Deploying grid authentication

This chapter provides deployment information for grid authentication. Most of the
information applies to the deployment of grids, but you should also read this chapter
if you are deploying passcode list authentication.
• “Grid requirements” on page 104
• “Challenge requirements” on page 107
• “Grid card production models” on page 109
• “Physical grid card security” on page 117
• “Physical grid card production options” on page 118
• “Secure file transmission” on page 123
• “Automating processes” on page 124
103
Grid requirements
This section focuses on the items you need to consider before determining what type
of grid best suits your security needs and your users.
• “Grid size and format” on page 104
• “Grid lifetime and replacement” on page 105
Grid size and format

You can configure the size (the number of cells) and format (the contents of cells) of
a grid according to your organization’s policies. Although both are configured, the
grid size has more impact on security than the format of cell contents. (Do not
confuse grid size with challenge size—the number of cells presented to the user at
authentication.)
Grid size impact

The more cells in a grid, the better the resistance to an attacker who has gained some
knowledge of a user’s grid through impersonation.
For example, if an attacker successfully captures one successful login with three
coordinates, they are less likely to receive a subsequent challenge with those
coordinates using a 5 x 10 grid card as compared to a 3 x 8 grid card. To minimize the
probability that an attacker can use captured cells in subsequent challenges, the grid
size should be maximized within the constraints of usability.
Regarding usability, Entrust commissioned independent studies that show equal
usability for a 5 x 10 grid card and a 7 x 12 grid card. This means organizations can
deploy larger grids to users for scenarios that require higher security. For more details
on this and other recommendations, see “Grid card usability study” on page 181.
Note: It may be appropriate within a user population to deploy various grid sizes
depending on the frequency of use and the transaction risk. Entrust
IdentityGuard supports this approach by allowing you to set up users in groups.
See “Group requirements” on page 79.
Grid format impact

Cell format has a direct impact on cell value unpredictability (also called “cell
entropy”), or how difficult it is for someone to guess cell values. Cell format choices
include using alphanumeric characters instead of numeric only, and using more than
one character per cell.

Feedback on guide
Cell entropy is related to the number of potential characters for each cell in the grid.
If a grid uses only single numeric digits, there are just 10 potential entries per cell,
however if the grid uses single alphanumeric characters instead, each cell has 36
possibilities. The greater the number of possibilities, the more difficult it is for an
attacker to overcome the randomness of the challenges.
Table 20 lists the policy considerations related to grid size and format.
Table 20: Policy considerations associated with grid size and format
Policy consideration Recommendations

Rows and columns in grid Maximize the number of rows and columns within physical
form and usability constraints.
Characters in grid Use single alphanumeric characters.
Characters per cell Use one character per cell for maximum usability.
Characters that can replace other Consider having replacement characters for:
characters
• characters that are easily confused with others (for
example, the letters U and V, or the letter O and the
number 0)
• uppercase and lowercase characters (such as A and a)
Grid lifetime and replacement

Grids provide a strong defense against short-lived phishing attacks; however, a
long-term pharming attack could obtain sufficient information over time to gradually
reduce a grid’s effectiveness. Therefore, replace Entrust IdentityGuard grids
periodically to provide continuous protection of your users’ identities. There is no
single replacement period that will work for all applications.
You can configure grid lifetime and replacement based on:
• time (for example, one year)
• usage (for example, when over 50% of the grid is used at least once)
This enables you to fit the renewal cycles to specific risk scenarios or user groups (see
“Group requirements” on page 79). By configuring the grid lifetime and replacement
policies, you can configure Entrust IdentityGuard to address identity fraud risk on a
per group basis, where groups get new grid cards more or less frequently depending
on the risk.
Deploying grid authentication 105

Feedback on guide
Table 21 lists the policy considerations related to grid lifetime and replacement.
Table 21: Policy considerations associated with grid lifetime and replacement
Policy consideration Recommendations

Lifetime based on time or usage? • If your users authenticate infrequently, base the
lifetime of the grid card on time.
• In higher-risk or transaction-intensive situations,
renew a grid based on usage.
Lifetime of card if based on time • Given the short window of opportunity for specific
attacks, a life span of one year or more is
recommended.
Replacement and warning • Scan the logs regularly for warning messages
thresholds regarding replacement thresholds. Build automated
systems to scan the log file for replacement warnings,
or use the Administration interface to search for card
grids that are nearing expiry or usage thresholds and
initiate the replacement process.
• Ensure your users have sufficient time to obtain a new
grid card when their current one is about to expire.
• If a grid expires before a replacement grid card is
received, you can issue temporary PINs. You can use
knowledge-based authentication to validate users’
identities when they call to report an expired grid card.
For more information, see “Entrust IdentityGuard
users” on page 31.

Feedback on guide
Challenge requirements
This section focuses on the factors to consider before determining what type of grid
challenge best suits your security needs and your users.
• “Challenge size” on page 107
• “Challenge algorithm” on page 108
Challenge size
You can configure the size of the Entrust IdentityGuard challenge (the number of cells
in a grid challenge), and this has an impact on the security of the solution.
• The greater the number of cells used in a challenge, the more data is given
away with each observation by an attacker.
For example, should users be tricked into entering a single authentication to
an attacker’s application, they would be giving away twice as much grid data
with a challenge size of six coordinates as with three coordinates. The more
data that is given away, the more quickly an attacker will gather enough data
to answer a challenge from the legitimate application.
• The challenge needs to be of a minimum size to reduce the probability that
an attacker can guess some or all of the challenge coordinate responses.
For example, assume an attacker successfully captures some grid card data
and then attempts to authenticate. The attacker receives a challenge in
which one of the challenge coordinates is already known to the attacker.
With a challenge size of two, the attacker has a much better chance of
obtaining the remainder of the challenge by guessing than if the challenge
size was four, especially since the Entrust IdentityGuard lock-out feature
limits the authentication attempts.
• Find a balance between the minimum and maximum constraints when you
set the optimal challenge size for a given grid size.
For most applications, the optimal challenge size is three. This number
provides the best overall resistance to an attacker guessing remaining
challenge coordinates across a range of observed authentications.
Varying the grid challenge size

Through policy settings, you can present a different number of grid challenges based
on the type of access or transaction the user requires and the risk associated with the
site. For example, access to an internal company intranet portal could require three
grid coordinates while access to an external Web-based investment site could require
four coordinates.

Feedback on guide
Challenge algorithm
Entrust IdentityGuard includes two types of challenge generation algorithms for grid
authentication:
• Random picks cells randomly when creating a challenge (this is the default).
The process for creating one challenge does not depend on previous
challenges.
• Least-used uses a configured number of least-used cells in every challenge.
You can set the policy to use one least-used cell per challenge up to the entire
challenge.
By generating challenges using the least-used cells from an user’s grid, it
becomes more difficult for an attacker who has previously viewed some
successful authentications to correctly respond to the challenge. However, it
limits the useful life of the grid, depending on the least-used threshold (see
“Grid lifetime and replacement” on page 105).

Feedback on guide
Grid card production models
At a high level, Entrust IdentityGuard grid and passcode list production requires the
following activities:
• In an LDAP directory environment, the user must already exist in the
directory.
• Create the user in Entrust IdentityGuard.
• Generate grid (or passcode list).
• Assign grid (or passcode list) to user.
• Produce a physical card containing the grid (or passcode list).
Entrust IdentityGuard provides two models for grid production: a produce-and-assign
model and a preproduction model.
• The produce-and-assign model involves generating a grid for each user as
needed. The produce-and-assign model is suitable for situations where the
user is already known to the organization and already exists in the repository.
• The preproduction model involves generating grid cards in bulk and then
assigning them to users later. The preproduction model is suitable when the
user is not known to the organization or when the grids are assigned to users
after generation.
As illustrated in Figure 25, the order in which these activities occur varies between the
produce-and-assign model and the preproduction model.
Figure 25: Grid production models
Produce -and-assign model
1. User exists in 2. User created 3. Grid 4. Card

primary in Entrust generated for produced
application IdentityGuard user
Preproduction model
1. Grid 2. Card 3. User exists in 4. User created 5. Grid assigned

generated produced primary in Entrust to user
application IdentityGuard
These two models are not mutually exclusive. For example, an organization may use
the preproduction model for new users and use the produce-and-assign model for
existing users. The organization could also use the preproduction model for Entrust
IdentityGuard grid card replacement.

Feedback on guide
• “Produce-and-assign model” on page 110
• “Preproduction model” on page 114
Produce-and-assign model
In the produce-and-assign model, the user (who will receive an Entrust IdentityGuard
grid card) must be known in advance of grid creation. The user is created within the
first-factor authentication application. Then use the Entrust IdentityGuard “Create
User” function to populate the user entry in the repository with the Entrust
IdentityGuard attributes. During the user creation process, a grid is generated for the
user.
In this model, grid card production and distribution must take into account that a grid
has already been created and assigned to a user within Entrust IdentityGuard.
Therefore, the physical card containing the grid must be distributed to the correct
recipient.
This approach is manageable for small-scale usage (a few grid cards a day), where the
entire enrollment process is handled as an over-the-counter service, completed in a
few minutes. One advantage to this process is that it easily supports Entrust
IdentityGuard grid card personalization, such as printing a photograph on the grid
card.
The following subsections provide more detail on how to produce and assign grids
when enrolling existing and new users:
• “Produce-and-assign grids for existing users” on page 110
• “Produce-and-assign grids for new users” on page 112
Produce-and-assign grids for existing users

Follow this procedure if you are using the produce-and-assign model for existing
users.

Feedback on guide
Figure 26: Grid production for produce-and-assign model (existing users)
Optional steps required

1. Entrust 7. Extract user if user delivery
IdentityGuard information into information is not in
Repository 6. Other repository second file Entrust IdentityGuard
Repository .
2. Extract list of 8. Merge two 9. Review and

users files to create deal with errors
production file
3. Generate 4. Export 5. Securely

grids production file transmit file to
card producer
To produce-and-assign grids for existing users

1 Ensure the users already exist in the Entrust IdentityGuard repository.
2 Extract a list of the users from the repository who are to receive grid cards.
3 Import the list of users into Entrust IdentityGuard and generate the grids for those
users. For detailed instructions, see the Entrust IdentityGuard Administration
Guide.
4 Export the selected users’ grids, user IDs, and delivery information into an Entrust
IdentityGuard production file.
5 Securely transmit the Entrust IdentityGuard production file to the grid card
production facility where grids are printed on cards or another appropriate
medium. See “Secure file transmission” on page 123.
Each user ID and grid combination must include the associated user ID and
delivery information. If this information is located in the Entrust IdentityGuard
repository, it is exported along with the user ID and grid. If the information is
located elsewhere, it must be extracted and matched or merged with the user IDs
and grids. The optional process steps are listed below.
6 (Optional) Based on the list of user IDs exported, access other corporate
repositories to obtain the name and mailing information of the selected users.
7 (Optional) Export the user information into a second file.

Feedback on guide
8 (Optional) Merge the two files together to create the Entrust IdentityGuard
production file containing the user information and associated grid information.
9 Report the exceptions in which user information cannot be found for a user, and
resolve them in a separate process.
10 Complete the enrollment process with “Delivery and activation” on page 149.
Produce-and-assign grids for new users

Implement the following steps if you are using the produce-and-assign model for
new users.
Figure 27: Grid production for produce-and-assign model (new users)
2a. Administrator
requests card
1. Entrust 2b. User logs in 3. Generate

IdentityGuard and requests grids
Repository card
2c. Cards 4. Export 5. Securely

requested in bulk production file transmit file to
card producer
To produce-and-assign grids for new users

1 Ensure the user exists in the primary application’s repository. This repository also
serves as the Entrust IdentityGuard repository.
2 Request the grid cards for the new users, using one of the following three
methods:
a Have the administrator request the grid card.
In an over-the-counter approach, the request for an Entrust IdentityGuard
grid card is submitted by the administrator. This approach is manageable for
small-scale usage (a few grid cards a day), where the entire enrollment
process is handled as an over-the-counter service, and completed in a few

Feedback on guide
minutes. One advantage to this process is that it easily supports Entrust
IdentityGuard grid card personalization, such as printing a photograph on it
b Have the user log in to a Web application (or something similar) and request
the grid card.
This login is performed using a current user name and password. For
example:
– An organization implements the application on an internal Web site
accessible to anyone on the network with a valid user name and password.
– The application authenticates the user.
– The user creates a request, using the user name for which the Entrust
IdentityGuard grid card is being requested. This user name must either exist
in the repository or the application must create a new user account at this
time. For example, the user name might be obtained or derived from the
network login user ID to simplify the request for the user.
c Create a central service that uses a bulk operation to generate Entrust
IdentityGuard grid cards for many users at once.
An administrator extracts information from the repository to select users for
whom Entrust IdentityGuard grid cards will be issued. For each user, the
extracted information must contain the user name and delivery information.
The delivery information depends on the delivery method. For more
information see “Delivery and activation” on page 149.
3 Entrust IdentityGuard generates and assigns a grid to each user name.
4 An administrator exports the Entrust IdentityGuard production file. It contains:
• the user name and grid information
• personalization and delivery information extracted from the repository
Using the user name as a key, the extracted information is merged with the grid
data and any information required to print the grid on a physical card. The output
of this process is an Entrust IdentityGuard production file.
Variations will occur in the process. Depending on the service approach, the
Entrust IdentityGuard production file may consist of a single grid or many grids.
An over-the-counter service will produce grid cards one at a time, while the other
approaches produce grid cards in quantity. The processes to produce the Entrust
IdentityGuard production file may merge the request information for new grid
cards, renewal grid cards and replacement grid cards into a single file.
5 Produce the grid cards.
• Send a production file to an application for grid card production and
subsequent delivery. For details, see “Physical grid card production options”
on page 118.
• If you are using the over-the-counter approach, keep a stock of blank cards
at the Service Desk for printing at the time of enrollment. The enrollment

Feedback on guide
process should take only a few minutes and the Entrust IdentityGuard grid
card would be handed to the user on the spot.
6 Complete the enrollment process with “Delivery and activation” on page 149.
Preproduction model
In the preproduction model, users are not necessarily known in advance. A set of grids
is generated, but not assigned to specific users. A grid is assigned to a user at some
point during the user registration and activation process. How and when the
assignment occurs depends on the user administration processes in place.
How the grid card production models are used plays a significant role in user life cycle
management. See “User life cycle management” on page 139.
Figure 28 shows the steps involved in the generation of the Entrust IdentityGuard
production file for the preproduction model. In this model, anonymous grids are
created. Grid assignment happens later in the registration process.
Anonymous grids can be sent to users in the mail. When the user receives a grid card
in the mail, they assign the grid card to themselves at a self-enrollment Web site. At
such a Web site, you can configure Entrust IdentityGuard to challenge the user to
prove that they have the grid card, rather than just ask for the serial number. For
example, after the user enters their serial number, they are presented with a grid
challenge. If the grid challenge fails, the grid card stays in the unassigned state. This
is to ensure that the user does not assign the wrong grid card to themselves by
entering the wrong serial number.
Also, users can receive their anonymous grids in person. For example, a bank teller
can pull a grid card out of a box to give to a customer in a bank branch. In this model,
grid cards should have a tamper-evident sticker that covers the grid, but not the serial
number.
Figure 28: Grid production for preproduction model
1. Generate 2. Export 3. Securely

grids and store in production file transmit file to
repository card producer
4. Card creation and delivery
5. Entrust 6. Create user,

IdentityGuard select card,
Repository assign grid

Feedback on guide
To preproduce grids
1 Create a set of Entrust IdentityGuard grids and assign the grids to a particular user
group. For information about where preproduced grids are stored, see
“Repository” on page 26.
The only information generated after this step is the serial number and contents
of the grid.
2 Export the unassigned grids by writing the serial numbers and grid configurations
to an Entrust IdentityGuard production file.
For information on exporting grids, see the Entrust IdentityGuard Administration
Guide.
3 Securely transmit the Entrust IdentityGuard production file to the grid card
production facility where grids are printed on cards or another appropriate
medium. See “Secure file transmission” on page 123.
4 Produce the grid cards using one of the following methods:
• Send the Entrust IdentityGuard export file to an application for grid card
production and shipment back to the organization, which stores the
unassigned grid cards until needed.
• Append the file with additional information relevant to the grid card
production facility. For example, if grid card production is outsourced then
the outsourcer will need billing information from the requesting
organization.
The remaining steps are completed once the grid cards are created and delivered.
5 If you use an LDAP-compliant directory as the Entrust IdentityGuard repository,
ensure the user entry exists in the directory.
6 Create the user in Entrust IdentityGuard, select the grid card and assign the grid
to the new user, using one of the following methods:
• Have the administrator select the grid card and assign it to the user.
In an over-the-counter approach, the administrator assigns the grid cards
when the user is present and hands the grid card to the user at that time. This
approach is manageable for small-scale usage (a few grid cards a day), where
the entire enrollment process is completed in a few minutes. One advantage
to this process is that it easily supports Entrust IdentityGuard grid card
personalization, such as printing a photograph on the grid card.
• Deliver the grid card to the user, and have the user log in to a Web
application (or something similar) to register the grid. When registering the
grid, the user provides the grid card’s serial number, which is used to assign
the grid to the user.
Login to the Web application is performed using a current user name and
password. For example

Feedback on guide
– An organization implements the application on an internal Web site
accessible to anyone on the network with a valid user name and password.
– The application authenticates the user.
– The user creates a request to set up their Entrust IdentityGuard account,
using the serial number of the Entrust IdentityGuard grid card. This serial
number must be made available to the user either on the grid card itself, or
in documentation sent with the grid card.
Entrust IdentityGuard generates and assigns a grid to each user name regardless
of where the request originated.
Forcing grid card activation

When new Entrust IdentityGuard users are first assigned grid cards, they can continue
to log into your system using just their user name and password until they activate
through Entrust IdentityGuard. This gives users a grace period between the time the
grid cards are mailed and when they are received. However, users can ignore the grid
card enrollment process and continue to log in without using the grid cards even after
they arrive. This represents a way to avoid second-factor authentication.
Entrust IdentityGuard lets you specify through a policy setting that new users must
activate their new grid cards within a certain period of time. After the date implied by
the grace period, their first-factor authentication access is blocked until they activate
their grid card. Once they have activated the grid card, they can never use just
first-factor authentication again.

Feedback on guide
Physical grid card security
Entrust IdentityGuard can be deployed in several ways, although the majority of
deployments will use a standalone physical card for a unique grid.
• Do not put specific information or branding on the grid card that will identify
your site as a potential attack point if a grid card is lost or stolen.
• Include anti-copying measures such as using hard-to-duplicate color
combinations or reflective card materials (though make sure the colors don’t
reduce usability).
• Consider adding a feature to your application to display the user’s last
successful login time and date. If this information does not match the user’s
personal experience, this alerts the user that some form of attack may have
occurred.
• Define a user policy and educate users on appropriate grid card handling to
prevent users from unwittingly exposing their grid data to an attacker, both
physically and electronically.

Feedback on guide
Physical grid card production options
You can choose from two basic options for grid card production:
• in-house (“In-house grid card production” on page 118)
• outsourced (“Outsourced grid card production” on page 119)
If there is no existing grid card production process, or the existing process is
unsuitable, Entrust can help with its own grid card production service capability. See
“Entrust IdentityGuard grid card production” on page 121 for more information.
Note: For users who are visually impaired, you can produce the grid cards with
Braille characters. If you do produce grid cards with Braille characters, ensure that
your application does not conceal challenges (such as presenting challenges as
images), but presents the challenges in machine-readable text.
Entrust IdentityGuard clients have successfully met their 508 standards

obligations using grid cards with Braille characters.
Also see “Grid card production cost factors” on page 121 and “Delivery and
activation” on page 149.
In-house grid card production

Use the in-house approach if you are leveraging existing grid card production
capability (for things such as security badges) to produce and distribute Entrust
IdentityGuard grid cards.
Typical characteristics
The following are general characteristics of deployments involving in-house grid card
production (note that these characteristics do not exclude an outsource approach for
deployment):
• used for Enterprise deployments where grid card production already exists
• grid cards are distributed at either over-the-counter service locations or
through existing corporate mailing facilities
Setup
The following areas need to be addressed prior to starting any in-house Entrust
IdentityGuard grid card production:
• Review internal departmental agreements and process.
• Check the inventory of existing card stock (for example, letter stock, card
artwork, logo, branding).

Feedback on guide
• Create a welcome letter and activation instructions for users.
• Ensure secure intra-departmental transmission capability
– for Entrust IdentityGuard grid card generation information
– for Entrust IdentityGuard grid card distribution (over-the-counter or
internal corporate mail)
Process
The following process steps are required with in-house Entrust IdentityGuard grid
card production. (These steps may vary based on corporate procedures and policy.)
To produce grid cards in-house

1 Securely send the Entrust IdentityGuard production file to the grid card
production location in a secure manner. See “Secure file transmission” on
page 123.
2 Analyze the Entrust IdentityGuard production file and select the appropriate card
or paper stock for printing.
3 Produce the Entrust IdentityGuard grid cards.
4 Notify the user about grid card pick-up and activation, or mail the grid card based
on user address information included in the Entrust IdentityGuard production file;
for example, you can use the company’s internal mailing information.
5 Activate the grid in one of two ways:
• Have an administrator authenticate the user face-to-face at the
over-the-counter service desk.
• Have the user follow the activation instructions contained in the Entrust
IdentityGuard grid card mailing.
Outsourced grid card production

For quantities greater than 1000, Entrust can assist in sourcing an appropriate grid
card production partner. For information about outsourced grid card production
options, contact Entrust (“Obtaining technical assistance” on page 15).
For quantities up to 1000, you can use the Entrust IdentityGuard Card Production
Service. For more information on this service, see “Entrust IdentityGuard grid card
production” on page 121.
If you already use an outsourced grid card production facility, negotiate the contracts
and service level agreements, and update the facility with the new requirements and
procedures for transmitting grid card and user data.

Feedback on guide
Typical Characteristics
The following are general characteristics of deployments involving outsourced grid
card production:
• The organization does not have an internal grid card production capability or
elects not to use the internal capability.
• The organization is a large, geographically dispersed company.
Setup
The following areas need to be addressed prior to starting any outsourced Entrust
• Select a grid card production facility for Entrust IdentityGuard grid card
production and distribution (Entrust can recommend a grid card production
partner).
• Create grid card production partner agreements.
• Write a welcome letter and activation instructions for users.
• Secure inter-organization transmission capability
– for Entrust IdentityGuard grid card generation information
– for Entrust IdentityGuard grid card distribution
• Send grid cards to users or deliver grid cards to the service desk for internal
distribution.
Process
The following steps are involved in outsourcing Entrust IdentityGuard grid card
production.
To outsource grid card production

1 Securely send the Entrust IdentityGuard production file to the grid card
production facility in either an encrypted file format or a secure FTP arrangement.
2 Analyze the production file and select the appropriate card or paper stock for
printing.
3 Analyze the production file for personalization information to be printed on the
individual Entrust IdentityGuard grid cards.
4 Analyze the production file for grid card shipping instructions.
5 Produce the grid cards and insert them into addressed envelopes for distribution.
6 Distribute the grid cards using the shipping instructions provided in the
production file. You can ship the grid cards to the user directly, or distribute the
grid cards from a central location (such as a service desk).

Feedback on guide
7 The user follows the activation instructions contained in the grid card mailing.
Entrust IdentityGuard grid card production

For quantities up to 1000, the Entrust IdentityGuard Card Production Service
(available from Entrust TrustedCare Online) provides a convenient and secure way to
order Entrust IdentityGuard grid cards over the Web. Administrators can order grid
cards online against a previously issued purchase order. Administrators also have the
flexibility to modify the grid card template to meet their requirements.
Typical characteristics
The following are general characteristics of deployments involving Entrust
• The organization using Entrust IdentityGuard grid cards does not have an
internal card production capability or elects not to use the internal capability.
• The organization would like to set up a quick pilot deployment.
• The organization does not need many grid cards (1000 grid cards or less)
Setup
Before starting any Entrust IdentityGuard grid card production, you must select one
of three card options:
• a generic card with a preproduced grid
• a generic card with a customer-assigned grid
• a customer card with a customer-assigned grid
For more information on this topic, see the Entrust IdentityGuard Card Production
Service User Guide.
Grid card production cost factors

There are many factors that influence the cost of Entrust IdentityGuard grid card
production. Table 22 describes a few of these factors.
Table 22: Factors that influence the cost of grid card production
Card/paper quality • The cost increases as the card thickness increases.

• Removable scratch covers increase cost.
Grid Card volume • Higher volumes cost less per grid card.
Branding detail (logos, • More colors and complex graphics increase costs.
colors)

Feedback on guide
Table 22: Factors that influence the cost of grid card production (continued)
Personalization detail • Bulk production of unassigned grid cards is cheaper.

• Personalization requires creating and matching the insert letter
and envelope with the correct grid card for each user.
• Personalization requires the protection of personal information,
which may increase the cost because of secure file transmission.
Distribution • Where and how the grid cards are shipped influences costs.
requirements • Bulk mailing versus individual distribution, standard post versus
courier, and remote geographical locations all affect costs.

Feedback on guide
Secure file transmission
Ensure that the Entrust IdentityGuard production file and any personal information
(for example, name and address) of the user is transferred securely. The following
sections describe several transmission technologies.
Secure Sockets Layer

The Entrust IdentityGuard Card Production Service provides an SSL (Secure Sockets
Layer)-protected Web site with electronic forms that accepts the Entrust
IdentityGuard production file as an attachment. This protects the data by encrypting
it in transit. This technique is simple to employ and uses well-understood technology.
Secure email
You can transmit the Entrust IdentityGuard production file as an attachment in a
secure email using S/MIME or PGP. This ensures that only the intended recipient can
open the file for subsequent processing. You can also digitally sign the email to
validate your identity. This technique is simple to employ and uses well-understood
technology, if you have a secure email system.
Secure FTP
You can transmit the Entrust IdentityGuard production file using an encrypted FTP
session. The data is encrypted in transit and, depending on the implementation, may
also be digitally signed for integrity. It requires the receiving organization to set up a
secure FTP server and to provide access to the sending organization. While the setup
may take longer than SSL or secure email, secure FTP allows for automated
transmission, which is important in very large deployments.
End-to-end encryption
An alternative to secure FTP is to encrypt and digitally sign the Entrust IdentityGuard
production file prior to transmission. You can then transmit the file by any available
means (for example, HTTP, email, or FTP), because only the intended recipient can
open the file for subsequent processing. The recipient can be a person who will
submit the file for processing, or an application that decrypts the file immediately
before processing it. This technique provides the broadest security for the Entrust
IdentityGuard production file, but this technique requires careful planning to
implement. Consideration needs to be given to the management of the encryption
keys, which can be assisted with the use of a public key infrastructure (PKI).

Feedback on guide
Automating processes
To enhance the existing functionality of Entrust IdentityGuard and facilitate
deployment, the following list and highlights areas that are candidates for
automation. Actual implementation details will differ depending upon your specific
requirements and environment.
• Entrust IdentityGuard provides a mechanism for exporting grid cards in XML
or CSV format for existing users. To automate this export, an application
exports the grid information to an XML file. The application could run
unattended as a batch job, and also encrypt the XML information for secure
transfer. Additional functionality to manipulate the format of the file or add
user information may also be required, depending on the requirements of the
grid card producer.
• Depending on the grid card production and distribution model chosen, there
may be a requirement to extract user information, such as name and address,
from other corporate information sources. In this case, you could write a
generic application to extract user information and make it available in an
encrypted XML or CSV file. The application would use the Entrust
IdentityGuard user name as a key to extract the user’s full name and mailing
information.
• Bulk user creation abilities and an automated application allows an
administrator to extract information from the Entrust IdentityGuard
repository and put it into the correct format for input into bulk operations.
• Meet reporting and auditing requirements by developing an application that
generates reports detailing users with grid cards in different states. You can
run this reporting application unattended as a batch job at any time. For
information on the grid card states, see the Entrust IdentityGuard
• Entrust IdentityGuard provides interfaces for administrators to perform user
management activities, and APIs that you can use to build a self-service
application for users. “User life cycle management” on page 139 describes
the process models for user self-service; write a Web application to support
this model using the Entrust IdentityGuard Administration API. For more
information, see the Entrust IdentityGuard Programming Guide that applies
to your programming language (Java Platform or .NET).

Feedback on guide
6
Deploying token authentication

This chapter provides deployment information for token authentication.
• “Using tokens for authentication” on page 126
• “Token deployment” on page 127
• “Physical token security” on page 128
125
Using tokens for authentication
Users can authenticate to Entrust IdentityGuard using tokens. Once Entrust
IdentityGuard and users are set up to accept tokens, users must enter a dynamic
password (the random number generated by a token device) in response to an
Entrust IdentityGuard token challenge.
Your application is not limited to one type of token or one token vendor. You can
configure Entrust IdentityGuard to use a wide range of tokens. The default
installation of Entrust IdentityGuard supports Entrust tokens. Each user can have a
current and a pending token at the same time, and they do not have to be from the
same vendor.
Token lifetime and replacement

Each user can use one token device at a time. However, a user entry can have a
current token and a token in pending state. For example, if the current token has low
batteries, you can associate a pending token with the user entry to replace the
existing token. Once the user authenticates with the new token, the state changes
from pending to current. The old token is canceled by Entrust IdentityGuard.
For more information on token states, see the Entrust IdentityGuard Administration
Guide.
Entering token values

The user’s token device generates the dynamic password (a number) that a user
enters at the challenge. Entrust IdentityGuard checks if the dynamic password is valid
and, if it is, authenticates the user.
A token response to a challenge always includes the dynamic password. When
supported by the token device, the challenge can also include a personal verification
number (PVN). See “Using personal verification numbers” on page 66.
A PVN consists of a string of numeric characters that users must enter with their
dynamic password when challenged by Entrust IdentityGuard. For example, if the
user’s PVN value is 1234, and the dynamic password value is 789789, the user must
enter 1234789789 as the authentication challenge response.

Feedback on guide
Token deployment
Token deployment is similar to preproduced grid card deployment. The main
difference is in the method used to add tokens to the repository. A box of tokens
comes with a data file. You add tokens to an Entrust IdentityGuard repository by
importing the token manufacturer's data file. Once the token data is loaded, you
supply token devices and assign token serial numbers to your users.
When the data file is loaded into the repository, the tokens are loaded as unassigned
tokens. Tokens must be assigned before they can be used for authentication.
Assigning tokens
A master user or administrator assigns tokens to users. Tokens have the same states
as grid cards (pending, hold_pending, current, hold and canceled). Only tokens that
are in the pending and current states are used for authentication. Token states have
the same transition behavior as for grid cards. For more information on token states,
see the Entrust IdentityGuard Administration Guide.
User tokens do not have an expiry date or a superseded date. Any token can be
unassigned and added back to the unassigned tokens list.
Token self-activation
Users can activate their own tokens. When the user receives the token, they must
activate it. The user authenticates (with for example, a user name and password) to
a self-registration Web site. The user enters the serial number of the token; however,
they must also authenticate using the token to demonstrate that they possess the
physical device. After successful authentication, the token is activated. If the
authentication fails, the token is unassigned.
Forcing token activation

When new Entrust IdentityGuard users are first assigned tokens, they can continue to
log into your system through their VPN or other connection using just their user name
and password until they activate through Entrust IdentityGuard. This gives users a
grace period to allow time for tokens to arrive by mail. However, users can ignore the
activation process and continue to log in without using the tokens even after they
arrive. This is one way to avoid second-factor authentication.
Entrust IdentityGuard lets you specify through a policy setting that new users must
use their new tokens within certain period. After the date specified by the grace
period, their first-factor authentication access is blocked until they activate with the
token. Once they activate their tokens, they can never use just first-factor
authentication again.
Deploying token authentication 127

Feedback on guide
Physical token security
Entrust IdentityGuard can be deployed in multiple forms, including a token
deployment.
When deploying tokens, it is recommended that you:
• Do not put specific information or branding on the token that will identify
your site as a potential attack point if a token is lost or stolen.
• Consider adding a feature to your application so that the application displays
the user’s last successful login time and date. If this information does not
match the user’s personal experience, this alerts the user that some form of
attack may have occurred.
• Define a user policy and educate users on appropriate token handling to
prevent users from unwittingly exposing their token data to an attacker, both
physically and electronically.

Feedback on guide
7
Deploying knowledge-based
authentication
This chapter provides deployment information for knowledge-based authentication
(questions and answers). Typically, you integrate Entrust IdentityGuard with your
current knowledge-based authentication application.
To make it easier for users, you can use questions and answers for additional
authentication rather than for your main second-factor authentication method. For
• “Question requirements” on page 130
• “Challenge requirements” on page 135
• “Security considerations” on page 137
Note: Many concepts discussed in the following sections were first presented by
Mike Just in “Designing and Evaluating Challenge-Question Systems” IEEE
Security & Privacy, vol. 02, no. 5, pp. 32-39, September-October, 2004.
129
Question requirements
This section provides you with information about how to create and select a set of
questions for your users to answer.
• “Sources of questions” on page 130
• “Creating good questions” on page 131
• “Selecting a set of questions” on page 133
Sources of questions
There are several methods for developing the questions for knowledge-based
authentication. The methods are discussed in Table 23.
Table 23: Methods for generating knowledge-based questions
Method Considerations
Generated codes • Examples include auto-generated PVNs, PINs, or TANs (transaction
numbers)
• Represents a simple form of question
• Applies to existing users and is extremely useful for encouraging
them to register for new services
Transaction data • Examples include the date and balance of a recent statement.
• Client applications must extract the data from an existing database
to form the questions
• Permits an organization to use information that is already known
about users as a part of knowledge-based authentication.
• Requires client applications to use Entrust IdentityGuard’s
Administration API (see the Entrust IdentityGuard Programming
Guide for more information). This custom application executes the
necessary Entrust IdentityGuard calls to import and manage the data
on a per user basis. Entrust Professional Services can help
organizations with this type of customizing task. For contact
information, see “Obtaining technical assistance” on page 15.
Prepopulated lists • May be necessary to have users register their own questions and
answers. It is recommended that your application present users with
a stock list of questions from which they make selections and provide
answers.
• Gives your organization control over the questions to ensure they
meet criteria for privacy, security, and usability. See “Creating good
questions” on page 131.

Feedback on guide
Table 23: Methods for generating knowledge-based questions (continued)
Method Considerations
User-generated • Allows users to enter their own question-and-answer challenges (not
recommended).
• Users generally do not write well-formed questions.
• Users tend to forget the answers to their own questions more
frequently than stock questions.
• In a design that uses multiple question-and-answer sets, it may make
sense to allow one question and answer that is composed entirely by
the user.
Creating good questions

The questions you choose have a direct impact on how successful your
knowledge-based authentication implementation will be. Measure the questions you
select against the criteria discussed in Table 24.
Table 24: Knowledge-based authentication criteria
Criteria Considerations
Privacy • Organizations are subject to legislation and regulations relating to
the collection, storage, control, and handling of personal
information.
• It is prudent to avoid personal information when building a
knowledge-based authentication system.
• Construct the information collected for question-and-answer sets so
that it is used exclusively for authentication purposes.
Security • Construct questions so that the answers are both difficult to obtain
and difficult to guess.
• For privacy reasons, do not rely on personal information such as
names, family histories and birth dates. Identity thieves regularly find
or steal personal information, rendering the reliability of personal
information almost useless.
• Avoid questions that have a limited number of realistic answers. For
example, What is my eye color? would not require many attempts
to guess a correct answer.
Deploying knowledge-based authentication 131

Feedback on guide
Table 24: Knowledge-based authentication criteria (continued)
Criteria Considerations
Usability • Knowledge-based authentication must be simple and easy for users
to use.
• The questions should have a wide applicability to the organization’s
users. For example, the question What is the name of my first pet?
only applies to pet owners.
• An answer must be easily recalled for the question to be useful.
Questions that reflect user’s habits, regular activities, or practices
generally meet this criteria.
• Answers need to remain constant for the question to be of value.
Questions that prompt for a “favorite” may have different responses
over time, while those that ask for a “first” should not change.
• A user must be able to enter a correct response each time. This is
discussed under “Challenge accuracy” on page 135.
Sample questions
The following are some examples of good questions:
What is your spouse’s middle name? What is your oldest sibling’s nickname?
What is your favorite restaurant? What is your maternal grandmother’s middle
name?
What is your best friend’s first name? What is your oldest child’s middle name?
Who is your favorite fictional character? What is your youngest child’s nickname?
What is the middle name of your oldest Which sports team did you like most as a
sibling? child?
What is the first name of your oldest nephew? What is your paternal grandmother’s first
name?
What is your paternal grandfather’s first name? What was the first name of your favorite
teacher in final year of high school?
What was the name of your first On what street did your best friend in high
girlfriend/boyfriend? school live? (enter full name of street only)
What is the first name of your spouse’s father? What is the first name of your oldest niece?
What is the first name of the Maid of Honour When is your wedding anniversary? (Month
at your wedding? and Year only)
What is the first name of the Best Man at your What is your paternal grandfather’s middle
wedding? name?

Feedback on guide
What is the first name of your oldest child? What is your youngest sibling’s nickname?
What was the first name of your nearest What is the first name of your spouse’s oldest
neighbor in 2000? sibling?
What was the name of your first roommate? What is your mother-in-law’s first name?
What is the middle name of your oldest As a child, what did you want to be when you
sibling? grew up?
What was your favorite college or university What is your maternal grandfather’s first
year? name?
What is the first name of the person you went What is your dream job?
to your prom with?
What is the first name of your best childhood What street did you live on when you were 10
friend? years old?
What is the first name of your oldest niece? What is the first name of your youngest child?
What is the first name of your mother’s How old was your father when you were born?
youngest sibling? (spell out the number)
What is your favorite pizza place? What is your mother’s middle name?
What is your maternal grandmother’s first What is the first name of the youngest of your
name? siblings?
What was the make of your first car? What is your spouse’s middle name?
What was the best holiday gift that you ever What street did your best friend in high school
received? live on? (enter name of street only)
What grocery store do you shop at most often? What was the first name of your first manager?
What is your oldest sibling’s nickname? What is your favorite vegetable?
What is your father’s middle name? What was your grandfather’s nickname?
What is your favorite fruit? What is your favorite fragrance?
What is your favorite charity? What is your favorite hobby?
Where did you meet your spouse for the first What is the first name of your father’s
time? (Enter location only) youngest sibling?
Selecting a set of questions

A common practice is to interact with the user to create several question-and-answer
sets during the enrollment process, then use a randomly selected subset for
subsequent knowledge-based authentication. In addition, your application can use
dynamic transaction data not stored by Entrust IdentityGuard to supplement the
knowledge authentication. Answers to questions such as When was your last

Feedback on guide
mortgage payment? or What was your last transaction value? could be presented
and validated outside of Entrust IdentityGuard. Such questions incrementally add to
the overall security of the deployment.
For usability reasons, users will not tolerate answering a large number of questions
for enrollment, and especially not at the time of authentication. Although you may
require the user to select and answer only a few questions during authentication, it is
recommended that you have a large selection of questions available. This increases
the odds that each user will find an appropriate set of questions and it increases the
system’s resistance to attack by making it more difficult for an attacker to anticipate
a given user’s questions. It is recommended that a user answer a minimum of five
questions (seven is better).
To make it easier on users, you can use questions and answers for additional
authentication rather than as your main second-factor authentication method. For

Feedback on guide
Challenge requirements
This section focuses on the items to consider before determining what type of
knowledge-based challenge best suits your security needs and your users.
Challenge size
You may want a different number of questions presented based on the type of access
or transaction the user requires. For example, access to a company information portal
could require two questions while access to a online investment site could require four
questions. It is recommended that a user answer at least three questions.
You set the minimum and maximum number of required questions in Entrust
IdentityGuard policy, and then set the exact number of questions for each
authentication scenario in your application. Your application must present a number
of questions between the minimum and maximum, and take into account the number
of wrong answers allowed (if applicable).
Challenge accuracy
Once you have determined how many questions a user must answer to authenticate,
you must determine how accurate a user’s answers must be.
Setting how many correct answers are required

Entrust IdentityGuard provides flexibility in the number of questions a user must
answer correctly. You can make it mandatory that all questions be answered correctly,
or you can allow room for error. For example, you can determine that three out of
four correct answers represents a successful authentication.
Setting the accuracy of answers

By default, Entrust IdentityGuard lets you compensate for close answers, common
abbreviations and misspellings of common words (for example, “St.” and “Street”)
with a word map file. You can edit this word map file over time. (For more information
on the word map file, see the Entrust IdentityGuard Administration Guide.)
However, you can also disable the use of a word map file and require exact answers.
In this case, the only leeway Entrust IdentityGuard allows is differences in
punctuation, letter case, and spacing. Entrust IdentityGuard also applies a character
map to support special characters (such as accented characters).
If you take the exact-answer approach, your application should employ the following
techniques to improve the chances of receiving an exact match:
• Standardize responses.

Feedback on guide
Questions that require answers formatted in a standard way (especially
dates), should include drop-down lists or other mechanisms that enforce a
standardized response.
• Avoid syntactic representations.
What do you expect the answer to look like (for example, having to process
“St.” as “Street”)? This requires thoughtful creation of the question.
Allowing a word map (inexact answers) can eliminate most of these
problems.
• Validate the answer set.
You should include rules-based post-processing of the answers given during
enrollment to ensure answer quality. Your application can reject answers that
do not fit your rules and prompt the user for a better answer. For example,
your application should reject:
– sequential keyboard sequences (such as qwertyuiop)
– repeated characters (such as aaaaaaaa)
– answers that repeat the question
– the same answer to different questions

Feedback on guide
Security considerations
Entrust IdentityGuard can be deployed in multiple ways, including a
knowledge-based deployment.
It is recommended that your organization employ the following security precautions:
• Users should not save their questions and answers to an electronic file onto
their computers or a portable device (such as a compact disc or USB drive).
An attacker could use the answers in the file to impersonate the user.
• Users should not write their questions and answers on a physical medium
(such as paper) where someone else can find the answers. An attacker could
memorize or steal the answers to impersonate the user.
• Consider adding a feature to your application where the application displays
the user’s last successful login time and date. If this information does not
match the user’s personal experience, this alerts the user that some form of
attack may have occurred.
• Define a user policy and educate users on appropriate knowledge-based
questions and answers to prevent users from unwittingly exposing their
authentication data to an attacker, both physically and electronically.

Feedback on guide
Feedback on guide
A
User life cycle management

This appendix provides information on the Entrust IdentityGuard user life cycle.
It contains the following sections:
• “Life cycle management overview” on page 140
• “Enrollment” on page 142
• “Usage” on page 144
• “Renewal” on page 145
• “Replacement” on page 146
• “Delivery and activation” on page 149
• “Maintenance” on page 151
139
Life cycle management overview
This section describes the high level processes for managing the life cycle of Entrust
IdentityGuard users. Since Entrust IdentityGuard is a multifactor authenticator, a user
account must already exist in the first-factor authentication application (for example,
user name and password). No assumptions are made about the organization’s
procedures for managing user accounts.
User life cycle management consists of the following stages and processes:
• enrollment
This is the initial stage where users enroll for the Entrust IdentityGuard
service. See “Enrollment” on page 142.
• usage
This is the normal operations stage where users login to your organization
through Entrust IdentityGuard. See “Usage” on page 144.
• renewal
This is an ongoing stage where users are issued new Entrust IdentityGuard
grids (on new cards), tokens, personal verification numbers (PVN) or
questions to replace older ones. See “Renewal” on page 145.
• replacement
This covers the handling of
– lost, stolen, damaged, and “left behind” Entrust IdentityGuard grid cards,
passcode lists, or tokens
– forgotten answers and PVNs
Users are issued temporary PINs (if using grid cards, lists, or tokens), or
receive replacement Entrust IdentityGuard grid cards, passcode lists or
tokens. See “Replacement” on page 146.
• delivery and activation
This describes the processes to physically deliver Entrust IdentityGuard grid
cards, passcode lists, or tokens and activate the authentication method for
each user. It does not apply to the nonphysical authentication methods, such
as knowledge-based questions and answers, or one-time passwords. See
“Delivery and activation” on page 149.
• maintenance
This describes the processes to
– Remove stale or idle grid cards or tokens from the Entrust IdentityGuard
system. This includes grid cards, lists or tokens that are cancelled, never
activated, or unassigned, as well as those assigned to terminated user
accounts.
– Update graphics or images used for organization authentication.

Feedback on guide
– Update personal verification numbers (PVN).
– Update IP geographical data.
See “Maintenance” on page 151.
User life cycle management 141

Feedback on guide
Enrollment
Enrollment is the first stage of the life cycle. In this stage:
• Users are registered in the Entrust IdentityGuard system.
• Users are assigned and provided with an Entrust IdentityGuard
authentication method (such as a grid card or token).
• Users activate the authentication method.
For enrollment, ensure you have processes and procedures in place to create and
manage user accounts and to issue the authentication credentials (such as user names
and passwords). Depending on the authentication methods assigned to users, the
following are examples of events that may occur:
• Entrust IdentityGuard grids are assigned to users and Entrust IdentityGuard
grid cards are produced.
• Microsoft Windows desktop users install Entrust IdentityGuard Desktop for
Microsoft Windows.
• Tokens are assigned to users and mailed to them, along with activation
instructions.
• Users are directed to a Web page where they go through a registration
process that sets up the questions and answers specific to them.
• Computers are registered.
To make sure new grid card and token users enroll promptly, use the search function
in the Administration interface to find users whose activation grace period is about to
expire. See “Forcing grid card activation” on page 116 for more information. The
same mechanism applies to tokens.
If you are using grid cards, passcode lists, or tokens, complete the enrollment process
with “Delivery and activation” on page 149.
User enrollment from LDAP user repository

If user entries exist in an LDAP repository, you can use the user enrollment function
to create Entrust IdentityGuard user accounts in specific groups that you choose.
User enrollment is a bulk process that you set up in Entrust IdentityGuard, either
through Administration interface or from the Master user shell. When you run the
operation that creates user accounts for new user entries in your LDAP directory, you
can choose whether to load them all, or choose which to load, as the process runs.
You can use the Entrust IdentityGuard user enrollment feature in one of two ways.
When you are first deploying Entrust IdentityGuard, or if you are introducing an new
LDAP repository full of new users, you can run user enrollment to load all users from
the LDAP repository to Entrust IdentityGuard.

Feedback on guide
You can also run user enrollment process once a day or once a week, for example, to
create Entrust IdentityGuard records for any users recently added to the LDAP
repository by filtering for the new user records—those not yet created in Entrust
IdentityGuard.

Feedback on guide
Usage
During the usage stage, users are actively logging into your system using the
authentication methods available to them.
The Entrust IdentityGuard system locks out a user after a configured number of
incorrect responses to a challenge (for example, three incorrect responses). This is
necessary to protect against a brute force attack in which an attacker attempts to log
in by repeatedly guessing an Entrust IdentityGuard challenge.
However, a legitimate user can be locked out by making consecutive errors. The
Entrust IdentityGuard system releases the lock out after a defined time period (for
example, 20 minutes), but this may be inconvenient to the user. The Entrust
IdentityGuard administrator can also release a lock. Organizations should design their
help desk procedures for this situation to ensure that proper identity verification is
performed before unlocking an user’s account.

Feedback on guide
Renewal
You should ensure users renew their authentication data (such as their passwords,
tokens, grid cards, PVNs, and knowledge-based information) on a regular basis. Once
the data expires or exceeds a usage period, make sure users are able to renew the
data promptly so that they are not denied service.
Ensure you put a process in place that completes the following actions (when
applicable) before expiry:
• a new grid card, passcode list, or token is issued and delivered to the user
• a user is redirected to a page that requests new knowledge-based
information
• users are directed to change their PVN
An automated central renewal service is recommended so that you do not have to
burden your staff with the overhead of administering routine renewals.
Figure 29 illustrates the high level process steps for renewal.
Figure 29: Enterprise renewal
To renew a user’s authentication data

1 Extract information from the Entrust IdentityGuard repository, selecting users
whose Entrust IdentityGuard authentication data will expire within a specified
time frame. This should be done on a regularly scheduled basis.
2 Generate and assign new authentication data.
• For grids and passcode lists, Entrust IdentityGuard generates and assigns new
authentication data for each selected user name.
• For tokens, administrators assign a new token to the user.
• For knowledge-based information or image/graphic replay authentication,
an application requests new information from a user when they log in.
3 If applicable, produce new grid cards and passcode lists or order more tokens.
Grid card production is discussed in detail in the section “Deploying grid
authentication” on page 103.
4 If you are using grid cards, passcode lists, or tokens, complete the renewal
process with “Delivery and activation” on page 149.

Feedback on guide
Replacement
Entrust IdentityGuard authentication data may be misplaced, lost, stolen, forgotten,
damaged or left behind. Therefore, to ensure users are not inconvenienced, it is
important to have contingency measures in place to provide users with the access
they need until replacement data is in their possession.
• For lost grid cards, passcode lists, or tokens, you can use the Entrust
IdentityGuard system to provide a temporary PIN on an as-required basis.
• For other types of authentication data (such as knowledge-based questions
and answers), your application needs to provide some means for a user to
request hints to answers, for example.
Figure 30 illustrates the high level process steps for replacement.
Figure 30: Enterprise replacement
To replace a user’s authentication data

1 A user needs to verify their identity and start the recovery process. There are
three approaches:
• over-the-counter recovery (identity verification)
In the over-the-counter approach, the user visits the service desk and
requests replacement authentication data. The service desk performs
in-person identity verification to ensure that the request is legitimate. This
approach is useful where a visit to the service desk is mandatory (for
example, the Entrust IdentityGuard grid is printed on the back of an
employee ID card).
• self-service recovery (identity verification)

Feedback on guide
In the self-service approach, the user has access to a self-recovery
application. The application performs an identity verification procedure,
possibly using knowledge-based authentication, to ensure that the request is
legitimate. The questions and answers for recovery must have been created
by the user during the enrollment process or through a separate application
after enrollment.
• central service recovery (identity verification)
In the central service approach, the user calls the service desk and requests
recovery of the authentication data. The service desk performs identity
verification over the phone to ensure that the request is legitimate.
2 The application or service desk administrator provides a user with a temporary
authentication method. If provided by an application, ensure that the
information is displayed in nonmachine-readable format.
• If using grid or token authentication, the administrator or application should
suspend or cancel the current grid card or token, and provide the user with
a temporary PIN. Cancellation is recommended for lost, stolen and damaged
grid cards and tokens. A “left behind” grid card or token (for example, the
user knows where the grid card is, and it is safe from attack) can be
temporarily suspended.
Attention: The cancellation process is irreversible for grid cards, passcode lists,
and tokens. Once they are cancelled, they can never be used again.
For information on temporary PINS, see “Temporary PIN authentication” on

page 65.
• If using out-of-band authentication, a one-time password should be
generated. A one-time password expires when used, or at the time specified
by policy, whichever comes first.
• If using knowledge-based authentication, give hints that the user provided
during registration. If the hints don’t help, issue a one-time password or
temporary PIN so the user can complete the recovery process.
3 Determine whether you need to replace or recover the authentication data.
• For grid cards, passcode lists, or tokens, the user may indicate whether
replacement or re-activation is necessary. If you cancel the grid card, list, or
token, then you must replace it. Ensure the temporary PIN is cancelled when
the user has successfully authenticated using a re-activated or new grid card,
list, or token.
• If using knowledge-based or image replay authentication, it is recommended
that, if the information is permanently forgotten, the user reset their
information through a secure Web page (such as one located on your

Feedback on guide
Intranet). Optionally, they can enter a temporary PIN to verify their identity
when accessing the page, or call an administrator to complete the process.
If you are using grid cards, passcode lists, or tokens, complete the replacement
process with “Delivery and activation” on page 149.

Feedback on guide
Delivery and activation
Delivery and activation processes are common to the enrollment, renewal and
replacement life cycle stages for cards (grids and passcode lists) and tokens. After
Entrust IdentityGuard authentication data (new, renewal or replacement) has been
produced, it must be delivered to the rightful owner and activated.
The physical distribution of authentication data requires both distribution and
inventory management processes. The specific requirements depend on whether the
grid cards or tokens will be picked up in person, mailed out, delivered by courier, or
a combination of these delivery methods.
For each of these options, distribution may be centralized into one location, to a few
locations such as regional offices, or many locations such as branch or retail centers.
Appropriate security and tracking processes should be in place for physical
distribution, and for managing inventory.
Figure 31 illustrates the high level process steps for delivery and activation.
Figure 31: Enterprise delivery and activation
Deliver card or
token to user
From
enrolment ,
replacement ,
or renewal
Deliver card or User pickup Activate
token to central (Verify identity, authentication
service desk personalization ) method
To deliver and activate a user’s authentication data

1 Grid cards and tokens can be delivered in two ways:
• using an over-the-counter service for immediate service
This involves an in-person pickup. For example, the Entrust IdentityGuard
grid may be printed on the back of an employee ID badge that requires a
recent photo on the front.
• using a central service that responds to user requests
Administrators can be given the option of mailing the grid card or token
directly to the user.
2 If you are using a central service, the user must visit the service desk where
personalization procedures are performed. You can require the service desk to

Feedback on guide
verify the person’s identity to ensure that the grid card or token is delivered to its
rightful owner.
3 Activate the grid card or token using the authentication application. You can use
an over-the-counter approach or a self-activation approach.
• In an over-the-counter approach, the administrator can activate the Entrust
IdentityGuard grid card or token immediately before handing it to the user.
• In a self-activation approach, the user initiates the activation by using the
Entrust IdentityGuard grid card or token in an authentication transaction.
This can be as simple as using the Entrust IdentityGuard grid card or token
on the next login.
For the activation procedures you deploy, take into account the requirements for
capturing information for self-service grid card or token replacement (see
“Replacement” on page 146).

Feedback on guide
Maintenance
Maintenance procedures are required to remove stale or idle data from the Entrust
IdentityGuard system. Ensure that an Entrust IdentityGuard administrator regularly
performs the following maintenance tasks.
Remove cancelled grid cards and tokens

The renewal and replacement stages result in old Entrust IdentityGuard grid cards and
tokens being replaced by new ones. At the time the new grid card or token is
activated, the old one is cancelled.
Cancelled grid cards and tokens can never be used again. However, the associated
information is retained in the repository. You should establish policies for:
• the archival and removal of cancelled grid cards and tokens on a periodic
basis
• whether or not archives need to be retained and, if so, for how long
Remove inactive grid cards and tokens

Organizations should not encounter many Entrust IdentityGuard grid cards and
tokens that were never activated, although they can get lost in transit. Users are
expected to notify the service desk in such circumstances. A replacement grid card or
token would be issued and the inactive grid card or token cancelled.
The Entrust IdentityGuard administrator can check for items that were never
activated on a periodic basis to ensure that they are either activated by the rightful
owner or cancelled.
Remove unassigned grid cards and tokens

Tokens and grid cards added in the preproduction model are initially unassigned. The
Entrust IdentityGuard administrator, in conjunction with the service desk, should
perform an inventory check on a periodic basis to identify any lost grid cards and
tokens and cancel them. It is expected that the service desk will maintain proper
inventory control and that few unassigned grid cards or tokens, if any, will be lost.
Synchronize with the repository

Coordinate maintenance activities between the Entrust IdentityGuard administrator
and the repository administrator. In particular, when user accounts are terminated,
the associated Entrust IdentityGuard information should be removed.
For information about creating new Entrust IdentityGuard users by synchronizing
your LDAP repository with Entrust IdentityGuard, see “User enrollment from LDAP
user repository” on page 142.

Feedback on guide
Update images used for mutual authentication
You should occasionally change the images users can select for image-replay mutual
authentication. This makes it harder for attackers to spoof your site.
Update personal verification numbers

Each personal verification number (PVN) includes a last-used date. You can check this
date to find a list of users whose PVNs need replacing. You should require users to
change their PVN on a regular basis.
Update IP geographical data

You can download new IP lists from Entrust on a monthly basis. New IP data files are
also included in each patch. See the Entrust IdentityGuard Administration Guide for
more information on updating IP data files.

Feedback on guide
B
Entrust IdentityGuard baseline

architectures
This section outlines some baseline architectures and complements the information
about architecture and deployment provided in the other guides in the Entrust
IdentityGuard documentation suite.
See the Entrust IdentityGuard Administration Guide for more information on the
authentication issues that influence the choice of architecture and configuration of
your Entrust IdentityGuard solution.
This appendix contains the following sections:
• “Architecture overview” on page 154
• “Web access” on page 156
• “VPN remote access” on page 160
• “Wireless access” on page 165
• “Microsoft Windows remote access” on page 168
• “Generic remote access” on page 172
• “Microsoft Windows desktop” on page 176
Note: Entrust Professional Services can provide more information on an

architecture suitable to your requirements. For contact information, see
“Obtaining technical assistance” on page 15.
153
Architecture overview
There are three levels of baseline architecture in this section: evaluation, standard and
high availability.
Evaluation
Evaluation-level architecture:
• suits test and proof-of-concept environments
• is designed to be low cost to implement, by minimizing the required
equipment
• represents a limited environment that you can set up quickly for
proof-of-concept, investigation of functionality, and so on
• is not intended for production purposes
Assumptions:
• generally very small, ranging from a few users up to a hundred users
• used for test purposes only
• no firewalls
• no NTP service; clock is set manually
• typically resides within a development environment, or on an isolated
network segment
Standard
Standard-level architecture:
• suits production implementations from pilot phase through initial rollout
• lacks equipment redundancy; any standard environment should be
implemented with robust equipment to provide a moderately high level of
availability and performance
• represents production environments suitable for a medium volume
environment
• is more complex to set up than the evaluation architectures because of
firewalls and other security provisions
• uses separate servers for each function to support higher throughput
Assumptions:
• support for internal or external users
• generally moderate in size, supporting tens of thousands of users
• multiple firewalls create zones for increasing levels of security

Feedback on guide
• limited provision for failover
• a backup strategy is in place to ensure that the data stores and system disks
can be rebuilt in the event of a hardware failure (add a disk mirroring strategy
to reduce recovery time in the event of a disk failure)
• an NTP service, connected to a trusted time source (such as a Stratum 1 or
Stratum 2 time server), is available to ensure clock accuracy for tokens (some
downtime is acceptable; no provision is made for replicated systems)
• network architecture already in place
High availability
High availability architecture:
• suits large scale production implementations that demand the highest levels
of availability and performance
• expands upon the standard configurations by adding redundancy for both
high availability and scalability
• is intended for production purposes in a high volume environment, whether
supporting internal or external users
Assumptions:
• offers higher throughput than standard baseline architectures
• includes redundant systems, links, trusted time sources, and data stores
• is more complex to set up because of the significant provision for security,
performance, and availability
• deployments are generally large, supporting millions of users
• uses load-balancers to achieve high availability for Entrust IdentityGuard
• user session “stickiness” configured on load-balancers to provide the ability
to consistently bring a user back to the same Entrust IdentityGuard Server
• can be based on SSL session ID, IP address, cookie, or HTTP redirection
This feature is required in a multiple Entrust IdentityGuard Server architecture
where challenge-response caching is used. Since this feature eventually
becomes the second-factor authentication repository, consider scaling the
second-factor authentication repository. Entrust IdentityGuard supports
users in multiple repositories.
Entrust IdentityGuard baseline architectures 155

Feedback on guide
Web access
You can deploy the Web access baseline architecture in an evaluation, standard or
high availability environment.
You can use any Entrust IdentityGuard authentication method when your users
access your organization using their Web browsers.
Web access - evaluation

Figure 32 illustrates how you can set up Entrust IdentityGuard to provide multifactor
authentication for your Web resources.
Figure 32: Web authentication evaluation architecture
Requirements
• directory or database with user repository
• Entrust IdentityGuard Server
• Web server or application server running an application that controls
first-factor authentication (user name and password) and manages the
repository
• client with Web browser

Feedback on guide
Web access - standard
The standard architecture, shown in Figure 33, extends the evaluation architecture
(“Web access - evaluation” on page 156) by:
• adding firewalls that provide network segmentation for the authentication
and application systems
• adding separate servers for the Web server and application server (consistent
with best practice for security, availability and performance)
• adding a separate computer containing the Entrust IdentityGuard
Administration interface where administrators manage users
Figure 33: Web access standard architecture
Requirements
• directory and/or database on a dedicated server for the user repository
• application server running an application that completes first-factor
authentication (user name and password) and manages the repository
(Entrust IdentityGuard can manage first-factor authentication if required)
• hard and soft firewalls creating a DMZ (demilitarized zone) for the Web
server, and protecting internal resources

Feedback on guide
• Web server located in DMZ that relays information between the client, the
application server, and Entrust IdentityGuard Server
• an administrator to manage Entrust IdentityGuard users
Web access - high availability

The architecture shown in Figure 34, extends the standard architecture (“Web access
- standard” on page 157) by adding load-balancers, replica Entrust IdentityGuard
Servers, and replicated user repositories. It is expected that the network components
(for example, routers, firewalls, and so on), Web servers and application servers are
configured to provide high availability and performance.
Figure 34: Web access high availability architecture

Feedback on guide
Requirements
• replicated directories and/or databases for the user repository, set up in a
high availability or disaster recovery cluster
• Entrust IdentityGuard Servers
• load-balancers to divide the load among the various Entrust IdentityGuard
Servers
• replicated application servers that complete first-factor authentication (user
name and password) and manage the repository (alternatively, Entrust
IdentityGuard can manage first-factor authentication if required)
• hard and soft firewalls creating a DMZ (demilitarized zone) for the Web
servers, and protecting internal resources
• replicated Web servers located in DMZ that relay information between the
client, the application server, and Entrust IdentityGuard Server
• administrators to manage Entrust IdentityGuard users

Feedback on guide
VPN remote access
You can deploy the VPN remote access baseline architecture in an evaluation,
standard or high availability environment.
You can use any of the following Entrust IdentityGuard authentication methods when
your users access your organization through VPN:
• grid authentication
• token authentication
• Entrust IdentityGuard password (first-factor) authentication
• one-time password authentication
• knowledge-based authentication
• risk-based authentication
VPN remote access - evaluation

Use this architecture to evaluate how Entrust IdentityGuard can integrate with your
current VPN solution to provide multifactor authentication to remote users.
Figure 35: VPN remote access evaluation architecture

Feedback on guide
Requirements
• directory or database with user repository
If using a database, you can install it on the same computer as the one
hosting Entrust IdentityGuard Server.
• Entrust IdentityGuard Radius proxy, configured on the same computer as the
Entrust IdentityGuard Server
• a first-factor authentication resource, such as a Remote Authentication Dial
In User Service (Radius) server, a domain controller, or an LDAP-compliant
directory (see “External authentication” on page 40); optionally, Entrust
IdentityGuard can also manage first-factor authentication
• VPN device (IPsec or SSL)
• client with VPN connection (dial-up, wireless, and so on)
VPN remote access - standard

The standard architecture, shown in Figure 36 on page 161, extends the evaluation
baseline architecture by adding firewalls (which provide network segmentation for
the authentication systems) and user administration.
Figure 36: VPN remote access standard architecture

Feedback on guide
Requirements
• directory and/or database on a dedicated server for the user repository
• Entrust IdentityGuard Radius proxy, configured on the Entrust IdentityGuard
Server computer
• a first-factor authentication resource, such as a Radius server, a domain
controller, or an LDAP-compliant directory (see “External authentication” on
page 40); optionally, Entrust IdentityGuard can manage first-factor
authentication
• VPN device (IPsec or SSL)
• client with VPN connection (dial-up, wireless, and so on)
• hard and soft firewalls creating a DMZ (demilitarized zone) for the VPN
device, and protecting internal resources
VPN remote access - high availability

The architecture in Figure 37 extends the standard VPN remote access configuration
(“VPN remote access - standard” on page 161) by adding load-balancers, replica
Entrust IdentityGuard Servers, and replicated user repositories.
The network components (for example, VPN devices, routers, firewalls, and so on)
and first-factor authentication resources must be configured to provide high
availability and performance.

Feedback on guide
Figure 37: VPN remote access high availability architecture
Requirements
• replicated directories and/or databases for the user repository, set up in a
high availability or disaster recovery cluster
Servers
• Entrust IdentityGuard Radius proxies, configured on the Entrust
IdentityGuard Servers
• a cluster of first-factor authentication resources, such as Radius servers,
domain controllers, or LDAP directories (see “External authentication” on
page 40); optionally, Entrust IdentityGuard can manage first-factor
authentication
• VPN devices (IPsec or SSL)
• clients with VPN connection (dial-up, wireless, and so on)
• administrators to manage Entrust IdentityGuard users

Feedback on guide
• hard and soft firewalls creating a DMZ (demilitarized zone) for the VPN
devices, and protecting internal resources

Feedback on guide
Wireless access
This architecture is not dependent on a specific platform for the access server. It only
requires that you have a wireless access point. You can deploy the wireless access
baseline architecture in an evaluation, standard, or high availability environment.
Since this architecture includes the Radius proxy, you can use these second-factor
authentication methods: grid, token, temporary PIN, OTP, and one
question-and-answer challenge. The token method can include a personal
verification number (PVN) challenge.
See Entrust IdentityGuard Administration Guide for supported deployments and
implementation details.
Wireless access - evaluation

Use this architecture to evaluate how Entrust IdentityGuard can provide multifactor
authentication for wireless users.
Figure 38: Wireless access evaluation architecture
Wireless access
point
LDAP or database
repository
EAP supplicant
Server with Radius
proxy
Requirements
• wireless access point
• LDAP directory or database user repository

Feedback on guide
• Entrust IdentityGuard Server and the Radius proxy
Wireless access - standard

The architecture shown in Figure 45 extends the evaluation architecture by adding
user administration so that you can provide multifactor authentication to wireless
users in your organization.
Figure 39: Wireless access standard architecture
Firewall
Distributed LDAP or
database repository
Access server
EAP supplicant supporting RAS and
EAP
Administrator Server with Radius
proxy
Requirements
• distributed LDAP directory or database user repository

Feedback on guide
Wireless access - high availability
The architecture shown in Figure 46 adds load-balancers, replica Entrust
IdentityGuard Servers, and replicated user repositories. It is assumed that network
components (access servers, routers, firewalls, and so on) and first-factor
authentication resources are configured to provide high availability and performance.
Figure 40: Wireless access high availability architecture

Firewall
Distributed LDAP or
database repository
Server with Radius
proxy
EAP supplicant Wireless access Load -balancing

point cluster
Server with Radius
Administrator proxy
Requirements
• replicated and distributed LDAP directory or database user repository
• multiple Entrust IdentityGuard Servers with the Radius proxy

Feedback on guide
Microsoft Windows remote access
You can deploy the Microsoft Windows remote access baseline architecture in an
evaluation, standard or high availability environment.
You can use the grid, token or temporary PIN authentication methods when your
users access your organization remotely through Microsoft Windows.
Microsoft Windows remote access - evaluation

Use this architecture to evaluate how Entrust IdentityGuard can add multifactor
authentication for Microsoft Windows remote users.
Figure 41: Microsoft Windows remote access evaluation architecture
Requirements
• Active Directory with user repository
• Domain controller (you can install it on the same machine as the user
repository)
• Microsoft Routing and Remote Access Service (RRAS) with Internet
Authentication Service (IAS)

Feedback on guide
• Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server
installed on RRAS computer
• client with Microsoft Remote Access capabilities
Microsoft Windows remote access - standard

The Microsoft Windows remote access standard architecture, shown in Figure 42,
extends the evaluation architecture by adding firewalls and user administration so
that you can provide multifactor authentication to the Microsoft remote users in your
organization.
Figure 42: Microsoft Windows remote access standard architecture
Firewall Firewall
Distributed domain
with Active Directory
Microsoft RRAS with

Microsoft Remote
Access Client
Remote Access Plug-in
Administrator
Server
Requirements
• distributed domain configuration with user repository

Feedback on guide
installed on the IAS computer
• hard and soft firewalls creating a DMZ (demilitarized zone) for the RRAS, and
protecting internal resources
Microsoft Windows remote access - high availability

The architecture in Figure 43 on page 171 extends the standard Microsoft Windows
remote access configuration (“Microsoft Windows remote access - standard” on
page 169) by adding load-balancers, replica Entrust IdentityGuard Servers, and
replicated user repositories.
The network components (for example, access servers, routers, firewalls, and so on)
and first-factor authentication resources must be configured to provide high
availability and performance.
Note: In any remote-access configuration shown in this section, you can set up
an architecture in which the IAS is enabled on a different computer than the
RRAS is. In that instance, you need to install the Remote Access Plug-in on the
computer hosting the IAS.

Feedback on guide
Figure 43: Microsoft Windows remote access high availability architecture
Requirements
• distributed domain configuration with replicated user repository
• load-balancers to divide the load between the Entrust IdentityGuard Servers
installed on the IAS computer
• hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote
Access Server, and protecting internal resources

Feedback on guide
Generic remote access
This architecture is not dependent on a specific platform for the access server. It only
requires that your remote client and access server support the Extensible
Authentication Protocol (EAP). You can deploy the generic remote access baseline
architecture in an evaluation, standard or high availability environment.
Since this architecture includes the Radius proxy, you can use these second-factor
authentication methods: grid, token, temporary PIN, OTP, and one
question-and-answer challenge. The token method can include a personal
verification number (PVN) challenge.
Generic remote access - evaluation

Use this architecture to evaluate how Entrust IdentityGuard can provide multifactor
authentication for remote users.
Figure 44: Generic remote access evaluation architecture
Access server
supporting RAS and
EAP
LDAP or database
repository
Windows EAP client
Server with Radius
proxy
Requirements
• an LDAP directory or database user repository
• access server supporting Remote Access Service (RAS) and EAP

Feedback on guide
• remote Microsoft Windows client supporting EAP
Generic remote access - standard

The architecture shown in Figure 45 extends the evaluation architecture by adding a
firewall and user administration so that you can provide multifactor authentication to
remote users in your organization.
Figure 45: Generic remote access standard architecture
Requirements
• distributed LDAP directory or database user repository
• hard and soft firewalls creating a DMZ (demilitarized zone) for the RAS, and
protecting internal resources

Feedback on guide
Generic remote access - high availability

The architecture shown in Figure 46 adds load-balancers, replica Entrust
IdentityGuard Servers, and replicated user repositories. It is assumed that network
components (access servers, routers, firewalls, and so on) and first-factor
authentication resources are configured to provide high availability and performance.
Figure 46: Generic remote access high availability architecture

Firewall Firewall
Distributed LDAP or
database repository
Server with Radius
proxy
Windows EAP client Access server Load -balancing

supporting RAS and cluster
EAP
Server with Radius
Administrator proxy
Requirements
• replicated and distributed LDAP directory or database user repository
• multiple Entrust IdentityGuard Servers with the Radius proxy
• load-balancers to divide the load among the Entrust IdentityGuard Servers

Feedback on guide
• hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote
Access Server, and protecting internal resources

Feedback on guide
Microsoft Windows desktop
You can deploy the Microsoft Windows desktop baseline architecture in an
evaluation, standard or high availability environment.
You can use the grid, token or temporary PIN authentication methods when your
users access your organization through their Microsoft Windows desktop.
Microsoft Windows desktop - evaluation

This architecture (shown in Figure 47) demonstrates how you can use Entrust
IdentityGuard to provide multifactor authentication to Microsoft Windows users
when they log in to their computer.
Figure 47: Microsoft Windows desktop authentication evaluation architecture
Requirements
• Active Directory with user repository
• domain controller (you can install it on the same machine as the user
repository)
• Entrust IdentityGuard Desktop for Microsoft Windows installed on a
computer

Feedback on guide
Microsoft Windows desktop - standard
The Microsoft Windows desktop standard architecture, shown in Figure 48, extends
the evaluation architecture by adding a firewall and user administration so that you
can provide multifactor authentication to the desktop users in your organization.
Figure 48: Microsoft Windows desktop standard architecture
Requirements
• distributed domain configuration with user repository
• firewall
• Entrust IdentityGuard Desktop for Microsoft Windows installed on users’
computers

Feedback on guide
Microsoft Windows desktop - high availability
The high availability grade baseline architecture, shown in Figure 49, extends the
standard grade baseline architecture by adding load-balancers and replica Entrust
IdentityGuard Servers, and replicated user repositories.
It is expected that the network components (for example, routers, firewalls, and so
on) and domain controllers will be configured to provide high availability and
performance.
Figure 49: Microsoft Windows desktop authentication high availability architecture
Firewall
Distributed domain
Entrust IdentityGuard with Active Directory
Desktop for Microsoft
Windows
Load -balancing
cluster
Administrator
Requirements
• distributed domain configuration with replicated user repository
Servers
• firewall

Feedback on guide
• Entrust IdentityGuard Desktop for Microsoft Windows installed on user’s
computers or laptops

Feedback on guide
Feedback on guide
C
Grid card usability study

Entrust IdentityGuard was introduced to the market in late 2004. Since inception, it
has generated significant interest in the market due to its ability to cost-effectively
combat identity theft (from phishing and pharming) as well as address enterprise
desktop and remote access security needs.
In May 2005, Design Interpretive conducted an independent usability study on
Entrust IdentityGuard grid authentication. The extremely positive results of the study
validate how easy Entrust IdentityGuard grid authentication is to use for both
consumer and enterprise application security.
This appendix contains the following sections:
• “Entrust IdentityGuard grid card usability study” on page 182
• “Recommendations” on page 185
• “Grid authentication implementation” on page 187
181
Entrust IdentityGuard grid card usability study
For organizations that want a strong authentication solution that is easy to use and
easy to deploy, the results of this study show that Entrust IdentityGuard grid
authentication is an ideal candidate. Built and supported by security experts from
Entrust, Entrust IdentityGuard delivers a highly secure way of strongly authenticating
users, whether in a consumer situation that demands increased protection against
identity theft, or an enterprise situation that is looking to strengthen security for
applications like remote access or desktop authentication.
• “Usability test summary” on page 182
• “Objective” on page 182
• “Methodology” on page 183
• “Usability test results” on page 183
Usability test summary

• 344 people participated in the study
• Usability of Entrust IdentityGuard grid authentication was excellent and
received a very high accuracy rate for authentication.
There were no statistical performance differences across the grid card designs
(varying sizes/layouts).
• The procedure required to successfully complete the Entrust IdentityGuard
challenge is inherently simple and has high user acceptance.
– 100% of participants achieved unaided successful login in two attempts.
– 93% of participants were somewhat or very willing to use it once per day.
• The temporary PIN login procedure for forgotten or lost grid cards was
straightforward and well understood by users.
100% achieved unaided successful login in two attempts.
Objective
The objective of the study was to assess the overall usability of Entrust IdentityGuard
grid authentication in both consumer and enterprise deployment scenarios. In
addition, the study looked to maximize the usability of Entrust IdentityGuard grid
authentication by formally testing various design implementations of:
• the coordinates table
For example, the number of cells and the visual delineation of rows and
columns.
• the login screen design and challenge process flow

Feedback on guide
For example, whether the challenge is consolidated into one screen or spread
across two screens.
The objective of these formal tests was to provide recommendations based on
testing, as well as gather user feedback on their experiences.
Methodology
The test had two separate execution phases, focusing independently on a consumer
environment through Web testing and an enterprise environment for desktop
authentication. It should be noted, that although desktop authentication was tested
only for enterprise users, the expectation is that similar excellent results would be
achieved for using Entrust IdentityGuard grid authentication for remote access
applications like IP/SEC or Enterprise methodology.
The enterprise test was conducted using a face-to-face interview technique. Desktop
authentication with Entrust IdentityGuard grid cards was used as the method of
understanding the usability in the enterprise, with the assumption that usability of
Entrust IdentityGuard grid cards for remote access would be similar. The same Entrust
IdentityGuard grid options that were used for the consumer testing were used for the
enterprise testing.
Key details of the testing include:
• Seventeen people from a medium sized enterprise were tested in a focus
group environment.
• An Entrust IdentityGuard temporary PIN was used as an alternative to an
Entrust IdentityGuard challenge in order to assess usability in situations
where a user has lost or forgotten their Entrust IdentityGuard grid card.
Usability test results

The results of the independent testing for Entrust IdentityGuard grid authentication
were extremely positive for both the consumer and the enterprise.
Key findings of the enterprise study:
1 Usability of Entrust IdentityGuard grid authentication was excellent and a very
high accuracy rate of grid number lookup was achieved.
Across the four different grid card designs and layouts (See Figure 50 on
page 184), no statistical difference was found. This shows that organizations
have the flexibility to deploy the grid size and layout that is best for them within
the bounds of the recommendations found here (see “Recommendations” on
page 185).
2 The procedure required to successfully complete the Entrust IdentityGuard
challenge is inherently simple and has high user acceptance.
Grid card usability study 183

Feedback on guide
Figure 50: Successful login attempts
2nd try
29%
1st try
71%
Figure 3: Enterprise initial authentication attempts
• 100% of participants achieved unaided successful login in two attempts;

71% of users on the first attempt and the other 29% on the second attempt.
• 93% of participants were somewhat or very willing to use it once per day.
3 The temporary PIN login (for forgotten/lost grid cards) procedure was
straightforward and well understood by users.
• 100% achieved unaided successful login in two attempts.

Feedback on guide
Recommendations
Based on the results of the study, the following recommendations should be
considered when deploying Entrust IdentityGuard grid authentication to ensure a
high degree of usability.
• “General guidelines” on page 185
• “Grid card design and layout” on page 185
General guidelines
You can increase probability of initial successful grid challenge response if you:
• Provide first time users with written instructions that graphically depict how
to use the grid card and login procedure.
• Provide access (using a corporate Intranet or training center) to instruction
materials (such as a multimedia demonstration of how to use the grid for that
particular application) describing how to use an Entrust IdentityGuard grid
card.
Grid card design and layout

Consider the following recommendations for grid card design and layout.
Fonts
Given that the different fonts used in the test did not affect usability, it is
recommended that you choose the font within the following guidelines to ensure a
high level of usability:
• Use fonts that people are generally familiar with (Arial, Verdana, Helvetica,
and Times lend themselves to better readability).
At small sizes, Verdana offers bigger looking characters at the same point size
as other fonts.
• Use a sufficient character point size to ensure readability. A minimum of
11-point is recommended.
Use of color
Given that the different fonts used in the test did not affect usability, it is
recommended that customers choose the font within the following guidelines to
ensure a high level of usability:
• Avoid color combinations that create a tendency to “vibrate.”

Feedback on guide
• Assist users that may have some form of color blindness.
– Do not rely on color alone to convey information.
– Avoid using only red and green in the grid design.
– Maintain a high contrast between text and background.
Design of the grid

Given that grid sizes tested here did not affect usability, it is recommended that you
choose the grid size that is best suited to your security requirements (noting that
increased grid size can deliver increased security) according to the following
guidelines:
• Do not use more than seven rows or columns in the grid. Adding more rows
or columns compromises size of text and readability.
• Do not use multiple characters within an individual grid cell as this tends to
compromise the size of text and readability.
• Use table row and column highlighting.
Although it was not a factor in this study, tables with both row and column
grid lines typically enable users to process data faster than tables with only
row or only column highlighting.
• Format column and row titles with emphasis (bold or a background color) to
assist in the immediate understanding of the table contents.
Titles should be sufficiently different than the data in the table to assist in
distinguishing between the table data and the row and column titles with
color or value.
• It is essential that all contents of the grid be precisely aligned and that each
column appear to the eye to be in virtual alignment with neighboring
elements.

Feedback on guide
Grid authentication implementation
This section provides more information on what the study determined about
implementing grid authentication.
• “Web login challenge method” on page 187
• “Mutual authentication (through displaying a authentication secret)” on
page 187
• “Temporary PIN length” on page 187
Web login challenge method

Given that the type of login challenge method did not affect usability, it is
recommended that organizations implement the method that is best suited to
organizational security requirements. However, there are inherent security benefits to
implementing a two-screen authentication process:
• A two-screen approach delivers the ability to achieve mutual authentication
(as a way of addressing phishing).
• A two-screen approach delivers the ability to lock a challenge for a user until
it is successfully completed (to limit the ability to brute-force attack a Web
site by cycling through challenges).
Mutual authentication (through displaying a authentication

secret)
If the Entrust IdentityGuard serial number (or another authentication secret like an
image stored by Entrust IdentityGuard) is displayed on the login screen to achieve
mutual authentication (used to help address phishing attacks), it is recommended that
any documentation sent to the user reinforces the security implications of that
authentication secret.
For more information, see “Mutual authentication methods” on page 52.
Temporary PIN length

When using a temporary PIN (for instances where the user has forgotten or lost their
grid and needs access to applications until a new grid is issued), it is recommended to
use a PIN with five to nine characters, depending on your security requirements.
• Five elements is the minimum needed to ensure security.
• Nine elements is the typical upper span limit of human memory. Going
beyond nine elements makes it very difficult for a user to remember.

Feedback on guide
Feedback on guide
Index
IndexIndex
- A B C D E F G H I J K L M N O P Q R S T U V W X Y Z -
A temporary PIN 65
token 41, 125
activation of grid cards and tokens 149 transaction 41
ActiveX for machine authentication 60 authentication secret 87
Administration interface 74 Authentication service 25
Administration service 26 automation 124
administrator 74
alias 75
alias in a consumer deployment 76 B
anonymous grids 114
backup and recovery 71
application data 55
baseline architectures 153
application integration 84 Braille grid card 118
architecture
evaluation 154
high availability 155 C
overview 154
standard 154 challenge
audit reporting 71, 89 grid 42, 108
authentication least-used cells 108
benefits 19 lock out 77
definition 19 passcode list 46
first-factor 40 random 108
methods 41 size 107
multiple factors 19 token 126
overview of authentication methods 34 client application 30
skip first-factor 40 components 23
authentication API 84 Entrust IdentityGuard Desktop 28
authentication factor. See authentication methods ISAPI filter 30
authentication methods 33 Radius proxy 27
comparison 37 Remote Access Plug-in 29
external 40 repository 26
grid 42, 103 server 24
grid replay 52 computer identity 55
image or message replay 53 cookie for machine authentication 55
knowledge-based 47 Customer support 15
machine 55
machine authentication 48
mutual authentication 52
D
one-time password (OTP) 49 database 90
passcode list 45 delivery of grid cards and tokens 149
password 39 delivery of one-time passwords 50, 51
Radius server 39 deployment of Entrust IdentityGuard
189
overview 68 G
planning 67
desktop architecture Getting help 15
evaluation 176 grid
high availability 178 automating 124
standard 177 cell entropy 105
Desktop for Microsoft Windows 28 cell format 104
directory repository 89 challenge 42
disaster recovery 94 challenge algorithm 108
distribution of grid cards and tokens 149 challenge size 45, 107
deployment risks 45
distribution 110
E format 104
lifetime 45, 105
email, secure 123
location replay 52
end user. See user
one-step authentication 43
end-to-end encryption 123
enrollment 142 passcode list 45
replacement 105
from LDAP repository 142
sample passcode list 46
LDAP users 89
Entrust IdentityGuard Administration service 26 serial number 52
size 45, 104
Entrust IdentityGuard Desktop for Microsoft Windows 28
two-step authentication 44
Entrust IdentityGuard ISAPI filter 30
Entrust IdentityGuard Radius proxy 27 grid authentication 42, 103
grid card
Entrust IdentityGuard Remote Access Plug-in 29
Braille 118
Entrust IdentityGuard Server 24
Entrust tokens 41, 125 cost factors 121
production 118
evaluation architecture 154
production model 109
external authentication 40
security 117
usability study 181
F grid card production
costs 121
failover 94 Entrust IdentityGuard Card Production Service 121
advanced multi-site 99 in-house 118
geographically-dispersed repositories 97 outsourced 119
local repository 97 Grid card production service 121
multi-site 98 grid card usability study 181
Radius server 100 recommendations 185
repository 96 results 183
scenarios 94 summary 182
file transmission 123 grid production model 110
with end-to-end encryption 123 group 79
with secure email 123
with secure FTP 123
with SSL 123 H
fingerprint, machine fingerprint 60
first-factor authentication 19, 27, 40 high availability
architecture 155
flash object for machine authentication 55
failover scenarios 94
FTP 123

I flash object 55
machine fingerprint 55
image library on Entrust TrustedCare 54 machine nonce 55
image replay, required disk space 54 machine secret 55
integrating applications 84 machine tag 55
considerations 87 sequence nonce 55
Microsoft Windows 85 with questions 129, 134
VPN 85 machine fingerprint 55
Web 84 application data 55
wireless access portal 86 Get 57
inventory of grid cards and tokens 149 Get request 61
ISAPI filter 30 sources 57
machine nonce 55
machine secret 55
J using ActiveX 60
JavaScript for machine secrets 59 using Javascript 59
machine tag 55
machine nonce 55
K sequence nonce 55
Kerberos 40 maintenance 151
knowledge-based authentication 47 master user 73
challenge size 135 master user shell 73
exact answers 135 Microsoft Windows desktop user 31
question qualities 131 Microsoft Windows remote architecture
question sources 130 evaluation 168
security 137 high availability 170
selecting questions 133 standard 169
word map 135 migrating to another platform 93
migrating to Entrust IdentityGuard 101
monitoring
L audit reporting 89
SNMP 71
least-used cells challenge 108
multifactor authentication 19
life cycle 139 multi-site failover
delivery and activation of grid cards and tokens 149
advanced 99
enrollment 142
standard 98
maintenance 151 mutual authentication 35, 52
overview 140
grid replay 52
renewal of authentication factors 145
image library 54
replacement of authentication factors 146 image or message replay 53
usage stage 144
lock out, reset 144
O
M one-step grid authentication 43
one-time password (OTP)
machine authentication 48, 55 authentication 49
application data 55
delivery 50, 51
cookie 55
OOB, see out-of-band
Index 191
operations 71 recovery 71
organization authentication remote access architecture
See mutual authentication evaluation 172
OTP, see one-time password high availability 174
out-of-band standard 173
authentication 49 Remote Access Plug-in 29
password delivery 50, 51 renewal of authentication factors 145
replacement of authentication factors 146
replay
P grid values 52
passcode list image 53
authentication 45 message 53
challenge 46 serial number 52
deployment risks 47 repository 26
length 47 database 90, 96
production 47 directory 89, 96
sample 46 failover 27
scratch cards 47 performance and maintainability 90
password authentication 39 selecting 89
people needed for deployment 70 synchronization 151
performance repository failover 96
repository 90 geographically dispersed 97
testing 91 local 97
performance testing 91 RRAS user 31
pharming 45
phishing 45
physical security 72
S
planning deployment of Entrust IdentityGuard 67 sample Web application 37
policies 69 scratch cards for passcode list 47
preproduction model, grid cards 114 search bases 81
produce-and-assign model 110 second-factor authentication 34
producing grid cards 118 secure email 123
production file secure FTP 123
pre-production model 114 sequence nonce 55
transmitting 123 shared secrets 88
Professional Services 16 SNMP monitoring 71
SSL
securing user responses 25
Q transmitting files 123
question and answer. See knowledge-based authentication standard architectures 154
strong authentication 18
system monitoring 71
R
Radius proxy 27, 39, 86 T
Radius server
authentication 39 TAN. See passcode list
failover 100 Technical Support 15
random challenge 108 technology 68

temporary PIN W
authentication 65
length 187 Web architecture
testing performance 91 evaluation 156
token high availability 158
assigning 127 standard 157
authentication 41, 125 Web services 25
challenge-response mode 42 Web user 32
deployment 127 wireless access architecture
entering values 126 evaluation 165
lifetime and replacement 126 standard 166
response-only mode 42 wireless architecture
security 128 high availability 167
self-registration 127 word map for knowledge-based authentication 135
transaction authentication 41
troubleshooting 71
two-step grid authentication 44
typographic conventions 12
U
usability study, grid cards 181
user 31
enrollment 89, 142
groups 79
life cycle 139
locking out 77
Microsoft Windows 31
requirements 75
RRAS 31
services 77
suspending 78
training 76
VPN 32
Web 32
user enrollment from LDAP repository 89, 142
user ID 75, 76
V
VPN architecture
evaluation 160
high availability 162
standard 161
VPN user 32
194 IdentityGuard Deployment Guide Document issue: 1.0
Feedback on guide

IG 91 Deployment Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IG 91 Deployment Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Entrust®

Document issue: 1.0

Date of Issue: August 2008

Entrust is a trademark or a registered trademark of Entrust,

This information is subject to change as Entrust reserves

Export and/or import of cryptographic products may be

2 IdentityGuard 9.1 Deployment Guide

About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

About Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

4 IdentityGuard 9.0 Deployment Guide Document issue: 1.0

Planning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Deploying grid authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

6 IdentityGuard 9.0 Deployment Guide Document issue: 1.0

Deploying token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

User life cycle management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

Entrust IdentityGuard baseline architectures . . . . . . . . . . . . . . . . . . . . . . . .153

8 IdentityGuard 9.0 Deployment Guide Document issue: 1.0

Grid card usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181

10 IdentityGuard 9.0 Deployment Guide Document issue: 1.0

About this guide

This chapter contains the following topics:

Table 1: Typographic conventions

Convention Purpose Example

Note and Attention text

Attention: Issues that, if ignored, may seriously affect performance, security, or

12 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

About this guide 13

14 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

About this guide 15

16 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

About Entrust IdentityGuard

Figure 1: Multifactor authentication with Entrust IdentityGuard

User name and password

Company Employee repository

This section contains the following topics:

18 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

Benefits of multifactor authentication

Identities become difficult to steal

Stolen identities become difficult to reuse

About Entrust IdentityGuard 19

First-factor authentication choices

Second-factor authentication choices

20 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

Mutual authentication choices

About Entrust IdentityGuard 21

22 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

Figure 2: Entrust IdentityGuard with an existing authentication system

Figure 3: Entrust IdentityGuard as the sole authentication system

This section contains the following topics:

About Entrust IdentityGuard 23

Entrust IdentityGuard server

24 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

Entrust IdentityGuard Server

Master user shell

SOAP SOAP SOAP

Entrust IdentityGuard Client

Entrust IdentityGuard Authentication service

About Entrust IdentityGuard 25

Master user shell

26 IdentityGuard 9.1 Deployment Guide Document issue: 1.0

First-factor authentication application