CRYPTOAdmin SPT Authentication Server v5.32 …portal.cryptocard.com/documentation/TechDocs/CRYPTOAdminV532.pdf · 2.1 Administration: ... 16.5 Solaris -Configuring the pam.conf file

CRYPTOAdmin SPT Authentication Server v5.32

Administrator Guide

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved http://www.cryptocard.com 030903

CRYPTOAdmin 5.32 Server Administrator Guide

Table of Contents

PROPRIETARY NOTICE .......................................................................................VIII

License and Warranty Information............................................................................ viii CRYPTOCard Software License Agreement ................................................................. viii Software License......................................................................................................ix Limited Software Warranty........................................................................................ x Warranty Exclusions................................................................................................. x Customer Obligation.................................................................................................xi

1. WHO SHOULD READ THIS MANUAL? .................................................................2

1.1 Additional Information and Assistance................................................................... 2 1.2 Related Documentation: ..................................................................................... 1

1.2.1 SC-1/EUS and ST-1/EUS Software Token Deployment Guide.............................. 1 1.2.2 CRYPTOWeb for IIS, NFuse and Exchange 2000/OWA Deployment Guide............. 1 1.2.3 CRYPTOLogon for LAN/Domain Authentication ................................................. 1 1.2.4 Plug-ins for Cisco, Check Point and Nortel VPN Clients Guides ............................ 1 1.2.5 Integrated Solutions Guides .......................................................................... 2

1.3 Conventions...................................................................................................... 2 1.4 Terminology...................................................................................................... 2

2. CRYPTOCARD SECURE PASSWORD TECHNOLOGY (SPT) OVERVIEW .................4

2.1 Administration: ................................................................................................. 5 2.2 Token Deployment:............................................................................................ 6

2.2.1 Hardware Tokens: ....................................................................................... 6 2.2.2 Software Tokens: ........................................................................................ 6 2.2.3 Smart Card Tokens:..................................................................................... 6

2.3 CRYPTODeploy ™............................................................................................... 7 2.4 Scalability:........................................................................................................ 7 2.5 SecurID Migration:............................................................................................. 7 2.6 Application and Interoperability Directory:............................................................. 8

2.6.1 VPN Solutions ............................................................................................. 8 2.6.2 Firewall Solutions: ....................................................................................... 8 2.6.3 Web Servers / Portals .................................................................................. 8 2.6.4 RADIUS Servers .......................................................................................... 8 2.6.5 LAN (Domain Logon).................................................................................... 8 2.6.6 Single Sign-on ............................................................................................ 8 2.6.7 Wireless ..................................................................................................... 8 2.6.8 Thin Clients ................................................................................................ 8

2.7 New Features in CRYPTOAdmin 5.32: ................................................................... 9

3. THEORY OF OPERATION..................................................................................10

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved i For assistance mailto:[email protected]


3.1 Server Modules ................................................................................................10 3.1.1 CRYPTOAdmin Server Module .......................................................................10 3.1.2 easyRADIUS Server Module..........................................................................10 3.1.3 CRYPTOAdmin Client Module (GUI) ...............................................................10 3.1.4 CRYPTOAdmin Client Module (CLI) ................................................................11

3.2 Authentication Agents .......................................................................................11 3.2.1 CRYPTOAgent for Funk Steel Belted RADIUS...................................................11 3.2.2 CRYPTOAgent for Microsoft IAS.....................................................................11 3.2.3 CRYPTOWeb for IIS.....................................................................................11 3.2.4 CRYPTOLogon for Windows ..........................................................................12 3.2.5 PAM for Linux/Solaris ..................................................................................12

3.3 End User Service (EUS) based Software and Smart Card Tokens .............................12 3.3.1 CRYPTOCard EUS for Windows......................................................................12 3.3.2 CRYPTOCard EUS for Linux ..........................................................................12 3.3.3 CRYPTOCard EUS for Mac OS X (10.2) ...........................................................13 3.3.4 CRYPTOCard EUS for Solaris.........................................................................13

3.4 VPN Plug-ins ....................................................................................................13 3.4.1 CRYPTOPlug-in for Cisco VPN........................................................................13 3.4.2 CRYPTOPlug-in for Check Point VPN-1 SecuRemote Client.................................14 3.4.3 CRYPTOPlug-in for Nortel Contivity Client .......................................................15

3.5 JDBC Drivers....................................................................................................16 3.6 Tools...............................................................................................................16 3.7 Hardware Components ......................................................................................16

4. CRYPTOCARD SPT INSTALLATION PREREQUISITES........................................18

4.1 CRYPTOAdmin Server Modules............................................................................18 4.2 Agents ............................................................................................................18 4.3 EUS Based Tokens ............................................................................................19 4.4 Hardware Tokens..............................................................................................19

5. LICENSING......................................................................................................20

5.1.1 What is a Full License? ................................................................................20 5.1.2 What is an Incremental License?...................................................................20 5.1.3 When is a Full License required and how are Full licenses ordered? ....................20 5.1.4 When is an Incremental license required? ......................................................20 5.1.5 How are licenses delivered? .........................................................................21 5.1.6 License Installation .....................................................................................21 5.1.7 Evaluation Licenses.....................................................................................21

6. TOKEN SELECTION..........................................................................................22

6.1 Software Token Overview ..................................................................................22 6.2 Hardware Token Overview .................................................................................22

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved ii For assistance mailto:[email protected]


6.3 Ease of Use......................................................................................................22 6.3.1 Is a software token secure? .........................................................................23 6.3.2 Are hardware tokens more secure? ...............................................................23 6.3.3 Do software tokens offer true two-factor authentication?..................................24 6.3.4 But what if the computer is stolen? ...............................................................24 6.3.5 Why is a PIN any better than a static password? .............................................24 6.3.6 What are the advantages of a software token?................................................25 6.3.7 Can tokens provide any other security functions? ............................................26

6.4 EUS Software tokens:........................................................................................26 6.4.1 ST-1/EUS Software Token............................................................................27 6.4.2 SC-1/EUS Smart Card Token........................................................................28

6.5 Hardware Tokens: ............................................................................................30 6.5.1 RB-1 Hard Token ........................................................................................30 6.5.2 KT-1 Key Chain Token.................................................................................30

7. CRYPTOADMIN SERVER INSTALLATION..........................................................31

7.1 Installation Sequence ........................................................................................32 7.2 CRYPTOAdmin Server Installation........................................................................33

7.2.1 Step 1. CRYPTOAdmin Server for Windows Installation and Configuration ...........33 7.2.2 Step 1. CRYPTOAdmin Server for Linux Installation and Configuration................34 7.2.3 Step 1. CRYPTOAdmin Server for Solaris Installation and Configuration ..............36

7.3 Step 2 – Server Configuration.............................................................................37 7.3.1 Configure additional Operators .....................................................................37 7.3.2 Overview: .................................................................................................38 7.3.3 Required information before proceeding:........................................................39 7.3.4 Launch CRYPTOAdmin Server Configuration utility...........................................39 7.3.5 Register Clients ..........................................................................................40 7.3.6 Register Operators......................................................................................40

7.4 Step 3. CRYPTOAdmin Client Installation and Configuration ....................................41 7.5 Step 4 – Launch CRYPTOAdmin Client..................................................................41

8. CRYPTOADMIN CLIENT GUI MANAGEMENT CONSOLE .....................................43

8.1 Detailed Description ..........................................................................................43 8.2 Toolbar ...........................................................................................................44 8.3 Group Tree ......................................................................................................45 8.4 Token List........................................................................................................45 8.5 Preview Pane ...................................................................................................46 8.6 Options dialog box ............................................................................................46 8.7 Initialization tab ...............................................................................................46 8.8 PIN Options tab ................................................................................................47 8.9 Connecting and Disconnecting Servers.................................................................47 8.10 Groups .......................................................................................................48

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved iii For assistance mailto:[email protected]


8.10.1 Creating, Modifying, and Deleting groups .......................................................48 8.10.2 Access to groups, Read Only groups, and Group Permissions ............................49

8.11 Tokens .......................................................................................................49 8.12 Creating and Deleting tokens.........................................................................50 8.13 Initializing tokens.........................................................................................51 8.14 Rename Token ............................................................................................51 8.15 Test tokens .................................................................................................51 8.16 Edit Token Info dialog box; Modifying Token properties .....................................52

8.16.1 Display Tab................................................................................................52 8.16.2 PIN tab .....................................................................................................53 8.16.3 Synchronization tab ....................................................................................54

8.17 What is QUICKLog Authentication...................................................................54 8.18 Why is QUICKLog better? ..............................................................................54 8.19 Default Token Profiles...................................................................................55 8.20 Find tokens .................................................................................................55 8.21 Dragging/Dropping & Copying/Moving tokens ..................................................56 8.22 Modifying Operator Permissions .....................................................................56

8.22.1 Group tree.................................................................................................57 8.22.2 Group permissions box ................................................................................57

9. INITIALIZING TOKENS ...................................................................................59

9.1 Hardware Token Initializers ................................................................................59 9.2 Initializer Requirements .....................................................................................60 9.3 Serial Cables ....................................................................................................60 9.4 Hardware Installation ........................................................................................60 9.5 COM Port Setup................................................................................................60 9.6 Initializer LED Indicators ....................................................................................61

9.6.1 Front panel LED’s (from left to right) .............................................................61 9.6.2 Top panel LED’s..........................................................................................61

10. INSTALL AND CONFIGURE EASYRADIUS SERVER............................................62

10.1 Overview ....................................................................................................62 10.2 Advantages of using easyRADIUS...................................................................62 10.3 Installation..................................................................................................62 10.4 Start/Stop easyRADIUS ................................................................................63 10.5 Testing the server ........................................................................................63 10.6 Configuring easyRADIUS...............................................................................64 10.7 The Clients file.............................................................................................65 10.8 Users File....................................................................................................65

10.8.1 Username..................................................................................................66 10.8.2 Check items...............................................................................................66 10.8.3 Control Items.............................................................................................66

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved iv For assistance mailto:[email protected]


10.8.4 Reply Items ...............................................................................................66 10.9 Hints and Huntgroup (Authentication Pre-Processing)........................................67 10.10 Troubleshooting ........................................................................................68

11. CREATE A CRYPTOADMIN REPLICA SERVER....................................................70

11.1 Replica Server Prerequisites ..........................................................................70 11.2 Step 1. Configure an NT/2000/XP Primary Server for Replication (Server A) .........70 11.3 Step 2: Configure an NT/2000/XP Replica Server (Server B) ..............................71

11.3.1 Test One-way Replication ............................................................................71 11.3.2 One-way Replication Considerations ..............................................................71

11.4 Step 3: Configure By-directional Replication on NT/2000/XP Servers ...................72 11.4.1 Test Bi-directional Replication.......................................................................73

11.5 Step 1. Configure a Linux/Solaris Primary Server for Replication (Server A)..........73 11.6 Step 2: Configuring the Replica Server (Server B) ............................................74

11.6.1 Test One-way Replication ............................................................................74 11.6.2 One-way Replication Considerations ..............................................................74

11.7 Step 3: Configure By-directional Replication on Linux/Solaris Servers ..................75 11.7.1 Test Bi-directional Replication.......................................................................76

11.8 Troubleshooting MySQL Replication ................................................................76 11.9 MySQL Commands .......................................................................................77

12. ALTERNATE DATABASES (MS-SQL, ORACLE) ...................................................78

12.1 Configure Oracle or MS-SQL for CRYPTOAdmin Server.......................................78 12.2 Modify .cfg Control Block for Oracle ................................................................79 12.3 Modify .cfg Control Block for MS SQL ..............................................................80 12.4 Create CRYPTOCardTokens Table in Database ..................................................81

13. CRYPTOADMIN SERVER BACK-UP ...................................................................82

13.1 Backing up your Database.............................................................................82

14. CLIENT COMMAND LINE INTERFACE (CLI) ......................................................83

14.1 CLI Commands and Syntax ...........................................................................84 14.2 Operator Permissions Reference Chart ............................................................88

15. ALTERNATE RADIUS SERVERS ........................................................................89

15.1 Cisco Secure ACS 3.0+ .................................................................................89 15.1.1 Configuring the External User Database .........................................................89 15.1.2 Setting the Unknown User Policy...................................................................91 15.1.3 Mapping CRYPTOCard Users to a Cisco Secure Group.......................................91 15.1.4 Troubleshooting Tips ...................................................................................92 15.1.5 Token Caching ...........................................................................................92 15.1.6 Cisco Secure logging messages ....................................................................92

15.2 Funk Steel Belted RADIUS.............................................................................94

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved v For assistance mailto:[email protected]


15.2.1 Windows Installation ...................................................................................94 15.2.2 Solaris Installation ......................................................................................95 15.2.3 Configuring CRYPTOAdmin ...........................................................................96 15.2.4 Configuring Funk Steel Belted RADIUS...........................................................96 15.2.5 Configuring RADIUS Authentication ...............................................................96 15.2.6 Enabling CRYPTOCard authentication.............................................................97 15.2.7 Troubleshooting Tips ...................................................................................97

15.3 Microsoft IAS RADIUS on Windows 2000 sp2 ...................................................98 15.3.1 Configure IAS ............................................................................................99 15.3.2 IAS Troubleshooting Tips ...........................................................................102 15.3.3 Changing the default RADIUS port in IAS .....................................................102 15.3.4 Logging rejected, discarded or successful authentication attempts...................102 15.3.5 Customizing IAS Logs................................................................................103 15.3.6 Starting the CRYPTOAdmin server in debug mode .........................................103

16. PAM FOR LINUX AND SOLARIS .....................................................................105

16.1 Compiling the PAM module ..........................................................................105 16.2 Server Configuration File (RADIUS) ..............................................................105 16.3 Securing the RADIUS Server Configuration ....................................................107 16.4 Configuring application-specific configuration files...........................................107 16.5 Solaris -Configuring the pam.conf file ...........................................................107

16.5.1 Solaris – Example pam.conf file ..................................................................108 16.6 Linux - CRYPTOCard PAM for Configuration Examples......................................109

16.6.1 Login\Telnet ............................................................................................109 16.6.2 FTP.........................................................................................................110 16.6.3 SSHD (OpenSSH) .....................................................................................110 16.6.4 PPP.........................................................................................................110

16.7 Troubleshooting.........................................................................................111 16.7.1 Authentication problems. ...........................................................................111 16.7.2 Compiling the modules returns an error. ......................................................111 16.7.3 The RADIUS server does not even see the requests.......................................112 16.7.4 SSH and Challenge Response .....................................................................112 16.7.5 Linux PAM, PPPD and Radius ......................................................................113

16.8 PAM module types, control flags and arguments .............................................114 16.9 Linux - Example and description of an application configuration file ...................116

17. DIAGNOSTIC TOOLS......................................................................................118

17.1 Radtest ....................................................................................................118 17.2 RADIUS_Test ............................................................................................118

18. TROUBLESHOOTING......................................................................................119

18.1 Token Resynchronization.............................................................................119

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved vi For assistance mailto:[email protected]


18.1.1 Web Based Resynchronization: ...................................................................119 18.1.2 Help Desk Resynchronization: ....................................................................119 18.1.3 Battery Replacement: ...............................................................................120 18.1.4 RB-1 / KT-1 Battery Replacement ...............................................................120

18.2 CRYPTOAdmin Server will not authenticate after upgrading. .............................120 18.3 CRYPTOAdmin Client cannot connect to the server..........................................121 18.4 End User Login failures ...............................................................................122

18.4.1 Incorrect username...................................................................................122 18.4.2 Incorrect password ...................................................................................122 18.4.3 Correct password......................................................................................123 18.4.4 Authentication failure ................................................................................123 18.4.5 Log files ..................................................................................................123 18.4.6 Logging level ...........................................................................................123 18.4.7 Location ..................................................................................................124

19. ORDERING ADDITIONAL CRYPTOCARD PRODUCTS.......................................125

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved vii For assistance mailto:[email protected]


Proprietary Notice

License and Warranty Information

CRYPTOCard Corporation, CRYPTOCard Corp. and their affiliates retain all ownership rights to the computer program described in this manual and other computer programs offered by the company (hereinafter called "CRYPTOCard") and any documentation accompanying those programs. Use of CRYPTOCard software is governed by the license agreement accompanying your original media. CRYPTOCard software source code is a confidential trade secret of CRYPTOCard. You may not attempt to decipher, de-compile, develop, or otherwise reverse engineer CRYPTOCard software, or knowingly allow others to do so. Information needed to achieve the interoperability of CRYPTOCard software with products from other manufacturers may be obtained from CRYPTOCard upon request.

This manual, as well as the software described in it, is furnished under license and may only be used or copied in accordance with the terms of such license. The material in this manual is furnished for information use only, is subject to change without notice, and should not be construed as a commitment by CRYPTOCard. CRYPTOCard assumes no liability for any errors or inaccuracies that may appear in this document.

Except as permitted by such license, no part of this publication may be reproduced; stored in a retrieval system; or transmitted in any form or by any means electronic, mechanical, recording or otherwise; without the prior written consent of CRYPTOCard.

Java and Solaris are registered trademarks of Sun Microsystems, Inc.

Microsoft Windows and Windows XP/2000/NTare registered trademarks of Microsoft Corporation.

CRYPTOCard Software License Agreement

This legal document is an agreement between CRYPTOCard Inc. and you, the end user. By installing this software you are agreeing to be bound by the terms and conditions of this License Agreement and Limited Warranty.

CRYPTOCard does NOT sell any rights in its computer software, but grants a right to use the software by means of a license.

You acknowledge that you have read, understand and agree to be bound by this License Agreement and Limited Warranty.

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved viii For assistance mailto:[email protected]


You agree that they form the entire agreement between the parties and that no oral or written information or advice given by CRYPTOCard or any person shall amend them nor form the basis of an agreement to increase CRYPTOCard's liability in any manner whatsoever.

Software License

1. GRANT: In consideration of payment by you of the license fee and subject to the terms and conditions of this License Agreement and Limited Warranty, CRYPTOCard grants to you a non-exclusive, non-transferable right to use the enclosed copy of a CRYPTOCard software program (the "SOFTWARE") and the enclosed written materials (the "DOCUMENTATION") as follows:

The SOFTWARE may be used on a single computer at a single location for so long as this License Agreement is in effect.

The DOCUMENTATION may be used by persons who use the SOFTWARE in accordance with the terms and conditions of this License Agreement, and solely for the purposes of obtaining information about the functions of the SOFTWARE, the specific ways in which the SOFTWARE operates and the procedures to follow to resolve problems with the SOFTWARE.

2. PROPRIETARY RIGHTS AND COPYING RESTRICTIONS: CRYPTOCard or its licensors therein owns Title to all of the Software and Documentation and all intellectual property rights. You specifically acknowledge that the Software and Documentation are copyrighted and contain confidential information and trade secrets of CRYPTOCard and therefore may not be disclosed to any third party without CRYPTOCard's prior written consent. Unauthorized copying of the SOFTWARE or of the DOCUMENTATION is expressly forbidden. You may be held legally responsible for any such unauthorized copying. You are authorized to make one (1) copy of the SOFTWARE solely for backup purposes. You must reproduce and include the copyright notice on the backup copy. You acknowledge and agree that, with respect to copies of Software to be installed on a host computer, CRYPTOCard may have included means to prevent copying or restrict usage of copies of the SOFTWARE.

3. USE RESTRICTIONS: As the LICENSEE, you may physically transfer the SOFTWARE from one computer to another provided that the SOFTWARE is used on only one computer at a time. You may not distribute copies of the SOFTWARE or the DOCUMENTATION to others. You may not modify, adapt, translate, reverse engineer, decompile, disassemble, or create derivative works based on the SOFTWARE or the DOCUMENTATION, except to the extent permitted by law.

4. TRANSFER RESTRICTIONS: This SOFTWARE and DOCUMENTATION is licensed only to you, the LICENSEE, and may not be transferred without the prior written consent of CRYPTOCard. Any authorized transferee of the SOFTWARE or the DOCUMENTATION shall be

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved ix For assistance mailto:[email protected]


bound by the terms and conditions of this License Agreement and Limited Warranty. In no event may you transfer assign, rent, lease, sell or otherwise dispose of the SOFTWARE or the DOCUMENTATION on a temporary or permanent basis except as expressly provided herein.

5. TERMINATION: CRYPTOCard may terminate This License Agreement upon written notice to you if you fail to comply with any provision of this License Agreement. Upon termination you shall destroy all copies of the SOFTWARE and the DOCUMENTATION.

Limited Software Warranty

The SOFTWARE and all accompanying written materials are provided “AS IS” without warranty or condition of any kind, express or implied, including but not limited to implied warranties or conditions of merchantability or fitness for a particular purpose and those arising by statute or otherwise in law or from a usage in the trade. The entire risk as to results and performance of the SOFTWARE is with you. Should the SOFTWARE or accompanying materials prove defective in any way, you (and not CRYPTOCard nor its dealers, distributors or employees) assume the entire cost of all necessary servicing, repair or correction. CRYPTOCard does not warrant, guarantee or represent that the functions contained in the SOFTWARE will meet your requirements or that the installation or operation of the SOFTWARE will be uninterrupted or error free.

CRYPTOCard warrants to their original LICENSEE that the written material and media on which the SOFTWARE is recorded are free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of purchase. CRYPTOCard’s entire liability shall be to replace the defective media and/or written materials when returned postage prepaid with proof of purchase to CRYPTOCard or an authorized CRYPTOCard dealer.

CRYPTOCard Hardware Warranty

CRYPTOCard warrants to the original Purchaser that CRYPTOCard Hardware Tokens and CRYPTOCard Initializers are free from manufacturing defects in materials and workmanship and agrees to remedy any such defect. This warranty shall be in effect for the period of five (5) years following the date of receipt by the original Purchaser. This warranty shall cover and be limited to parts and labor to repair defective units or provide replacements as determined at the sole discretion of CRYPTOCard.

Warranty Exclusions

This warranty does not apply to minor appearance defects, shipping damage, damage caused by abuse or by subjecting the product to usage for which the product was not designed. This warranty does not apply if electrical connection has been made to the

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved x For assistance mailto:[email protected]


product using other than equipment supplied or recommended by does it apply to units that have been altered or tampered with in any way or where repairs have been attempted by other than a CRYPTOCard authorized repair facility. This warranty becomes void for units on which serial numbers have been altered, defaced or removed.

This warranty does not apply to Batteries or to Liquid Crystal Displays in which the glass has been broken (a broken display is characterized by areas of permanent black discoloration that look like ink blots in the display window).

CRYPTOCard reserves the right to make changes in design or to make changes or improvements to these products without incurring the obligation to apply such changes or improvements to products previously manufactured.

The foregoing is in lieu of all other warranties expressed or implied by any applicable laws. CRYPTOCard does not assume or authorize, nor has it authorized any person to assume for it any other obligation or liability in connection with the sale or service of these products. In no event shall CRYPTOCard or any of its agents be responsible for special, incidental or consequential damages arising from the use of these products or arising from any breach of warranty, breach of contract, negligence, or any other legal theory. Such damages include, but are not limited to: loss of profits or revenue, loss of use of these products or any associated equipment, cost of capital, cost of any substitute equipment, facilities or services, downtime costs, or claims of customers of the Purchaser for such damages.

The Purchaser may have other rights under existing federal, state or provincial laws in the USA, Canada or other countries or jurisdictions, and where any terms of this warranty are prohibited by such laws, they are deemed null and void, but the remainder of the warranty shall remain in effect.

Customer Obligation

Shipping Damage: The Purchaser must examine the goods upon receipt and any visible damage should immediately be reported to the carrier so that a claim can be made. Purchasers should also notify CRYPTOCard of such damage. The customer should verify that the goods operate correctly and report all deficiencies to CRYPTOCard within 30 days of delivery. In all cases, the customer should notify CRYPTOCard prior to returning goods.

Goods returned under the terms of this warranty must be carefully packaged for shipment to avoid physical damage using materials and methods equal to or better than those with which the goods were originally shipped to the Purchaser.

Insurance and shipping charges to the repair facility are the responsibility of the Purchaser. CRYPTOCard Corporation will pay return charges for units repaired or replaced under terms of this warranty

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved xi For assistance mailto:[email protected]


Change History

Issue Date Version Changes

2003.04.04 Build 28 Initial release

2003-04-18 Build 35 Documentation update:

Clarify installation procedure for Linux and Solaris

Add reference for Cisco VPN Plug-in for MAC OS X

Add reference for EUS token support on Pocket PC

Add reference to CRYPTOWeb support for Citrix NFuse 2.0

Update MySQL replication troubleshooting.

2003-09-03 Clarify installation instructions for Solaris O/S

Copyright © 2002-2003 CRYPTOCard Corporation All Rights Reserved 1 For assistance mailto:[email protected]


1. Who Should Read This Manual?

This manual is intended for Security Officers and System Administrators. It assumes the reader to have a good knowledge of client-server computing terminology and processes and a working knowledge of the various operating systems on which CRYPTOAdmin Server, authentication agents, plug-ins and authenticators are installed.

CRYPTOCard’s web site is used to publish updates and addenda to this and other CRYPTOCard documents. Please visit our site at http://www.cryptocard.com/ often to stay current with new and important information about our products and services as it becomes available. Various quick start and deployment guides that provide specific configuration and integration instructions for a wide range IT products including firewalls, VPN’s, web servers and mail servers support this guide. These additional documents are located in the Support and Documentation area of our web site.

1.1 Additional Information and Assistance

CRYPTOCard’s technical support specialists will provide detailed guidelines and assistance in planning and implementing CRYPTOCard in your network. In addition to aiding in the selection of the appropriate authentication products, CRYPTOCard can suggest deployment procedures that will provide a smooth, simple transition from existing access control systems and a satisfying experience for network users. We can also help you leverage your existing network equipment and systems to maximize your return on investment. This complimentary support service is available from your first evaluation system download. Contact CRYPTOCard support by any of the following:

International Voice: +1-613-599-2441

North America Toll Free: 800-307-7042

mailto:[email protected]


http://www.cryptocard.com/



1.2 Related Documentation:

1.2.1 SC-1/EUS and ST-1/EUS Software Token Deployment Guide

This document describes the features, functionality and usage of EUS tokens on Windows, Linux, Solaris, MAC and Pocket PC. Refer to:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/EUSDeploymentGuide.pdf

1.2.2 CRYPTOWeb for IIS, NFuse and Exchange 2000/OWA Deployment Guide

This document describes the application of CRYPTOCard authentication to IIS servers and examples using Exchange OWA, Terminal Server for Web and Citrix NFuse. Refer to:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CRYPTOWebforIISDeploymentGuide.pdf

1.2.3 CRYPTOLogon for LAN/Domain Authentication

This document describes the application and installation of CRYPTOLogon Agent, used to lock down access to the desk top and enforce the use of OTP passwords for domain authentication. Refer to:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CRYPTOLogonDeploymentGuide.pdf

For Linux/Solaris systems refer to:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/PAMQuickStart.pdf

1.2.4 Plug-ins for Cisco, Check Point and Nortel VPN Clients Guides

These documents describe the installation and integration of EUS tokens authentication with VPN Clients resulting in transparent OTP authentication.

For CheckPoint:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CheckPointFW1VPN1QuickStart.pdf

For Cisco:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CiscoVPN3000QuickStart.pdf

For Nortel:

http://www.cryptocard.com/site/CRYPTONew_9/pdf/NortelContivityQuickStart.pdf


http://www.cryptocard.com/site/CRYPTONew_9/pdf/EUSDeploymentGuide.pdf

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CRYPTOWebforIISDeploymentGuide.pdf

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CRYPTOLogonDeploymentGuide.pdf

http://www.cryptocard.com/site/CRYPTONew_9/pdf/PAMQuickStart.pdf

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CheckPointFW1VPN1QuickStart.pdf

http://www.cryptocard.com/site/CRYPTONew_9/pdf/CiscoVPN3000QuickStart.pdf

http://www.cryptocard.com/site/CRYPTONew_9/pdf/NortelContivityQuickStart.pdf


1.2.5 Integrated Solutions Guides

Refer to this section of our web site for configuration and installation guides for a wide range of CRYPTOCard ready solutions for Databases, Firewalls, VPN’s, Web Servers, Portals etc.

http://www.cryptocard.com/index.cfm?PID=124&PIDList=58,124&PageName=User%20Guides%20%28PDF%27s%29

1.3 Conventions

Courier Bold Command line text to be entered at prompt (e.g. tar –xf er- foo.tar); a Linux, UNIX or Windows filename (e.g. .tar)

<required> Text which you are required to enter

[optional] Text which you may enter or omit

1.4 Terminology

Administrator: a person with unrestricted permissions and rights to CRYPTOAdmin Server. An administrator creates Operators, grants group permissions to Operators, sets default token profiles, can view, add, update, initialize and delete tokens on the database.

Operator: a person with restricted permissions and rights to CRYPTOAdmin Server. Operator rights and permissions are assigned by the Administrator and can be individually defined to reflect the Operator role and responsibility. Generally Operator permissions are limited to creating and managing groups and tokens in the database and viewing, adding, updating, initializing and deleting tokens. Operator permissions can be a subset of these functions.

End-User: a person using a CRYPTOCard token to authenticate to a CRYPTOCard protected network, system or resource.

Server: in the context of this guide Server will always mean the CRYPTOAdmin Authentication Server application and/or platform a person with restricted permissions and rights to CRYPTOAdmin Server.

Client: in the context of this guide Client will always mean the management and administration GUI or CLI used to manage CRYPTOAdmin Server.

Authenticator: a CRYPTOCard hardware, software or smart card device used to generate a one-time password. Also referred to as a Token.





CRYPTOCard Secure Password Technology (SPT): refers to CRYPTOAdmin Server and related range of authentication agents, VPN plug-ins and tokens that together provide an effective two-factor authentication solution.

One-time Password (OTP): a pseudorandom password generated by a token. It is valid for only one logon for a specific End-user.



2. CRYPTOCard Secure Password Technology (SPT) Overview

CRYPTOCard SPT is used to require strong user authentication at one or more network access points before an End-user can log on. It replaces static passwords by combining two-factor authentication with One Time Passwords (OTP) to prevent the use of lost, stolen, easily guessed or shared passwords to gain access to protected systems. Once implemented, only users to whom you have issued a CRYPTOCard token will be able to gain access to the protected network, systems or resources. With each logon attempt their token will provide a new and unique password, valid only for the specific user and the current logon attempt.

Built around the CRYPTOAdmin Server authentication engine core, it includes all the necessary modules and agents to lock-down an entire network including:

• Administrative access to routers, firewalls, VPN gateways

• Remote network access through firewalls, NAS and VPN

• Web portals including IIS, Apache and iPlanet

• Exchange 2000 Servers (OWA)

• Windows domain logon (LAN) and local machine

• Citrix Server (ICA/NFuse/CSG)

• Unix network / service logon (telnet, ftp, su etc.)

• Kerberos (MIT)



While CRYPTOCard SPT is a sound technical solution for password management, experienced system administrators will know that a successful solution must also be manageable, scalable, usable and readily accepted by all “End-users” in any situation.

To that end a system administrator can look to CRYPTOCard SPT to provide a solution that is easier to manage and use than static passwords, providing a universal, consistent End-user logon experience regardless of End-user location or network point of access.

CRYPTOAdmin Server is a multi-component client-server application that allows system administrators to initialize CRYPTOCard tokens, assign and deploy tokens to End-users and authenticate End-users at CRYPTOCard SPT protected network access points.

It combines the security and administrative advantages of a centralized authentication service with the flexibility of secure, distributed administration consoles. The result is an authentication system that can be easily configured to reflect the structure and geographic diversity of the organization as well as the hierarchy, roles and responsibilities of the administrative staff.

CRYPTOAdmin Server has been designed to accommodate virtually any network topology. Authentication services can be added as, when and where required, permitting an organization to manage, control and expand authentication services on their schedule. For example, an organization may first choose to lock down administrative ports on network equipment, next adding authentication to their VPN services or portals, followed by OWA/Exchange 2000 mail account authentication, and ultimately replacing the use of passwords for local domain (LAN) logon. At each stage a user requires only their personal CRYPTOCard token and the PIN to prove their identity and gain access.

CRYPTOAdmin Server supports any combination of CRYPTOCard tokens, so that the ideal user experience and application integration can be achieved. Organizations can take advantage of the automated deployment and application integration (e.g. VPN clients) of software tokens for PC’s, Mac’s and PDA’s, choose the machine independence of hardware tokens or opt for the multifunction smart card token.

2.1 Administration:

CRYPTOAdmin Server allows users and tokens to be organized according to administrator-defined criteria such as region, department, access type.

Administrators themselves can be assigned granular rights, so that they have access to only those groups and operations for which they have been authorized.



By distributing administration consoles, organizations can establish regional facilities for issuing tokens and providing help desk facilities.

CRYPTOAdmin Server supports multiple concurrent administrators, located as necessary throughout the network and Administrators may be required to use a token to gain access to the management console.

2.2 Token Deployment:

CRYPTOAdmin Server can eliminate the complexity and much of the cost associated with issuing and deploying tokens to a widely distributed user population. Organizations can establish their own regional issuing offices, electronic token distribution, web based token distribution or implement the optional CRYPTODeploy™ automated user enrollment service.

2.2.1 Hardware Tokens:

CRYPTOCard hardware tokens can be issued and deployed from a central office or by regional administrators as and when required. CRYPTOCard tokens do not have an expiration date therefore they do not need to be periodically repurchased and redistributed. Hardware tokens are computing platform independent and are ideal for users that require the ability to logon to the network from any machine.

2.2.2 Software Tokens:

CRYPTOCard software tokens are ideal for widely distributed user populations that always use the same PC to logon to the network. Software tokens have the advantage of electronic distribution. This means that an administrator can issue and deploy virtually any number of tokens with the click of a mouse, eliminating the distribution costs and time required by hardware tokens. They also permit a high degree of integration with many applications (such as VPN clients) and of course, are never forgotten at home.

Software tokens are more secure than digital certificates. They are encrypted and installed in a system secure directory on the End-user machine. All CRYPTOCard software tokens require the use of a secret PIN before they will generate a password to prevent unauthorized use. If the PIN attempt threshold is exceeded, the token locks and will not generate another password. Administrative reset (local or remote) is required to reload and activate a “locked” token.

2.2.3 Smart Card Tokens:

Smart card tokens combine the distribution advantages of software tokens with the portability of hardware tokens. In addition, smart card tokens can be the repository for



digital certificates. Combined, the one-time password authentication can be used not only for authentication, but to ensure that only the authorized user has access to the digital certificate. Smart card tokens can also be used for physical security by activating for door lock systems and incorporating photo ID’s and other identification data on the card.

2.3 CRYPTODeploy ™

CRYPTODeploy ™ is an optional add-on web deployment tool for CRYPTOAdmin Server that automates issuing, installing, self-enrollment and activation of CRYPTOCard tokens to authorized users. Once initiated by the administrator, users are directed to a unique URL for one-time enrollment and installation of their token. Installation can only be executed once without Administrative reset, and only with knowledge of an initial deployment PIN, separately transmitted to the user.

2.4 Scalability:

CRYPTOAdmin Server can be deployed on Windows NT/2000, Red Hat Linux or Sun Solaris servers. CRYPTOAdmin supports local and remote replica servers for hot standby/failover where necessary.

Organizations can use CRYPTOCard’s native MySQL database or optionally use MS-SQL, Oracle or any JDBC compliant database system for the CRYPTOAdmin server.

CRYPTOAdmin Server is designed for high availability to respond to peak demands as well as network outages through RADIUS load balancing, mirrored servers and an authentication process that is not sensitive to time-synchronization or network transit delays. CRYPTOAdmin Server can be implemented as a stand-alone system or installed on existing RADIUS servers.

2.5 SecurID Migration:

CRYPTOAdmin Server, in conjunction with Cisco Secure ACS can provide transparent migration away from SecurID/ACE Server. As SecurID tokens expire, users are issued a CRYPTOCard replacement token. The ACE server can be deactivated once all tokens have been replaced with CRYPTOCard tokens. There is no interruption of service, only improved usability, better security and substantial reduction in cost and administration.



2.6 Application and Interoperability Directory:

2.6.1 VPN Solutions

• Cisco VPN3000 family • Check Point VPN-1 • Nortel Contivity • Netscreen • SSH • RADIUS compliant VPNs

2.6.2 Firewall Solutions:

• Cisco PIX • Check Point Firewall –1 • Nokia • WatchGuard • RADIUS compliant firewalls

2.6.3 Web Servers / Portals

• Microsoft IIS • Apache • Sun One • Citrix NFuse/ICA/CSG • ASP, JSP based servers

2.6.4 RADIUS Servers

• Cisco Secure ACS • Funk Steel Belted RADIUS • Microsoft IAS • CRYPTOCard easyRADIUS

2.6.5 LAN (Domain Logon)

• Microsoft Windows NT/2000 • Unix (Solaris, Linux)

2.6.6 Single Sign-on

• MIT Kerberos • Netegrity

2.6.7 Wireless

• Cisco 802.1x using PEAP • Funk Odessey

2.6.8 Thin Clients

• Wyse Winterm



2.7 New Features in CRYPTOAdmin 5.32:

• One PIN and You're In Secure Password Technology

• 32K Smart Card Support for Windows 2000 and XP

• 32K Smart Card Support for Mac OS X

• PC Smart Card (PCMCIA) Reader Device for Windows 2000 and XP

• PC Smart Card (PCMCIA) Reader Device for Mac OS X

• PC Card (PCMCIA) Smart Card reader PCSC Certification/Compliance

• USB Smart Card reader

• 32K Smart Card applet and PC Support

• Concurrent support for hardware, software and smart card tokens

• Soft Token for Mac OS X, Win 95/98/NT/2000/XP

• CRYPTOLogon for Windows NT/2000/XP

• CRYPTOLogon for Windows - Exchange Server 2000 (OWA)

• CRYPTOLogon for Citrix NFuse/ICA

• CRYPTOWeb for Windows IIS Server

• Automated authentication applet for IIS, NFuse and OWA

• ST-1/EUS and SC-1/EUS based tokens

• MS Certificate Compatible

• Verisign Certificate Compatible

• Entrust Certificate Compatible

• Replication / Failover

• Remote management

• Role based management

• CRYPTOKit SDK



3. Theory of Operation

The CRYPTOCard SPT Server package consists of a number of modules that allow a System Administrator to build a strong authentication system tailored to the specific needs of their organization. These modules are organized by function: Server, Authentication Agents, EUS based tokens, VPN Plug-ins, JDBC Drivers and Tools. Hardware components such as the RB-1 and KT-1 tokens, SC-1 USB and PCCard smart card readers, and RBI and KTI Initializers complete the CRYPTOCard SPT solution.

3.1 Server Modules

3.1.1 CRYPTOAdmin Server Module

CRYPTOAdmin Server is the authentication engine and token database repository for the network. Authentication requests are received by CRYPTOAdmin Server from protected access points via industry standard RADIUS or by CRYPTOCard authentication agents. All token types (RB-1, KT-1, ST-1 and SC-1) are supported by the Server.

CRYPTOAdmin Server services client applications such as the CRYPTOAdmin Client, easyRADIUS server, authentication agents such as CRYPTOWeb for IIS, as well as 3rd party RADIUS servers such as Funk Steel Belted RADIUS, Cisco Secure ACS and Microsoft IAS.

CRYPTOAdmin Server can use any JDBC compliant database system. MySQL is the default database. Drivers for MS-SQL and Oracle are included with the CRYPTOAdmin distribution.

3.1.2 easyRADIUS Server Module

easyRADIUS server is included with the CRYPTOAdmin Server distribution. It is provided for use where:

• There is no pre-existing compatible RADIUS server currently installed on the network

• Cisco Secure ACS v3.0 or higher is the default RADIUS/TACAS+ server on the network

Generally easyRADIUS (if required) is installed on the CRYPTOAdmin Server. Cisco Secure ACS 3.0+ requires easyRADIUS and supports installation of easyRADIUS/CRYPTOAdmin Server locally or on a separate, remote server.

3.1.3 CRYPTOAdmin Client Module (GUI)

This component features a graphical user interface (GUI) to manage and initialize tokens. This CRYPTOAdmin Client communicates with the CRYPTOAdmin Server to retrieve and



update CRYPTOCard token database information. It can generate and initialize EUS software tokens and initialize RB-1 and KT-1 hard tokens via the RBI and KTI token Initializers respectively.

3.1.4 CRYPTOAdmin Client Module (CLI)

This component provides text based, command line functionality equivalent to the GUI interface. Furthermore, it has the ability to ‘import’ other user databases into the CRYPTOAdmin database via batch command. Like the GUI client, it supports the generation and initialization of EUS software tokens and supports RB-1 and KT-1 token initialization via the RBI and KFI token Initializers respectively.

3.2 Authentication Agents

3.2.1 CRYPTOAgent for Funk Steel Belted RADIUS

Installation of this agent creates a link between CRYPTOAdmin Server and Funk Steel Belted RADIUS (SBR), permitting SBR to use CRYPTOCard authentication. The agent supports the connection of SBR Profiles to CRYPTOAdmin Server Token Groups of the same name.

3.2.2 CRYPTOAgent for Microsoft IAS

Installation of this agent creates a link between CRYPTOAdmin Server and Microsoft IAS, permitting IAS to use CRYPTOCard authentication.

3.2.3 CRYPTOWeb for IIS

Installation of this agent creates link between IIS and the CRYPTOAdmin Server, permitting IIS to use CRYPTOCard authentication. It installs an ISAPI plug-in on IIS, creating a CRYPTOCard Tab in the IIS manager. This tab provides an Operator friendly management interface to apply CRYPTOCard authentication to the IIS server, specified folders or individual files. CRYPTOWeb for IIS also includes a customizable Logon applet that automates the authentication process for EUS based tokens.



3.2.4 CRYPTOLogon for Windows

This agent is installed on Windows NT, 2000 or XP End-user computers to require CRYPTOCard authentication before logging onto a Windows LAN (domain authentication). It also requires the use of a CRYPTOCard token for local machine logon when not connected to the LAN. It can replace or be used in conjunction with Microsoft Logon.

3.2.5 PAM for Linux/Solaris

PAM (Pluggable Authentication Module) can be used on Linux and Solaris based systems to implement CRYPTOCard authentication support on a service-by-service basis. Using PAM, an Administrator can require the use of a CRYPTOCard token for SU, Telnet, HTTP, SSH and virtually any other service.

3.3 End User Service (EUS) based Software and Smart Card Tokens

The EUS software provides a common management and automated authentication interface for both the ST-1 software and SC-1 smart card tokens. The EUS token is enabled with the application of one or more End-user specific ST-1 software or SC-1 smartcard initialization files generated by CRYPTOAdmin Server.

EUS tokens automate and greatly simplify the authentication process when used in conjunction with CRYPTOCard VPN plug-ins (Cisco, Nortel, Check Point etc.), web server logon applets and CRYPTOLogon local machine and LAN authentication agent/. Refer to the SC-1/EUS and ST-1/EUS Token Deployment Guide for detailed information on deployment and use of EUS based tokens.

3.3.1 CRYPTOCard EUS for Windows

This module installs the EUS token authenticator software, common to all ST-1 software or SC-1 smart card tokens on Windows platforms.

3.3.2 CRYPTOCard EUS for Linux

This module installs the EUS token authenticator software, common to all ST-1 software or SC-1 smart card tokens on Linux platforms.



3.3.3 CRYPTOCard EUS for Mac OS X (10.2)

This module installs the EUS token authenticator software, common to all ST-1 software or SC-1 smart card tokens on Mac OS X (10.2) platforms.

3.3.4 CRYPTOCard EUS for Solaris

This module installs the EUS token authenticator software, common to all ST-1 software or SC-1 smart card tokens on Solaris platforms.

3.4 VPN Plug-ins

VPN plug-ins provide a link between EUS based tokens and a VPN client for a “One-Pin-and-You’re-In” automated authentication process. Once installed, the user will launch the VPN client and enable the EUS token with their secret security PIN when prompted. Once enabled by the PIN, the EUS token will generate a one time password and automatically pass this along with the End-user’s logon name to the VPN client, which completes the logon process without further End-user intervention.

3.4.1 CRYPTOPlug-in for Cisco VPN

Installs the EUS plug-in for Cisco VPN 3.6+ clients resulting in the following End-user logon experience:

Click on the Cisco VPN icon to launch the VPN Client

On computers with more than one EUS token, select the token to be used for authentication from the Token Name drop down. Select the Cisco VPN Connection from the connection drop down.



Enter secret security PIN to enable token.

Cisco VPN connection will appear in the system tray.

3.4.2 CRYPTOPlug-in for Check Point VPN-1 SecuRemote Client

Installs the EUS plug-in for the Check Point SecuRemote Client resulting in the following End-user logon experience:

Click on the SecuRemote icon to launch the VPN Client

On computers with more than one EUS token, select the token to be used for authentication from the Token Name drop down. Enter secret security PIN to enable token.

SecuRemote connection will appear in the system tray.



3.4.3 CRYPTOPlug-in for Nortel Contivity Client

Installs the EUS plug-in for the Nortel Contivity Client resulting in the following End-user logon experience:

Click on the Contivity VPN icon to launch the VPN Client

On computers with more than one EUS token, select the token to be used for authentication for the Token Name drop down. Select the Contivity VPN Connection from the connection drop down.

Enter secret security PIN to enable token.

The Contivity connected icon will appear in the system tray.



3.5 JDBC Drivers

CRYPTOAdmin Server supports any JDBC compliant database system. The default database is MySQL. Drivers for MS-SQL and Oracle are provided for organizations that prefer these servers. Refer to Alternate Databases (MS-SQL, Oracle) for more information on configuring CRYPTOAdmin for MS-SQL and Oracle.

3.6 Tools

CRYPTOAdmin Server includes tools for troubleshooting and testing RADIUS connections and for migrating / importing external databases into MySQL. Refer to Chapter 12 Alternate Databases (MS-SQL, Oracle) for more information on Tools.

3.7 Hardware Components

Hardware OTP tokens are convenient, easy to use devices that are machine, operating system and application independent. Encryption keys and other information are generated by CRYPTOAdmin Server and inserted into the tokens using an Initializer unit. The RB-1 and KT-1 tokens use the RBI and KTI Initializers respectively. SC-1 smart cards are initialized through the USB or PCCard reader/writer.

SC-1-UB

Smart Card Token including USB Reader/Writer

SC-1-PB

Smart Card Token including PCCard Reader



RB-1

Hard Token shown with RBI Initializer

KT-1

Key Chain token shown with KTI Initializer



4. CRYPTOCard SPT Installation Prerequisites

4.1 CRYPTOAdmin Server Modules

Microsoft Windows Red Hat Linux Sun Solaris

CRYPTOAdmin Server with

EasyRADIUS Server Module

NTsp6, 2000, XPsp1

P3-350Mhz

128 MB RAM

200 MB Disk

150B/token

Linux 7.1 - 8.0

P3-350 MHz

128 MB RAM

300 MB Disk

150B/token

Xfree 86 using Gnome or KDE

Solaris 2.7, 2.8

Ultrasparc

128 MB RAM

300 MB Disk

150B/token

Xserver using CDE

CRYPTOAdmin Client (GUI)

98, NTsp6, 2000, XPsp1

P3-350Mhz

128 MB RAM

40 MB Disk

16 bit Color, SVGA

Linux 7.1 - 8.0

P3-350 MHz

128 MB RAM

40 MB Disk


SVGA

Solaris 2.7, 2.8

Ultrasparc

128 MB RAM

40 MB Disk

Xserver using CDE

4.2 Agents

Microsoft Windows Red Hat Linux Sun Solaris

CRYPTOWeb for IIS

IIS Server v.5 2 MB Disk

N/A N/A

CRYPTOLogon NTsp6, 2000, XPsp1 N/A N/A

CRYPTOAgent for Funk SBR

1 MB Disk N/A 1 MB Disk

CRYPTOAgent for MS-IAS

1 MB Disk N/A N/A



4.3 EUS Based Tokens

Apple Microsoft Windows Red Hat Linux* Sun Solaris*

Mac OS X (10.2) 25 MB Disk 64 MB RAM

16 bit Color, SVGA

95*, 98*, NT4sp6, 2000, XPsp1 25 MB Disk 64MB RAM

16 bit Color, SVGA

*SC-1 not supported on 95/98/NT4

Linux 7.1 - 8.0 P3-350 MHz 25 MB Disk 64MB RAM


*SC-1 not supported on this O/S

Solaris 2.7, 2.8 Ultrasparc 25 MB Disk 64MB RAM

Xserver using CDE *SC-1 not supported

on this O/S

4.4 Hardware Tokens

Token Type Requirement

RB-1 RBI Initializer installed on CRYPTOAdmin Client machine KT-1 KTI Initializer installed on CRYPTOAdmin Client machine



5. Licensing

CRYPTOAdmin 5.x Servers are licensed according to the Server operating system and the maximum number of tokens that may be registered in the server database. There are two types of licenses available for a CA5.x server: Full and Incremental.

Every server requires one Full license. A server may have multiple Incremental licenses.

5.1.1 What is a Full License?

The Full license is always the first license installed on a Server and is always in the format of F# - ####.lic. It defines the server characteristics, specifically:

• Full License Number

• Server Name

• Server Operating System

• Initial quantity and type of tokens purchased for installation on the server

5.1.2 What is an Incremental License?

Incremental licenses provide two separate functions: to define additional purchased tokens to be registered in the database against the maximum permitted in the Full license; to increase the maximum number of tokens permitted by the Full license. Incremental licenses are always in the format of I# - ####.lic

The Incremental license references the Full license and will only work if installed in the folder or directory that holds the referenced Full license.

5.1.3 When is a Full License required and how are Full licenses ordered?

A Full License is required for each NEW installation of CRYPTOAdmin Server. Every order for CRYPTOAdmin Server will automatically receive a Full License according to the size of the server purchased.

5.1.4 When is an Incremental license required?

Incremental licenses are required each time additional tokens are purchased for installation on a CRYPTOAdmin Server. Incremental licenses will be issued automatically and at no charge when an order for tokens references the Full license on which the tokens will be registered.



5.1.5 How are licenses delivered?

Both Full and Incremental licenses are emailed directly to the CRYPTOAdmin Server Administrator as specified in the purchase order.

5.1.6 License Installation

A valid license must be installed in the CRYPTOAdmin Server 'licenses' directory, which is located in:

• Windows: Program Files|CRYPTOCard|CRYPTOAdmin|Server directory

• Red Hat: /etc/cryptocard

• Solaris: /etc/cryptocard

5.1.7 Evaluation Licenses

CRYPTOAdmin Server distributions downloaded from the CRYPTOCard web site include an evaluation license valid for up to 60 days and support up to 5 of each CRYPTOCard token type. Remove the evaluation license and replace with a Full license to convert an evaluation system into a production system after removing all tokens from the evaluation system that are not included in the Full license.

Contact [email protected] for any evaluation or permanent licensing related questions or support.




6. Token Selection

CRYPTOCard offers 2 general types of tokens: software (ST-1/EUS software, SC-1/EUS Smart card) and hardware (RB-1 calculator, KT-1 key chain).

6.1 Software Token Overview

EUS Software tokens are “applications” that run on general purpose hardware such as a PC, PDA or Smart Card. The primary advantages of software tokens are: integration with VPN Clients, Browser authentication and other applications; electronics distribution, enrollment and revocation, low cost. When a one-time logon password is required, the user will activate the token by entering their secret PIN. Depending on the level of integration desired, the token will either display a password to be input by the End-user during logon or, ‘hand-off’ the one-time password directly to an authorized requestor (such as a VPN client via a CRYPTOCard Plug-in). Software tokens must be used on a specific machine. This can be advantageous for organizations that wish to prevent use of additional or unauthorized PC’s by an individual user.

6.2 Hardware Token Overview

Hardware tokens are small, stand-alone devices designed to be carried in a pocket, purse, wallet, necklace or computer bag and will generate a one-time password regardless of the network or computing environment. The primary advantage of hardware tokens is machine and O/S independence. The End-user logon experience is very similar to a static username/password logon with one critical difference; instead of supplying a static password when prompted, the user will respond with a one-time password provided by the token. Every time the user attempts to logon to the network, the token will provide a new, unpredictable password, valid only for the current logon attempt.

6.3 Ease of Use

CRYPTOCard tokens are easier to use and much more reliable that static passwords. There are several reasons for this:

• Token holders need only remember their PIN, they do not need to periodically change passwords or remember multiple passwords.

• Users will not be locked out of systems due to missed password change notices.

• Depending on the token type and level of integration, users may never see a password again. For example, smart card or software tokens can “hand-off” a new



and unique password directly with an authorized requestor (eg. VPN client) in much the same manner as a digital certificate, but only after the user provides their PIN.

• Calls to the help-desk due to locked accounts, lost / forgotten passwords and failed logon attempts are substantially reduced in most network implementations.

• CRYPTOCard tokens provide high usability and reliability, key components in gaining End-user acceptance.

6.3.1 Is a software token secure?

Yes! CRYPTOCard software tokens are comprised of 3 parts: a general purpose application (EUS), an initialization file (*.tok, *.sc) and a PIN. The application in itself is identical in every install. It performs the cryptographic functions required to generate a one-time password and provides the interface for entering the user PIN and when necessary, displaying a one-time password.

The initialization file is unique for each user and is generated by the CRYPTOAdmin Authentication Server against which the token will be used to authenticate. The initialization file contains the secret key as well as other customizable parameters used by the application during the encryption process to generate a one-time password. The initialization file is encrypted. This provides protection both during transport to the End-user machine and once installed.

As with hardware tokens, the PIN is used to protect a software token against unauthorized use. Generally a software token is issued with an initial PIN set by the administrator which must be changed by the End-user to a new PIN of a predetermined length and complexity before the token can generate a one-time password. This ensures that the PIN is known only to the End-user. If the number of incorrect PIN entry attempts exceeds the pre-set limit, (typically 3 attempts), the software token is disabled. Once disabled, the token cannot generate a one-time password until it is re-initialized through intervention by the system administrator.

6.3.2 Are hardware tokens more secure?

Hardware tokens derive their security advantage by being implemented on specially designed, tamperproof hardware and are independent of the computing environment. However, security is more than hardware, it also depends upon effective policies and procedures. Organizations should consider all aspects of token management, selecting the token type or types that will best meet security and operational requirements. Some considerations:

• The effort and complexity involved in physical delivery of the token to the End-user.



• Implementing a security policy and procedure to respond to users whose hardware tokens have been lost, forgotten or simply left at a client site.

• How long and at what cost does it take to get a replacement hardware token to an End-user.

• Does token integration with VPN clients provide a more usable, user-friendly experience.

• What potential risks are introduced by workarounds to the above.

Software tokens can generally simplify and minimize the impact on users and administrators. Combined with lower cost, easier, electronic deployment and near transparent integration, software tokens may offer a better overall solution for some or all of the End-user population.

6.3.3 Do software tokens offer true two-factor authentication?

Yes. The user must still have the token and must enter the correct PIN to generate a one-time password. In other words theft of the PC with the token is still not enough to gain access to the network. Note that the PIN is used to enable the token. It is not used to generate a password nor is it sent across the network. And unlike time based systems, CRYPTOCard software tokens will only display a single OTP when activated by the End-user’s security PIN.

6.3.4 But what if the computer is stolen?

PC/PDA theft is a reality. That is why the software token is encrypted, requires a PIN to activate and will erase itself from the PC/PDA if the maximum number of PIN attempts exceeds the permitted threshold. (Note: that hardware tokens are often stored in the computer bag with the laptop, therefore theft of the laptop usually includes theft of the token, just as it does with software tokens or digital certificates). This is in fact one of the benefits of 2-factor authentication: theft of one factor does not compromise the security of the solution.

As compared with digital certificates, software tokens offer better security protections: there is a maximum number of PIN attempts, the tokens are not easily copied from machine to machine and cannot be transported on a diskette.

6.3.5 Why is a PIN any better than a static password?

The PIN is known only to the token owner and is never sent across the network. In addition, the PIN only provides access to the token. Conversely, static passwords are sent across the



network, are easily captured or guessed and when used, provide access to networked resources. Due to this weakness, standard static password management requires periodic password changes resulting in user resistance, recycled passwords or passwords that are written down. As the PIN is not transmitted, it is not necessary to force a user to periodically change the PIN, resulting in higher user acceptance and less administration.

6.3.6 What are the advantages of a software token?

There are several, for both the administrator and the End-user.

• Deployment: Software tokens can be electronically deployed which makes them especially attractive to organizations with large and/or widely dispersed End-user populations. Through electronic deployment and secure ‘self-registration’, software tokens relieve administrators of one of the largest burdens and cost factors of hardware tokens, that of physical distribution.

• Integration: Software tokens can be integrated in End-user applications, making them all but transparent to the End-user. Consider the advantages of a typical scenario where the End-user:

1. Clicks on the dialer to connect to the internet

2. The dialer launches the VPN client on internet connection

3. The authorized requestor, in this case a VPN client launches the token which prompts for the PIN. On correct entry of the PIN, the token passes this sessions’ one-time password directly to the authorized requestor, insulating the user from the remainder of the logon process.

• Availability: Software tokens are always available. Users do not forget them at home or leave them on their desk or at a client site.

• Revocation: software tokens are easily revoked by system administrators. There is no need to recover the token from the End-user machine to revoke a software token. The token is simply deleted from the active tokens registered on the server.

• Re-deployment: Since software tokens use server-side licensing, revoked tokens become available to be re-issued to new users as often as required, at no additional cost. Re-issuing generates an entirely new and unique initialization file, including a new, unique encryption key, just as if the token was being issued for the first time. This makes software tokens ideal for use with term employees, contractors or external users and organizations where distribution and/or recovery of a hardware token might be difficult or unlikely.



6.3.7 Can tokens provide any other security functions?

Yes, depending on the type being employed. In addition to their normal authentication function, CRYPTOCard Smart Card tokens can be used for physical security and extended data security functions. For example:

• The SC-1 smart card production kit permits an organization to colour code and personalize the smart card to include photo ID, employee numbers and visual indications of security clearance level.

• Every SC-1 includes a mag stripe which can be programmed as required by the application / organization. Typical applications include personal data, door entry etc.

• The SC-1 can be ordered with the industry standard HID/Mifare proximity door access technology employed by the majority of perimeter/building access control systems.

• The SC-1 can be the repository / electronic wallet for Microsoft and Verisign certificates, providing a secure means of storing and transporting certificates. Coupling this function with the token authentication ensures that the user is authenticated before access to the certificate is granted.

• CRYPTOCard RB-1 hard tokens can also function as digital signature card where authenticating the data involved in a transaction is critical. This dual functionality not only ensures that “Bob is Bob”, but that this is also “Bob’s transaction data”.

6.4 EUS Software tokens:

The EUS itself is common to all supported token types and serves five key purposes:

• It presents a common user interface for all CRYPTOCard software tokens including the ST-1 software token and the SC-1 smart card token. In this function it provides a GUI to generate passwords, load tokens and perform specific management functions for one or more tokens installed on the End-user computer or smart card.

• It provides a common application level interface which allows all EUS-based tokens to be integrated with 3rd party applications such as VPN clients, producing an automated and near transparent End-user logon experience. In this role the End-user is typically prompted to input a secret security PIN to enable the token. Once enabled, the token will automatically pass both the user logon name and a single one-time password directly to the requesting application (e.g. VPN client). Without compromising on security the EUS insulates the user from the complexity of one-time password authentication and simplifies the End-user logon experience to:



• Click on the desktop icon to launch the VPN

• Enter the PIN when prompted

• Begin working

• The same functionality can be enabled for web servers and Microsoft Domain logon resulting in a common logon experience for the End-user for both internal and external access to the network. CRYPTOAdmin 5.32 includes various Plug-ins for 3rd party products such as Cisco, Check Point and Nortel VPN clients, Microsoft Domain Logon authentication and IIS, Apache and Sun One web servers.

• The EUS in combination with CRYPTOCard Domain Logon agents can be used to prevent unauthorized access to the local machine as well as the domain.

• The EUS can be integrated in custom or legacy applications using CRYPTOKit EUSapi Once integrated, the application will be compatible with any EUS based token.

6.4.1 ST-1/EUS Software Token

Advantages: Ideal for large distributed user populations, temporary or consulting staff where access to the End-user machine by administrators and/or cost and administrative overhead of hardware token distribution is a significant consideration. May be revoked and reissued without additional cost or access to the End-user machine. Supports multiple distribution methods including web based secure self-enrollment.

Dependencies: Machine dependant, specifically designed for End-users that access the network from one computer only.

Usage: One-time passwords, digital signatures for e-commerce applications.

Refer to the SC-1/EUS and ST-1/EUS Token Deployment Guide for a more detailed explanation of EUS based tokens.



EUS Interoperability

EUS Installation Environment * ST-1/EUS Software Token

Windows 95/98 ●

Windows NT ●

Windows 2000 (SP3 required for SC-1) ●

Windows XP SP1 ●

Red Hat Linux (7.1 – 8.0) with Gnome ●

Solaris (2.7, 2.8) with CDE or Gnome ●

Mac OS X (10.2) ●

EUS Plug-ins and Agents

Cisco VPN Client 3.6+ for Windows ●

Check Point VPN-1 Client for Windows ●

Nortel Contivity Client 4.65+ for Windows ●

Microsoft IIS v5.0 ●

Apache ●

Sun One ●

Microsoft Domain Logon ●

* Contact CRYPTOCard technical support for a list of environments, plug-ins and agents released after document publication

6.4.2 SC-1/EUS Smart Card Token

Advantages: Ideal for large distributed user populations. Combines the advantages of hardware tokens with software token deployment. Smart Cards support electronic distribution and self enrollment of token.

Includes either a USB or PCCard reader/writer.

Dependencies: Requires EUS and Smart Card reader where ever token will be used.

Usage: One-time passwords, digital signatures, digital certificates, multiple tokens, photo ID, magnetic strip / contactless (HID) perimeter door access, 3rd party application support.



Refer to the SC-1/EUS and ST-1/EUS Token Deployment Guide for a more detailed explanation of EUS based tokens.

EUS Interoperability

EUS Installation Environment * SC-1/EUS

Smart Card Token

Windows 2000 sp3 ●

Windows XP SP1 ●

Red Hat Linux (7.1 – 8.0) with Gnome

Solaris (2.7, 2.8) with CDE or Gnome

Mac OS X (10.2) ●

USB Reader/writer included (SC-1U) ●

PCCard Reader/writer included (SC-1P) ●

EUS Plug-ins and Agents

Cisco VPN Client 3.6+ for Windows ●

Check Point VPN-1 Client for Windows ●

Nortel Contivity Client 4.65+ for Windows ●

Microsoft IIS v5.0 ●

Apache ●

Sun One ●

Microsoft Domain Logon ●

* Contact CRYPTOCard technical support for a list of environments, plug-ins and agents released after document publication



6.5 Hardware Tokens:

6.5.1 RB-1 Hard Token

Advantages: Machine and network independent. Ideal for system administrators or consultants which must logon to a network from more than one machine or location or where installation of software on the End-user machine is impractical or not permitted. Deploy-once token technology eliminates the need to periodically recover and re-deploy tokens. Tokens include a 5 year warranty and dual, End-user replaceable batteries. Typical battery lifespan is 5 years before battery replacement is required. Durable metal case.

Usage: One-time passwords, Digital Signatures

Dependencies: Programmable using RB-Init token Initializer

6.5.2 KT-1 Key Chain Token

Advantages: Machine and network independent. Ideal for system administrators or consultants which must logon to a network from more than one machine or location or where installation of software on the End-user machine is impractical or not permitted. Deploy-once token technology eliminates the need to periodically recover and re-deploy tokens. Tokens include a 5 year warranty and dual, End-user replaceable batteries. Typical battery lifespan is 5 years before battery replacement is required. Durable metal case.

Usage: One-time passwords

Dependencies: Programmable using KT-Init token Initializer.



7. CRYPTOAdmin Server Installation

This section applies to new installations of CRYPTOAdmin Server using the default MySQL database and assumes a license supporting all required token types is available for installation. EUS tokens are referenced throughout this section for testing purposes though any token type can be used that is supported by the installed license. EUS tokens provide an effective means of testing end-to-end authentication including VPN, Web server and LAN authentication agents and are included in the CRYPTOAdmin Server evaluation distribution.

The CRYPTOAdmin Server installer can install the following modules and agents:

Module Windows Linux Solaris

CRYPTOAdmin Server

MySQL recommended recommended recommended

CRYPTOAdmin Client recommended recommended

easyRADIUS optional optional

Funk SBR Agent optional n/a optional

Contact [email protected] for instructions on upgrading from previous versions of CRYPTOAdmin Server.

CRYPTOAdmin Client must be installed to manage the CRYPTOAdmin Server and by default will be installed on the CRYPTOAdmin Server during installation. A separate Client-only installer can be used to install a remote Client.

easyRADIUS server must be installed if:

• a CRYPTOCard supported RADIUS server is not installed

• CiscoSecure ACS 3.0+ is installed and is the preferred RADIUS server

easyRADIUS Server module should not be installed if:

• Funk Steel Belted RADIUS is installed and is the preferred RADIUS server

• Cisco Secure ACS 2.6 is installed and is the preferred RADIUS server

• Microsoft IAS is installed and is the preferred RADIUS Server

• RADIUS is not required.

All new CRYPTOAdmin Server installations should begin on a server with a newly installed operating system. A CRYPTOAdmin 5.32 Server License is required before proceeding with




installation. Refer to Chapter 15, Alternate RADIUS Servers for 3rd party RADIUS implementation and integration instructions.

7.1 Installation Sequence

1. Install CRYPTOAdmin Server and Client (and easyRADIUS server if required)

2. Configure CRYPTOAdmin Server

3. Install and configure a remote CRYPTOAdmin Client (optional)

4. Configure and test easyRADIUS Server (optional)

5. Install CRYPTOCard EUS token on test “End-user” platform (refer to SC-1/EUS and ST-1/EUS Software Token Deployment Guide)

6. Test authentication using EUS token

7. Install and test CRYPTOAdmin Server replica

8. Configure CRYPTOAdmin Server for additional CRYPTOAdmin Clients and/or operators as required

9. Configure operator permissions according to roles.

10. Set up a Back-up Server

11. Install and test VPN Plug-in (refer to appropriate VPN Plug-in Guide)

12. Install and test CRYPTOWeb for IIS, NFuse and OWA (refer to CRYPTOWeb for IIS Deployment Guide)

13. Install and test CRYPTOLogon for LAN/Domain authentication (refer to CRYPTOLogon Deployment Guide)



7.2 CRYPTOAdmin Server Installation

7.2.1 Step 1. CRYPTOAdmin Server for Windows Installation and Configuration

The default CRYPTOAdmin Server installer for Windows will install CRYPTOAdmin Server, CRYPTOAdmin Client and MySQL database server.

Server Installation:

Run CRYPTOAdmin Server installer for Windows

setup-ca532.exe

Select easyRADIUS module installation if required.



At the “install MySQL” prompt accept all defaults. Set root password to desired value when prompted. “Launch the MySQL installation program now”.

CRYPTOAdmin Server Configuration utility will launch automatically with a prompt to change the CRYPTOAdmin Server Administrator password.

Enter <New CRYPTOAdmin Administrator Password>

Re-enter <New CRYPTOAdmin Administrator Password> to confirm

Install a valid license in the CRYPTOAdmin Server 'licenses' directory, which is located Program Files|CRYPTOCard|CRYPTOAdmin|Server directory

Start MySQL, CRYPTOAdmin Server (and easyRADIUS if installed) from Windows Services.

Go to Section 7.3 Step 2 – Server Configuration

7.2.2 Step 1. CRYPTOAdmin Server for Linux Installation and Configuration

The default installer for Linux does not include the MySQL database system.

Server Installation:

• Install MySQL from the Red Hat distribution or download from http://www.mysql.com

Change the password for the Root account on MySQL.

/usr/bin/mysqladmin -u root -p password <new-password>

MySQL must be running before proceeding with the CRYPTOAdmin Server installation. The CRYPTOAdmin Server installer defaults include the installation of CRYPTOAdmin Server, CRYPTOAdmin Client and easyRADIUS.

1. Unzip: gunzip CRYPTOAdmin_for_Red Hat_pack.tar.gz

2. Untar: tar -xvf CRYPTOAdmin_for_Red Hat._pack.tar

3. Install CRYPTOAdmin: rpm -i cadmin-5.32-xxx.i386.rpm where xxx is the

CRYPTOAdmin build number/name of rpm

4. CDConfig will launch automatically with a prompt to change the CRYPTOAdmin Server Administrator password. For new installation the default password is <cryptoadmin>

5. Enter: <New CRYPTOAdmin Administrator Password>


http://www.mysql.com/


6. If installation has been done using console-only mode, an message will be returned with instructions to run CDconfig & mysqlinit.sh manually. /etc/mysqlinit.sh can be run at anytime to initialize the CRYPTOCard token database and permissions in MySQL.

7. mysqlinit.sh will launch with a prompt to enter the MySQL database root account password. Enter <new password> from step 2.

8. Check /etc/cryptocard/mysqlinit.log. There should be no errors.

9. Install a valid license in the CRYPTOAdmin Server 'licenses' directory, which is located /etc/cryptocard/licenses

10. Start the CRYPTOAdmin Server (and easyRADIUS server if installed)

11. /etc/init.d/cadmind start

[/etc/init.d/radiusd start]




7.2.3 Step 1. CRYPTOAdmin Server for Solaris Installation and Configuration

The installer for Solaris does not include the MySQL database system. Server Installation:

1. Install MySQL 3.23. This can be downloaded from http://www.mysql.com

2. Change the password for the Root account on MySQL.

/usr/bin/mysqladmin -u root -p password <new-password>

3. MySQL must be running before proceeding with the CRYPTOAdmin Server installation.

4. The CRYPTOAdmin Server installer defaults include the installation of CRYPTOAdmin Server, CRYPTOAdmin Client, easyRADIUS and the Funk Steel Belted RADIUS Plug-in.

Untar: tar -xvf CRYPTOAdmin_for_Solaris.tar

5. Install CRYPTOAdmin pkgadd -d cadmin-5.32-xxx-sol-sparc where “xxx” is

the build number.

6. Select the packages you wish to install. The following packages are available:

o Cccadmind: installs the CRYPTOAdmin Server component

o Ccclients: installs the CRYPTOAdmin Client (management console) component

o Cccommon: installs the CRYPTOAdmin common files. This component must be installed.

o Ccfunk: installs the Funk Steel Belted RADIUS Plug-in. Only required where Funk SBR will be used.

o Ccradius: installs the CRYPTOCard easyRADIUS Server component.

7. After installing the desired packages, run CDconfig (found under /usr/sbin) to set the Administrator password for the CRYPTOAdmin Server. The default password is “cryptoadmin”.

If desired you may now also configure remote CRYPTOAdmin Clients and set up additional operators. Do so now or at any time by running CDconfig. See section 7.3 for details on Server Configuration.


http://www.mysql.com/


8. Edit the cryptocard.cfg (found under /etc/cryptocard). You must uncomment the [JDBC-Setup] heading and the appropriate JDBC / Database control block. Refer to the README file under /etc/cryptocard for more details. This section may require additional customization, depending on the database selected for the CRYPTOAdmin Server.

9. If using MySQL as the CRYPTOAdmin Server database, run the mysqlinit.sh script from /etc/cryptocard to create the token database and table structure. If you have set a MySQL root password you may be prompted to enter it at this point.

10. Check /etc/cryptocard/mysqlinit.log. There should be no errors.

11. Install a valid license in the CRYPTOAdmin Server 'licenses' directory, which is located /etc/cryptocard/licenses

12. Start the CRYPTOAdmin Server (and easyRADIUS server if installed)

13. /etc/init.d/cadmind start

[/etc/init.d/radiusd start]


7.3 Step 2 – Server Configuration

The default CRYPTOAdmin Server installation also installed a Client on the CRYPTOAdmin Server with the following parameters:

• IP Address: 127.0.0.1

• Packet Encryption Key: 1234567890abcdef

• Administrator Logon ID: Admin

• Administrator Password: <New CRYPTOAdmin Administrator Password>

No further Server or Client configuration is required to begin using this Client to manage the Server and issue tokens. Skip to Step 4 if no additional Clients or Operators are required.

The remainder of this section provides instructions for the registration of remote Clients and/or additional Operators. Skip to Step 4 if no additional Clients or Operators are required.

7.3.1 Configure additional Operators



Additional CRYPTOAdmin Clients and Operators must be defined in CRYPTOAdmin Server before a Client connection to the server can be established. This step ensures that only valid Clients and Operators have access to the server.

Windows, Linux and Solaris distributions include a separate Windows Client installer (setup-ca-client532.exe). Run this installer on the remote machine to create a remote Client.

7.3.2 Overview:

Configuring the Server for a remote Client begins with defining the CRYPTOAdmin Server-Client communication parameters. At the networking level, the IP address of each Client as well as an encryption key to protect the privacy and integrity of the data being transmitted between the Client-Sever must be registered in the CRYPTOAdmin Server.

The second step is to define Operators, the required Operator logon authentication method and the Operator access mode. CRYPTOAdmin Server can require an Operator to use either a static password or a CRYPTOCard token to logon to the Client and establish a connection with the server. If a token is required, the Administrator must first create and issue the token to the Operator before the Operator can logon at the Client. “Operator access mode” setting determines whether or not the Operator can modify the Server database. “Configurable Mode” is required for Operators that must add/delete/modify/initialize or test tokens. “Read-only Mode” is for Operators with audit functions only.

The permissions granted by Configurable Mode are further defined and/or restricted during installation and configuration of the Client. The following chart describes the primary differences between an “Admin” Administrator, “Configurable” Operator and a “Read-Only” Operator



Administrator • Owns and maintains CRYPTOAdmin Server

• Creates and remove Operators.

• Define and grant Operator roles and permissions

• Sets default token profiles

• Views, adds, updates, initializes and deletes tokens on the Server

• Creates and remove groups.

Configurable Operator

• Create and manage groups/tokens in the database

• View, add, update, initialize and delete tokens according to permissions

• Create sub-groups

Read-only Operator

• May only view token profiles.

7.3.3 Required information before proceeding:

• Client IP address <192.168.10.40>

• The Logon ID for each Client Operator to be configured on the system. <OperatorName>

• The Operator logon password (not required if Operators must use a CRYPTOCard token to logon at the Client.) [OperatorPassword]

7.3.4 Launch CRYPTOAdmin Server Configuration utility

Windows: Start|Programs|CRYPTOCard|CRYPTOAdmin 5.32|CRYPTOAdmin

Server Configuration

Linux: Solaris and Red Hat administrators must be logged in as ‘root'.

Launch the application CDconfig from the ‘root' account.

Solaris: Solaris and Red Hat administrators must be logged in as ‘root'.

Launch the application CDconfig from the ‘root' account.

Enter <New CRYPTOAdmin Administrator Password>



7.3.5 Register Clients

Select Option 1 = Set up client IP address and packet encryption key <192.168.10.40>

Record IP address and packet encryption key for subsequent use during installation of Client.

Repeat process for each Client as required.

7.3.6 Register Operators

Select Option 2 = Set up operator information <Operator>

Create “Operator” and select access mode and authentication method.



7.4 Step 3. CRYPTOAdmin Client Installation and Configuration

Windows, Linux and Solaris distributions include a separate Windows installer for a Remote Client. Run this installer (setup-ca-client532.exe) at the remote machine if a Remote Client is required (192.168.10.40) otherwise skip to 7.5 Step 4 – Launch CRYPTOAdmin Client.

7.5 Step 4 – Launch CRYPTOAdmin Client

This section is specific to the Client Graphical User Interface (GUI). Refer to Chapter 14, Client Command Line Interface (CLI) for Command Line Client specific instructions.

Windows: Start|Programs|CRYPTOCard|CRYPTOAdmin 5.32|CRYPTOAdmin Client

Linux &

Solaris

Run CAClient. If you are not logged in as “superuser”, run CAClient from a shell prompt the first time this application is run to create a Client icon on the desktop.



Click on the toolbar to start Operator Logon to Server. Enter <New CRYPTOAdmin Administrator Password> and click “Connect” on the CRYPTOAdmin Connect dialogue.



8. CRYPTOAdmin Client GUI Management Console

This section details the functionality of CRYPTOAdmin GUI Client.

8.1 Detailed Description

The CRYPTOAdmin 5.32 Client interface consists of four main sections: Toolbar; Group Tree; Token List; Preview Pane.



8.2 Toolbar

The Toolbar across the top of the program’s main window contains buttons to access the most frequently used program functions. The Operator can customize the toolbar by choosing between Large Icons With Text and Small Icons Without Text.

The toolbar contains seven buttons that perform the following functions:

Click to start Operator Logon to Server. For details see Section 8.9 Connecting and Disconnecting Servers.

Click to Disconnect from the selected server. For details see Section 8.9 Connecting and Disconnecting Servers

Click to access New Token dialog box. For details see Creating and Deleting tokens

Click to access Edit Token Info dialog box. For details see Edit Token Info dialog box; Modifying Token properties

Click to access the Find Tokens dialog box. For details see Find tokens

Click to access the Add Group dialog box; For details see Groups

Initialize Token: Click to initialize the selected token. For details see Initializing tokens



8.3 Group Tree

The Group Tree is used to display the CRYPTOAdmin Server(s) the Operator is currently connected to, in a hierarchal-tree. The intention of the Group Tree is to provide the Operator with a friendly and familiar tree structure similar to the representation of file folders in the Windows Explorer. To easily copy or move Tokens between Groups, the Operator can drag a token from the Token List and drop it on to the Group folder. See Creating, Modifying, and Deleting groups.

The root node of the Group Tree is labeled “Servers”. Branched off the root are child nodes that represent the connected servers labeled with the server name (e.g., “localhost” or “127.0.0.1”). Branched off the server nodes are nodes representing the groups on that server. Groups can contain other child groups, and all groups are represented by a yellow folder icon to closely resemble the familiar folder hierarchy of Windows Explorer.

The Operator can right-click on a Group node in the Group Tree to access a pop-up menu. The pop-up menu provides easy access to common Group functions. For more information about Groups, see Groups.

8.4 Token List

The Token List is used to display the Tokens, which exist in the currently selected Group. The Token List consists of a header, which provides two resizable columns (“Name” and “Description”). The Token Name, and description of the Token type are displayed in the main portion of the token list.

The list allows users to select multiple tokens using the standard Windows CTRL and SHIFT multi-select conventions. Tokens can be copied or moved among Groups and Servers or dragged-and-dropped onto Group nodes in the Group Tree. For more information about Groups and the Group Tree see Groups and Client Group Tree, respectively.

Double-clicking on a Token in the Token list activates the Edit Token Info dialog box. For details about editing token information, see Edit Token Info dialog box; Modifying Token

properties.

Right clicking on a Token in the Token list accesses a pop-up menu. The pop-up menu provides easy access to common Group functions. For more information on Tokens, see Tokens.



8.5 Preview Pane

The Preview Pane is used to display the information about the selected Token in the Token List. The Preview Pane consists of three tabs (Display, PIN, and Synchronization) which display the Token information that relates to that particular aspect of a Token. For details about the contents of all three tabs, and information on editing token information, see Edit

Token Info dialog box; Modifying Token properties.

The preview pane is read-only. Below the tabs, there is a button labeled “Edit Token” which gives the Operator access to the Edit Token Info dialog box.

8.6 Options dialog box

The Options dialog box consists of two tabs: Initialization and PIN Options. To access the Options dialog box, click Server|Options on the main menu.

The OK button saves all options and closes the dialog box. The Cancel button closes the dialog box without saving.

8.7 Initialization tab

On the Initialization tab, the Operator specifies the options for initializing tokens from this Client. RB-1 and KT-1 tokens require a RBI and KTI token Initializer respectively to initialize tokens.

By default SC-1/EUS smart card and ST-1/EUS software token initialization files are output to the CRYPTOAdmin\Client\tokens\ directory on the Client.

If the directory specified as the output path does not exist when OK is clicked the Operator is informed and asked the specified directory should be created.

If selected the Log PINs option will output initialized token names and related initial deployment PIN to a text file in the default \tokens\ directory.



8.8 PIN Options tab

The PIN Options tab features two check box options:

Alphanumeric random PINs –When selected, random PINs generated for software-based tokens during initialization (ST-1/EUS, SC-1/EUS) will include alphabetic characters as well as digits; when not selected all random PINs will contain only digits.

Length of PIN is 8 – When selected, random PINs generated for software-based tokens (ST-1/EUS, SC-1/EUS) will have a length of eight; when not selected random PINs will have a length equal to the length specified in “Default Token Profiles”

Both of these options are selected by default.

8.9 Connecting and Disconnecting Servers

To connect to a CRYPTOAdmin Server, access the Connect dialog box by clicking the Connect button on the Toolbar, or click Server|Connect on the main menu. Since the Operator can establish multiple simultaneous connections to different servers, the Connect options are always enabled. Servers and Operators are available through the dropdown boxes.

To successfully establish a connection, the Operator is required to enter a valid Operator name, IP Address or server name, and Password. At first use, the defaults are “admin” and “127.0.0.1”. When a new connection is established, the Operator and Server get added to the respective drop-down lists, and these values become the defaults for the next use of the dialog box.

Clicking the Edit button in the Connect dialog accesses the Edit Server Configuration dialog box allowing client-side configuration of the server connection.



The fields in the Edit Server Configuration dialog box are:

Key: Accepts 16-character Packet Encryption Key used to encrypt the Client-Server network communication. It must match the corresponding key on the server for this IP address.

Port: The port number through which the network communication occurs. Default 624. Accepts any valid integer value.

Timeout: Amount of time (in seconds) to wait before assuming a failed connection. Default 60. Accepts any integer value from 1 to 999.

Operators that are required to use a token to logon to the CRYPTOAdmin Server will be prompted with a challenge and will be required to enter the correct token-generated response.

To disconnect from a CRYPTOAdmin Server, select the server in the Group Tree, and click the Disconnect button on the Toolbar or click Server|Disconnect on the main menu. The Operator will be prompted to confirm the disconnect.

8.10 Groups

8.10.1 Creating, Modifying, and Deleting groups

Tokens can be organized by Groups. CRYPTOAdmin Server can return a Group attribute to a RADIUS server or Agent which will apply corresponding access rights to End-users in the Group. Operators can be permitted or restricted access to a Group.

To access the Add Group dialog box, right-click the node in the Group Tree and select New|Group from the pop-up menu or select a group node or a server node in the Group Tree, and then click Edit|New|Group on the main menu or click the New Group button on the toolbar.



The fields in the Add Group dialog box are:

Name: The name being assigned to this group. Group names are limited to a 20 character length; this includes the names of all parent and child groups and includes a $ for each name separator. (e.g., “Canada$Ontario” represents a subgroup name Ontario nested in group Canada; the length of the group name is 14.) Valid characters include: a..z, A..Z, 0..9.

Description: A description for the group. Length is limited to 64 characters.

Parent: Read-only, indicates the name of the parent group.

To delete a group, right-click the node in the Group Tree and select Delete Group from the pop-up menu or select a group node in the Group Tree, and then click Edit|Delete|Group on the main menu, press Delete on the keyboard.

To delete a group, it must be empty of tokens and child groups. The Operator will be informed if the group is not empty.

8.10.2 Access to groups, Read Only groups, and Group Permissions

The Administrator has full access to all groups and tokens. The Administrator has the ability to restrict an Operator’s access to specific groups.

Read-only groups will appear in the Group Tree in red-text. Token properties can be set to read-only or no-access, and will be displayed in the Preview Pane and Token Info dialog boxes in disabled or empty text fields.

For more information on setting up Operator Permissions, see Access to groups, Read Only

groups, and Group Permissions.

8.11 Tokens

CRYPTOAdmin 5.32 supports the following Tokens:

Type Description Serial Numbers beginning with

ST-1 Software token 7xxxxxxxx

KT-1 Key Chain token 30xxxxxxx, 31xxxxxxx

RB-1 Hard token 4xxxxxxxx, 20xxxxxxx

SC-1 Smart Card token 90xxxxxxx



8.12 Creating and Deleting tokens

To access the Add Token dialog box, select a group node or a server node in the Group Tree, and then click the New Token button on the toolbar, or right-click the node in the Group Tree and select New|Token from the pop-up menu or click Edit|New|Token on the main menu.

The fields in the Add Token dialog box are as follows:

Token type: Operator selects the desired token type from the read-only drop-down list.

Name: The name of the token must be unique from all other tokens in the database. Maximum length is 64 characters, valid characters include a..z, A..Z, 0..9, @, period “.”, space “ “

Serial number: 9-digit number helpful in establishing token identity. The first two digits are used to identify token type. The remaining digits are unused by the system but are useful for inventory control.

Valid range: Indicates the valid serial number range for the token type selected in the Token Type field.

Group: Read only field, indicates the selected group where the token will be added.

A token is created with the corresponding Default Token Profile for the specified Token Type. For information on accessing and modifying the Default Token Profiles, see Default

Token Profiles.

Clicking OK adds the token, clicking Cancel closes the dialog box without creating the token. The information in each field is checked for validity and the Operator is warned in the case of invalid information.

Token creation will fail if one of more of the following conditions exists:

• The specific token is not supported by the installed Server License

• The maximum number of tokens permitted by the license is exceeded



• The maximum number of this token type permitted by the license is exceeded.

8.13 Initializing tokens

To initialize a token, select the token in the Token List, click Initialize button on the toolbar, right-click on the token in the Token List and select Initialize Token from the pop-up or menu click the Edit|Initialize Token.

Initialization Options are set using the Initialization tab in the Options dialog box, see Initialization tab”.

The Operator is prompted for instructions specific to the token type being initialized:

ST-1, SC-1: The Operator is informed of the name, location of initialization file, initial deployment PIN.

KT-1: The Operator is prompted with instructions for preparing the token and inserting it into the KTI Initializer hardware attached to the Client.

RB-1: The Operator is prompted with instructions for preparing the token and inserting it into the RBI Initializer hardware attached to the Client.

8.14 Rename Token

The Rename token function can be used to modify the token name. Most often this is used if the End-user logon name changes or the token is assigned to a new End-user without re-initialization. To access the Rename token function right-click on the highlighted token and select Rename token from the drop down box, or select Edit|Rename token from the main menu.

8.15 Test tokens

The Test token function is used to confirm the correct function of the token. This function can be used prior to and after token deployment. Right-click the token in the Token List and click Test Token in the pop-up menu List or click Edit|Test Token on the main menu.

The fields in the Test Token dialog box are as follows:



Token: read-only field displaying token name.

Response Mode: read-only field displaying the token’s Response Mode (QuickLog or Challenge-Response).

Next Challenge: read-only field displaying the challenge which the token must respond to.

Response: the Operator enters the response produced by the token.

After entering a response, clicking OK performs the test and the user is informed of success or failure. Cancel closes the dialog box.

This function can be used by the Help Desk to confirm correct function of a token without compromising security as only the user name, challenge and response are transmitted resulting in either a pass or fail.

8.16 Edit Token Info dialog box; Modifying Token properties

To modify token properties, access the Edit Token Info dialog box.

To access the Edit Token Info dialog box, select a Token in the Token List, and then click the Edit Token Info button on the toolbar, double click on the Token in the Token List, right-click the token in the Token List and select Edit Token Info from the pop-up menu or select Edit|Edit Token Info from the main menu.

The Edit Token Info dialog box consists of three tabs: Display, PIN, and Synchronization. Available properties vary depending on the token type.

8.16.1 Display Tab

The Display tab contains all properties relating to what is displayed on the token.

Token type: A description of the token type (read-only).

Date initialized: Indicates the date the token was last initialized (read-only).

Serial number: Indicates the token’s serial number (read-only)

Display Type: Non-editable drop-down list; determines the characters to be used in displaying the tokens



challenges and responses. (Decimal uses only decimal characters 0..9; Hexadecimal also includes valid hex characters 0..9, a..f, A..F).

Telephone display: Checkbox; determines if the token’s response will be presented in a “telephone” format. I.e., if the fourth character of the response is blocked out by a dash “-“ to produce a standard “555-1212”-style result.

Language: Non-editable drop-down list; determines the language used to present information and instructions on the token. Options vary for different token types.

Automatic shut-off: Non-editable drop-down list; determines the length of time of inactivity after which the token will automatically turn itself off.

Token ID: Text field; String that is displayed on the token. Limit 8 chars; valid characters include a..z, A..Z, 0..9, period “.”, space “ “.

Display Token ID: Checkbox; determines if the Token ID is displayed by the token during use.

8.16.2 PIN tab

The PIN tab contains all properties relating to the token’s PIN.

PIN Type: Non-editable drop-down list; determines the PIN type. (I.e., No PIN, User-changeable, Fixed, with Feedback). When set to No PIN, the other properties are not visible.

Min PIN Length: For user-changeable PINs, indicates the minimum PIN length when the user attempts to change his PIN.

PIN: The tokens’ PIN when it is first initialized; this field is not restricted by the Min PIN Length. Valid characters are 0..9; tokens that support alpha-numeric PINs also use valid characters a..z, A..Z.

Make Random PIN: Button generates a Random PIN in the Initial PIN field as specified by Min PIN Length (for ST-1 and SC-1 tokens the random PIN generated is 8-characters in length). Alpha-numeric PINs will be included for tokens that support this feature. Some characters are not included in the randomly generated PIN because they are too similar visually and may cause



confusion among users; these characters are: “Il1ijoO0” (upper-I, lower-L, digit-1, lower-I, lower-J, lower-O, upper-O, digit-0)

Try attempts: Non-editable drop-down list; determines the number of consecutive times the End-user can fail to enter the PIN correctly before the token enters a Locked state.

8.16.3 Synchronization tab

The Synchronization tab contains all properties relating to the tokens’ challenge/response sequence.

Next Challenge: Read-only text field; indicates the next challenge that will be issued to the token.

Set Next Challenge: Allows the Administrator to specify the tokens’ next challenge.

Response mode: Non-editable drop-down list; response mode determines whether the token will automatically provide a OTP (QUICKLog) or require its user to enter a challenge in order to generate a response.

Multiple responses per power cycle: Checkbox; determines if the user can obtain more than one OTP from the token without having to turn the token off and re-enter the PIN. This option is not available on all tokens.

Display challenge: Checkbox; determines if the challenge will be displayed on the token. This option is not available on all tokens.

8.17 What is QUICKLog Authentication

QUICKLog is the most popular form of strong user authentication. It improves on the challenge/response method by permitting strong user authentication without requiring the user to key a challenge into the token before a password is generated.

8.18 Why is QUICKLog better?

QUICKLog solves two key network security issues: it makes the logon process faster, easier and more reliable for end users, a key component in gaining user acceptance; it works with



all RADIUS or TACACS+ compliant products including all VPN, Firewall and NAS products from leading vendors such as Cisco, Check Point and Nortel. This includes all RADIUS or TACAS+ compliant products that do not currently support full challenge/response.

8.19 Default Token Profiles

The Default Token Profile is the set of properties that will be assigned to a token when it is first created. There is a unique Default Token Profile for each token type.

The Default Token Profile dialog box for the specific token type is accessible by selecting Server|Default Token Profiles and then selecting the desired token type.

Default Token Profile information is stored on the client side and is therefore workstation specific (not Operator specific). That is, given a specific CRYPTOAdmin 5.32 Client installation, any Operator who connects to any remote server from this location will receive (and be able to modify) the same set of Default Token Profiles.

The Default Token Profile dialog box is virtually identical to the Edit Token Info dialog in design and layout. Notable differences are as follows:

Set Next Challenge button is disabled

Serial Number, Next Challenge, and Date Initialized fields show generic information

On the PIN tab:

Initial PIN field accepts “<RANDOM>” which indicates new tokens will be created with a random PIN

Make Random PIN button places the text “<RANDOM>” in the Initial PIN field

8.20 Find tokens

The Find Tokens dialog box allows the Operator to perform a search of a single server for all tokens matching specified criteria. Both the Token Name and Serial Number fields support standard “wildcard” searching; e.g., Token Name “*a” will return all tokens whose names that contains “A”. This can be combined with Serial Number field



to further filter search results.

Double-clicking a token in the results list opens the Edit Token Info dialog box, just as if the Operator has double-click on a token in the Token List in the main program window.

8.21 Dragging/Dropping & Copying/Moving tokens

Tokens can be cut and pasted (or copied and pasted) between groups.

Tokens can be dragged from the Token List and dropped into a group on the Group Tree. By default, this action will move the tokens; if the user holds down the control keyboard-button when dropping the tokens the action indicates copying the tokens.

Tokens cannot be copied onto the same server. If the Operator attempts to copy/paste tokens into a group on the same server, he is notified and asked if he would like to move the tokens.

To cut/copy tokens, select the tokens in the Token List, right-click on the Token List and select Cut or Copy Tokens from the pop-up menu, select Edit|Cut Tokens or Edit|Copy Tokens from the main menu or use keyboard short cuts Ctrl-X / Shift-Del and Ctrl-C / Ctrl-Insert.

To paste tokens, select the destination group node in the Group Tree and then select Edit|Paste Tokens from the main menu, or right-click on the node in the Group Tree and select Paste Tokens from the pop-up menu, or use keyboard short-cut Ctrl-V/ Shift-Insert.

8.22 Modifying Operator Permissions

The Administrator has the ability to restrict Operators’ abilities to access/modify specific token properties. This is done through the Operator Permissions dialog box.

To access the Operator Permissions dialog box, select Edit|Operator Permissions from the main menu. The Administrator is prompted to enter the name of the Operator for which permissions are to be set.



The Operator Permissions dialog box contains a Group Tree (similar to the one on the main form) that displays all of the groups on the selected server in a hierarchal format, and a Group permissions box that provides the controls for modifying the specified Operator’s permissions for the group that is selected in the tree.

8.22.1 Group tree

Selecting a group in the Group Tree displays the permissions the specified Operator has been assigned in that group in the permissions panel. If the Operator has not been assigned permissions to the selected group, the permission information indicates No Access for every field.

8.22.2 Group permissions box

Shows all of the permissions the Operator has within the selected group; the permissions are arranged in the same tab-sequence as the tabs in the Edit Token Information dialog box.



The Create/Delete Tokens permission determines if the Operator has permission to create and delete tokens on the server regardless of the settings of the other permission. That is, the Create/Delete Tokens permission overrides the access granted by all other permissions. Create/Delete Tokens can be set to No Access or Full Access.

The Group Access permission can be set to Read Only, No Access, or Full Access and overrides all individual permissions to token properties.

The individual token properties are accessed using the Display, PIN, and Synchronization tabs. All token properties can be set to No Access, Read Only, or Full Access. The arrangement of the tabs mimics the tabs on the Edit Token Info dialog box.

The All No Access, All Read Only, and All Full Access buttons set all permissions to the respective settings where applicable.

The Apply Changes button saves any changes to the server.



9. Initializing Tokens

CRYPTOCard hardware tokens are not factory pre-programmed with OTP keys. This ensurs that only the issuing organization owns the encryption keys used to generate OTPs. Initialization is the process that programs the tokens, making them unique for each user and for the organization.

The token initialization process begins when the Operator selects “Initialize” token. The Server generates a unique encryption key for the token and transfers this along with the token options to the Client in one of two ways:

• For hardware tokens it passes the encrypted data through the Client directly to the attached KTI or RBI Initializer. The Operator inserts the token into the Initializer when prompted. The initialization completes in approximately 5 seconds. Initializers can be installed on one or more Clients.

• For software tokens, it stores the encrypted initialization file to the directory defined on the Client under Server|Options. (TokenName.tok for ST-1, TokenName.sc for SC-1). The initialization file can then be transferred to the end user machine for application on the EUS token software. Note that the initialization file’s deployment PIN is required to allow application on the EUS. Refer to the SC-1/EUS and ST-1/EUS Deployment Guide for detailed instructions.

9.1 Hardware Token Initializers

Each hardware token type has it’s own specific Initializer:

• RB-1 tokens are initialized using an RBI Initializer.

• KT-1 tokens are initialized using a KTI Initializer.

Tokens can be re-initialized as required. Re-initialization can be used to insert new keys or change token operating parameters.



9.2 Initializer Requirements

Initializer’s must be installed on Windows based CRYPTOAdmin Clients.

The CRYPTOCard Initializer is equipped with a worldwide universal input voltage power supply. The universal input on this supply means that it can be directly connected to the mains power virtually anywhere in the world. It does not require any adjustments. It senses the mains voltage and automatically configures itself. A power cord has been included with the supply which should be compatible with the mains outlets in your country. If the mains plug on this cord does not suit your mains connection, however, you may do one of the following:

• Replace the power cord with a cord having the appropriate molded-in mains plug. The power cord connects to the power supply with an IEC type connector, the same as found on virtually every PC around the world. Therefore, any power cord that will work with a PC should work with the Initializer power supply.

• Replace the mains plug on the included power cord with a local mains plug. This should only be done by someone qualified to perform this work.

9.3 Serial Cables

This unit has been shipped with 2 serial data cables for connection between the Initializer and the COM port on a PC. One cable has a DB-9 female connector on the PC end and the other has a DB-25 female connector. Both cables have a DB-25 pin male connector on the Initializer end. Use whichever cable suits your computer. If you use the 9-pin cable, you may use the other cable as an extension cable.

9.4 Hardware Installation

• Insert the DC power jack on the end of the power supply cable into the matching plug on the back of the Initializer.

• Plug the IEC end of the mains power cord into the Initializer power supply.

• Plug the mains end of the power cord into a suitable AC power outlet. Connect the Initializer to a PC serial port with a serial cable.

• Turn on the Initializer by raising the switch on the back panel of the unit. The green power LED on the front panel should go on.

9.5 COM Port Setup

Initializers require a dedicated COM port on the Windows Client. Make sure that the operating system recognizes the existence of the serial port hardware and that you know



which COM port number it is. Also make sure that there are no interrupt conflicts or other conflicts with other installed hardware.

9.6 Initializer LED Indicators

Initializers are equipped with five front panel LED’s and two flashing LED’s mounted on the top. These LED’s should be lit at the appropriate time to guide the user in the operation of the Initializer.

9.6.1 Front panel LED’s (from left to right)

• INSERT (Green) OK to insert token

• INIT (Yellow) Initialization in process

• DONE (Green) Initialization complete

• ERROR (Red) A problem has been encountered in initializing a token

• POWER (Green) indicates unit has power applied

9.6.2 Top panel LED’s

There are two red LED’s on the top of the RBI Initializer near the token slot that flash alternately when a token is being initialized.

WARNING

Removing the RB-1 token while initialization is in progress will damage the Initializer and render it inoperative. Wait until the “Initialization Complete” LED illuminates to remove the RB-1 token.



10. Install and Configure easyRADIUS Server

10.1 Overview

easyRADIUS is CRYPTOCard’s implementation of RADIUS. RADIUS (Remote Authentication Dial-In User Service) is a client/server security protocol created by Livingston Enterprises and is on the IETF (Internet Engineering Task Force) standards track (RFC 2138 and RFC 2139). Although the term RADIUS refers to the network protocol that the client and server use to communicate, it is often used to refer to the entire client/server system.

10.2 Advantages of using easyRADIUS

Centralized security - In large networks, security information may be scattered throughout the network on different devices. RADIUS allows user information to be stored on one host, minimizing the risk of security loopholes. All authentication and access to network services is managed by the host functioning as the easyRADIUS server.

Flexibility - The easyRADIUS server may be adapted to your network. This allows access rights to be assigned to groups for easier administration. easyRADIUS may be used with any communications server, firewall, router or VPN server that supports the RADIUS protocol.

Simplified management - easyRADIUS is tightly integrated with CRYPTOAdmin, providing a single point of administration for all security information. CRYPTOAdmin is used to add new users to the CRYPTOAdmin database, which will automatically be recognized by the easyRADIUS server.

This section will help Administrators install and run easyRADIUS with the minimal amount of configuration. For more in-depth information please see the CRYPTOCard easyRADIUS Administration Guide.

10.3 Installation

easyRADIUS is installed by the CRYPTOAdmin Server installer. Refer to CRYPTOAdmin Server

Installation for more information and instructions.

By default easyRADIUS server is installed in manual mode.



10.4 Start/Stop easyRADIUS

On Windows go to:

• Control Panel| Administrative Tools| Services, select CRYPTOCard easyRADIUS and start the service

On Linux Systems:

• Administrator must be logged into the root as ’superuser’.

• To start the server, run /etc/rc.d/init.d/radiusd start [debug]

• To stop the server, run /etc/rc.d/init.d/radiusd stop [debug]

Use [debug] option RADIUS server running on the desktop is required.

On Solaris Systems:

• Administrator must be logged into the root as ’superuser’.

• To start the server, run /etc/init.d/radiusd start [debug]

• To stop the server, run /etc/init.d/radiusd stop [debug]

Use [debug] option RADIUS server running on the desktop is required.

10.5 Testing the server

The easyRADIUS install includes the radtest utility. Use the radtest utility to test easyRADIUS.

radtest user password ip address[port] nas-port secret

Correct output from this command should be:

[root@server bin]$ /usr/sbin/radtest test password 127.0.0.1 0 testing123

radrecv: Request from host localhost code=2, id=2,

length=119

Reply-Message = "Test succeeded: easyRADIUS is running.",

Reply-Message = "Please delete the test user to prevent unauthorized logins".



10.6 Configuring easyRADIUS

easyRADIUS is designed to be used in conjunction with CRYPTOAdmin Server. CRYPTOAdmin must be installed with easyRADIUS since there are important configuration and set-up files that are shipped with CRYPTOAdmin required by easyRADIUS. easyRADIUS server files are stored in the:

• Windows: \Program Files\CRYPTOCard\CRYPTOAdmin\Server directory

• Linux/Solaris: /etc/cryptocard directory.

easyRADIUS server files and their definitions

clients Defines the RADIUS clients that will be using easyRADIUS for authentication services. (NAS, firewall, router or VPN server) More on the clients file can be found below.

users The remote user database. Default user handling is set up in this file to use the CRYPTOAdmin database for token authentication. More on the users file can be found below.

hints Contains a list of username prefix and suffix identifiers for special user authentication handling.

huntgroups Defines a list of valid NAS and ports through which users may connect. This list is used in conjunction with the Huntgroup-Name = XXX attribute in the users file.

dictionary A collection of NAS dictionaries used by easyRADIUS for attribute mapping for special RADIUS clients.

naslist Used in conjunction with the “clients” file, this file identifies the type of each NAS and its short name/identifier for logging purposes.

cacclient.exe The CRYPTOAdmin GUI client application.

cadmin.exe The CRYPTOAdmin console client application.

cadmind.exe The CRYPTOAdmin server application.

radiusd.exe The easyRADIUS server application.

radtest.exe A RADIUS client test application. Useful for debugging and isolating problems in the system configuration.



10.7 The Clients file

The client’s file has two functions. The first function is to define an access control list for RADIUS requests. If the easyRADIUS server receives a RADIUS request from a machine which is not listed in the clients file, the request is discarded and an error message is logged. The second function of the clients file is to define the secret, which is shared between the RADIUS client and the easyRADIUS server. This shared secret is used to sign and authenticate the RADIUS requests, and ensures that the request comes from a particular service executing on the RADIUS client.

# #Clients # # # # # # # # # # #

This file contains a list of RADIUS clients which are allowed to make authentication requests, and their encryption key. Description of the fields: *The first field is a valid host name or IP address for the client, with optional network bit mask. *The second field (separated by blanks or tabs) is the shared secret. It should be AT LEAST 16 characters long and no longer than 63 characters. It should be composed of random letters and numbers, and NOT dictionary words.

# Client Name Key 192.168.0.0/16 Secret1 192.168.10.0/25 Secret2 Localhost Secret3 127.0.0.1 Secret4 # End of File

10.8 Users File

The users file stores authentication and authorization information for all End-users authenticated with easyRADIUS. Each user has an entry, which consists of four parts:

• username, check items, control items (optional) and reply items.

bob Auth-Type = CRYPTOCard,Group-Name = "Active" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 192.168.0.200, Framed-IP-Netmask = 255.255.255.254, Framed-Routing = None, Framed-Compression = Van-Jacobson-TCP-IP, Filter-Id = "std.ppp", Framed-MTU = 1500

The default installation of easyRADIUS includes a database configured for CRYPTOCard authentication only. No additional reply items are included in the "users" file. This means



that any RADIUS client request that easyRADIUS receives will attempt to authenticate the user with an entry defined in the CRYPTOAdmin database.

When the easyRADIUS server receives a username/password pair from a RADIUS client, the easyRADIUS server scans the "users" file for a match, starting from the top of the file. If a match is located, the user is authenticated using the information in that user entry. If a matching user entry is not found during the scan, but a matching default entry is located, that entry is used. Default entries should appear at the end of the "users" file; the easyRADIUS server stops scanning entries when a matching default entry is found.

10.8.1 Username

The username can contain any character except null (“\0”), space or tab and can be up to 64 characters long. Usernames used with easyRADIUS are case-sensitive.

10.8.2 Check items

Check items are listed on the first line of a user entry, separated by commas. For an access-request to succeed, all check items in the user entry must be matched in the access-request. In the example above, "bob" is authenticated with a CRYPTOCard token, and will be authenticated if he is in the "Active" CRYPTOAdmin group. An attempt to authenticate "bob" will be made if an entry matches the check items. If a match is not found, easyRADIUS will look for an entry that does match, such as: "Default = CRYPTOCard".

(For a listing of all check items please see the CRYPTOCard easyRADIUS Administrator’s Guide)

Care must be taken to ensure proper user file configuration.

10.8.3 Control Items

Control items define special easyRADIUS server handling instructions when a user is authenticated. Control items supported by easyRADIUS include "Hint" and "Fall-Through", among others.

(For a listing of all control items please see the CRYPTOCard easyRADIUS Administrator’s Guide)

10.8.4 Reply Items

Reply items give the RADIUS client information about the user's connection, for example, whether PPP or SLIP is used or whether the user's IP address is negotiated. In the previous example, "Framed-Protocol" is a reply item. The value of "Framed-Protocol" is PPP,



indicating that "bob" uses PPP for his connection. If all check items in the user entry are satisfied by the access-request, the RADIUS server sends the reply items to the easyRADIUS client to configure the connection.

(For a listing of all reply items please see the CRYPTOCard easyRADIUS Administrator’s Guide)

10.9 Hints and Huntgroup (Authentication Pre-Processing)

Authentication pre-processing is controlled through the easyRADIUS "hints" and "huntgroups" files. These files contain instructions for special handling of all access-request messages before user authentication is attempted. The Prefix and Suffix check items allow a user to access multiple services by prepending or appending a series of characters to the user’s username. Prefix and Suffix strings must consist of 16 or fewer printable ASCII characters. The Strip-User-Name check item is used to instruct easyRADIUS to remove the specified Prefix or Suffix characters before authenticating the user. The Hint reply item can be used to link a control entry in the "hints" file to a collection of reply item settings in the "users" file. The Hint reply item is used as a check item in the "users" file. An excerpt from the hints file is shown below:

DEFAULT Prefix = "P", Strip-User-Name = Yes Hint = "PPP" DEFAULT Suffix = ".ppp", Strip-User-Name = Yes. Hint = "PPP"

In the above example, a DEFAULT username starting with "P" will have the leading "P" stripped away during authentication. Likewise, a username ending with “.ppp" will have the trailing ".ppp" stripped away during authentication. The Hint = "PPP" reply item in the "hints" file is used as a check item in the users file. Thus, if the "users" file contains:

DEFAULT Auth Type = CRYPTOCard,Hint = "PPP" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 192.168.0.200, Framed-Routing = None, Framed-MTU = 1500

If user "bob" specified a username of "bob.ppp", the easyRADIUS server would strip the ".ppp" from his username and authenticate the username "bob" against the CRYPTOAdmin Server database. easyRADIUS would then configure bob's connection as a PPP connection, since the Hint = "PPP" check item will be found.



10.10 Troubleshooting

Ensure that easyRADIUS can execute from the computer on which it is installed. The simplest way to ensure easyRADIUS can execute is to run it from a console window in debug mode.

Windows: stop the easyRADIUS service radiusd.exe –sfxyz –l stdout

The Output should look like this: C:\Program Files\CRYPTOCard\CRYPTOAdmin\Server radiusd –sfxyz –l stdout Successfully jdbc and connected to the database. Starting – reading configuration files... Ready to process requests.

Linux: /etc/rc.d/init.d/radiusd stop /etc/rc.d/init.d/radiusd start debug

Solaris: /etc/init.d/radiusd stop /etc/init.d/radiusd start debug

The Output should look like this: [root@server bin]$ radiusd start debug Starting - reading configuration files ... Ready to process requests.

If the "Ready to process requests." message is not displayed, then the easyRADIUS server cannot execute. Possible causes:

• You may not have installed easyRADIUS, or the installation may have had errors.

• Windows: you are trying to start the RADIUS server from an MSDOS prompt. This may generate the following message:

C:\Program Files\CRYPTOCard\CRYPTOAdmin\Server radiusd –sfxyz –l stdout Successfully jdbc and connected to the database. Unable to link to cryptolib: syserr radiusd 111105: Cannot allocate resources : Connection denied. If the database exists, it is most likely owned by an running service such as CRYPTOAdmin and you do not have permissions under this account to access it. C:\Program Files\CRYPTOCard\CRYPTOAdmin\Server>

This error is generated when CRYPTOAdmin is running in NT SERVICES and easyRADIUS is running from the console. There are 2 ways around this. Run both CRYPTOAdmin and easyRADIUS from the MSDOS prompt or start easyRADIUS first then start CRYPTOAdmin from NT SERVICES.

• Windows: If CRYPTOCard JDBCDataService is not running the following error message will be generated. To fix this problem go into NT SERVICES and start the CRYPTOCard JDBCDataService.



C:\Program Files\CRYPTOCard\CRYPTOAdmin\Server radiusd –sfxyz –l stdout Successfully jdbc and connected to the database. from ccJdbcGetCount failed to get method id 900108: Can’t locate ccJdbcGetCountTable method. Exiting.. 900108: Can’t locate the ccJdbcPrepareToFetch method. Exiting.. Starting – reading the configuration files .. Ready to process requests

Fix this problem by starting the CRYPTOCard JDBCDataService.

• Linux/Solaris: You may also not have configured easyRADIUS properly for CRYPTOCard libraries.

• Linux/Solaris: There is already an existing pid for the service. To remove the pid run:

find / -name radiusd.pid –exec rm {} \;

Linux/Solaris: This configuration can be done from a shell prompt, as in the following examples:

csh, tcsh, and variants: [root@server /etc]# setenv LD_LIBRARY_PATH=/usr/lib/cryptocard/lib sh, bash, and variants: [root@server /etc]#LD_LIBRARY_PATH=/usr/lib/cryptocard/lib [root@server /etc]# export LD_LIBRARY_PATH

The Output should look like this: [root@server bin]$ radiusd start debug Starting - reading configuration files ... Ready to process requests.



11. Create a CRYPTOAdmin Replica Server

CRYPTOAdmin Server can be replicated, providing a fully redundant, fault tolerant authentication service.

11.1 Replica Server Prerequisites

In order to configure a CRYPTOAdmin Replica Server the following items must be properly installed and configured.

• CRYPTOAdmin Server using MySQL must be installed on the Replica Server. It is preferable the Primary and Replica CRYPTOAdmin Servers use the same MySQL version. Ensure that each MySQL Server ID is unique.

• If not done during the installation of CRYPTOAdmin Server/MySQL Server on the Primary and Replica Server, run mysqlinit.cmd now.

• Confirm bidirectional communication between the Primary and Replica using Ping.

11.2 Step 1. Configure an NT/2000/XP Primary Server for Replication (Server A)

Create / edit the c:\WinNT\my.ini file on the Primary Server and add the following lines on the Primary Server:

[mysqld]

server-id = 1

log-bin

log-slave-updates

Grant permission for the Replica Server (Server B) to connect to the Primary Server (Server A) by issuing the following SQL command from the Primary Server Command Prompt:

mysql > Grant file on *.* to replicate@IPAddress identified by ‘password’;

Where replicate is a special replication user on the Primary with file privileges; IP Address is the IP of the Replica Server; password is a valid password of your choice. Include the quotation marks (‘’) and the semi-colon (;).



If the Primary Server database is populated with tokens, stop the MySQL service on both the Primary and Replica system, then copy the \MySQL\Data\CRYPTOAdminjdbc directory to Replica server.

Save the file and restart the Primary MySQL service.

11.3 Step 2: Configure an NT/2000/XP Replica Server (Server B)

Create / edit the c:\WinNT\my.ini, and add the following lines (NOTE: Database name is case sensitive):

[mysqld]

server-id = 2

master-host = <IP Address of the Primary server>

master-user = <replication user name>

master-password = <replication user password>

replicate-do-db = CRYPTOAdminjdbc

Save the file and restart the Replica MySQL service.

11.3.1 Test One-way Replication

Test One-way replication before configuring for bi-directional replication.

Add a token to the Primary Server database using the Client.

Use the Client to connect to the Replica Server. The new token should be present, confirming the correct function of one-way replication.

11.3.2 One-way Replication Considerations

Groups created on the Primary server must be manually created on the Replica, permitting tokens in the Primary Server Group to be replicated successfully.

If the Primary Server goes down in a One-way replication setup, it’s database will need to be brought back up to date with the Replica database before bringing the Primary back online.



To do this, stop both MySQL servers, and copy the \ MySQL \ Data \ CRYPTOAdminjdbc folder from the Replica to the Primary and then restart the MySQL service on both servers.

11.4 Step 3: Configure By-directional Replication on NT/2000/XP Servers

Bi-directional replication is accomplished by setting up one-way replication via the instructions above, and then configuring additional one-way replication in reverse.

Add the following lines to c:\WinNT\my.ini on the Primary Server

[mysqld]

master-host = <IP Address of the Replica>




Save the file and restart the MySQL service.

Add the following lines to c:\WinNT\my.ini of the Replica Server.

[mysqld]

log-bin

log-slave-updates

Grant permission for the Primary (Server A) to connect to the Replica (Server B) the by issuing the following SQL command from a Command Prompt on the Replica Server:


Where replicate is a special replication user on the Replica with file privileges; IP Address is the IP of the Primary; password is a valid password of your choice.

Include the quotation marks (‘’) and the semi-colon (;).




Groups created on the Primary server must be manually created on the Replica, permitting tokens in the Primary Server Token Group to be replicated successfully.

Restart the MySQL service.

11.4.1 Test Bi-directional Replication

Simulate a network or server outage by stopping the MySQL service on the Primary (Server B).

C:\> net stop mysql

Connect to the Primary with a Client. Select a token and perform “Test Token” (Main Menu: Edit|Test). A successful test will advance the challenge for this token in the Replica database.

Start the MySQL service on the Primary (Server A).

C:\> net start mysql

Using the Client, connect to the Primary Server and confirm that the challenges for the token match on the Primary and Replica.

11.5 Step 1. Configure a Linux/Solaris Primary Server for Replication (Server A)

Create / edit the /etc/my.cnf file, and add the following lines:

[mysqld]

socket = /tmp/mysql.sock (enter your path to the mysql.sock)

server-id = 1

log-bin

log-slave-updates

Grant permission for the Replica Server (Server B) to connect to the Primary Server (Server A) by issuing the following SQL command from a Command Prompt on the Primary Server:




Where replicate is a special replication user on the Primary with file privileges; IP Address is the IP of the Replica Server; password is a valid password of your choice. Include the quotation marks (‘’) and the semi-colon (;).


Save the file and restart the Primary MySQL daemon.

11.6 Step 2: Configuring the Replica Server (Server B)

Create / edit the /etc/my.cnf file and add the following lines:

[mysqld]

socket = /tmp/mysql.sock (enter your path to the mysql.sock)

server-id = 2

master-host = <IP Address of the Master server>




Save the file and restart the Replica MySQL daemon.

11.6.1 Test One-way Replication

Test One-way replication before configuring for bi-directional replication.

Add a token to the Primary Server database using the Client.

Use the Client to connect to the Replica Server. The new token should be present, confirming the correct function of one-way replication.

11.6.2 One-way Replication Considerations



Groups created on the Master server must be manually created on the Replica, permitting tokens in the Master Server Group to be replicated successfully.

If the Master Server goes down in a One-way replication setup, the Master Server database will need to be brought back up to date with the Slave database before bringing the Master back online. To do this, stop both MySQL servers, and copy the \ MySQL \ Data \ CRYPTOAdminjdbc folder from the Replica to the Master and then restart the MySQL daemon on both servers.

11.7 Step 3: Configure By-directional Replication on Linux/Solaris Servers

Bi-directional replication is accomplished by setting up one-way replication via the instructions above, and then configuring additional one-way replication in reverse.

Add the following lines to /etc/my.cnf on the Primary Server:

[mysqld]

master-host = <IP Address of the Replica>




Save the file and restart the MySQL daemon.

Add the following lines to /etc/my.cnf of the Replica Server.

[mysqld]

log-bin

log-slave-updates

Grant permission for the Primary (Server A) to connect to the Replica (Server B) the by issuing the following SQL command from a Command Prompt on the Replica Server:




Where replicate is a special replication user on the Replica with file privileges; IP Address is the IP of the Primary; password is a valid password of your choice.

Include the quotation marks (‘’) and the semi-colon (;).


Groups created on the Primary server must be manually created on the Replica, permitting tokens in the Primary Server Token Group to be replicated successfully.

Restart the MySQL daemon.

11.7.1 Test Bi-directional Replication

Simulate a network or server outage by stopping the MySQL daemon on the Primary (Server A).

C:\> net stop mysql

Connect to the Replica with a Client. Select a token and perform “Test Token” (Main Menu: Edit|Test). A successful test will advance the challenge for this token in the Replica database.

Start the MySQL daemon on Primary (Server A).

C:\> net start mysql

Using the Client, connect to the Primary Server and confirm that the challenges for the token match on the Primary and Replica.

11.8 Troubleshooting MySQL Replication

If a problem is encountered, the log file created by MySQL. The log file on Windows is located in the \ mysql \ data directory by default, with a .err extension. On Linux / Solaris the log file is located in /var/lib/mysql by default with a format of hostname.err. Note the database name are case sensitive. An error in the database name will cause replication to fail, even though a connection exists between the two MySQL servers.

If socket errors are received on Linux / Solaris systems, stop the MySQL daemon on both servers. Remove all .bin, .err, .info files from the mysql directory. Restart the Primary server and then enter the command:



mysql> reset master;

Restart the Slave server and then enter the command:

mysql> reset slave;

11.9 MySQL Commands

mysql> show master status;(provides status information on the binlog of the master)

mysql> show slave status; (provides status information on the essential parameters

of the slave)

mysql> show databases; (lists the databases that are present)

mysql> use [database name]; (selects the database to work with, ie:

CRYPTOAdminjdbc)

mysql> show tables; (lists the tables that exist in the selected database)

mysql> show tables; (lists the tables that exist in the selected database)

mysql> delete from [table] where userid = ‘[user]’; (deletes specified user

from the selected table)

mysql> show grants for [user@IP Address]; (lists the grants for the specified user)

mysql> grant file on *.* to [user@IP Address] identified by ‘[password]’; (allows the slave system to replicate)

mysql> mysql;

mysql> select host, user, password from user; (lists all hosts and the users that

have grant privileges & the password)

For more information on MySQL, please visit http://www.mysql.com



12. Alternate Databases (MS-SQL, Oracle)

CRYPTOAdmin Server can utilize any JDBC compliant database server. The following provides configuration requirements and instructions for use of MS-SQL or Oracle with CRYPTOAdmin Server. It assumes that the database server has been installed and operational.

Example parameters:

<cryptoadminjdbc> is the name of the CRYPTOAdmin Server database on the database server.

<cryptocard> is the user name of an account with full privileges on <cryptoadminjdbc>

<ccdatabasemanager> is the password for account <cryptocard>

<127.0.0.1> is the IP address of the database server

/CRYPTOAdmin/Server is the installation location of CRYPTOAdmin Server on Windows

/etc/cryptocard is the installation of CRYPTOAdmin Server on Linux/Solaris

Oracle installations will require the Auguro.jar JDBC driver included with the CRYPTOAdmin Server distribution.

MS-SQL installations will require the Una2000.jar driver included with the CRYPTOAdmin Server distribution.

12.1 Configure Oracle or MS-SQL for CRYPTOAdmin Server

1. Create a database <cryptoadminjdbc> for use by CRYPTOAdmin Server

2. Create an account <cryptocard> with password <ccdatabasemanager> on the <cryptoadminjdbc>

3. Copy JDBC driver (Auguro.jar for Oracle, Una2000.jar for MS-SQL) to:

Windows: \CRYPTOAdmin\Server

Linux/Solaris: /usr/lib/cryptocard

4. Edit [The JDBC-Setup control block] of cryptocard.cfg as shown. Replace < > with database, account, password and IP address of actual system.



12.2 Modify .cfg Control Block for Oracle

Windows

#The Oracle JDBC-Setup control block #

driver=com.inet.ora.OraDriver url=jdbc:inetora:<127.0.0.1>:1521:<CRYPTOAdminjdbc> user=<cryptocard> passwd=<ccdatabasemanager> path=.;./ccjdbc.jar;./Auguro.jar timeout=20 silent=1 resync=1500

Linux

[JDBC-Setup] driver=com.inet.ora.OraDriver url=jdbc:inetora:<127.0.0.1>:1521:<CRYPTOAdminjdbc> user=<cryptocard> passwd=<ccdatabasemanager> path=/usr/lib/cryptocard/ccjdbc.jar:/usr/lib/cryptocard/Auguro.jar libpath=/usr/local/j2re1.3/lib/i386/server/usr/local/j2re1.3/lib/i386 timeout=20 silent=1 resync=1500

Solaris

[JDBC-Setup] driver=com.inet.ora.OraDriver url=jdbc:inetora:<127.0.0.1>:1521:<CRYPTOAdminjdbc> user=<cryptocard> passwd=<ccdatabasemanager> path=/usr/lib/cryptocard/ccjdbc.jar:/usr/lib/cryptocard/Auguro.jar libpath=/usr/local/j2rel_3_0_01/lib/sparc/classic:/usr/local/j2rel_3_0_01/lib/sparc timeout=20 silent=1 resync=1500



12.3 Modify .cfg Control Block for MS SQL

Windows

[JDBC-Setup] driver=com.inet.tds.TdsDriver url=jdbc:inetdae:<127.0.0.1>:1433?database=<CRYPTOAdminjdbc> user=<cryptocard> passwd=<ccdatabasemanager> path=.;./ccjdbc.jar;./Una2000.jar timeout=20 silent=1 resync=1500

Linux

[JDBC-Setup] driver=com.inet.tds.TdsDriver url=jdbc:inetdae:<127.0.0.1>:1433?database=<CRYPTOAdminjdbc> user=<cryptocard> passwd=<ccdatabasemanager> path=/usr/lib/cryptocard/ccjdbc.jar:/usr/lib/cryptocard/Una2000.jar libpath=/usr/local/j2re1.3/lib/i386/server/usr/local/j2re1.3/lib/i386 timeout=20 silent=1 resync=1500

Solaris

[JDBC-Setup] driver=com.inet.tds.TdsDriver url=jdbc:inetdae:<127.0.0.1>:1433?database=<CRYPTOAdminjdbc> user=<cryptocard> passwd=<ccdatabasemanager> path=/usr/lib/cryptocard/ccjdbc.jar:/usr/lib/cryptocard/Una2000.jar libpath=/usr/local/j2rel_3_0_01/lib/sparc/classic:/usr/local/j2rel_3_0_01/lib/sparc timeout=20 silent=1 resync=1500



12.4 Create CRYPTOCardTokens Table in Database

Create the CRYPTOCardTokens table in <CRYPTOAdminjdbc>

Windows:

c:/program files/cryptocard/cryptoadmin/server/file2db.exe –n

Linux:

file2db –n

Solaris:

runfile2db -n

Confirm creation of CRYPTOCardTokens table.

Launch CRYPTOAdmin Server.



13. CRYPTOAdmin Server Back-up

Create a CRYPTOAdmin / easyRADIUS back-up when initially bringing the service on-line and in advance of any upgrade.

13.1 Backing up your Database

To backup your database you need to copy the following files to another directory or medium:

cryptocard.cfg, cadmin.exe, ccinit, ccsecret, cryptocards, groups, operator, opergroups, passwd, peers, users

In addition back-up the MySQL, Oracle or MS-SQL database using native tools.



14. Client Command Line Interface (CLI)

This component provides text based, command line functionality equivalent to the GUI interface. Furthermore, it has the ability to ‘import’ other user databases into the CRYPTOAdmin database via batch command. Like the GUI client, it supports the generation and initialization of EUS software tokens and supports RB-1 and KT-1 token initialization via the RBI and KFI token intializers respectively.

Commands are entered on a single line as a series of words separated by spaces or tabs. Commands may be abbreviated to its shortest representation that is distinct from other commands. For example, there are two commands beginning with the letter <d>

disconnect and delete. Disconnect may be abbreviates as di, and Delete as de.

Abbreviating either command to d is not permitted, as d by itself is ambiguous. Commands

are not case sensitive.

If an incorrect command is entered, a list of valid commands will appear. Some command executions do not display a result when they succeeded and while others display descriptive text about the tokens.

Type help for information on all commands. Type ? after a command for specific help.

Syntax:

< > indicates mandatory information

[ ] indicates optional information

Example:

Connect <host>[:port] name [password]

Connect 127.0.0.1 Admin cryptoadmin

Or

By hitting <Enter> after name and entering the password on the next line, the password will not be visible.

Connect 127.0.0.1 Admin

Password:>cryptoadmin



Administrators can use all commands. Operators can use all commands that do not conradict their permissions.

14.1 CLI Commands and Syntax

Command Syntax

Required Permission

Connect Connect <host>[:port] name [password]

DIsconnect DIsconnect

This command will disconnect the client from the remote server, but the client will remain open.

Quit Quit

This command will disconnect the client from the remote server.

Exit Exit

This command will close the client.

Help Help [command]

Displays command information and syntax

SHow SErvers SHow SErvers

This option lists the CRYPTOAdmin Servers the operator is permitted to access.

LIst TOkens LIst TOkens

Group Access

Lists all tokens in the group

FInd TOken FInd TOken <token name> Group Access

If token is found: Displays token name, serial number, group



Command Syntax

Required Permission

SHow DEfault TOken SHow DEfault Token

Shows all default token profiles listed in the CRYPTOAdmin Client Command-Line Interface block of cryptocard.cfg on Client.

SHow TOken SHow TOken <token name>

Displays token parameters for <token name>

NEw TOken New token <token name> <serial #> [pin] Group Access

Where <token name> is 1 – 64 characters

Where <serial #> is any 9 digit number as follows:

KT-1 30xxxxxxx KT-1 31xxxxxxx SC-1 90xxxxxxx

RB-1 4xxxxxxxx RB-1 20xxxxxxx ST-1 7xxxxxxxx

Where [pin] meets Default Token attributes

The default token profile determines the minimum parameters that will be accepted when using the new token command. Incorrect parameters will cause the command to fail. Missing optional parameters will be overridden by the default token profile. Default token profiles may be modified by editing the cryptocard.cfg file, CRYPTOAdmin Client Command-Line Interface block on the Client.

Initialize TOken Initialize TOken <token name> [port]

Initializes <token name>, creating initialization file for software tokens or activating initialer on indicated port for hardware tokens.

(Solaris/Linux Clients: CRYPTOAdmin attempts to put the software token initialization file in /usr/lib/cryptocard/tokens. Operators who can log on as “Root” can create the path manually. Operators who cannot log on as “Root”, must either be granted permissions to /usr/lib/cryptocard/tokens or a link that points to a location they can use must be created in /usr/lib/cryptocard.

TEst TOken TEst <token name>

Causes a challenge to be displayed for <token name>. Response generated by <token name> must be entered to complete test.

DElete TOken DElete TOken <token name> Token Access

Removes <token name> from database



Command Syntax Required Permission

LIst Groups LIst Groups

Lists only those groups a Configurable operator has read or read/write access to. It will list all groups for a Read Only operator.

NEw Group New group <group name> [“description”] Group Access

This creates a new group directly on the root of the server, or inside an already existing group. The group name must not exceed 20 alphanumeric characters (including nested groups and delimiters).

Example:

new group Canada

Creates the group Canada on the root of the server.

set group Canada establishes Canada as the active group

new group Ontario creates the group Ontario under Canada

Length of new group is 14 characters (Canada$Ontario)

set group Ontario establishes Ontario as the active group

new group Ottawa creates the group Ottaw

Length of new group is 20 characters (Canada$Ontario$Ottaw)

[description] can be up to 20 characters in length excluding quotes

SEt Group Set Group Group Access

Use this command to move from group to group.

For example: set group Canada will bring you to the group called Canada.

To move to the group Ontario, that resides within the group Canada, enter

set group Ontario.

To move backwards, enter set group. In the example above, this will bring you back to the group Canada.

To move to an entirely different set of groups, type in the whole group name. For example: to move directly out of the group Ottawa to the group Washington (nested inside the group USA), the text would be set group usa$washington

The input prompt identifies the current group.



Command Syntax

Required Permission

Udate Group Update Group <GroupName> [“description”]

Changes description of <GroupName> to “description”

SHow PErmissions SHow Permissions <GroupName> [operator] Group Access

Displays operator permissions for <GroupName>

NEw PErmissions

NEw Permissions <GroupName> <Operator> [Permissions]

Administrator Only

Assigns permissions to <operator> for <GroupName>

Refer to 14.2 Operator Permissions Reference Chart

UPdate PErmissions

Update Permissions <GroupName> <Operator> [Permissions]

Administrator Only

Assigns permissions to <operator> for <GroupName>

Refer to 14.2 Operator Permissions Reference Chart

DElete PErmissions

DElete PErmissions <GroupName> <Operator>

Administrator Only

Deletes permissions for <Operator> on <GroupName>

Version Version

Displays CLI Client version



14.2 Operator Permissions Reference Chart

Field Operator Permission Field Description No

Access Read Only

Read Write

Definition Group Access --- 0 1

1st digit Access to PIN Information 0 1 2

2nd digit Access to Hex/Decimal display settings 0 1 2

3rd digit Access to Telephone token display setting 0 1 2

4th digit Access to Challenge Mode setting 0 1 2

5th digit Access to Try Attempts settings 0 1 2

6th digit Access to Minimum PIN Length setting 0 1 2

7th digit Access to Idle Timeout setting 0 1 2

8th digit Access to Language setting 0 1 2

9th digit Access to Initial PIN setting 0 1 2

10th digit Access to Token Display ID setting 0 1 2

11th digit Access to Token Serial Number 0 1 2

12th digit Access to Next Challenge 0 1 ---

13th digit Access to Token Initialization Date 0 1 2

14th digit Ability to create and delete token 0 --- 2



15. Alternate RADIUS Servers

15.1 Cisco Secure ACS 3.0+

Cisco Secure version 3.0+ connects to the CRYPTOAdmin Server using the RADIUS authentication protocol. This means that the CRYPTOAdmin Server may run on same machine as ACS or on a separate machine, and that the CRYPTOAdmin Server must have easyRADIUS installed.

The following information is required during configuration:

IP Address of the ACS server:

IP Address of CRYPTOAdmin server:

Port number used by easyRADIUS server:

Port used by easyRADIUS server:

Shared Secret:

15.1.1 Configuring the External User Database

From the Cisco Secure ACS administrator select External User Databases.

Then click on Database Configuration.

Next select CRYPTOCard Token Server.



Choose Create New Configuration.

Submit the default name for the configuration.

Select Configure.

Enter the IP address or host name of the primary CRYPTOCard server.

[OPTIONAL] Enter the IP address or host name of the secondary CRYPTOCard server.

Enter the shared secret for the easyRADIUS server(s).

Verify that the correct port for the easyRADIUS server is entered.

NOTE: If Cisco Secure and CRYPTOCard are installed on the same server, easyRADIUS must be manually configured to use an available port. This is because Cisco Secure will already lock ports 1645, 1646, 1812 and 1813 (defaults) for its RADIUS server. To change the port that easyRADIUS uses, edit the “radius” and “radacct” entries in the “WinNT\system32\drivers\etc\services” file to an available port number.

Enter the timeout for communications between ACS and easyRADIUS.

Enter the number of retries ACS should make before trying the secondary easyRADIUS server.



Enter the delay that ACS should wait before trying the failed primary CRYPTOCard server again, as the ”Failback Retry Delay”.

15.1.2 Setting the Unknown User Policy

The Unknown User Policy in Cisco Secure can be used to help automatically add CRYPTOCard users to the ACS database.

The rules of this policy are used by ACS to determine what to do when an authentication request comes in for a username that is not found in the Cisco Secure database.

If the policy states that the CRYPTOCard server should be checked, then the username will be forwarded to CRYPTOCard for authentication. The username will only be added to the Cisco Secure database after a successful authentication by the CRYPTOCard server.

15.1.3 Mapping CRYPTOCard Users to a Cisco Secure Group

The Database Group Mappings setting determines what group to create new CRYPTOCard users in, if the Unknown User Policy is configured to check the CRYPTOCard Token Server.

From the Cisco Secure ACS administrator select External User Databases.

Then click on Database Group Mappings.



Select the CRYPTOCard server.

Choose the default group.

15.1.4 Troubleshooting Tips

15.1.5 Token Caching

If token caching fails with Cisco Secure 3.0, verify the registry on the ACS server:

HKLM/SW/Cisco/CiscoAAAv3.0/Authenticators/Libraries/13/

REG_DWORD "Properties" should be 0x10d (269 decimal)

Then restart the CSAdmin and CSauth services.

15.1.6 Cisco Secure logging messages

The following is an explanation of the logging messages in the “Failed Attempts” log file in Cisco Secure ACS:

“CS user unknown”

Cisco Secure logs this message when it receives a username that is not in the local database.

If the username does correspond to a token in the CRYPTOAdmin database, the Unknown User Policy in Cisco Secure has not been configured to search the CRYPTOAdmin database.

“External DB auth failed”

Cisco Secure logs this message when it receives an incorrect password for a given CRYPTOCard token user. Use the CRYPTOAdmin Client, or the “test” function in Cisco Secure, to verify that the token is initialized correctly.



“External DB not operational”

This message appears in the Cisco Secure 3.0 logs when the CRYPTOAdmin service is not running.

Make sure that the CRYPTOAdmin service is running before trying to log in again.

If a Cisco Secure 3.0+ server logs this message, it indicates that ACS was unable to connect to the easyRADIUS server as configured in the CRYPTOCard Token Server Configuration. Verify this information using the RadTest command line utility in the Cisco Secure “Utils” directory.



15.2 Funk Steel Belted RADIUS

15.2.1 Windows Installation

During the installation of the CRYPTOAgent for Funk Steel Belted RADIUS, support for CRYPTOCard token authentication will be added to Funk Steel-Belted RADIUS.

The following information will be required during the installation of the CRYPTOAgent for Funk Steel Belted RADIUS:

IP Address of CRYPTOAdmin SPT server:

CRYPTOAdmin SPT server port:

CRYPTOAdmin operator name:

CRYPTOAdmin operator password:

Packet Encryption Key of CRYPTOAdmin SPT server:

In the CRYPTOAgent Configuration dialogue, enter the configuration information of the CRYPTOAdmin SPT server.



15.2.2 Solaris Installation

During the installation of the CRYPTOAdmin SPT server you can choose to install the CRYPTOAgent for Funk Steel Belted RADIUS.

The following packages are available: 1 CCcadmind CRYPTOAdmin Server (sparc) 5.32-020 2 CCclients CRYPTOAdmin client (sparc) 5.32-020 3 CCcommon CRYPTOAdmin common files (sparc) 5.32-020 4 CCfunk CRYPTOAgent for Funk SBR (sparc) 5.32-020 5 CCradius easyRADIUS (sparc) 5.32-020

Once the CRYPTOAgent for Funk Steel Belted RADIUS has been installed you must edit the cryptocard.aut file located in the /CRYPTOCard_Funk_plugin directory. At the bottom of the file enter the configuration information of the CRYPTOAdmin SPT Server, then copy the file to the SBR server directory.

[CRYPTOAdmin]

Host=127.0.0.1

Operator=Admin

Password=somepassword

Timeout=30

EncryptionKey=1234567890ABCDEF

Autoconnect=30



15.2.3 Configuring CRYPTOAdmin

The CRYPTOAdmin SPT server must be configured to allow authentication requests from the Funk Steel Belted RADIUS server. Use the CRYPTOAdmin Server Configuration utility to set the IP address of Funk SBR and packet encryption key that will be used. See Section 7.2.3 for information on this utility.

15.2.4 Configuring Funk Steel Belted RADIUS

Once the CRYPTOAgent for Funk Steel-Belted RADIUS has been installed, and Funk Steel-Belted RADIUS is able to connect with the CRYPTOAdmin SPT server, CRYPTOCard authentication must be enabled within Funk Steel-Belted RADIUS.

15.2.5 Configuring RADIUS Authentication

There is no need to add users to the Steel-Belted Radius database. To get Funk Steel-Belted RADIUS to apply check-list / return-list attributes to a CRYPTOCard user, or group of users, create a profile with the necessary attributes in Funk Steel-Belted RADIUS.



Add CRYPTOCard tokens to a group of the same name in CRYPTOAdmin.

NOTE: If a user is located in a CRYPTOAdmin group then a profile with the same name must exist in Steel Belted Radius for the user to successfully authenticate.

15.2.6 Enabling CRYPTOCard authentication

Select the Configuration radio button in the Funk Steel-Belted RADIUS Administrator.

From the Authentication methods (in order) box, select the CRYPTOCard Token setting, and click the Activate button.

Arrange the order that the authentication methods will be tried using the up and down arrow buttons. CRYPTOCard Token should be the last active authentication method in the list.

Click the Save button to apply the settings.

At this point you can create a test token user in CRYPTOAdmin and attempt to authenticate through the NAS device.

15.2.7 Troubleshooting Tips

CRYPTOCard.aut file

When Funk Steel-Belted Radius communicates with the CRYPTOAdmin SPT server, it uses the settings found in the cryptocard.aut file located in the SBR service directory. The example below is the minimal amount of information required in this file:

On Windows: ; CRYPTOAdmin plugin for Funk SBR [Bootstrap] LibraryName=C:\Program Files\CRYPTOCard\CRYPTOAdmin\Server\cryptocard.dll Enable=1 InitializationString=CRYPTOCard Token



[Authentication] ChallengePrompt=CRYPTOCard Challenge ChallengeSeparator=0 RespnosePrompt=Enter Response: ResponseSeparator=1 [CRYPTOAdmin] Host=127.0.0.1 Operator=Admin Password=cryptoadmin Timeout=30 Encryptionkey=1234567890ABCDEF

On Solaris: [Bootstrap] LibraryName=libcryptocard.so Enable=1 InitializationString=CRYPTOCard Token [Authentication] ChallengePrompt=CRYPTOCard Challenge ChallengeSeparator=0 RespnosePrompt=Enter Response: ResponseSeparator=1 [CRYPTOAdmin] Host=127.0.0.1 Operator=Admin Password=cryptoadmin Timeout=30 Encryptionkey=1234567890ABCDEF

Autoconnect=30

In this example, the CRYPTOAdmin SPT server is on the same host as the Steel-Belted Radius server, the Administrator password for the CRYPTOAdmin SPT server is “cryptoadmin” and the Packet Encryption Key is “1234567890ABCDEF”.

Note: The Packet Encryption Key is case sensitive. The order of each configuration block will vary, a specific order is not needed.

15.3 Microsoft IAS RADIUS on Windows 2000 sp2

This section deals primarily with the configuration of IAS for use with a RADIUS client and CRYPTOAdmin Server. For more in-depth information on IAS please visit http://www.microsoft.com.


http://www.microsoft.com/


Run the CRYPTOCard Authentication Agent for IAS found in the /Authentication Agents folder of the CRYPTOAdmin Server distribution.

15.3.1 Configure IAS

Go to the Control Pane|Administrative Tools|Internet Authentication Service.

In order to allow IAS to authenticate users, the incoming NAS device must be part of it’s clients list. In the Internet Authentication Service management console right click on clients and choose new client.

Enter the name of the NAS client then click Next.

Enter the NAS IP Address and it’s shared secret.

Once the NAS client has been entered select Remote Access Policies. Select “Grant remote access permission”



Next click the Edit Profile button.

Click on the Encryption tab and add “No Encryption” to the levels of encryption.



Click on the Authentication tab and select “Unencrypted Authentication (PAP,SPAP)”

The CRYPTOAdmin server must be configured to allow authentication requests from an IAS server. Use the CRYPTOAdmin Server Configuration utility to set the IP address of Funk SBR and packet encryption key that will be used. See Section 7.2.3 for information on this

utility.



Restart the CRYPTOAdmin server for the settings to take effect.

15.3.2 IAS Troubleshooting Tips

15.3.3 Changing the default RADIUS port in IAS

By default IAS uses RADIUS port 1645 and 1812 for authentication and 1646 and 1813 for accounting.

If you need to adjust the Authentication and/or Accounting port right click on Internet Authentication Service and choose Properties. In the RADIUS tab you can change the Authentication and Accounting ports.

15.3.4 Logging rejected, discarded or successful authentication attempts

In order to log connection events in IAS right click on Internet Authentication Service and choose Properties. On the Service tab place a checkmark on the preferred logging level.



15.3.5 Customizing IAS Logs

The log settings can be adjusted in IAS. In the Remote Access Logging section of the management console, right click Local File and choose Properties. In the Settings and Local File tab adjust the logging levels.

15.3.6 Starting the CRYPTOAdmin server in debug mode

On Windows from a DOS prompt go to: \Program Files\CRYPTOCard\CRYPTOAdmin\Server directory and type:



cadmind –l stdout

On Linux from a console window type:

/etc/rc.d/init.d/cadmind start debug

On Solaris from a console window type:

/etc/init.d/cadmind start debug



16. PAM for Linux and Solaris

This section deals primarily with the installation of the CRYPTOCard PAM modules. For more in-depth information on PAM configuration and a description of other modules please visit

http://www.us.kernel.org/pub/linux/libs/pam/

The Linux PAM modules are located in: /lib/security

The Linux application-specific configuration files are located in: /etc/pam.d

The Solaris PAM modules are located in: /usr/lib/security

The Solaris application-specific configuration files are located in: /etc/pam.conf

Each application-specific configuration file grants some service to users. The most common configuration files are login, ftp, su and ppp.

An application must be PAM-aware in order to use a PAM module. Please consult the application’s documentation to determine if it is PAM-aware.

16.1 Compiling the PAM module

Login as root. Expand the package to a temporary location then enter the CRYPTOCard PAM module source directory. In order to compile the module for your system type:

make

On Linux copy pam_radius_auth.so to /lib/security as pam_radius_auth.so:

cp pam_radius_auth.so /lib/security/pam_radius_auth.so

On Solaris copy pam_radius_auth.so to /usr/lib/security as pam_radius_auth.so.1

cp pam_radius_auth.so /usr/lib/security/pam_radius_auth.so.1

(If you receive any errors while compiling please see the Troubleshooting Section)

16.2 Server Configuration File (RADIUS)

When the CRYPTOCard PAM module is used it searches for a file called server in the /etc/raddb directory.


http://www.us.kernel.org/pub/linux/libs/pam/


This file contains the location of the RADIUS servers, the shared secret and the order in which each RADIUS server will be checked. A generic server configuration file called pam_radius_auth.conf can be found in the CRYPTOCard PAM module source directory.

This file must be renamed and placed into the /etc/raddb directory.

First, we need to make sure the directory exists, type:

ls /etc/rad*

If you see /etc/raddb, the directory exists. If not, type:

mkdir /etc/raddb

Now, copy the generic server configuration file over to the /etc/raddb directory by going into the CRYPTOCard PAM module source directory and typing:

mv pam_radius_auth.conf /etc/raddb/server

Below is an example of the server configuration file.

Blank lines or lines beginning with # are considered as comments or simply ignored.

# pam_radius_auth configuration file. Save as: /etc/raddb/server

#

# server[:port] shared_secret timeout (s)

127.0.0.1 testing123 1

other-server other-secret 3

# having localhost in your radius configuration is a Good Thing

#

# See the INSTALL file for pam.conf hints

#

The columns are as follows:

Server[:port] shared_secret timeout (default 3 seconds)

The timeout field controls the time the module waits before deciding if the server has failed to respond. This setting is optional. If multiple RADIUS Server lines exist, they are tried in order. If the server fails to respond, it is skipped and the next server is used.



Note: The port number or name is optional. Official radius port numbers 1812 or 1645.

Check your /etc/services file to determine the radius port you are using.

16.3 Securing the RADIUS Server Configuration

Once the server file is completed it MUST be secured in order to prevent tampering. The following procedure will secure the server file.

chown root /etc/raddb/

chmod go-rwx /etc/raddb

chmod go-rwx /etc/raddb/server

16.4 Configuring application-specific configuration files

The last step in setting up the CRYPTOCard PAM module is to configure the PAM-aware application you would like to implement. All the applications listed in the /etc/pam.d directory are PAM-aware. CRYPTOCard only offers support for login/telnet ftp and ssh. In theory the CRYPTOCard module will work for any application in the pam.d directory.

In the text editor of your choice, open the configuration file of the PAM-aware application you would like to configure with radius support.

The specific configuration file must have the following line added BEFORE any PAM module entries:

auth sufficient /lib/security/pam_radius_auth.so skip_passwd

(To see a complete listing of PAM module types, control flags and arguments please see the Troubleshooting section).

16.5 Solaris -Configuring the pam.conf file

The last step in setting up the CRYPTOCard PAM module on Solaris is to configure the PAM aware application. All the applications listed in the /etc/pam.conf file are PAM aware.



CRYPTOCard only offers support for login, su, ftp, ssh and telnet. In theory the CRYPTOCard module will work for any application in pam.conf.

The following line needs to be added:

service auth sufficient /lib/security/pam_radius_auth.so.1 skip_passwd

If a service in the pam.conf file contains the line:

service auth required /lib/security/pam_unix_auth.so.1

The CRYPTOCard PAM modules must be BEFORE the entry.

Example:

telnet auth sufficient /lib/security/pam_radius_auth.so.1 skip_passwd telnet auth required /lib/security/pam_unix_auth.so.1

(To see a complete listing of PAM module types, control flags and arguments please see the Troubleshooting section).

16.5.1 Solaris – Example pam.conf file

# PAM configuration

# Authentication management

# CRYPTOCard PAM Module Entry for login

login auth sufficient /usr/lib/security/pam_radius_auth.so.1 skip_passwd login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1

#

#CRYPTOCard PAM Module Entry for telnet

telnet auth sufficient /usr/lib/security/pam_radius_auth.so.1 skip_passwd telnet auth required /usr/lib/security/pam_unix.so.1 #

# CRYPTOCard PAM Module Entry for OpenSSH

sshd auth sufficient /usr/lib/security/pam_radius_auth.so.1 sshd auth required /usr/lib/security/pam_unix.so.1 sshd account required /usr/lib/security/pam_unix.so.1

#CRYPTOCard PAM Module Entry for F-Secure

sshd2 auth sufficient /usr/lib/security/pam_radius_auth.so.1 sshd2 auth required /usr/lib/security/pam_unix.so debug



sshd2 account required /usr/lib/security/pam_unix.so debug sshd2 password required /usr/lib/security/pam_unix.so debug sshd2 session required /usr/lib/security/pam_unix.so debug rlogin auth sufficient /usr/lib/security/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/pam_unix.so.1 # dtlogin auth required /usr/lib/security/pam_unix.so.1 # rsh auth required /usr/lib/security/pam_rhosts_auth.so.1 other auth required /usr/lib/security/pam_unix.so.1 # Account management # login account requisite /usr/lib/security/pam_roles.so.1 login account required /usr/lib/security/ pam_projects.so.1 login account required /usr/lib/security/ pam_unix.so.1 # dtlogin account requisite /usr/lib/security/ pam_roles.so.1 dtlogin account required /usr/lib/security/ pam_projects.so.1 dtlogin account required /usr/lib/security/ pam_unix.so.1 # other account requisite /usr/lib/security/ pam_roles.so.1 other account required /usr/lib/security/ pam_projects.so.1 other account required /usr/lib/security/ pam_unix.so.1 # # Session management other session required /usr/lib/security/ pam_unix.so.1 # Password management other password required /usr/lib/security/ pam_unix.so.1 dtsession auth required /usr/lib/security/ pam_unix.so.1

16.6 Linux - CRYPTOCard PAM for Configuration Examples

The following examples are for several known PAM aware applications.

16.6.1 Login\Telnet

#%PAM-1.0

auth required /lib/security/pam_securetty.so

#CRYPTOCard PAM module

auth sufficient /lib/security/pam_radius_auth.so skip_passwd auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_pwdb.so



password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so nullok use_authtok md5 shadow session required /lib/security/pam_pwdb.so session optional /lib/security/pam_console.so

16.6.2 FTP

#%PAM-1.0

auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed


auth sufficient /lib/security/pam_radius_auth.so auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_shells.so account required /lib/security/pam_pwdb.so session required /lib/security/pam_pwdb.so

16.6.3 SSHD (OpenSSH)

For security reasons and compatibility with the CRYPTOcard PAM module you must have at least SSH2 version 2.4 for F-Secure or SSH2 version 2.9 for OpenSSH.

#%PAM-1.0 #CRYPTOCard PAM module

auth sufficient /lib/security/pam_radius_auth.so auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so shadow use_authtok nullok session required /lib/security/pam_pwdb.so

16.6.4 PPP

#%PAM-1.0

auth required /lib/security/pam_nologin.so


auth sufficient /lib/security/pam_radius_auth.so auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so session required /lib/security/pam_pwdb.so



16.7 Troubleshooting

16.7.1 Authentication problems.

If you are experiencing continuous authentication failure try running the services from the console. Shutdown CRYPTOAdmin and easyRADIUS using:

On Linux:

/etc/rc.d/init.d/cadmind stop

/etc/rc.d/init.d/radiusd stop

Then restart using the debug option

/etc/rc.d/init.d/cadmind start debug

/etc/rc.d/init.d/radiusd start debug

On Solaris:

/etc/init.d/cadmind stop

/etc/init.d/radiusd stop

Then restart using the debug option

/etc/init.d/cadmind start debug

/etc/init.d/radiusd start debug

This will force all output to the console. You should be able to see in real-time all activity coming through the server. You may also want to check the log files (On Linux: /var/log). If you are not using easyRADIUS, check the log files of your Third Party RADIUS server.

16.7.2 Compiling the modules returns an error.

While compiling If you receive a make error, you'll have to edit the Makefile to remove the GNU make directives 'ifeq', 'else', etc. You may want to consider getting a more recent version of GNUmake.



16.7.3 The RADIUS server does not even see the requests

Check the /etc/raddb/server file. Make sure that the ip address; port and secret are set up the same as the port and secret between CRYPTOAdmin and you RADIUS Server.

16.7.4 SSH and Challenge Response

For security reasons and compatibility with the CRYPTOcard PAM module you must have at least SSH2 version 2.4+ for F-Secure or version 2.5.2+ for OpenSSH.

For Linux: Make the following adjustment in the sshd or sshd2 application configuration file in the /etc/pam.d directory.

Auth sufficient/lib/security/pam_radius_auth.so skip_passwd

For Solaris: Make the following adjustment in the pam.conf file

For OpenSSH

sshd auth sufficient /usr/lib/security/pam_radius_auth.so.1 skip_passwd

For F-Secure:

sshd2 auth sufficient /usr/lib/security/pam_radius_auth.so.1 skip_passwd

For Linux and Solaris for OpenSSH make the following adjustments to the sshd_config file:

PasswordAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication yes

PAMAuthenticationViaKbdInt yes

For Linux and Solaris for F-Secure make the following adjustments to the sshd2_config file:

PermitEmptyPasswords no

AllowedAuthentications [email protected],publickey,password

SshPAMClientPath {Path to the ssh-pam-client file}

AllowedAuthentications [email protected],publickey,password


mailto:[email protected],publickey,password


16.7.5 Linux PAM, PPPD and Radius

This section assumes you already have Linux setup as a dialup server. For information on how to setup a Linux dialup server, please read the PPP-HOWTO.

In order to get PAM, PPPD, RADIUS up and running you must make the following configuration changes:

In the /etc/ppp/options you must at least have

+pap

-chap

lock

asyncmap 0

crtscts

modem

debug

kdebug 7

login

Do not include the “auth” argument in the options file

In the /etc/mgetty+sendmail/login.config file make the following adjustments:

/AutoPPP/ - a_ppp /usr/sbin/pppd file /etc/ppp/options

* - - /bin/login @

#* - - /usr/sbin/pppd @

In the /etc/pam.d/ppp file add:

auth sufficient /lib/security/pam_radius_auth.so

Download the latest RADIUS PAM module from

http://www.freeradius.org/pam_radius_auth/

The freeRADIUS PAM module will only function for PPP and CRYPTOAdmin. Challenge response for PPP is not supported.


http://www.freeradius.org/pam_radius_auth/


16.8 PAM module types, control flags and arguments

(This information was gathered from the PAM Administrators Guide. It can be found online at http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html or in the Solaris Man Pages)

A general configuration line has the following form:

module-type control-flag module-path arguments

Module-type: One of (currently) four types of module. The four types are as follows:

Auth: This module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership (independently of the /etc/groups file discussed above) or other privileges through its credential granting properties.

Account: This module performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user---`root' login only on the console.

Session: Primarily, this module is associated with doing things that need to be done for the user before/after they can be given service. Such things include the logging of information concerning the opening/closing of some data exchange with a user, mounting directories, etc.

Password: This last module type is required for updating the authentication token associated with the user. Typically, there is one module for each `challenge/response' based authentication (auth) module-type.

Control flags: The control-flag is used to indicate how the Linux-PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module.

Required: This indicates that the success of the module is required for the module-type facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.

Requisite: Like required, however, in the case that such a module returns a failure, control is directly returned to the application. The return value is that associated with the first


http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html


required or requisite module to fail. Note, this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.

Sufficient: The success of this module is deemed `sufficient' to satisfy the PAM library that this module-type has succeeded in its purpose. In the event that no previous required module has failed, no more `stacked' modules of this type are invoked. (Note, in this case subsequent required modules are not invoked.). A failure of this module is not deemed as fatal to satisfying the application that this module-type has succeeded.

Optional: As its name suggests, this control-flag marks the module as not being critical to the success or failure of the user's application for service. In general, Linux-PAM ignores such a module when determining if the module stack will succeed or fail. However, in the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application. One example of this latter case is when the other modules return something like PAM IGNORE.

Arguments: Not all of these options are relevant for all uses of the module.

use_first_pass: Instead of prompting the user for a password, retrieve the password from the previous authentication module. If the password does not exist, return failure. If the password exists, try it, returning success/failure as appropriate.

try_first_pass: Instead of prompting the user for a password, retrieve the password from the previous authentication module. If the password exists, try it, and return success if it passes. If there was no previous password, or the previous password fails authentication, prompt the user with "Enter RADIUS password: ", and ask for another password. Try this password, and return success/failure as appropriate. This is the default for authentication.

skip_passwd: Do not prompt for a password, even if there was none retrieved from the previous layer. Send the previous one (if it exists), or else send a NULL password. If this fails, exit. If an Access-Challenge is returned, display the challenge message, and ask the user for the response. Return success/failure as appropriate. The password sent to the next authentication module will NOT be the response to the challenge. If a password from a previous authentication module exists, it is passed on. Otherwise, no password is sent to the next module.

conf=foo: Set the configuration filename to 'foo'. Default is /etc/raddb/server



client_id=bar: Send a NAS-Identifier RADIUS attribute with string 'bar'. If the client_id is not specified, the PAM_SERVICE type is used instead. ('login', 'su', 'passwd', etc.) This feature may be disabled by using 'client_id='. i.e. A blank client ID.

use_authtok: Force the use of a previously entered password. This is needed for pluggable password strength checking i.e. try cracklib to be sure it's secure, then go update the RADIUS server.

accounting_bug: When used, the accounting response vector is NOT validated. This option will probably only be necessary on old (i.e. Livingston 1.16) servers.

16.9 Linux - Example and description of an application configuration file

Login\Telnet

#%PAM-1.0

auth required /lib/security/pam_securetty.so

#CRYPTOCARD PAM module

auth sufficient /lib/security/pam_radius_auth.so skip_passwd

auth required /lib/security/pam_pwdb.so try_first_pass shadow nullok

auth required /lib/security/pam_nologin.so

account required /lib/security/pam_pwdb.so

password required /lib/security/pam_cracklib.so

password required /lib/security/pam_pwdb.so nullok use_authtok md5 shadow

session required /lib/security/pam_pwdb.so

session optional /lib/security/pam_console.so

The first line allows root to log in from certain areas. All other users are ignored by it. (By default root cannot telnet or ftp into a system).

The second line asks the user for their CRYPTOCard password. It then checks with the RADIUS server, if this passes the user is given a token. Since this is flagged as sufficient, if the user’s password works, PAM skips down to the 5th line, if not PAM moved down to the next line.



The third line takes the password that was supplied in line two and runs it's checks on it. If it passes, then it gives it's ok. If the password doesn't pass (or in the case of root, one wasn't asked for) then the module asks the user for a password. It then runs this new password through it's tests.

The fourth line checks to see if the nologin file exists. If it does, then only root is allowed to login. This is for letting root do maintenance without having to remain in single user mode.

The fifth line checks the status of the users account. It might do anything from warn them that their password is about to expire, not let them in if their account has expires, or simply be silent and let the user in.

The sixth line does a password check and tells the user if their password isn't very good.

The seventh line updates any password authentication associated with that user.

The eighth line simply logs the username and service-type to syslog.

The ninth line authorizes any console programs. As you can see this is optional and won't stop anything, though it does send out a warning if it doesn't pass.



17. Diagnostic Tools

17.1 Radtest

Radtest is a command line tool used to test the authentication process by generating authentication requests to through a RADIUS server to the CRYPTOAdmin Server. Radtest is located in the default CRYPTOAdmin Server directory.

Type Radtest.exe to review the command syntax.

17.2 RADIUS_Test

Radius_Test is a GUI tool used to test the authentication process by generating authentication requests to through a RADIUS server to the CRYPTOAdmin Server. Radius_Test is located in the Tools folder on the CRYPTOAdmin Distribution.



18. Troubleshooting

This section is specifically intended to provide information relevant to helpdesk roles. Situations in which the helpdesk may be called on to provide support to an End-user include cases where a token has fallen out of sync with the server, the End-user has lost the token, become locked out, or has forgotten their PIN, or the battery power for the token has run low.

18.1 Token Resynchronization

When a token has been stepped through many passwords without using the passwords to authenticate to the CRYPTOAdmin Server, the token and server may get out of sync.

The number of times that a token must be stepped ahead before it becomes out of sync with the server depends on the size of the synchronization window configured on the server.

There are two simple methods for resynchronization at token:

18.1.1 Web Based Resynchronization:

Users may resynchronize their tokens by accessing a resynchronization page on a CRYPTOWeb enabled IIS server set up for this purpose by your organization. The server will present the user with a synchronization challenge that they will key into their token, completing the resynchronization process. This process is secure because the synchronization challenge is specific for each End-user and changes with each resynchronization.

18.1.2 Help Desk Resynchronization:

The End-user calls the help desk and identifies themselves with their logon ID. The Help Desk uses the “Test” function to generate a resynchronization challenge that the End-user keys into their token. As with the Web based method, the resynchronization challenge will only work for the End-user’s token and changes with each resynchronization. There is no need for the Help Desk to identify the End-user beyond their logon ID and at no time does the help desk provide a password.

Lost Tokens

If a token is lost or forgotten, the help desk (with appropriate permissions) can generate a replacement token. Depending on your security policy, the Help Desk can also provide a list of One time passwords (typically 10) that can be used in sequence until the replacement



token is received by the End-user. This method has the advantage of preventing the use of the lost token until returned to the Administrator for reprogramming.

18.1.3 Battery Replacement:

Typically CRYPTOCard tokens will operate for approximately 5-6 years before battery replacement is required. Depending on the model, the token display will either indicate a low battery condition about 2 months before failing, or the display will grow noticeably dim.

Every CRYPTOCard hardware token holds 2 coin-cell batteries. Replacement of one battery at a time will permit the token to continue functioning. As long as only one battery at a time is removed and replaced, the token will not need to be returned to the Administrator for reprogramming.

18.1.4 RB-1 / KT-1 Battery Replacement

1.

2.

3.

Remove battery compartment cover

Remove one battery and replace it with a new battery (CR2016)

Remove other battery and replace it.

18.2 CRYPTOAdmin Server will not authenticate after upgrading.

If CRYPTOAdmin server services start after upgrading (either from a previous version of CRYPTOAdmin or from the evaluation version) but the server will not process authentication request, it is likely that the server license has been exceeded. This is caused by a mismatch between the license and the quantity and/or type of tokens in the database. CRYPTOCard licensing is token-specific.

The CRYPTOAdmin client will display an error message if the license expired, if there are more tokens in the database than the license allows, or if the CRYPTOAdmin server is unable to connect to the database.

The only way of having too many tokens in the database is if an import has been done from another database, or if the existing license is removed, and replaced with a more restrictive one. The CRYPTOAdmin client will not allow Operators to add more tokens than the server is licensed for.



Licensing information is recorded in the CRYPTOAdmin log file each time the CRYPTOAdmin service start:

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:222) 901105: License information:

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:228) 901108: License will expire in approximately 38 days.

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:230) 901109: Licensed RB-1 tokens: 5.

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:231) 901110: Licensed KT-1 tokens: 10.

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:232) 901111: Licensed ST-1 tokens: 5.

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:233) 901112: Licensed PT-1 tokens: 5.

22Mar2001 08:10:31 Notice cadmind[1280:1276] (JLicense.c:234) 901113: Licensed SC-1 tokens: 0.

When the CRYPTOAdmin log file reports license problems, ensure that the RDBMS is running, and that the CRYPTOAdmin server is able to access the token database. If so, contact CRYPTOCard regarding upgrading the server license or removing tokens from the database.

18.3 CRYPTOAdmin Client cannot connect to the server

If the CRYPTOAdmin Client is unable to connect to the server it is likely due to a change in the network or the server configuration, such as changes to the IP address of the Server or Client. This can occur if the server configuration has changed, and those changes have not been applied to the client configuration.

When experiencing problems logging in to the CRYPTOAdmin server from the GUI client, make sure the Packet Encryption Key, the username, and the password are correct and match at both the Server and Client.

If connection problems occur when using the command-line client, ensure that the [cadmin client] block in the “cryptocard.cfg” file of the Client match the settings for the Server.

1. Attempt to ping the server from the client machine. This should verify that the client and server machines are able to communicate. If the ping attempt fails, there may be a problem with the network connection between the client and server.

2. Make sure the server is running. Try connecting to the server using the client locally.



3. Make sure the client machine is listed in the “peers” file. If it is not, run the server configuration utility to add the client to the list of machines that are allowed to connect to the server.

4. Make sure the Operator account being used to connect to the server is valid. Confirm that you can connect to the server locally with the client, using the same Operator name and password.

Make sure the packet encryption key match between the client and the server. Check the entry for that client machine in the “peers” file.

18.4 End User Login failures

When the End-user is unable to login successfully, there are several possible points of failure, anywhere from the End-user entering improper login information to a failure in the NAS, the RADIUS server, or the CRYPTOAdmin server. This section is intended to help determine the point of failure when the End-user has trouble logging in, so that troubleshooting efforts may be focused in that area.

In each case, the CRYPTOAdmin log files can be used to help determine the point of failure.

18.4.1 Incorrect username

The CRYPTOAdmin server will fail the login attempt when the End-user enters a username that does not exist in the token database.

Login attempts with usernames that do not exist in the CRYPTOAdmin database are not logged. Therefore, the log file will only show an incoming connection from the RADIUS server.

18.4.2 Incorrect password

The CRYPTOAdmin server will also fail login attempts if End-users do not enter the correct password.

When the CRYPTOAdmin server receives a login attempt from a valid user, it will generate the challenge for that user. Whether or not the token is configured for challenge-response mode, the CRYPTOAdmin log files will show that challenge:

26-Apr-2001 13:07:14 n cadmind[884:2032] 108194: Challenge user 'phil' with '34783785' (session Id=0)

If the End-user has entered the wrong password, the RADIUS server will send a failed response message to the NAS.



18.4.3 Correct password

If the End-user enters the correct username and password, the CRYPTOAdmin server will log a message including the username, challenge and response used:

26-Apr-2001 13:15:08 * cadmind[520:2072] 108198: Check response of '119-5124' for user 'phil' successful (session Id=0, challenge=34783785)

If the End-user reports consistent login failures, but the CRYPTOAdmin log files show that they have passed the CRYPTOCard authentication process, then the failure is occurring after the authentication has succeeded.

18.4.4 Authentication failure

If the token passes the internal test, then there is a failure somewhere between the End-user and the CRYPTOAdmin server. Watch the CRYPTOAdmin log files to determine if the proper authentication information is getting through to the CRYPTOAdmin server, and troubleshoot accordingly.

If no authentication attempt is getting through to the CRYPTOAdmin server, check the RADIUS server, the RADIUS client(s), and the remote client, to see where the failure occurs.

Information required by CRYPTOCard Technical Support

When a support issue occurs, the Technical Support Representatives at CRYPTOCard will require the following information and files:

Server License Number (Fx-xxxx.lic)

cryptocard.cfg, peers, Operator, passwd, groups, cadmind-mmmdd.log, ccauthen-mmmdd.log, radius-mmmdd.log (if using easyRADIUS only)

18.4.5 Log files

Most RADIUS servers have reporting abilities and the CRYPTOAdmin server has the ability to store log files.

Often these products will allow you to decide how much logging information is recorded for events.

18.4.6 Logging level



It is always best to have the highest level of detail in the logs when trying to determine the cause of a problem.

To set the logging level in CRYPTOAdmin, edit the cryptocard.cfg file. The cryptocard.cfg file is in the \WinNT directory in Windows, and in the /etc/cryptocard directory in Unix/Linux. This file may contain several [Logging] blocks. For maximum logging, set the logging block for “cadmind” to the following:

[Logging]

SourceName = cadmind

Destination = cadmind-%b%d.log

Date = %d%b%Y %H:%M:%S

Level = all res secure errno debug idebug trace emerg

[Logging]

SourceName = ccauthen

Destination = ccauthen-%b%d.log

Date = %d%b%Y %H:%M:%S

Level = all res secure errno debug idebug trace emerg

Restart both CRYPTOAdmin and the RADIUS server after changing their configuration, to ensure that the changes are implemented.

18.4.7 Location

The location for log files is specified in the [Logging] blocks of the cryptocard.cfg file.

By default the CRYPTOAdmin log files are stored in the /var/log directory in Unix/Linux, and in the CRYPTOCard\CRYPTOAdmin\Server directory, under the installation directory, in Windows.



19. Ordering additional CRYPTOCard Products

CRYPTOCard SPT products can be ordered directly from CRYPTOCard or through your local authorized CRYPTOCard SPT Security Partner. The following is a list of product codes and recommended ordering procedures:

Product Code

Description

ST-1 Software token

SC-1-U Smart Card token including 32k smart card, USB reader/writer

SC-1-P Smart Card token including smart card and PCCard (PCMCIA) reader/writer

RB-1 Hard Token

KT-1 Key Chain Token

RBI Token Initializer

KTI Token Initializer

Orders may be placed by:

Email to: [email protected]

Fax: +1-613-599-2442

Voice: +1-613-599-2441 (ask for sales)

Mail: CRYPTOCard

300 March Road, Suite 304, Kanata, Ontario. K2K 2E2 Canada

Include CRYPTOAdmin Server Full License number on all orders.

Include the Administrator email address for delivery of CRYPTOAdmin Server, ST-1 Software Token and SC-1 Smart Card Token licenses.



Documents

CRYPTOAdmin SPT Authentication Server v5.32 …portal.cryptocard.com/documentation/TechDocs/CRYPTOAdminV532.pdf · 2.1 Administration: ... 16.5 Solaris -Configuring the pam.conf file