IG 90 Deployment Guide-Iss20

Entrust

IdentityGuard 9.0

Deployment Guide

Document issue: 2.0

Date of Issue: November 2007

2 IdentityGuard 9.0 Deployment Guide

Copyright 2007 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.

Table of contentsAbout this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Documentation conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Note and Attention text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Obtaining documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Documentation feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Obtaining technical assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Telephone numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Email address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

CHAPTER 1About Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Why use Entrust IdentityGuard? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Challenges of first-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Benefits of multifactor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Identities become difficult to steal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Stolen identities become difficult to reuse . . . . . . . . . . . . . . . . . . . . . . . . 23

Authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

First-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Second-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Mutual authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Entrust IdentityGuard components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Entrust IdentityGuard Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Entrust IdentityGuard Authentication service . . . . . . . . . . . . . . . . . . . . . 28

Entrust IdentityGuard Administration service. . . . . . . . . . . . . . . . . . . . . . 29

Administration interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 IdentityGuard 9.0 Deployment Guide Document issue: 1.0

Properties editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Master user shell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

First-factor authentication application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Entrust IdentityGuard Radius proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Entrust IdentityGuard Desktop for Microsoft Windows . . . . . . . . . . . . . . . . . . 31

Entrust IdentityGuard Remote Access Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Entrust IdentityGuard ISAPI filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Client applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Entrust IdentityGuard users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Microsoft Windows desktop users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Routing and Remote Access Service (RRAS) users . . . . . . . . . . . . . . . . . . 34

VPN users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Web users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

CHAPTER 2Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Overview of available authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

First-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Radius server authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

External authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Second-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Grid authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Determining the grid challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Passcode lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Knowledge-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

One-time password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

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

Sources of application data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Setting risk policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Setting authentication policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

IP geographic locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Blacklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Temporary PIN authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Using personal verification numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

CHAPTER 3Planning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Planning: initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Entrust IdentityGuard policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Other precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Planning administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Assigning master users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Assigning administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Planning user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Alias and user ID requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Aliases in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Training users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Providing services to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Locking out users based on authentication method . . . . . . . . . . . . . . . . . . . . . 72

Suspending users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Group requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Groups in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Groups in an enterprise deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Analyzing your companys group needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Group implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


CHAPTER 4Deployment considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

Application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Web integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Microsoft Windows integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

VPN remote access integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Wireless Access Portal integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Application considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Integrating with existing user management systems . . . . . . . . . . . . . . . . . . . . . 81

Using shared secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Selecting a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Directory repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Database repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Performance and maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Performance testing strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Backing up, restoring and migrating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

High availability and disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Entrust IdentityGuard Server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Directory failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Local directory failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Geographically dispersed directory failover . . . . . . . . . . . . . . . . . . . . . . . 89

Database failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Radius server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Switching over to Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

CHAPTER 5Deploying grid authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

Grid requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Grid size and format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Grid size impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Grid format impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Grid lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7Varying the grid challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Challenge algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Grid production models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Produce-and-assign model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Produce-and-assign grids for existing users . . . . . . . . . . . . . . . . . . . . . 102

Produce-and-assign grids for new users . . . . . . . . . . . . . . . . . . . . . . . . 104

Preproduction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Forcing card activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Physical card security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Physical card production options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

In-house card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Typical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Outsourced card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Typical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Entrust IdentityGuard card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Typical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Card production cost factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Secure file transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Secure email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Secure FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Automating processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

CHAPTER 6Deploying token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Using tokens for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Token lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Entering token values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


Token deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Assigning tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Token self-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Forcing token activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Physical token security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

CHAPTER 7Deploying knowledge-based authentication . . . . . . . . . . . . . . . . . . . . . . . .121

Question requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Sources of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Creating good questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Selecting a set of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Challenge accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Setting how many correct answers are required . . . . . . . . . . . . . . . . . . 126

Setting the accuracy of answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

APPENDIX AUser life cycle management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Life cycle management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Delivery and activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

9Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Remove cancelled cards and tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Remove inactive cards and tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Remove unassigned cards and tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Synchronize with the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Update images used for mutual authentication . . . . . . . . . . . . . . . . . . . . . . . 140

Update personal verification numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Update IP geographical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

APPENDIX BEntrust IdentityGuard baseline architectures . . . . . . . . . . . . . . . . . . . . . . . . 141

Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Web access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Web access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Web access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Web access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

VPN remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

VPN remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

VPN remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

VPN remote access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Wireless access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Wireless access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Wireless access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Wireless access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155


Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Microsoft Windows remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Microsoft Windows remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . 156

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Microsoft Windows remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . 157

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Microsoft Windows remote access - high availability . . . . . . . . . . . . . . . . . . . 158

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Generic remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Generic remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Generic remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Generic remote access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Microsoft Windows desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Microsoft Windows desktop - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Microsoft Windows desktop - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Microsoft Windows desktop - high availability . . . . . . . . . . . . . . . . . . . . . . . . 165

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

APPENDIX CCard usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167

Entrust IdentityGuard card usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Usability test summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Usability test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

General guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Card design and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Use of color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

11

Design of the grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Grid authentication implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Web login challenge method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Mutual authentication (through displaying a authentication secret) . . . . . . . . 173

Temporary PIN length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

13

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 15

Related documentation on page 16

Obtaining documentation on page 17

Obtaining technical assistance on page 18

This guide contains the following sections:

About Entrust IdentityGuard on page 21 describes Entrust IdentityGuard and what it does.

Authentication methods on page 35 describes and compares the authentication methods and how to deploy them.

Planning your deployment on page 63 describes Entrust IdentityGuard deployment planning considerations.

Deployment considerations on page 77 describes how to integrate Entrust IdentityGuard into your existing applications.

Deploying grid authentication on page 95 describes, in detail, how to deploy grid authentication.

Deploying token authentication on page 117 describes, in detail, how to deploy token authentication.

Deploying knowledge-based authentication on page 121 describes, in detail, how to deploy knowledge-based authentication.

User life cycle management on page 129 describes the life cycle for an Entrust IdentityGuard user.

14 IdentityGuard 9.0 Deployment Guide Document issue: 1.0Feedback on guide

Entrust IdentityGuard baseline architectures on page 141 describes various architectures for deploying Entrust IdentityGuard.

Card usability study on page 167 describes a study completed to examine card usability aspects.

15About this guideFeedback on guide

Documentation conventionsTable 1 contains the typographic conventions that appear in this guide:

Note and Attention textThroughout 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.

Table 1: Typographic conventions

Convention Purpose Example

Bold text (other than headings)

Indicates graphical user interface elements and wizards

Click Next.

Italicized text Used for book or document titles

Entrust TruePass 7.0 Deployment Guide

Blue text Used for hyperlinks to other sections in the document

Entrust TruePass supports the use of many types of digital ID.

Underlined blue text

Used for Web links For more information, visit our Web site at www.entrust.com.

Courier type Indicates installation paths, file names, Windows registry keys, commands, and text you must enter

Use the entrust-configuration.xml file to change certain options for Verification Server.

Angle brackets

< >

Indicates variables (text you must replace with your organizations correct values)

By default, the entrust.ini file is located in /conf/security/entrust.ini.

Square brackets

[courier type]

Indicates optional parameters

dsa passwd [-ldap]


Related documentationEntrust 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 repositoryMicrosoft Active Directory, Microsoft Active Directory Application Mode, Critical Path InJoin Directory, IBM Tivoli Directory, Novell eDirectory, Oracle Directory, or Sun ONE Directorysee the Entrust IdentityGuard Directory Configuration Guide.

For information about configuring Entrust IdentityGuard to work with a supported JDBC databaseIBM DB2 Universal Database, Microsoft SQL Server, MySQL, PostgreSQL, or Oracle Databasesee 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


Obtaining documentationEntrust 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 feedbackYou 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 Entrusts 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.

[email protected]


Obtaining technical assistanceEntrust 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 supportEntrust 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 numbersFor 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 addressThe email address for Customer Support is:

[email protected]


Professional ServicesThe 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

21

Chapter 1

About Entrust IdentityGuard

Entrust IdentityGuard is a multifactor authentication product that enhances security and verifiability by providing multifactor authentication methods. It allows users to prove their identity when accessing sensitive resources from their Microsoft Windows desktop, remotely through a VPN connection, or over the Web.

This chapter contains the following sections:

Why use Entrust IdentityGuard? on page 22

Authentication choices on page 24

Entrust IdentityGuard components on page 27


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 organizations 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

This section contains the following topics:

Challenges of first-factor authentication on page 23

Benefits of multifactor authentication on page 23

Employee repository

Entrust IdentityGuard Server

User name and password authentication resource

Company VPN device

Company firewall

User that requires multifactor

authentication

23About Entrust IdentityGuardFeedback on guide

Challenges of first-factor authenticationAuthentication is the process of determining whether someone or something is, in fact, who or what it presents itself as. 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 alonewhich are easy to steal and easy to reuseare 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 authenticationMultifactor 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 stealWith 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 reuseYour 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 users 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.


Authentication choicesEntrust 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 choicesYou 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

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 41.

Second-factor authentication choicesEntrust 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 voice message delivery)


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 43. For cards, tokens and one-time-passwords, you can include the use of a personal verification number (PVN). See Using personal verification numbers on page 64 for more information.

Mutual authentication choicesMutual 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 54.

Machine authenticationEntrust IdentityGuard allows you to verify a user by comparing current properties of the users 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 57 for a detailed description of machine authentication.

Risk-based authenticationEntrust IdentityGuard allows you to determine situations where second-factor authentication is applied, based on a users 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.

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 60 for a detailed description of risk-based authentication.


Entrust IdentityGuard componentsThe 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

Figure 3: Entrust IdentityGuard as the sole authentication system

This section contains the following topics:

Entrust IdentityGuard Server on page 28

Repository on page 30

First-factor authentication application on page 31

Entrust IdentityGuard Radius proxy on page 31


Repository

UserFirst-factor

authenticationapplication


RepositoryUser


Entrust IdentityGuard Desktop for Microsoft Windows on page 32

Entrust IdentityGuard Remote Access Plug-in on page 33

Client applications on page 34

Entrust IdentityGuard users on page 35

Entrust IdentityGuard ServerThe Entrust IdentityGuard Server is the main component of the Entrust IdentityGuard system. It 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 IdentityGuards 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.


Figure 4: Entrust IdentityGuard components

Entrust IdentityGuard Authentication serviceThe 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.

Client authentication

application


Client administration

application

SOAP (SSL is optional)

SOAP (with SSL)

Entrust IdentityGuard Desktop for Microsoft

Windows


Administration service

Master user shell

Authentication service

Entrust IdentityGuard Radius proxy


Entrust IdentityGuard Administration interface and

Properties editor

HTML/HTTPS

Web administration application

Application serverRepository

Directory

Database


Entrust IdentityGuard Administration serviceThe 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, 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 interfaceAdministrators use the Web-based Administration interface to perform system and user administration operations that define how Entrust IdentityGuard will work in your organization.

Properties editorAdministrators use the Properties editor to set or review the properties that govern the behavior of Entrust IdentityGuard and its components.

Master user shellThe master user shell is a command line 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.

RepositoryEntrust IdentityGuard uses your existing repository to store user data in an existing LDAP-compliant directory, a JDBC-compliant database or both. 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.

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 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 on repositories, see Selecting a repository on page 83.

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 will attempt 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 88.

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 77.

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 proxyThe 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 password authentication). If the resource is a domain controller or directory, you must


use external authentication (see External authentication on page 42). 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 IdentityGuardno 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), and a 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 WindowsEntrust 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 2000 or Windows XP desktop (online or offline)

The Windows Login feature of the Entrust IdentityGuard Desktop for Microsoft Windows allows users to use grid 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 dial-up, wireless, or VPN remote access

The Microsoft Routing and Remote Access Service (RRAS) feature of the Entrust 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 Manager is deployed using a Windows installer (MSI) file. You can customize the installer file by applying a transform (MST) file, 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 organizations policies and practices.

In this scenario, each user in your company has a 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 card (for example, the user lost the card), the user can enter a temporary PIN, which Entrust IdentityGuard Desktop will validate.

If the user is offline, the user can enter an offline temporary PIN, which Entrust IdentityGuard Desktop will validate 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-inThe 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.


Entrust IdentityGuard ISAPI filterEntrust 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 applicationsClient applications use the Authentication API and the Administration API to access Entrust IdentityGuards 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 (Administration API)

Obtaining user information (user ID, email address, image replay 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 (Authentication API)

Presenting them with an initial authentication page (user name 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 IdentityGuards response to the user


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 usersEntrust IdentityGuard users are divided into different categories, based on how they access your organizations resources. See Entrust IdentityGuard baseline architectures on page 141 for diagrams showing how Entrust IdentityGuard interacts with these users.

Microsoft Windows desktop usersMicrosoft 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) usersRRAS 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.

Allow self-administration of users

Presenting a page that allows them to change user information (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

Table 3: Sample activities of client applications (continued)

Client applications can By


VPN usersVPN 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 79.

Web usersWeb 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 78.

35

Chapter 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.

This chapter contains the following sections:

Overview of available authentication methods on page 36

First-factor authentication methods on page 41

Second-factor authentication methods on page 43

Mutual authentication methods on page 54

Machine authentication on page 57

Risk-based authentication on page 60

Temporary PIN authentication on page 63

Using personal verification numbers on page 64


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 IdentityGuards 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

37Authentication methodsFeedback 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 64.

mutual authentication (organization authentication)

In mutual authentication, your organization proves itself as authentic. Mutual authentication can involve different types of replay authentication.

Grid authentication(grid location challenge

and response )

Out-of-band authentication(one-time password by SMS

mail, email , or voice mail)

Knowledge -based authentication

(questions and answers )

Token authentication(dynamic password )

Passcode list authentication

(often scratchpad)


Figure 7: Mutual authentication methods

machine authentication

In machine authentication, the users identity is verified based on various properties of the users 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 users geographic locationRisk 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.

Serial replay authentication(grid card serial number )

Message replay authentication (user entered

message)

Grid location replay authentication (grid locations shown specific to

user)

Image replay authentication

(user selected image )


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 65 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 method

Physical requirements for users

Renewal options1 Sample use

Token Token hardware When device is lost or battery dies (6 years or more)

Requiring strong second-factor authentication

Grid Card Based on use or time Requiring strong second-factor authentication

Passcode list Printed list Based on use or time Requiring infrequent one-time 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 delivered by an out-of-band mechanism

None2 One-time use only One-time, highly sensitive operation

Machine (can be part of risk-based authentication)

N/A Based on each login, length of time, or when users change computers

Users access site from personally-owned computers

IP geolocation (risk-based)

N/A N/A Users access site from a variety of locations


Replay (organization) Card, if using grid location or serial number replay

N/A Verification of organization

1. An administrator or application can force a renewal at any time.2. Users need a telephone number, SMS information, or email account in order to receive the one-time password.

Table 4: Comparison of available authentication methods (continued)

Authentication method

Physical requirements for users

Renewal options1 Sample use


First-factor authentication methodsYou can use Entrust IdentityGuard to directly manage first-factor authentication; that is, to check if a users 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 organizations password requirements.

Radius server authenticationFor 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 42.

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.


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 authenticationThe 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 144. Also see the Entrust IdentityGuard Installation Guide for more information.


Second-factor authentication methodsYour 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.

The following second-factor authentication methods are available:

Token authentication on page 43

Grid authentication on page 44

Passcode lists on page 47

Knowledge-based authentication on page 49

One-time password authentication on page 51

Token authenticationUsing 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 (response-only mode). The Mini Token is available in an AT version (a time+event synchronous token) and an OE version (an OATH compliant token). Entrust IdentityGuard also supports tokens from other vendors.

In addition, you can configure the Entrust IdentityGuard APIs to use any tokens from any token vendor. Different token types can be assigned to your users, and 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 Administration Guide.

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 impossible 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.


Grid authenticationWith 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 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 card, thus providing a second factor of authentication.

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

Table 5: Token authentication advantages and considerations (continued)


Figure 8: Entrust IdentityGuard challenge sample

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 users 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

************

IGuser1


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 users 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 54). 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 card usability study on page 168).

It is inexpensive to set up, maintain and renew.


Determining the grid challenge sizeThere 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 listsPasscode 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. With this approach, you provide users with a list of randomly generated passcodes for second-factor authentication.

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).

Deployment types Web access

Microsoft Windows remote access

VPN remote access

Microsoft Windows desktop

Deployment risks and mitigation

Through mechanisms such as phishing or pharming, an attacker can capture one or more grid authentications made by a user and attempt to authenticate to the legitimate application. Replace 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 card security is maintained throughout the deployment process.

Table 6: Grid authentication advantages and considerations (continued)


Some organizations view passcode lists as easier for their users to use than cards, though our usability study proved that card use is quick to learn. (See Card usability study on page 167.)

Typically, you distribute these lists to users on a printed sheet of paper similar to Figure 11. You can also distribute scratch-off 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.


To help users remember the one-time use restriction, 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.

Knowledge-based authenticationA 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.

Table 7: Passcode list authentication advantages and considerations

Advantages One-time use of a password makes it impossible for attackers to reuse authentication data.

You can create multiple one-time passwords 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 will be 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 mitigation

Some phishing attacks target this form of authentication.

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.


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 users 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 cards or tokens).

You can leverage previous interactions between the user and your organization.


One-time password authenticationThere are si

IG 90 Deployment Guide-Iss20

Documents

Transcript of IG 90 Deployment Guide-Iss20