SafeWord PremierAccess Administration Guide version - SafeNet

Administration Guide

SafeWord PremierAccess

www.safenet-inc.com4690 Millennium Drive, Belcamp, Maryland 21017 USATelephone: +1 410 931 7500 or 1 800 533 3958

©2010 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners.

Copyright© 2011 Aladdin Knowledge Systems Ltd. (“Aladdin”). All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without written permission from Aladdin.

TrademarksAladdin, SafeWord, PremierAccess, and RemoteAccess are trademarks of Aladdin. All other trademarks, tradenames, service marks, service names, product names, and images mentioned and/or used herein belong to their respective owners.

Software License AgreementThe following is a copy of the Software License Agreement as shown in the software:

CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE LOADING THE SOFTWARE. THIS AGREEMENT GOVERNS THE USE OF THE SOFTWARE (AS DEFINED BELOW). BY CLICKING “I ACCEPT” BELOW, OR BY INSTALLING, COPYING, OR OTHERWISE USING THE SOFTWARE, YOU ARE SIGNING THIS AGREEMENT, THEREBY BECOMING BOUND BY ITS TERMS. BY INDICATING YOUR AGREEMENT, YOU ALSO REPRESENT AND WARRANT THAT YOU ARE A DULY AUTHORIZED REPRESENTATIVE OF THE ENTITY THAT HAS PURCHASED THE SOFTWARE AND THAT YOU HAVE THE RIGHT AND AUTHORITY TO ENTER INTO THIS AGREEMENT ON THE ENTITY’S BEHALF. IF YOU DO NOT AGREE WITH THIS AGREEMENT, THEN CLICK “I DO NOT ACCEPT” BELOW OR DO NOT USE THE SOFTWARE AND RETURN ALL COPIES OF THE SOFTWARE AND DOCUMENTATION TO ALADDIN OR THE RESELLER FROM WHOM YOU OBTAINED THE SOFTWARE.

1. DEFINITIONS.

1.1 “Documentation” means the published user manuals, User Guide and any additional documentation that are made available for the Software.

1.2 “Software” means the machine-readable object-code version of Aladdin’s SafeWord software including any revisions, corrections, modifications, enhancements, updates and/or upgrades thereto that you may receive.

2. GRANT OF LICENSE. Aladdin grants to you, and you accept, a personal, nonexclusive, non-transferable and fully revocable limited license to use the Software, in executable form only, for a predefined set number of licensed users, as described in the Software accompanying Documentation and only according to the terms of this Agreement. Under no circumstances will you receive any source code of the Software. Aladdin also grants to you, and you accept, a non-exclusive, and non-transferable limited license to use the Documentation solely in conjunction with the Software.

3. LIMITATION OF USE. You may not: 1) copy the Software, except to make one copy of the Software solely for back-up or archival purposes; 2) transfer, distribute, rent, lease or sublicense all or any portion of the Software or Documentation to any third party; 3) translate, modify, adapt, decompile, disassemble, or reverse engineer any Software in whole or in part; 4) modify or prepare derivative works of the Software or the Documentation; or 5) use the Software to process the data of a third party; 6) place the Software onto a server so that it is accessible via a public network; and 7) use any back-up or archival copies of the Software (or allow someone else to use such copies) for any purpose other than to replace an original copy if it is destroyed or becomes defective. You agree to keep confidential and use your best efforts to prevent and protect the contents of the Software and Documentation from unauthorized disclosure or use. Aladdin reserves all rights that are not expressly granted to you. If you are a member of the European Union, this agreement does not affect your rights under any legislation implementing the EC Council Directive on the Legal Protection of Computer Programs. If you seek any information within the meaning of that Directive you should initially approach Aladdin.

4. DISCLAIMER OF WARRANTIES. Aladdin does not warrant that the functions contained in the Software will meet your requirements or that operation of the program will be uninterrupted or error-free. The entire risk as to the results and performance of the Software is assumed by you. THE SOFTWARE IS FURNISHED, “AS IS” WITHOUT ANY WARRANTY OF ANY KIND, AND ALADDIN AND ITS LICENSORS HEREBY DISCLAIM ALL WARRANTIES, EXPRESS, IMPLIED OR STATUTORY IN RESPECT OF THE SOFTWARE INCLUDING, WITHOUT LIMITATION, ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTIES AS TO NON-INFRINGEMENT. SOME STATES AND COUNTRIES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHER RIGHTS WHICH VARY BY STATE OR COUNTRY.

5. LIMITATION OF REMEDIES. ALADDIN’S AND ITS LICENSORS ENTIRE LIABILITY UNDER, FOR BREACH OF, OR ARISING OUT OF THIS AGREEMENT, IS LIMITED TO A REFUND OF THE PURCHASE PRICE OF THE SOFTWARE OR SERVICE THAT GAVE RISE TO THE CLAIM. IN NO EVENT SHALL ALADDIN OR ITS LICENSORS BE LIABLE FOR YOUR COST OF PROCURING SUBSTITUTE GOODS. IN NO EVENT WILL ALADDIN OR ITS LICENSORS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL, EXEMPLARY, OR OTHER DAMAGES INCLUDING, WITHOUT LIMITATION, ANY LOSS OR DAMAGE TO BUSINESS EARNINGS, LOST PROFITS OR GOODWILL AND LOST OR DAMAGED DATA OR DOCUMENTATION, SUFFERED BY ANY PERSON, ARISING FROM AND/OR RELATED

i

WITH AND/OR CONNECTED TO DELIVERY, INSTALLATION, USE OR PERFORMANCE OF THE SOFTWARE AND/OR ANY COMPONENT THEREOF, WHETHER OR NOT ALADDIN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.

6. TERM AND TERMINATION. This license is effective until terminated. You may terminate it at any time by destroying the Software, including all computer programs and Documentation, and erasing any copies residing on computer equipment. This Agreement also will automatically terminate if you do not comply with any terms or conditions of this Agreement. Upon such termination you agree to destroy the Software and Documentation and erase all copies of the Software residing on computer equipment.

7. PROTECTION OF CONFIDENTIAL INFORMATION. The Software and Documentation are delivered to you on a confidential basis and you are responsible for employing reasonable measures to prevent the unauthorized disclosure or use thereof, which measures shall not be less than those measures employed by you in protecting your own proprietary information. You may disclose the Software or Documentation to your employees as necessary for the use permitted under this Agreement. You shall not remove any trademark, trade name, copyright notice or other proprietary notice from the Software or Documentation.

8. OWNERSHIP. The Software and Documentation are licensed (not sold) to you. All intellectual property rights including trademarks, service marks, patents, copyrights, trade secrets, and other proprietary rights evidenced by or embodied in or attached/connected/related to the Software and Documentation are and will remain the property of Aladdin or its licensors, whether or not specifically recognized or protected under local law. This License Agreement does not convey to you an interest in or to the Software, but only a limited right of use revocable in accordance with the terms of this license agreement. Nothing in this Agreement constitutes a waiver of Aladdin’s intellectual property rights under any law. You will not remove any product identification, copyright notices, or other legends set forth on the Software or Documentation.

9. EXPORT RESTRICTIONS. You agree to comply with all applicable United States export control laws, and regulations, as from time to time amended, including without limitation, the laws and regulations administered by the United States Department of Commerce and the United States Department of State. You have been advised that the Software is subject to the U.S. Export Administration Regulations. You shall not export, import or transfer Software contrary to U.S. or other applicable laws, whether directly or indirectly, and will not cause, approve or otherwise facilitate others such as agents or any third parties in doing so. You represent and agree that neither the United States Department of Commerce nor any other federal agency has suspended, revoked or denied your export privileges. You agree not to use or transfer the Software for end use relating to any nuclear, chemical or biological weapons, or missile technology unless authorized by the U.S. Government by regulation or specific license.

10. U.S. GOVERNMENT RIGHTS. Any Software or Documentation acquired by or on behalf of a unit or agency of the United States Government is “commercial computer software” or “commercial computer software documentation” and, absent a written agreement to the contrary, the Government’s rights with respect to such Software or Documentation are limited by the terms of this Agreement, pursuant to FAR § 12.212(a) and its successor regulations and/or DFARS § 227.7202-1(a) and its successor regulations, as applicable.

11. ENTIRE AGREEMENT. This Agreement is our offer to license the Software and Documentation to you exclusively on the terms set forth in this Agreement, and is subject to the condition that you accept these terms in their entirety. If you have submitted (or hereafter submit) different, additional, or other alternative terms to Aladdin or any reseller or authorized dealer, whether through a purchase order or otherwise, we object to and reject those terms. Without limiting the generality of the foregoing, to the extent that you have submitted a purchase order for the Software, any shipment to you of the Software is not an acceptance of your purchase order, but rather is a counteroffer subject to your acceptance of this Agreement without any objections or modifications by you. To the extent that we are deemed to have formed a contract with you related to the Software prior to your acceptance of this Agreement, this Agreement shall govern and shall be deemed to be a modification of any prior terms in their entirety.

12. GENERAL. Any waiver of or modification to the terms of this Agreement will not be effective unless executed in writing and signed by Aladdin. If any provision of this Agreement is held to be unenforceable, in whole or in part, such holding shall not affect the validity of the other provisions of this Agreement. By entering into this Agreement, you agree to allow Aladdin to obtain current license information from the system or systems on which the Software is installed for the purpose of determining license renewal information. You may not assign this License Agreement or any associated transactions without the written consent of Aladdin. This Agreement shall be construed and governed in accordance with the laws of Israel (except for conflict of law provisions) and only the courts in Israel shall have jurisdiction in any conflict or dispute arising out of this Agreement. The application of the United Nations Convention of Contracts for the International Sale of Goods is expressly excluded. The failure of either party to enforce any rights granted hereunder or to take action against the other party in the event of any breach hereunder shall not be deemed a waiver by that party as to subsequent enforcement of rights or subsequent actions in the event of future breaches.

ii

Technical Support informationAladdin works closely with our reseller partners to offer the best worldwide Technical Support services. Your Aladdin reseller is the first line of support when you have questions about products and services; however, if you require additional assistance, contact us directly.

• For all support related issues (product overview, training, downloads and documentation, and tech support contact information), see our Web page at: www.aladdin.com/sw-support.

• To use the Aladdin KnowledgeBase, go to www.aladdin.com/kb-sw. You will need to enter your Company ID to access knowledge base articles.

Publishing history

About SafeNet and Aladdin Knowledge Systems

In 2007, SafeNet was acquired by Vector Capital, a $2 billion private equity firm specializing in the technology sector. Vector Capital acquired Aladdin in March of 2009, and placed it under common management with SafeNet. Together, these global leading companies are the third largest information security company in the world, which brings to market integrated solutions required to solve customers’ increasing security challenges. SafeNet’s encryption technology solutions protect communications, intellectual property and digital identities for enterprises and government organizations. Aladdin’s software protection, licensing and authentication solutions protect companies’ information, assets and employees from piracy and fraud. Together, SafeNet and Aladdin have a combined history of more than 50 years of security expertise in more than 100 countries around the globe. Aladdin is expected to be fully integrated into SafeNet in the future. For more information, visit www.safenet-inc.com or www.aladdin.com.

Date Part number Software release

September 2004 SPOP-MN-ADMN32-A SafeWord PremierAccess, Version 3.2

June 2010 76-010182 SafeWord PremierAccess, Version 3.2.1.05

August 2011 76-010212 SafeWord PremierAccess, Version 3.2.1.06

iii

www.aladdin.com/kb-sw

www.aladdin.com

www.aladdin.com/sw-support

www.aladdin.com/kb-sw

http://www.safenet-inc.com/

http://www.aladdin.com/

iv

CONTENTS

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWelcome! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWho should read this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWhat is covered in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

CHAPTER 1 PremierAccess Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1An introduction to PremierAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2The AAA solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Understanding strong authentication . . . . . . . . . . . . . . . . . . . . . . . . .4Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Authenticating with tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Synchronous authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Asynchronous authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

SafeWord MobilePASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14MobilePASS software authenticators . . . . . . . . . . . . . . . . . . . . . . . . . .14SafeWord hardware tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Component overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16Supported agents overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21User privileges and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Privileged users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Unprivileged users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Administrative groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24Groups and subgroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24Types of groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

CHAPTER 2 Administration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Required administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Optional administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Strong authentication for a VPN connection . . . . . . . . . . . . . . . . . . .33Strong authentication for Web sites and their content . . . . . . . . . . .35Strong authentication to wireless LANs using tokens . . . . . . . . . . . .37Strong authentication using phones, pagers, and PDAs . . . . . . . . .39Using Cisco devices with PremierAccess . . . . . . . . . . . . . . . . . . . . .40

i

Table of Contents

CHAPTER 3 Basic System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Using the Admin Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Task bar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Starting the Admin Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Organizing authenticator files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Where to find the hardware programming files . . . . . . . . . . . . . . . . 45Importing the authenticator programming files . . . . . . . . . . . . . . . . . 45

Setting up and maintaining administrator accounts . . . . . . . . . . . . . . . 47Cloning the default system administrator account . . . . . . . . . . . . . . 47Creating a primary working account . . . . . . . . . . . . . . . . . . . . . . . . . 49Assigning roles to the primary working account . . . . . . . . . . . . . . . . 50Assigning a token to your primary working account . . . . . . . . . . . . . 50Testing your primary working account . . . . . . . . . . . . . . . . . . . . . . . 55Assigning a password to the default account . . . . . . . . . . . . . . . . . . 55

Other basic tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Finding entries in PremierAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Editing admin group properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

CHAPTER 4 Using the MobilePASS feature . . . . . . . . . . . . . . . . . . . . . . . 59Understanding MobilePASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Generating and importing MobilePASS software tokens . . . . . . . . . . 61Configuring MobilePASS policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Defining policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Duplicating policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Searching existing policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Editing existing policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Deleting policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Configuring MobilePASS features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Installing the MobilePASS Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configuring the user’s maximum MobilePASS tokens . . . . . . . . . . . 73Configuring the AllowAnyToken attribute . . . . . . . . . . . . . . . . . . . . . 73Using the device nickname feature . . . . . . . . . . . . . . . . . . . . . . . . . 75Allowing reenrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Retaining enrollment passphrases . . . . . . . . . . . . . . . . . . . . . . . . . . 79Configuring SoftPIN collection emulation . . . . . . . . . . . . . . . . . . . . . 80

Assigning software tokens to users . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Enrolling users with the Administration Console . . . . . . . . . . . . . . . 81Allowing users to self-enroll with the Enrollment Portal . . . . . . . . . . 85Verifying enrollment reservations . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Disabling the software token enrollment feature . . . . . . . . . . . . . . . 87Disabling software token manual enrollment . . . . . . . . . . . . . . . . . . 87

Software token enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Using the MobilePASS Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Changing and updating your admin server credentials . . . . . . . . . . 88Using the Enrollment Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

ii

Table of Contents

CHAPTER 5 Setting Up Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . .93Editing the PremierAccess configuration . . . . . . . . . . . . . . . . . . . . . . .94

Configuring General settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95Configuring the log server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97Configuring Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

Working with admin groups, ACLs and roles . . . . . . . . . . . . . . . . . . .100Creating admin groups and subgroups . . . . . . . . . . . . . . . . . . . . . .100Creating login ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101Understanding roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102Creating roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102Understanding login ACL entries . . . . . . . . . . . . . . . . . . . . . . . . . .104Creating login ACL entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104Editing ACL entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Ordering ACL entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Implementing your access control policy . . . . . . . . . . . . . . . . . . . . . .113Method 1 - Similar users grouped by role . . . . . . . . . . . . . . . . . . . .113Method 2 - Multi-role users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Understanding Web ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115Creating a Web ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116Passing personalization data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

CHAPTER 6 Managing User & Authenticator Information . . . . . . . . . . . .127Understanding users and access levels . . . . . . . . . . . . . . . . . . . . . . .128Adding and importing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128

Creating user accounts manually . . . . . . . . . . . . . . . . . . . . . . . . . .129Setting user privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Modifying personalization data . . . . . . . . . . . . . . . . . . . . . . . . . . . .139Adding unprivileged users with the user wizard . . . . . . . . . . . . . . .140

Adding, changing or removing authenticators . . . . . . . . . . . . . . . . . .144Adding or changing authenticator profiles . . . . . . . . . . . . . . . . . . . . .145

Fixed password profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145Digital certificate profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147Certificate verification policies . . . . . . . . . . . . . . . . . . . . . . . . . . . .150Enrolling digital certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152Revoking digital certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152Modifying hardware authenticator profiles . . . . . . . . . . . . . . . . . . .153

Assigning role(s) to multiple users . . . . . . . . . . . . . . . . . . . . . . . . . . .155Importing user records from a third-party user database . . . . . . . . . .157Deleting a user record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159Resetting a locked account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160Understanding personalization data . . . . . . . . . . . . . . . . . . . . . . . . . .161

Data elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161The data dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161Creating personalization data attributes . . . . . . . . . . . . . . . . . . . . .162Restricting the values of attributes . . . . . . . . . . . . . . . . . . . . . . . . .163Editing personalization data attributes . . . . . . . . . . . . . . . . . . . . . .164

iii

Table of Contents

Removing personalization data attributes . . . . . . . . . . . . . . . . . . . 164Personalizing your Web applications . . . . . . . . . . . . . . . . . . . . . . . . 165

HTTP header messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Personalization data: basic example . . . . . . . . . . . . . . . . . . . . . . . 168Personalization data: advanced example . . . . . . . . . . . . . . . . . . . 170

Session management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

CHAPTER 7 Monitoring PremierAccess Activity . . . . . . . . . . . . . . . . . . 175Understanding audit logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Querying audit logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Viewing specific entry details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Troubleshooting with the Audit Log Monitor . . . . . . . . . . . . . . . . . . . 180Invoking the Audit Log Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Choosing logs to monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Generating reports from the Admin Console . . . . . . . . . . . . . . . . . . . 182Creating reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Report templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Report worksheet generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Generating reports from the command line . . . . . . . . . . . . . . . . . . . . 186Using the command line reporting tool . . . . . . . . . . . . . . . . . . . . . . 187

Exporting data into Excel worksheets . . . . . . . . . . . . . . . . . . . . . . . . 188

CHAPTER 8 Maintaining PremierAccess . . . . . . . . . . . . . . . . . . . . . . . . . 189Understanding audit log archives . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Managing audit log archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Configuring the archival of audit logs . . . . . . . . . . . . . . . . . . . . . . . 192Using advanced archiving features . . . . . . . . . . . . . . . . . . . . . . . . 193

Replication and fault tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Ring topology architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194How replication works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Optimizing archiving, authentication, and replication performance . . 196Archiving during minimal activity periods . . . . . . . . . . . . . . . . . . . . 196Using multiple database connections . . . . . . . . . . . . . . . . . . . . . . . 197Running without an archive log master . . . . . . . . . . . . . . . . . . . . . 197

Backing up and restoring your user database . . . . . . . . . . . . . . . . . . 199Backing up your database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Restoring your database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Backing up your database using the command line . . . . . . . . . . . . 201

Repairing invalid entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Managing the Admin and AAA Server keys . . . . . . . . . . . . . . . . . . . 203

CHAPTER 9 Managing the PremierAccess RADIUS Server . . . . . . . . . . 205Overview of the PremierAccess RADIUS Server . . . . . . . . . . . . . . . 206

RADIUS protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206PremierAccess RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 206PremierAccess RADIUS Server features . . . . . . . . . . . . . . . . . . . . 207

iv

Table of Contents

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209PremierAccess RADIUS configuration files . . . . . . . . . . . . . . . . . . . .210Authorization and configuration groups . . . . . . . . . . . . . . . . . . . . . . .210

Creating an ACL entry and role for RADIUS . . . . . . . . . . . . . . . . .210Configuring the groups in the Users file . . . . . . . . . . . . . . . . . . . . .211Configuring the RADIUS proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . .212

Authenticators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214RADIUS-encrypted memorized passwords . . . . . . . . . . . . . . . . . .214Memorized passwords appended to usernames . . . . . . . . . . . . . .215RADIUS encrypted synchronous dynamic passcodes . . . . . . . . . .215Synchronous dynamic passcodes appended to usernames . . . . .216Shared tokens with memorized passwords . . . . . . . . . . . . . . . . . .216Asynchronous dynamic passcode authenticators . . . . . . . . . . . . . .217CHAP-authenticated transparent memorized passwords . . . . . . . .217CHAP-encoded encapsulated dynamic passwords . . . . . . . . . . . .218

Troubleshooting common problems . . . . . . . . . . . . . . . . . . . . . . . . . .219Check the radius.cfg configuration files . . . . . . . . . . . . . . . . . . . . .219The clients file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219The users file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219The dictionary file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219Launch the PremierAccess RADIUS Server in debug mode . . . . .220

Diagnostic traces during correct operation . . . . . . . . . . . . . . . . . . . . .222Authentication with a PremierAccess password . . . . . . . . . . . . . . .222Authentication with a simple synchronous authenticator . . . . . . . .225Authentication with an asynchronous authenticator . . . . . . . . . . . .228Authentication with a CHAP authenticator for “user_chap” . . . . . . .234

Diagnostic traces with incorrect configuration . . . . . . . . . . . . . . . . . .238radius.cfg missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238RADIUS secret incorrect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240Dictionary file problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243Users file problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247Sample Dictionary file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247Sample Users file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250Sample authfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

CHAPTER 10 Managing the RADIUS Accounting Server . . . . . . . . . . . . .255Understanding the RADIUS Accounting Server . . . . . . . . . . . . . . . . .256How the server works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256Configuring the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256Starting the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257

Example: Enabling accounting on Cisco router . . . . . . . . . . . . . . .257Sample accounting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257

CHAPTER 11 Managing the RADIUS Server for Ascend . . . . . . . . . . . . . .259PremierAccess interface to the Ascend RADIUS Server . . . . . . . . . .260

v

Table of Contents

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260References and additional resources . . . . . . . . . . . . . . . . . . . . . . . . 261

CHAPTER 12 Setting Up Web-based Enrollment . . . . . . . . . . . . . . . . . . . 263Understanding Web-based, user enrollment . . . . . . . . . . . . . . . . . . . 264Customizing enrollment configurations . . . . . . . . . . . . . . . . . . . . . . . 264

General tab settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Certificate tab settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Customizing enrollment forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Simple customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Intermediate customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Advanced customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Enrollment reservation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Sample enrollment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Creating enrollment reservations . . . . . . . . . . . . . . . . . . . . . . . . . . 269Using the reservation wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Passphrases and usernames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Importing users into a reservation . . . . . . . . . . . . . . . . . . . . . . . . . 281

Advanced Mode option features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Setting advanced mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Other enrollment tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Reviewing reservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Capturing the enrollment URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289What your end users see . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

User ChangePin feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Configuring the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298User instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

CHAPTER 13 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Common problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Where are the servers installed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308Troubleshooting the Enrollment Server . . . . . . . . . . . . . . . . . . . . . . . 309

Errors that occur during enrollment . . . . . . . . . . . . . . . . . . . . . . . . 310Problems starting Apache and the Servlet engine . . . . . . . . . . . . . 311Why Apache or the servlet engine might fail to start . . . . . . . . . . . 311

Problems connecting to the Admin Server . . . . . . . . . . . . . . . . . . . . 312Finding the Enrollment List HTML page . . . . . . . . . . . . . . . . . . . . . . 313

APPENDIX A PremierAccess in DoD PKI Environments. . . . . . . . . . . . . . 315Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Private keys and digital certificates . . . . . . . . . . . . . . . . . . . . . . . . 316Trust points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Installing DoD PKI trust points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316Removing non-DoD trust points . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Importing certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

vi

Table of Contents

Installing Uniform Resource Indicators for DoD PKI services . . . . . .317Using PremierAccess in DoD PKI environments . . . . . . . . . . . . . . . .317Protecting private keys from loss or compromise . . . . . . . . . . . . . . .318PKI User’s Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319

APPENDIX B Setting Up Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321Using the Password Checker plugin . . . . . . . . . . . . . . . . . . . . . . . . .322Using the Authentication Broker plugin . . . . . . . . . . . . . . . . . . . . . . .323

Broker requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324How the Authentication Broker works . . . . . . . . . . . . . . . . . . . . . . .324

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335

vii

Table of Contents

viii

PREFACE

Welcome! This section introduces the administration guide and contains the following sections:

• "Who should read this guide" on page ix

• "What is covered in this guide" on page x

Who should read this guide

This guide is intended for administrators, or others who are responsible for coordinating or managing the PremierAccess software on Solaris systems. You should also have a basic familiarity with networking concepts and understand general system administration.

ix

Preface

What is covered in this guide

This guide provides the information you will need to manage SafeWord® PremierAccess® on Solaris systems. It includes background information about the product components, and configuration instructions for setting up the software. Table 1 provides a brief description of the information contained in each chapter.

Table 1: Chapter summaries

Chapter Title Description

Chapter 1:PremierAccess Overview

Provides an overview of SafeWord® PremierAccess®.

Chapter 2:Administration Overview

Provides an overview of the administrative tasks associated with PremierAccess.

Chapter 3:Basic System Tasks

Provides detailed system task procedures.

Chapter 4:Using the MobilePASS feature

Provides detailed information related to the MobilePASS software token application.

Chapter 5:Setting Up Access Controls

Provides detailed procedures to customize PremierAccess.

Chapter 6:Managing User and Authenticator Information

Provides detailed procedures for setting up personalization data, adding and importing users, and other tasks in PremierAccess.

Chapter 7:Monitoring PremierAccess Activity

Describes how to monitor PremierAccess activity using its audit logs.

Chapter 8: Maintaining PremierAccess

Describes common PremierAccess maintenance tasks.

Chapter 9: Managing the PremierAccess RADIUS Server

Provides management information for the RADIUS Server.

Chapter 10: Managing the RADIUS Accounting Server

Provides management information for the RADIUS Accounting Server.

More...

x

Preface

Table 2 provides summary information about the other SafeWord documents, Software Development Kits, and the online help that are available for use with SafeWord PremierAccess.

Table 2: Summary of SafeWord PremierAccess documentation and SDKs

Chapter 11: Managing the RADIUS Server for Ascend

Provides management information for the RADIUS Server for Ascend.

Chapter 12: Setting Up Web-based Enrollment

Provides descriptions of the enrollment reservations process, which allows users to self-enroll via their Web browser.

Chapter 13: Troubleshooting

Provides troubleshooting and corrective action instructions for PremierAccess.

Appendix A:PremierAccess in DoD PKI Environments

Provides information about using PremierAccess within Department of Defense Public Key Infrastructure environments.

Appendix B:Setting Up Plugins

Provides information about the the Password Checker plugin and the Authentication Broker plugin.

Glossary Defines PremierAccess- and networking-related terminology.

Index Provides a cross-reference to important terms used in this guide.

Chapter Title Description

Document Description

PremierAccess Installation Guide for Solaris

Provides specific information for installing the SafeWord PremierAccess product on Solaris operating systems. This document is available as a PDF at SafeWord PremierAccess Install Guide. .

Authenticators Administration Guide

Describes the hardware tokens and software authenticators supported by SafeWord PremierAccess. This document is available as a PDF from the SafeWord PremierAccess Authenticators Admin Guide.

More...

xi

http://www3.safenet-inc.com/safeword/docs/swpa.aspx



Preface

Agent Administration Guide

Describes the individual software modules (agents) supported by SafeWord PremierAccess. This document is available as a PDF from the SafeWord PremierAccess Agent Admn Guide.

Card Programmer Software User Guide

Describes the Windows menu-driven software that allows you to program SafeWord hardware tokens. This document is available by request.

eToken Hardware Programmer Administrator’s Guide

Describes the Windows-based application that allows you to define and then program settings for eToken PASS and Gold authenticators. This document is available with the product shipment and by request.

Token Programmer Describes how to program the Alpine token. This document is available by request.

Online Help Comprehensive online help including search, index, and context sensitive help. Online help is available by clicking the Help button or the menu option from the Admin Console.

Latest information about PremierAccess and other SafeNet network security products

The SafeNet home page at www.safenet-inc.com

MobilePASS SDK Enables developers to embed MobilePASS functionality into a Java/J2ME application. The MobilePASS SDK is available at SafeWord PremierAccess MobilePASS SDK

SafeWord PremierAccess Administration SDK, version 3.2.1

Enables developers to integrate SafeWord PremierAccess administration functions into other administrative systems. The SafeWord PremierAccess Administration SDK is available at SafeWord PremierAccess Administration SDK

Document Description

xii


http://www3.safenet-inc.com/support/safeword/premier-access-authentication-sdk.aspx






1CHAPTER PremierAccess

Overview

In this chapter...

An introduction to PremierAccess ....................................................2

The AAA solution..............................................................................4

Authenticating with tokens..............................................................12

SafeWord MobilePASS ..................................................................14

MobilePASS software authenticators .............................................14

SafeWord hardware tokens............................................................15

Component overview......................................................................16

Supported agents overview............................................................21

User privileges and permissions ....................................................22

Administrative groups.....................................................................24

1

Chapter 1: PremierAccess OverviewAn introduction to PremierAccess

An introduction to PremierAccess

PremierAccess is strong authentication management software. It is fully customizable and works with your organization’s defined authentication policy to control network access for all of your users including internal users, remote dialup employees, customers and suppliers, and business partners. Users access only the resources you designate for them, through a variety of access points including the Web, a VPN, or remote dialup through RADIUS servers. Figure 1 shows a few of the user types and access methods that can be handled by PremierAccess.

Note: The information in this chapter is introductory in nature. If you are familiar with basic network security concepts, and you already have an understanding of PremierAccess, you may choose to skip ahead to the next chapter for specific administration overview information.

Figure 1: Examples ofuser types and access

methods

Windows Citrix Telnet/FTP IAS Browser

Dial in Web VPN

Remote Users

Customers/Suppliers Business Partner Internal Users

Dial in Router Firewall VPN Gateway

PremierAccessAgent

PremierAccessAgent

PremierAccessAgent

PremierAccessAgent PremierAccess

AgentRADIUSClient

RADIUSClient

RADIUSClient

Applications

Data

DataData

PremierAccess controls access to your data and applications

PremierAccessAgent

Administrator

2

Chapter 1: PremierAccess OverviewAn introduction to PremierAccess

Figure 2 shows an example network with PremierAccess installed. Three access methods are shown: dial-in access with a hardware token, VPN access using a software token, and wireless access through a gateway. You will find additional configuration examples in the section entitled: “Usage scenarios” on page 33 in this guide.

Figure 2: ProductOverview

AccessPointFirewall and VPN

gateway

Dial-in access usinghardware token

Dial-up router

VPN access usingsoftware token

Messaging server

Internet Webserver

Web accesscontrol gateway

3

Chapter 1: PremierAccess OverviewThe AAA solution

4

The AAA solution

The PremierAccess AAA (Authentication, Authorization, and Accounting) Server ensures that users logging into your network are the particular persons they claim to be before it grants them access to the system. The AAA solution provides strong authentication, authorization, and accounting, providing users with the applications and resources they need.

Understanding strong authentication

Authentication is the act of proving someone or something as trustworthy or genuine. Authentication is usually accomplished by presenting proof of identity. When you write a check as payment for goods, you also present a form of identification to the person accepting your check. This ID is proof that you are the same person whose name appears on the check you are issuing as payment. PremierAccess accomplishes authentication by demanding assigned credentials of users attempting access (the challenge), and comparing their answer to confirm that it is what was expected (the response). Credentials can be:

• something the user knows — password, PIN, etc.

• something they have — token, key, magnetic card, smart card, etc.

• something they are — fingerprint, retinal scan, voice print, etc.

Note: In this guide, the term PIN is the acronym for Personal Identification Number. SafeWord also uses the term SoftPIN, which refers to optional PINs that administrators may require users to append to their passcodes when users authenticate. Additionally, the term device PIN is used to refer to the optional PINs that are set on software token devices when MobilePASS is activated. When enabled, device PINs must be entered on the token device in order to generate passcodes.

Strong authentication is authentication that requires multiple factors and uses advanced technology to verify a user’s identity. A simple example of multiple-factor authentication is your bank ATM card. To conduct business with your bank, you must have something (your ATM card), and you must know something (your PIN). Confidence in the security of your account is assured with the knowledge that even if you were to lose your ATM card, it would be virtually useless to anyone else unless they also knew the PIN associated with it. This is two-factor authentication.

This authentication is determined by the demand for a password. For users who only need access to lower-value network resources (such as e-mail), a password may be sufficient for access. However, for other users, who need access to more sensitive network resources, you may


assign multiple authenticators, each with individually defined authentication strengths. Figure 3 shows the authentication phase, which is the first of the AAA Server functions.

Figure 3: Your securitypolicy: the authentication

phase

Determining the number of authenticators your users will need, and defining the security level or strength of those authenticators increases your ability to protect sensitive and critical resources to a far greater degree. Authenticators and their strengths are an important part of your security policy, and should be considered carefully before distributing tokens to your users. For more information about authenticators and strengths, see Table 13 on page 108.

Authorization

Authorization is defined as the act of granting permission. The PremierAccess AAA Server permits or denies access to protected applications and resources. The AAA Server checks each user request for access against the collections of rules you have defined for that user. Figure 4 shows the authorization phase, which is the second of the AAA Server processes.

Are you who youclaim to be?

AuthenticationPhase 1

Phase 2

Phase 3

Authorization

Accounting

AAA Server Phases

5


Figure 4: Your securitypolicy: the authorization

phase Are you who you claim to be?


Phase 2

Phase 3

Authorization

Accounting

Are you allowed access to the requested Web or network resource?

AAA Server Phases

6


Access rules define your organization’s security policy, determining who can log in, and which applications and resources they are authorized to access. The access rules you set can be applied to groups of users who share common access needs, by putting your users into logical groups, and then defining the rules that permit or deny access to specific resources. Access rules are another important part of your security policy.

ACLs

In PremierAccess, all requests to access resources are processed through one or more ACLs (access control lists). An ACL is simply a collection of access rules that you define for a set of resources that you are protecting. Lower-risk resources will have less restrictive rules, while highly-sensitive resources will have stricter rules. ACLs define your security policy.

PremierAccess comes pre-populated with two default ACLs, the DEFAULT_LOGIN_ACL and the DEFAULT_WEB_ACL. They are both stored in GLOBAL DATA, which is one of the administrative groups in PremierAccess.

ACLs are where you store your security policies. Login ACLs store the rules that control access to your network services and the Web. All users must be authorized by a login ACL before they are permitted access to your Web servers.Web ACLs are a special kind of ACL that are used specifically for defining security policy within the context of a Web server. They govern access to individual URLs and their content on your Web servers. You can define access rules down to the URL level of granularity with Web ACLs.

Important: We strongly recommend that during testing of new security policies, you place those policies in new login and Web ACLs, and leave the default ACLs intact and unmodified.

ACL entries

ACL entries are the access rules that make up an ACL. They specify the user access permissions of your security policy, and are the most important parts of an ACL. When an authenticated user attempts access into your network, the circumstances of that attempt must meet the permission criteria of at least one matching ACL entry for successful authorization and authentication to occur.

You define permission criteria when you create your ACL entries. For instance, in a login ACL, you can set up entries that allow access to

7


particular resources, to all users, or to limited users based on role, IP address, PremierAccess agent or custom application, or specific user name. This information is the subject of your entry. Once you have defined the subject part of the entry, you set the restrictions that will be applied to the users who are targeted by the subject. You can restrict all access, allow unrestricted access, or grant access based on authenticator strength, date range, and day and time.

8


Roles

In PremierAccess, roles are tags or labels that identify groups of users who share common access privileges. In other words, roles define collections of access rules applicable to particular groups of users.

You may choose to categorize users into roles based on their relationship to your organization. For example, you might set up roles for management, accounting, human resources, IT, and administrative staff members. Another possibility is to create roles with names that denote user authorization, for instance, “nightshift users”. You may also have roles for accessing servers (by server name or IP address), with a role for your mail server, your HR, Finance, and Sales servers. You would then create ACL entries for each of these resources.

Important: Every role must be associated with a supporting login ACL in order for it to have any meaning within your PremierAccess security policy.

Figure 5 illustrates groups of users with multiple roles, their relationship to a login ACL, and the ACL entries that map access restrictions based on those roles.

9


Figure 5: Role to loginACL relationship

Though not a required user attribute, roles are valuable because they offer a quick means of applying or modifying uniform sets of access permissions to large numbers of users.

Accounting

In PremierAccess, accounting is the recording, logging, and archiving of every authentication attempt into your protected network. Accounting is the third phase of the AAA authentication process. The AAA Server records all events, which can be recalled by using the log search functionality within the Administration Console. Figure 6 shows the complete AAA Server process.

Mmgt_staff

Individuals

users...

can havemultipleroles...

that point toa login ACL...

that contains

J_Jones

R_Cordrey

H_Parsons

M_West

ID Subj / Restrict

1

2

3

Subj=Role: ManagementCompanyLogin ACL

entries which canmap access restrictionsto individual roles.

L_Barry

J_May

J_Gilbert

F_Flores

M_Gilbert

J_McAbee

K_Allison

P_Wren

H_Parsons

R_Fowler

or groups of

Subj=Role: Administrative

Restrict: Unrestricted

Restrict: M-F 0700-1800

Subj=IP: 192.168.XX.XXRestrict: day/time

Subj=IP: 192.168.XX.XXRestrict: Auth Strength 12

Subj=Role: IT_staffRestrict: Unrestricted

4

10

Mmgt_staff

Admin_staff

Weekend_day

Weekend_swing

IT_staff

Sales_server

HR_server

Application_server

10


Figure 6: Your securitypolicy: the accounting

phase

Audit log information

The following accounting information is recorded in an audit log each time there is an access request:

• Date and time of request

• Whether the authentication attempt passed or failed

• Authorization violations

Recent audit logs are stored in the database until archiving. All audit log archives are stored on the Administration Server.

You load, unload, and delete audit log archives, and set up how often you want logs to archive automatically, using the Manage Audit Log Archive function in the Administration Console.

Keywords in the sccservers.ini file can be set to control the number of threads that are used for loading archive sets, and the number of logs in a batch per thread. In addition, actions such as adding, deleting, or modifying entries, cause separate audit logs to be created, generating an audit trail of all database activity. For more information about logs and archives, see Chapter 8, Maintaining PremierAccess.

Note: The Administration Server is sometimes referred to as the log server in the user interface.

Are you who you claim to be?


Phase 2

Phase 3

Authorization

Accounting

Are you allowed access to the requested Web or network resource?

Pass or fail is recorded.

AAA Server Phases

11

Chapter 1: PremierAccess OverviewAuthenticating with tokens

Authenticating with tokens

SafeWord tokens feature the following authentication modes:

• Time (synchronous)

• Event (synchronous)

• Challenge-response (asynchronous).

Additionally, beginning in SafeWord PremierAccess version 3.2.1.06, each authentication mode may be customized by configuring MobilePASS policies to suit individual organizational needs. For more information about MobilePASS policies, refer to “Configuring MobilePASS policies” on page 63.

Synchronous authentication

Synchronous authentication is not dependent on a challenge being issued by the SafeWord Authentication Engine. Instead, the Authentication Engine knows - from the imported token data file - the encryption algorithm being used by the tokens entered into the database, and what passcodes to expect from each token. The passcodes are synchronized between the Authentication Engine and the token using either time-dependent or event-dependent synchronization.

Time-synchronous mode

In time-synchronous mode, the one-time passcodes change automatically every 10 to 60 seconds. And since the SafeWord token clock continuously runs in the background, the passcodes are always in sync.

Event-synchronous mode

Event-synchronization uses an ordered passcode sequence to determine which passcode is valid. The Authentication Engine determines which passcode is valid by tracking where in the sequence of numbers a token should be. Synchronization can be maintained between the server and token even if the token is a few passcodes ahead of the server.

How synchronous authentication works

Synchronous authentication works as follows:

1 A user attempts to access a protected resource, and is prompted to enter their user ID and token-generated passcode.

2 The SafeWord Authentication Engine verifies that the received passcode is what was expected.– If the passcode is what was expected, access is allowed.– If the passcode is not what was expected, access is denied.

12

Chapter 1: PremierAccess OverviewAuthenticating with tokens

Since synchronous authentication does not require users to enter a challenge, the user workload is lighter. Also, nearly all authentication protocols can support synchronous tokens.

Asynchronous authentication

Challenge-response mode

Asynchronous authentication uses a challenge-response system in which the SafeWord Authentication Engine issues a “challenge” to a user seeking access to a protected resource. The user enters the issued challenge into the token, which generates a single-use passcode response. Asynchronous authentication works as follows:

1 A user attempts to connect to a protected system by entering their user ID, and SafeWord responds by issuing a challenge to the user.

2 The user types the challenge into their token.

The token holds an encryption algorithm identical to that held by the SafeWord Authentication Engine. The token decrypts the challenge and displays a single-use passcode that will be expected by the Authentication Engine.

3 The user enters the token-generated passcode into the prompt, and the Authentication Engine verifies the passcode matches the expected response.– If the passcode matches the appropriate encryption code, the

user is allowed access to that system.– If the passcode does not match the appropriate encryption, the

user is denied access to that system.

13

Chapter 1: PremierAccess OverviewSafeWord MobilePASS

14

SafeWord MobilePASS

SafeWord MobilePASS® is a software version of a hardware token. It combines the security of two-factor authentication with the convenience of one-time passcodes generated on personal mobile devices and computers. The MobilePASS Portal is an optional component that includes the Enrollment Portal where users can enroll their software tokens. The MobilePASS Portal can be installed on the same machine as the SafeWord core servers, or it can be installed on another machine in the same network. It is supported on all operating systems that support the core SafeWord servers.

MobilePASS software authenticators

The software token is an application that generates passcodes on the desktop and on select mobile devices. SafeWord PremierAccess installations include two software evaluation tokens. The tokens are named EVAL-SOFTWARE-1 and EVAL-SOFTWARE-2, and they are available for download in the SoftwareEvalTokens.dat file, which is located at <install_dir>/AdminConsole.

Note: SafeWord’s integrated MobilePASS software supports software tokens only. It does not support Messaging tokens. If you will be using Messaging tokens, use the stand-alone MobilePASS Factory.

SafeWord MobilePASS provides you with two ways to generate software authenticators. You can use the integrated MobilePASS product, which is included with SafeWord PremierAccess version 3.2.1.05 and higher, or you can use the stand-alone MobilePASS Factory application. The integrated product supports iPhone/iPad//iPod touch devices, J2ME devices, Android devices, Mac OS, Windows XP, Windows 7, Windows Vista, Windows Phone 7, Windows 2003, Windows 2008, and the latest BlackBerry devices. The stand-alone MobilePASS Factory supports J2ME-enabled devices, earlier versions of BlackBerry devices, and smart phones, providing these users with device-specific authentication applications.

Note: For more information about the MobilePASS Factory, refer to the SafeWord Authenticators Administration Guide which is available on the SafeWord Documentation page at www3.safenet-inc.com/safeword/docs/swpa.aspx.


Chapter 1: PremierAccess OverviewSafeWord hardware tokens

Figure 7: AuthenticationOptions

SafeWord hardware tokens

SafeWord hardware tokens are hand-held passcode generators programmed to validate the passcodes. They have a liquid crystal display (LCD) to display their generated passcodes, and either a single button to generate a passcode, or a simple keyboard to enter SafeWord-issued challenges into the token.

SafeWord supports the following token types from SafeNet:

• SafeWord Gold

• eToken PASS

• SafeWord Alpine

• SafeWord Platinum

• SafeWord Silver

15

Chapter 1: PremierAccess OverviewComponent overview

Component overview

PremierAccess is comprised of four core components and a number of optional components. The components work with special software modules called agents to control users access to protected resources in the secured network.

All PremierAccess core and optional components are Solaris compatible. The components, their functional summary, and whether they are core or optional, are listed in Table 3.

Table 3: PremierAccess core and optional components

Component Function summary Core Opt.

Database server • serves as the repository for PremierAccess data

X

Admin Server (AS)

• executes commands from the Admin Console and other admin clients

• provides secure access to the database server by requiring authentication

• issues X.509 certificates

• digitally signs each record entry with an internal cryptographic key to protect the integrity of data

• replicates database changes to other PremierAccess databases

X

Authentication Authorization and Accounting (AAA) Server

• permits or denies access to your resources and applications

• verifies digital certificates

• logs authentication attempts

• sends passwords to mobile phones using the MobilePass plugin

X

More...

16


Admin Console (AC)

• allows local and remote administration of your PremierAccess environment and security policy

• allows creation and management of MobilePASS policies and the users associated with them

• allows adding, importing, and managing users and digital certificates and their associated verification policies

• allows you to create groups and subgroups to organize users and PremierAccess data elements for delegated administration

• allows you to assign authenticators for users

• allows you to view log events

• allows you to generate reports of every object data type in the database

X

Enrollment Server (ES)

• provides Web-based user self-enrollment

• allows enrolling users to test their authenticators once they have enrolled

X

Web Login Server (WLS)

• provides a Web-based interface to the AAA Server

• supports varied authentication methods including fixed and dynamic passwords, and digital certificates

• creates session credentials that serve as proof of successful authentication

X

More...


17


18

RADIUS-based servers

Note: Optional servers used for VPNs and remote dial-in configurations.

RADIUS:

• allows VPNs, routers, and comm servers using the RADIUS protocol to communicate with PremierAccess

• sends user’s names and passwords to PremierAccess where their authentication is verified or denied

RADIUS for Ascend:

• allows clients using the Ascend RADIUS protocol to communicate with PremierAccess

• allows any communication terminal server or other client that supports RADIUS for Ascend to authenticate users with PremierAccess when installed on the authentication server

RADIUS Accounting:

• operates as a client of the RADIUS accounting server listening for properly formatted packets

• passes user accounting information to and from the designated RADIUS accounting server

X

Authentication Broker plugin

• an extension of the AAA Server

• extends access to PremierAccess-protected resources to other user databases, such as LDAP and AD in your network

• allows for gradual migration from legacy token authentication systems

X

More...



Core and optional server components, and some of the agents available for use with the components are shown in Figure 8.

MobilePASS • allows users to generate passcodes from mobile devices and their Mac and Windows Desktops. (See “MobilePASS software authenticators” on page 14 for support details.)

X

MobilePASS Enrollment Portal

• allows users to enroll their software token device without administrative assistance

X

Password Checker plugin

• allows a customer to further define what constitutes a valid fixed password for their organization

X


19


Figure 8: Core andoptional components

Authentication Server (AAA)

Admin Server

RADIUSServer S

erve

rW

eb L

ogi

n

Universal Web Agent PAM agent

Terminal Services Windows Domain Login agent

.OWA agent

Core componentsOptional Optional

EASSP protocol RADIUS protocol

[Access point via[Access points via PremierAccess agents]

Dial-in/VPN]

BrokerAuth.

Web

Ser

ver

EASSPprotocol

PremierAccess System

agent

Database Server

RADIUS client

Admin Console

Enr

ollm

ent

Ser

ver

20

Chapter 1: PremierAccess OverviewSupported agents overview

Supported agents overview

PremierAccess uses agents, which are software modules specific to PremierAccess, to allow access to protected resources in a secure network. Agents act as User Access Points (UAPs). Table 4, “Supported agents,” provides a brief description of the agents currently supported by PremierAccess.

Table 4: Supported agents

Tip: Documentation for these agents can be found in the SafeWord Agent Administration Guide which is available for download from the SafeNet corporate Web site at www3.safenet-inc.com/safeword/docs/swpa.aspx.

Agent Description

Universal Web Agent (UWA)

The Universal Web Agent sits in the data stream between the user’s browser and the Web applications residing on the server being protected by the UWA.

SafeWord Agent for PAM

The Pluggable Authentication Module (PAM) framework allows applications requiring authentication and other security services to access those services generically. Authentication services can be updated for improvements or new technologies without rewriting. PAM support is an integrated feature of Sun's Solaris operating system (release 2.6+). The SafeWord PAM agent allows SafeWord authentication in PAM-compliant applications supplied by Sun and others such as login, telnet, and ftp.

SafeWord IAS/NPS Agent

The SafeWord IAS/NPS Agent is the Microsoft IAS RADIUS solution that provides SafeWord strong authentication for remote access through the Microsoft IAS RADIUS Server.

Outlook Web Access Agent

The Outlook Web Access (OWA) Agent works withthe Microsoft Exchange Server to provide SafeWord strong authentication through the Microsoft Exchange OWA component.

Agent for Web Interface

The Agent for Web Interface is the authentication component for use on the Citrix Web Interface server.

21

www3.safenet-inc.com/safeword/docs/swpa.aspx

Chapter 1: PremierAccess OverviewUser privileges and permissions

User privileges and permissions

Users in the PremierAccess database are categorized into one of three administrative levels: system administrators, group administrators (which includes local administrators and helpdesk staff), and regular users. These three levels of users fit into two categories, those with administrative privileges (system administrators, local administrators, and helpdesk staff), and those without administrative privileges (regular users). Table 5, “User levels and privileges,” summarizes the user levels, and whether or not they have administrative privileges.

Table 5: User levels and privileges

Privileged users

Privileged users can administer some portion of the PremierAccess system. The extent of their administration depends on their level of permissions. In general, administrators can create, modify, and manage groups and users that are under their control. There are three types of administrative users: system administrators, local administrators, and helpdesk staff. Table 6 shows the permissions granted each privileged user type.

Note: Local administrators and helpdesk staff are collectively known as group administrators because their administrative permissions are restricted to those admin groups specifically assigned to them by the system administrator.

Level Privileged Unprivileged

System administrators X

Group administrators (local administrators and helpdesk staff)

X

Regular users X

22

Chapter 1: PremierAccess OverviewUser privileges and permissions

Table 6: Privileged user types and permissions

Unprivileged users

Users not given system, local, or helpdesk staff privileges are referred to as unprivileged users. Most users will be unprivileged users. These are regular users who cannot perform any administrative tasks within PremierAccess.

Privileged user type Privilege level Permissions

System administrator Highest level of permissions

Exercise all administrative tasks including:

• Modify system configurations (preferences)

• Backup and restore the database

• Create other administrative users

Local administrator Middle level of permissions

• Administer groups created by system administrator and assigned to them

• Administer data elements (users, tokens, roles, etc.) that reside in their assigned group hierarchy

Helpdesk staff Lowest level of permissions

Modify specific segments of user records for groups and subgroups to which they are assigned

23

Chapter 1: PremierAccess OverviewAdministrative groups

Administrative groups

Admin groups are virtual containers that hold users or other objects ( tokens, ACLs, or roles, to name a few). Groups allow system administrators to organize and manage large numbers of users. Using groups, system administrators can delegate the administrative duties of particular groups within the hierarchy of an organization to local administrators.

Groups and subgroups

You can create groups and organize them in a number of ways. Organize them alphabetically, or by department, or geographic region.Nest groups within groups to further subdivide them into a parent-child group hierarchy that resembles your organization. Group affiliation is required since every object must belong to a group, and a user is considered a group.

Note: A user’s placement in an admin group has no bearing on their authorizations within PremierAccess. It is simply an organizational container. It should not be confused with the concept of groups as defined within Unix operating systems. PremierAccess roles are analogous to Unix groups.

24


Types of groups

PremierAccess has two kinds of groups: global and non-global.

• Global groups: Global groups contain data, such as ACLs, roles, and profiles, that you want other administrators to view and access. Placement in a global group makes these objects visible, but not modifiable to all administrative users. Users cannot be placed in global groups. Global groups and the objects within them can only be created and modified by system administrators. This prevents local administrators from having unintended access to users in other groups.

• Non-global groups: Non-global groups are visible to system-level administrators. They can also be visible to local administrators and helpdesk staff who have been granted specific management duties over those specific groups. This gives system administrators the ability to assign local or helpdesk administrators to specific groups without also granting them access to other groups. These groups normally contain users, but can also contain roles, ACLs, tokens and authenticator profiles, and reservations that are relevant only to users in that local group. By placing users in non-global groups, you are able to divide a large number of users into smaller groups that are independent of groups at the same hierarchical level, then assign group-level administrators to manage those groups.

Note: You will likely only have one global group in your deployment. Most of your groups will be non-global groups. Users can only reside in non-global groups.

For more information about creating groups, see “Working with admin groups, ACLs and roles” on page 100.

25


26

2CHAPTER Administration Overview

In this chapter...

Required administrative tasks ........................................................28

Optional administrative tasks .........................................................30

Usage scenarios.............................................................................33

27

Chapter 2: Administration OverviewRequired administrative tasks

Required administrative tasks

In PremierAccess, there are a number of tasks that every administrator will likely perform. For example, starting the Admin Console is a task that every administrator will perform repeatedly. As a convenience for you, Table 7 lists the required administrative tasks. The tasks are sequentially ordered as steps. Although it is not required, we recommend following the steps in the order that they are listed when you are setting up PremierAccess. After that, you can follow the procedures as you find them necessary. Each step includes a short overview and a reference (which is also a hyperlink to the procedure) to further information about the task.

Note: Starting the Admin Console is listed as a required task because this guide assumes that administrators will be using the Admin Console to manage their system.

Table 7: Required administrative tasks

Task Overview and references

1 Starting the Admin Console

The Admin Console (AC) is the main interface into the PremierAccess system. See “Starting the Admin Console” on page 43.

2 Creating a primary working account

Creating a primary account and assigning a token or fixed password to the account gives you a working account to use with PremierAccess. It also allows you to maintain the default administrator account intact. This permits troubleshooting authentication issues should they occur. To create a primary working account, see “Creating a primary working account” on page 49.

Security Alert: Although you may choose not to import token programming files before creating a primary working account, we advise you to assign a token to both your default system account and your primary working account for added security. For information about importing programming files, see Table 8, “Optional administrative tasks”.

3 Editing the SafeWord PremierAccess configuration

You can set up PremierAccess to suit your organization’s individual needs. General, server, and session configuration data are set from the Admin Console. To set up these settings, see “Editing the PremierAccess configuration” on page 94.

More......

28

Chapter 2: Administration OverviewRequired administrative tasks

4 Creating a login ACL

The login ACL provides the enforcement of your security policy by governing who gets into your network, where they can go, and under what circumstances they can get there. To create a login ACL, see “Creating login ACLs” on page 101.

Note: PremierAccess comes with a default login ACL. We recommend making a copy of that ACL, and using it to create your own login ACL. Keep the original default login ACL intact and unmodified.

5 Creating login ACL entries

Login ACL entries specify user permissions as defined by your security policy. Users attempting access to your network must meet the permission criteria as defined by your ACL entries. To create ACL entries, see “Creating login ACLs” on page 101.

6 Ordering ACL entries

Login ACL entries are evaluated sequentially from the first entry to the last. You must order entries from the most restrictive to the least, with the most restrictive at the top of the list. To order ACL entries, see “Ordering ACL entries” on page 112.

7 Create roles Roles help you manage your user’s access requirements. They are tags that identify user’s access privileges. To create roles, see “Creating roles” on page 102.

Important: This step requires pre-planning. If you have not already decided how you want to organize your users into logical roles, we recommend you sketch out that plan before creating roles.

8 Adding users to PremierAccess

PremierAccess provides several ways to bring users into the system. To add users manually, see “Creating user accounts manually” on page 129. To add users with the wizard, see “Adding unprivileged users with the user wizard” on page 140. To add users from a SafeWord 5.x database, see “Adding and importing users” on page 128. To import users from other SafeWord PremierAccess databases, see “Backing up and restoring your user database” on page 199. To allow self enrollment, see “Understanding Web-based, user enrollment” on page 264.

9 Assign roles to users

You may find it helpful to organize your users and devices into logical categories that work for your organization. If roles are assigned, when the AAA Server checks a user’s credentials, the roles assigned to the user will determine their access permissions. Assigning roles is an option you may choose when you import user’s into PremierAccess.


29

Chapter 2: Administration OverviewOptional administrative tasks

Optional administrative tasks

Table 8 lists optional administrative tasks. Each includes a short overview and a reference to further information.

Table 8: Optional administrative tasks


1 Import token programming files and generate MobilePASS licenses

If your organization will be using hardware tokens, you must import the token programming files into PremierAccess. If MobilePASS will be used, you must generate and import the MobilePASS licenses. For details on these tasks, see “Organizing authenticator files” on page 45 and “Generating and importing MobilePASS software tokens” on page 61 respectively.

Security Alert: Although you may choose not to import token programming files, we advise you to assign a hardware or software token to both your default and your primary system accounts for added security.

Important: Importing token files does not create user records, nor does it embed the programming data into a user record. Importing the files simply introduces the token files to PremierAccess for associations. Once the token files are imported, you can assign a hardware or software token to the user. When you enter the serial number of the token during creation of the user record, PremierAccess associates the cryptographic key held by the token assigned with that user. During a login attempt by the user holding that token, the PremierAccess AAA Server can anticipate the correct response from that token when it issues an authentication challenge.

2 Configure MobilePASS policies

MobilePASS policies allow you to customize users software authenticator devices. You may choose between event sync, time sync, and challenge- response mode, whether to enforce a SoftPIN, to force PIN changes and attack lockouts, the length of passcodes, the length of time before a new passcode can be generated (time-sync mode only), and the challenge length (challenge response mode only). For details about these tasks, see “Configuring MobilePASS policies” on page 63.

More...

30


3 Create groups and subgroups

Groups and subgroups are virtual containers that hold users or PremierAccess data elements. They are helpful in organizing and managing large numbers of users and for delegating their administration to local admins. For set-up information, see “Working with admin groups, ACLs and roles” on page 100.

Important: This step requires pre-planning. If you are not certain about how you want to organize your users and objects into groups and subgroups, consider sketching out an organizational plan before creating groups and subgroups.

4 Create a Web ACL

Web ACLs protect Web servers and their content. They work with the Universal Web Agent, which must be installed on each server it is to protect. To create a Web ACL, see “Understanding Web ACLs” on page 115.

Note: Web ACLs will not take effect until the UWA is configured to use it. For more information about configuring the UWA, see the Universal Web Agent Administration Guide.

Important: This step requires pre-planning. If you have not already decided which areas of your Web site require higher security than other areas, we recommend you determine site security levels before creating Web ACLs.

5 Create Web ACL entries

Web ACL entries are three-part rules that govern access to individual URLs and their content. You create Web ACL entries when you create Web ACLs.

6 Add or modify authenticators

You can assign up to three hardware, software, and fixed password authenticators to a user, and you can assign multiple digital certificates so they can log into the system. In the case of a lost authenticator, you can assign a temporary fixed password to a user. To add or change an authenticator, see “Adding, changing or removing authenticators” on page 144.

Note: Authentication methods should be based on the access needs of your users. Users requiring access to higher risk resources will require stronger authenticators than users accessing lower-risk resources.

More...


31


7 Configure the Password Checker plugins

The Password Checker plugin is available for extending your authentication needs. For more information see: Appendix B: “Setting Up Plugins” on page 321.

8 Install the Authentica-tion Broker

The Authentication Broker extends PremierAccess protection to users in other databases in your network. It allows authentication requests to be proxied to external sources such as a Windows 2000/2003, Windows 2008, Active Directory server, or a RADIUS Server. For more information about the Authentication Broker, see “Using the Authentication Broker plugin” on page 323.


32

Chapter 2: Administration OverviewUsage scenarios

Usage scenarios The following scenarios describe PremierAccess in a variety of network solutions. Although these scenarios represent only a few of the possibilities for using PremierAccess, they are some of the more common ways that corporations use the product for strong authentication and authorization.

The scenarios provide you with real-world solutions that you can use to configure PremierAccess in your network. Each includes a brief description of the scenario, a sketch showing the components and steps involved, a list of hardware and software requirements, and a numbered list of steps to follow if you choose to implement the solution in your network.

Strong authentication for a VPN connection

This scenario summarizes how to use PremierAccess to provide strong authentication when remote users connect through a VPN gateway to your protected network.

Figure 9: Strongauthentication for a VPN

connection

Internet

Application Server

VPN Gateway

User Workstation

Corporate Office Remote Users

Authentication

Token

Telecommuter

Road WarriorVPN Client

VPN Client

Authentication Server

with MobilePASS

RADIUS

33


How it works

When a user seeks access from a remote location to a network that is protected by a VPN gateway, the gateway and the client VPN software create a private tunnel through the Internet. The VPN uses IPSec (Internet Protocol Security) technology to protect the privacy and integrity of packets that contain messages or other data as they pass through the tunnel. When a message arrives at its destination, the protocols remove the protection so it does not interfere with any conventional application software or protocols.

PremierAccess provides strong authentication at the gateway. It requires the user to authenticate before the VPN tunnel is established. Users authenticate with a dynamic passcode generated by a hardware token, or with a passcode generated by a software program that is installed on their computer.

Setting it up

To set up this configuration:

1 Install the PremierAccess core servers and the RADIUS Server(s). See the PremierAccess Installation Guide for details.

2 Configure PremierAccess so remote users can access the resources to which they need access. You can use roles to do this. For example, you might create a role called Remote Users, and point it to a specific login ACL that you have set up for this group of users.

3 Configure your RADIUS Servers to accept authentications from the VPN gateways. This is done by editing the RADIUS Servers client’s file.

4 Install and configure your VPN gateway (the Check Point VPN-1, or Cisco VPN Concentrator 3000 for example), and your VPN client software on remote user’s computers.

5 Distribute token devices to users if they do not already possess them, inform them that MobilePASS software is available for installation. This could be accomplished using the PremierAccess Enrollment Server.

34


Strong authentication for Web sites and their content

This scenario summarizes how to protect a Web site and its content when some areas must be available to anyone accessing the site, while other applications and Web pages need to be protected so they are only accessible to users with the appropriate credentials. For the protected areas, you will restrict access based on user roles.

Figure 10: Strongauthentication for Websites and their content

How it works

When a user with a specific role seeks access to protected Web pages on the company Web site, the UWA intercepts the request, and, if it is for a protected resource, checks to see if they have already logged in via the WLS. If not, they are redirected to the WLS for authentication, after which the WLS redirects them back to the original request. Once they are logged in, the UWA gets the user’s roles and other information, and grants or denies access. If the request is for an unprotected resource, it is just passed through.

Universal Web Agent

Web Login Server

Server

(2) Employee Pages

(3) Manager Pages

(1) Public Pages

Role Pages

Manager

Employee

(1) (2) (3)

(1) (2)

35


In the scenario, a member with the role Manager has unrestricted access to all pages (1), (2), and (3). They can access highly-sensitive data that is stored on the Manager pages, less critical data available to users assigned the Employee role, and information stored on the Public pages that are available to everyone. Users with the role Employee can access the Employee pages and the Public pages, but they are restricted from accessing Manager pages. All other users are restricted to those pages that are not designated as being protected.

Setting it up


1 Install the PremierAccess core servers and the Web Login Server.

Note: See your PremierAccess Installation Guide for details.

2 Install and configure the UWA to protect the Web site. See the SafeWord PremierAccess Universal Web Agent Administration Guide.

3 Establish your security policy by determining access rights and security levels for your resources and your users.

4 Configure PremierAccess to meet your security policy needs. For instance, for this scenario, you would set up a role for managers, and a role for employees, then point the roles to their appropriate login ACLs. After that, you would create Web ACLs with entries that protect the individual URLs on your Web servers.

36


Strong authentication to wireless LANs using tokens

This scenario summarizes how to use strong authentication to wireless LANs using tokens. Two configurations are illustrated, one showing PremierAccess using the Extensible Authentication Protocol (EAP) and 802.1X authentication, and the other showing PremierAccess strongly- authenticating users at a wireless access control gateway.

Figure 11: Strongauthentication to wireless

LANS using tokens

How it works

In example number 1, the wireless client sends an authentication request to an 802.1X-enabled wireless access point. The access point repackages the authentication request before sending it to the EAP-enabled RADIUS Server. The RADIUS Server reviews the request and forwards to PremierAccess for authentication and authorization. If the access request passes, the RADIUS Server informs the wireless access point to grant the user access.

In example number 2, a request is sent to a wireless access point. The wireless access point forwards the request to the access control gateway. The gateway blocks access until the user authenticates with PremierAccess.

Web Browser

EAP

RADIUS

Authentication server

RADIUS

Firewall-like devices(Vernier Networks or Bluesocket for example)

Wireless client withsoftware such as

running Cisco Secure ACS,

Internal or external network

1

2

Funk Odyssey or

Funk Odyssey Windows XP or

Access Control Gateway

RADIUSFree

37


Setting it up


1 Install wireless client software (supplicant) on the client requesting authentication.

2 Install an 802.1X wireless network card (802.1X-compatible) on the client.

3 Configure an 802.1X-enabled Wireless Access Point.

4 Install the PremierAccess core servers and the RADIUS Server.

5 Import or enroll users to your user database.

6 Configure your EAP-enabled RADIUS Server to accept authentications from your wireless access points (for example, CiscoSecure ACS, Funk Odyssey or FreeRADIUS).

7 Configure the EAP-enabled RADIUS Server to terminate EAP and proxy standard RFC 2186-based authentications to the PremierAccess server. The standard RADIUS server will authenticate PAP and CHAP only. For MSCHAP v1/v2, use the IAS and the SafeWord IAS Agent.

Note: You can use Protected EAP (PEAP) or Tunnel Transport Layer Security (TTLS) to accomplish this. Refer to the vendor’s specific documentation for details.

38


Strong authentication using phones, pagers, and PDAs

This scenario summarizes how PremierAccess and MobilePASS can be used by remote users to strongly authenticate and gain access to authorized Web pages and applications with passcodes generated on their mobile devices.

Figure 12: Strongauthentication with digital

devices

How it works

MobilePASS is a software token application that generates passcodes on the desktop and on select mobile devices.

MobilePASS provides you with two ways to generate software tokens. You can use the integrated MobilePASS product, which is included with SafeWord PremierAccess version 3.2.1.05 and later, and/or you can use the stand-alone MobilePASS Factory application.

The MobilePASS software application provides users with passcodes directly on their mobile devices. It has an integrated support feature that allows administration directly from the SafeWord PremierAccess Admin Console. .

Setting it up


1 Install PremierAccess core servers.

2 Generate and import MobilePASS licenses. For more information about MobilePASS, see Chapter 4, Using the MobilePASS feature.

MobilePASS

Universal Web Agent

Web Login Server

Authorized Web pages and applications

Server

MobilePASS

Wireless ServiceProvider

Enter phonepasscode

82P16H + PIN

UsernameType of authenticatorToken secret keyDevice addressAuthorized roles

passcode82P16H

Digital phone,pager or PDA

39


Using Cisco devices with PremierAccess

This scenario summarizes how easily PremierAccess integrates into and works with the wide range of Cisco devices operating in network environments providing strong authentication and access control.

Figure 13: Using Ciscodevices with

PremierAccess

How it works

Requests for access to the LAN are intercepted at the Cisco router and passed to PremierAccess for strong authentication before passing through the Cisco Secure PIX firewall and onto the LAN.

Setting it up


1 Install the PremierAccess core servers and the RADIUS Server.

2 Identify CiscoSecure ACS as a PremierAccess RADIUS client.

3 Set up your users and tokens in PremierAccess.

Authentication Server

Cisco DialupRouter

Cisco SecurePIXFirewall

LAN

RADIUS

RADIUS

Cisco SecureACS

40

3CHAPTER Basic System Tasks

In this chapter...

Using the Admin Console...............................................................42

Organizing authenticator files.........................................................45

Setting up and maintaining administrator accounts........................47

Other basic tasks............................................................................57

41

Chapter 3: Basic System TasksUsing the Admin Console

Using the Admin Console

The Admin Console allows you to manage users, create user groups, assign tokens, and create the security policies that define access to your protected network and Web resources. It also allows you to view audit logs.

Task bar icons

You perform tasks within the Admin Console using the text-based menus along the top of the console, or using the task bar icons located below the menus. Both methods allow you to customize your network system. Table 9, “Admin Console task bar icons,” defines each of the task bar icons.

Table 9: Admin Console task bar icons

Icon Function

Server Connect - opens an SSL connection to the machine where your Admin Server is installed and begins a session.

Server Disconnect - closes the SSL connection and ends the current session.

Find Users - opens the Find User Entries window to search for all available users or conduct a refined search for users matching specific criteria you choose.

Find Web ACLs - opens the Find Web ACL Entries window to search for all available Web ACLs or for Web ACLs matching specific criteria.

Find User Reservations - opens the Find User Enrollment Reservations window to search for all available user enrollment reservations or reservations matching specific criteria.

Find Sessions - opens the Find Session Entries window and allows you to search for all available session entries or for session entries matching specific criteria.

Find Audit Logs - opens the Find Audit Log Entries window and allows you to find all available audit logs or audit logs matching specific criteria.

View Entry - allows you to view other information associated with a selected entry.

Edit Entry - allows you to edit information associated with a selected entry.

More...

42


Starting the Admin Console

To start the Admin Console, locate and change to the directory where you installed PremierAccess. For example [cd SWPA].

Note: Words in square brackets [XXX] are placeholders for optional text.

1 If you are using the command line, cd to <install_dir>/PremierAccess/AdminConsole. If you are using the file manager, locate and open the PremierAccess/AdminConsole folder.

2 Launch the Admin Console:– If you are using the command line, type ./client.sh. If you are using the

file manager, locate and click the client.sh icon. – When the main Admin Console window appears, confirm that the

machine where your Admin Server is installed is displayed and selected in the right pane. The convention is [servername]: [portnumber].

Note: You may use the IP address instead of the server name and port number.

3 Click the Server Connect icon in the task bar. This opens an SSL connection to the machine on which your Admin Server is installed.

4 At the Username prompt, enter administrator.

5 Click OK. The Connection in Progress dialog box appears.

Changing the administrative password

6 Enter the default password administrator.

7 (Conditional) As this is the first time you have started the Admin Console, the Server Password Change Wizard window appears. To properly secure the installation, you must change the password for the account ENROLL_SYS_ADMIN. This account is used by the PremierAccess Enrollment Server. As a valid administrative user, its password must be changed, even if you did not install the server. Click Next.

Duplicate Entry - allows you to make a duplicate copy of a selected entry, then change the properties to create a new entry of the same type.

Delete Entry - allows you to permanently delete a selected entry from the PremierAccess database.

Icon Function

43


8 Enter a new password in the New Password field. The password must be at least four (4) characters long.

Important: Memorize or record this password in a secure location. You will need it later to configure each Enrollment Server.

9 Re-enter the same password in the Confirm Password field.

10 Click Next. A successfully changed password window appears.

11 (Conditional) This step varies based upon where your Enrollment Server is installed:– If your Enrollment Server is installed on the same machine as the Admin

Server to which you are currently connected, configuration information is automatically updated. To complete this procedure, click Finish.

– If one or more of your Enrollment Servers is installed remotely, you must change the Admin Server password manually in the appropriate configuration file. To change the password, click the More Info button. When the Configuring Remote Servers window appears, read the important message, click OK, and then browse to the web.xml configuration file. It is located in: <SWPA-dir>/SERVERS/Web/WebPlatform/webapps/servlets/WEB-INF. Change the value for the attribute [adminpwd] to the password you entered in the New Password field, then restart the Servlet Server.

Note: This is the location of the web.xml file for the SafeWord PremierAccess Enrollment Server. It should not be mistaken with the MobilePASS Enrollment Server.

12 If you want to secure this account with an authenticator that is stronger than a memorized password, follow the steps described in “Assigning a token to your primary working account” on page 50.

44

Chapter 3: Basic System TasksOrganizing authenticator files

Organizing authenticator files

Authentication is the process of proving that the identity claims of a user attempting to access your network are genuine. Authenticators can be hardware or software tokens, or some other mechanism that is used to verify the identity of the individual logging onto the network.

If you will be using MobilePASS tokens only, once you generate and import the MobilePASS tokens (see “Generating and importing MobilePASS software tokens” on page 61), you simply provide users with MobilePASS application and enrollment information. If you are not using hardware tokens, skip to “Setting up and maintaining administrator accounts” on page 47. If you are using hardware tokens, continue to the next section.

Where to find the hardware programming files

If you are using hardware tokens, PremierAccess associates the serial number of each token with the proper cryptographic algorithm after you import the programming files. The hardware programming files are located on the media that was included with the hardware tokens in your product box. The programming file is called import0.dat. It contains information such as token type, cryptographic key, type of display, and other information associated by token serial number for each hardware token included with your shipment.

Importing the authenticator programming files

If you are using hardware tokens, you must import their programming files into PremierAccess before you can use them. Before importing authenticator files, you should have their destination location prepared.

Copying the import files

Before importing the authenticator files, you will need to copy the import file from the source media to a target directory.

To copy the import file from the source media to a target directory:

1 Create a directory called Import in your SWPA path (Example: ...PremierAccess/SERVERS/...)

2 Copy the import0.dat file into the directory.

Importing the files

If you are using hardware tokens, insert the media that came with your hardware tokens into the appropriate drive on your computer.

1 From the Admin Console, select File -> Import -> Software/Hardware Authenticators. The Locate Authenticator Import File window appears.

45

Chapter 3: Basic System TasksOrganizing authenticator files

2 In the Locate Authenticator Import File window, enter the name of the file from which to import the authenticator programming files. You can also locate the file using the Browse button.

3 When the Import File Location browser window appears, browse to the ./SWPA/import directory you made earlier.

4 Locate the import0.dat file* and select it.

5 Click Open.

Note: *You may also see p.dat, ps.dat, and import1.dat files; which are related to programming data and multi-host support (multiple sets of keying material in one hardware token).

The Locate Authenticator Import File window appears, with the import0.dat file in the Import File field.

6 Click Next. The Select Admin Group window appears.

7 From the Admin Group drop down list, select the group to which you wish to associate the imported programming files.

8 Click Next. The Select Authenticator Strength window appears.

This is the numerical strength value for this authenticator type. The strength assigned should reflect how effective you consider this authenticator type to be.

9 Choose either Use default authenticator strength or Specify custom authenticator strength. If you choose to specify a custom authenticator strength, set the custom strength to a value between 1 and 20. For more information about authenticator strengths, see Table 13 on page 108.

10 Click Next. The Choose Overwrite Settings window appears.

11 You may overwrite all the existing authenticators in the database, or you may allow them to remain there. To overwrite all existing authenticators in the database, select the Choose Overwrite Settings check box.

12 When the Select Admin Group window reappears, click Import.

13 When all the records have been imported, an Import Completed window appears. Click OK.

14 When the Import More Software/Hardware Tokens window appears click No unless you want to import more token records.

15 Click OK.

46

Chapter 3: Basic System TasksSetting up and maintaining administrator accounts

Setting up and maintaining administrator accounts

PremierAccess recommends you maintain two administrator accounts for use with the software, a system administrator account and a primary working account. Your product ships with a fully functional default system administrator account with settings designed for the administration of the software. The default system administrator account has several purposes including serving as the account you use to troubleshoot authentication issues. Additionally, it is used to create your primary working account. The following is a list of tasks that must be completed in order to set up and maintain your default system administrator account and your primary working account. Be sure to complete these tasks in the order listed here as each is dependent on the previous one.

1 Clone the default system administrator account.

2 Create your primary working account using the cloned account.

3 Assign an authenticator to your primary working account.

4 Log out and log back into the primary working account to ensure it functions as expected.

5 Assign a difficult fixed password to your system administrator account and secure your password.

Cloning the default system administrator account

The default system administrator account included with your software is designed for several purposes, including troubleshooting your primary working account. For this reason, you should not change the settings associated with this account, but rather, you should clone the default account and then customize the clone. By maintaining the default system administrator account in its original state, you have a tool for troubleshooting authentication issues should they occur. To clone the default system administrator account,

1 Start the Admin Console.

2 Highlight the Reserved Admin Group folder and expand its contents by clicking the (+) symbol next to it.

Reserved admin groups should be used for administrative-level users. You would not put users into global groups because that would permit all admin-istrative users to have access to them. Using a RESERVED admin group lets you delegate the administrative duties of specific groups to specific administrators.

47


Figure 14: Adminconsole with users

displayed

3 Select Users. In the right pane you will see a list of usernames and admin groups. To the left of each username, there is a user symbol for unprivileged users, or there is a star symbol for administrators. Administrative privilege level is indicated by the color of the star.– Red stars denote system administrator-level users– Blue stars denote local administrator-level users– Yellow stars denote helpdesk staff– The user icon labeled BAD_USER_ID is for unrecognized user logins.

For more information about BAD_USER_ID, refer to “Reconfiguring the unregistered user ID” on page 96.

Note: User icons that appear in color indicate an unprivileged user with an enabled account. A grayed out icon indicates a user account that is disabled or not completely set up.

4 In the right pane, highlight Administrator under the Usernames list.

5 Right-click the highlighted name, then select Duplicate. The Create a New User window appears with the General tab displayed and the name Copy of Administrator in the Username field.

6 Click OK.

You are ready to create your primary working account using the clone of the default system administrator account. Continue to “Creating a primary working account” on page 49.

48


Creating a primary working account

Creating a primary working account, and assigning a hardware token to it provides you and the other administrators in your organization with an account to use for system administration. Doing this also allows you to maintain the default system administrator account intact, which is essential for troubleshooting authentication issues should they occur. To create a primary working account:

1 In the main Admin Console window, highlight the RESERVED Admin Group folder and click the plus (+) next to it to display its contents.

2 Select Users. In the right pane you will see a list of usernames and admin groups.

3 Highlight Copy of Administrator, right-click on it, and then select Edit. The Edit User window appears with the General tab displayed.

Figure 15: Edit a NewUser window (General

tab)

4 Highlight Copy of Administrator in the Username field, and then enter a new name over the selected text. This name will identify your primary working account; its name should be something that will make it recognizable as such.

5 Select an admin group from the Admin Group list. For your primary working account you should use the default RESERVED admin group. Continue to “Assigning roles to the primary working account” on page 50.

Important: Since you are creating your primary working account, we recommend that you do not edit the group properties unless there are custom changes you are certain you want to apply to this admin group.

49


Assigning roles to the primary working account

Roles help you manage user access by serving as tags that identify the access privileges of your groups and users. To create roles for your primary working account, do the following:

1 Double-click on the username.

2 Click the Edit button, and then click the Select button from the Roles pane. The Pick Role(s) window appears with DEFAULT_ROLE highlighted.

Figure 16: Pick roleswindow

3 Assign the default role to your primary working account by clicking the Select button. You are returned to the Edit User window and the DEFAULT_ROLE appears under Roles.

4 Click OK.

You now have a complete primary working account from which you will administer user accounts. To secure your working account, assign an authenticator to it. To assign a token to this account, refer to “Assigning a token to your primary working account” on page 50. Additionally, you may choose to assign a SoftPIN to add another layer of security. If you choose this option, after assigning a token to the account, refer to “Assigning a SoftPIN to the primary working account” on page 53.

Assigning a token to your primary working account

Assigning a hardware token to your primary working account, and then strictly limiting use of that token to administrators who are responsible for administration of the primary working account, ensures the security of the account. You will be using the authenticator programming files you imported earlier in order to assign a hardware token to the account.

50


To assign a hardware token to the primary working account, from the Admin Console’s main window, open the RESERVED admin group folder by clicking the plus (+) symbol next to it.

1 Select Users. The list of users contained in that group appears in the right pane of the Admin Console.

2 Right-click on your primary working account, and then click Edit. The Edit User window appears.

Note: The Edit User window appears with the name you gave your primary working account displayed.

Figure 17: Edit User:Primary Working Account

window

3 Select the Authenticators tab.

4 Click the Pick authenticator button.

Figure 18: Enter SerialNumber window

5 Enter the serial number from your token in the Serial Number field. The serial number corresponds to the number (letter and number) found on the back of the token you are using for this account. If you are using a software

51


token, the serial number is located in the SoftGen II output file “keyphrase.text”. If you will be using a MobilePASS software token, you must activate licenses using the MobilePASS Licensing feature before you can assign a token. For details about MobilePASS licensing, see “Generating and importing MobilePASS software tokens” on page 61.

Note: MobilePASS tokens can only be assigned through the wizard (Tools > MobilePASS Enrollment).

6 (Optional) Enter a SoftPIN for this token in the SoftPIN field. For details, see “Assigning a SoftPIN to the primary working account” on page 53.

Figure 19: Serial numberlocations

7 Click the Advanced tab and ensure that the Never option is selected under Account Expires.

8 Click the Privileges tab and verify that System administrator is selected under Administrative Level.

Figure 20: Create a newuser window (Privileges

tab)

9 Click OK to finish.

Security Alert: When you deploy PremierAccess operationally, we strongly recommend assigning hardware token or software authenticators for every user.

E103969

(back of authenticator)

52


Assigning a SoftPIN to the primary working account

You may choose to require that administrators enter a SoftPIN in addition to the token-generated passcode they must supply in order to access the primary working account. SoftPINs are optional; they consist of numerical strings that are generally appended to the end of the passcode each time an administrator accesses the account. SoftPINs add an additional layer of security to your account. They are equivalent to the hard PIN that is used with SafeNet’s gold and platinum tokens.

Tip: If you would rather require that a SoftPIN be prepended to the beginning of the token-generated passcode, refer to the SafeWord PremierAccess Installation Guide for configuration details. The installation guide is available for download from the SafeWord PremierAccess documentation page at http://www3.safenet-inc.com/safeword/docs/swpa.aspx.

To assign a SoftPIN to your primary working account, on the Enter Serial Number window, enter a 4-digit numerical string in the SoftPIN field, then click OK. When the Create a New User window appears you will see the authenticator and ID listed under Passwords and Software/Hardware Authenticators.

Important: If you designate a SoftPIN, (5432 for example), you must append it to the token generated passcode each time you authenticate. For more information about SoftPINs, refer to “Using SoftPINs with a user account” on page 131.

Figure 21: Create a NewUser with HardwareAuthenticator serial

number

Editing the primary working account authenticator properties

To view or edit the properties of the primary working account’s token, ensure that the token is highlighted, then click the Properties button under the Passwords and Software/Hardware Authenticators pane. The Edit Hardware Authenticator window appears with the properties for the authenticator displayed.

53




Figure 22: EditHardware Authenticator

window

1 Click the View button next to the Profile field.

2 Click the Edit button. A new window appears with the General tab displayed.

3 Adjust any of the following features to fit your individual needs:– Authenticator strength - Sets the authenticator strength value for all

tokens with this profile. For more information about authenticator strengths, see Table 10 on page 56.

– Admin Group - This is the admin group to which this authenticator profile is associated.

– Display Name - This is the name that appears at the login prompt for tokens with this profile.

– Comments - These are the comments that fellow administrators will see when viewing this profile.

4 When you are finished making changes to the General tab, click the Configure tab.

5 By default, passwords are echoed on input. If you do not want the passwords echoed, clear the check box and click OK.

6 To add or edit a SoftPIN for this account, either:– Enter a 4-digit value in the SoftPIN field, and then click OK.

Or

– Highlight the existing SoftPIN, enter a new SoftPIN over the highlighted one, and then click OK.

54


Testing your primary working account

It is important to test your primary working account and the token you have assigned to it once you are finished setting them up. To test the account you will need to log out and then log back in under your new primary working account username, using the token and SoftPIN if required. To test the account:

1 Log out of the session by clicking the Server Disconnect icon.

2 Click Yes. You are logged out.

3 Click the Server Connect icon.

4 Enter your primary working account username.

5 Enter the requested information for the token you have assigned. If you are unable to successfully log in, troubleshoot your primary working account by logging out and then logging back in under the default system administrator user account. If you are able to successfully log in, the primary working account is functioning properly. In that case you can now safely change your default system administrator account’s password. Continue to “Assigning a password to the default account” on page 55.

Assigning a password to the default account

To ensure the integrity and security of the default system administrator account, you should assign a difficult and lengthy fixed password to it, and then you should keep that password locked in a safe place where only the highest level system administrators in your organization will be able to access it.

Important: Do not change the password assigned to the default system administrator account until you have logged out and successfully logged back into your primary working account.

To assign a new fixed password to your default system administrator account, do the following:

1 From the Create a New User window, select the Authenticators tab.

2 Click Add password. The Enter a Fixed Password window appears.

Figure 23: Enter a FixedPassword window

Note: Since you are creatingthis password for yourself, clear this box, otherwise, you will be forced to changeyour password the nexttime you login.

55


Note: The available default profiles are fixed and Emergency. Table 10 lists the attributes of the two default password profiles. For more information about password profiles, see “Adding or changing authenticator profiles” on page 145.

Table 10: Default fixed password profile attributes

Tip: You can modify the default fixed password profile settings at any time, or create a new fixed password profile with different settings. The procedures are discussed in “Adding or changing authenticator profiles” on page 145.

3 Enter your new password in the Fixed Password field. To ensure the security of this account you should create a lengthy and difficult fixed password that is not easily hacked or guessed.


5 Clear the User must change password with first login check box.

Note: Typically, you would only check this box when you are assigning a fixed password to a user OTHER than yourself. Allowing users to change their password when they first login gives them a sense of confidence that only they know their password.

6 Click OK to finish.

7 Click OK to return to the Admin Console.

8 Log off and then log back on using your new system administrator name and fixed password.

Fixed password profile name

StrengthMinimumpasswordlength

Minimumpassword Age

No. ofwarningdays

fixed 5 4 Never expires N/A

Emergency (see note) 20 12 3 days 3

Note: The Emergency fixed password profile should only be used by administrators or helpdesk staff to temporarily assign a fixed password authenticator when a user has lost or otherwise compromised his hardware authenticator.

56

Chapter 3: Basic System TasksOther basic tasks

Other basic tasks

The sections that follow outline other basic tasks that are commonly performed from the Admin Console.

Finding entries in PremierAccess

The PremierAccess Admin Console includes functionality that allows you to search and find categories of data. These categories include users, login ACLs and Web ACLs, user reservations, admin groups, roles, and authenticator profiles. The following procedure outlines how to find login ACLs, but the same procedure applies to any of the object categories.

To find a login ACL, select Find ->ACLs -> Login. The Find Login ACL entries window appears.

Figure 24: Find ACLentries window

1 Use either the Find all available, or Find all that match filters to locate the ACL you created earlier. The filters contain different parameters such as object IDs or admin group IDs that can be filtered upon.

2 Click the More button to use additional filters. If more than one filter is used, you can click the Less button to remove the last filter.

3 Click Find. The Find Results: ACL Entries list appears with the list of login ACLs displayed.

Exporting data

In addition to finding object data, the Admin Console allows you to export that data directly into spreadsheet files. For more information about exporting data, refer to “Exporting data into Excel worksheets” on page 188.

57

Chapter 3: Basic System TasksOther basic tasks

Editing admin group properties

You may edit admin group’s properties to make the admin group more suitable to your needs. Existing admin groups are listed on the left pane of the main Admin Console window. To edit the properties for an existing admin group:

1 Double-click on the admin group you wish to edit.

2 When the Edit Admin Group window appears, click the View button to display the group’s properties and information about the last modifications made to this group.

3 Click the Edit button to modify the properties for this group.

4 Make desired changes to the group, then click OK.

58

4CHAPTER Using the MobilePASS

feature

In this chapter...

Understanding MobilePASS ...........................................................60

Generating and importing MobilePASS software tokens................61

Configuring MobilePASS policies ...................................................63

Configuring MobilePASS features ..................................................71

Assigning software tokens to users................................................81

Software token enrollment..............................................................88

59

Chapter 4: Using the MobilePASS featureUnderstanding MobilePASS

Understanding MobilePASS

SafeWord MobilePASS is a software version of a hardware token. It provides PremierAccess users with an additional authentication option, software tokens. MobilePASS can generate passcodes on desktops and on select mobile devices.

Note: SafeWord PremierAccess includes two (2) software tokens for evaluation purposes. These tokens (EVAL-SOFTWARE-1 and EVAL-SOFTWARE-2) are located in a file named SoftwareEvalTokens.dat in the AdminConsole folder.

SafeWord MobilePASS provides you with two ways to generate software tokens. You can use the integrated MobilePASS product, which is included with SafeWord PremierAccess, and/or you can use the stand-alone MobilePASS Factory application. The integrated MobilePASS product supports iPhone/iPad/iPod touch devices, J2ME devices, Android devices, Windows Phone 7, Windows Desktop, Mac, and select BlackBerry devices.

Note: For more information about the MobilePASS Factory, refer to the SafeWord Authenticators Administration Guide which is available on the SafeWord Documentation page at http://www3.safenet-inc.com/safeword/docs/swpa.aspx.

The MobilePASS Portal is an optional component where users can enroll their software tokens. The MobilePASS Portal can be installed on the same machine as the core SafeWord servers, or it can be installed on another machine in the same network. It is supported on all operating systems that support the core SafeWord servers.

Note: If you have the MobilePASS Portal and the WebPlatform components on the same machine, ensure the they are using different ports.

60


Chapter 4: Using the MobilePASS featureGenerating and importing MobilePASS software tokens

61

Generating and importing MobilePASS software tokens

To generate and import MobilePASS software tokens, do the following:

1 If you are using the command line, cd to <install_dir>/PremierAccess/AdminConsole. If you are using the file manager, locate and open the PremierAccess/AdminConsole folder.

2 Launch the Admin Console: If you are using the command line, type ./client.sh. If you are using the file manager, locate and click the client.sh icon.

3 Log into the Console as a system administrator.

4 Click the Configuration menu, and then select MobilePASS Licensing. The MobilePASS Token Generation window appears.

Figure 25: MobilePASSToken Generation

window

5 Referring to your MobilePASS/SofToken® II Activation Certificate, enter the following information on the Licensing window:

a Enter the serial number from your MobilePASS/SofToken® II Activation Certificate in the Serial Number field.

b Enter the total number of units from your certificate in the Units field.

c Enter the Seed value in the Seed field.

d Enter your authorization code in the Auth Code field.

Chapter 4: Using the MobilePASS featureGenerating and importing MobilePASS software tokens

e Enter your activation code in the Activation Code field.

f Select the Admin Group to which the tokens should be imported.

• (Optional) Click the View button to display the Admin Group’s properties.

• (Optional) Click the Check button to confirm that the Admin Group exists. A list of groups matching the search criteria appears. If the search criteria field is empty, a list of all existing groups appears.

g Select the Overwrite Existing Tokens on Import check box to overwrite existing import records when new records are generated. If you do not want to overwrite existing records, leave the check box cleared.

h Select Generate All or Generate Range.

If Generate All is selected, all available units associated with this license will be generated. In this case, continue to step 6 to generate and import the records.

If Generate Range is selected, the Start Serial Number field, and the Count field are activated. In this case, do the following:

• In the Starting Serial Number field, enter the serial number of the first unit in the range of units that will be generated.

• In the Count field, enter the number of units to generate.

6 Click the Generate button. The desired records are generated and imported into the SafeWord database.

7 When the Import Completed window appears, click OK.

62

Chapter 4: Using the MobilePASS featureConfiguring MobilePASS policies

Configuring MobilePASS policies

Before you can assign MobilePASS tokens to users, or allow users to self enroll with MobilePASS, you must create MobilePASS policies. These policies communicate the specific capabilities of a token device between the MobilePASS clients and the MobilePASS portals and SafeWord servers.

Token capabilities are based on a device token’s type, (event synchronous, time synchronous, or challenge response). The standard policies allow you to set a minimum of policy options, while custom policies provide an array of options, including passcode and challenge lengths, time sync intervals (ticks), allow policy downgrade, secure mode, transaction signing mode, SoftPIN, and device PIN options.

Note: In SafeWord, the term SoftPIN refers to optional PINs that administrators may require users to append to their passcodes when users authenticate. Additionally, the term device PIN is used to refer to the optional PINs that are set on software tokens when MobilePASS is activated. When enabled, device PINs must be entered on the MobilePASS application in order to generate passcodes.

Defining policies

To define policies, do the following:

1 Launch the SafeWord PremierAccess Administration Console.

2 Select Configuration > MobilePASS Policy. The MobilePASS Policy Configuration window appears. There are no existing policies at this time.

Figure 26: MobilePASSPolicy Configuration

window

63


3 Specify a name for the MobilePASS Policy. You may use Default or specify a name of your choosing.

4 In MobilePASS, Standard policies are fixed and cannot be customized. Custom policies allow you to create device tokens that meet individual organizational needs. Table 11 provides the policy parameters available with each token type. Using this information, select the type of token to which you will be applying this policy. You may choose one of the following:– Standard Event Sync– Standard Time Sync– Standard Challenge Response– Custom Event Sync– Custom Time Sync– Custom Challenge Response.

Note: For more information about event sync, time-sync, and challenge-response modes, refer back to “Authenticating with tokens” on page 12.

5 Select a desired passcode length from the Passcode Length list. You may choose a 6-digit or an 8-digit passcode. If you choose a standard policy, the length of passcode option is disabled, and the default setting displays.

6 (For custom challenge-response tokens only) Select a challenge length from the list. You may choose a 6-digit or an 8-digit challenge length.

7 (For custom time-synchronous policy tokens only) Select the interval (in seconds) before a new passcode is available from the Time Sync Interval list. You may choose 20 seconds, 30 seconds, or 60 seconds.

8 By default, the Allow Policy Downgrade check box is selected. This option enables MobilePASS to work with older client devices that do not support current version policies. If this check box is cleared, and a user’s token device does not support the current policy requirements when they enroll, the enrollment will fail. Leave the option selected or clear the check box.

9 Under PIN Options, select Collect SoftPIN (appended to MobilePASS passcode) during self-enrollment to require users associate a SoftPIN with this token. If you will not require a SoftPIN, leave this check box cleared.

Note: When you choose to collect SoftPINs, users will be required to set up a SoftPIN when they enroll their token. They will be required to append or prepend this SoftPIN to their token-generated passcode each time they authenticate using MobilePASS. This is not the user’s device PIN.

64


10 (Custom Policies Only) Secure mode allows SafeNet to react to security vulnerabilities of client devices on a case by case basis. Select the Secure Mode check box to allow SafeNet to possibly modify MobilePASS client behavior when security vulnerabilties become known.

Note: When secure mode is enabled, application updates may result in MobilePASS disabling clients that do not meet their defined security mode.

Note: The Transaction Signing Mode feature is not available in currently available MobilePASS clients.

Table 11: MobilePASS token types and capabilities

Token Type Parameters Parameter Options

Standard Event Sync

Passcode Length 6 digits (fixed)

Device PIN Length 4 digits (fixed)

Use Attack Delay Disabled (fixed)

Use Attack Lockout Enabled 10 (fixed)

Force Device PIN Change Disabled (fixed)

Allow Policy Downgrade Enabled or Disabled

Collect SoftPIN Enabled or Disabled

Standard Time Sync


Device PIN Length 4 digits (fixed)


Use Attack Lockout Enabled 10 invalid attempts (fixed)


Time Sync Interval 30 seconds (fixed)



More...

65


Standard Challenge Response


Challenge Length 8 (fixed)

Device PIN Length 4 (fixed)


Use Attack Lockout 10 (fixed)




Custom Event Sync

Passcode Length 6 or 8

Use Device PIN • Enable or Disable

• When enabled, PIN length: 4, 6 or 8

Use Attack Delay • Enable or Disable

• When enabled, attacks before delay begins: 2, 4, or 8 invalid attempts

Note: Initial delay is one minute. Increases by one minute for each failed attempt. Delay reaches a maximum at 20 minutes, and resets only upon successful device PIN entry.

Use Attack Lockout • Enable or Disable

• When enabled, attacks before lockout: 3, 6, or 10 invalid attempts

Note: The number of attacks before lockout should always be greater than the number of attacks before an attack delay.

More...


66


Force Device PIN Change • Enable or Disable

• When enabled, successful uses before device PIN change: 128, 256, or 384



Custom Time Sync


Time Sync Interval 20, 30, or 60 seconds


• When enabled, 4, 6 or 8 digits

Use Attack Delay • Enable or Disable

• When enabled, attacks before delay begins: 2, 4, or 8 invalid attempts

Note: Initial delay is one minute. Increases by one minute for each failed attempt. Delay reaches a maximum at 20 minutes, and resets only upon successful device PIN entry.




More...


67






Custom Challenge Response


Challenge Length 6 or 8


• When enabled, PIN length: 4, 6 or 8

Use Attack Delay If attack delay is enabled:

• Attacks before delay begins: 2, 4, or 8

Initial delay is one (1) minute, and increases by one minute for each failed attempt. Delay reaches a maximum at 20 minutes, and resets only upon successful device PIN entry









68


11 CIick the Save button. You have finished creating policies for this token type. You may configure another token policy, or you may close the window.

Note: Standard policies include the most commonly used features and are easy to implement. Customized policies will lengthen the policy strings. Shorter policy strings are easier for users to enter, and may result in less user entry errors.

Duplicating policies

To duplicate an existing policy, do the following:


2 Select Configuration > MobilePASS Policy. The MobilePASS Policy Configuration window appears.

3 Select the policy to duplicate from the list of existing policies.

4 Click the Duplicate button.

5 Rename the copy with an appropriate name.

6 Click the Save button.

Searching existing policies

To search for an existing policy, do the following:



3 Enter the desired policy number into the Policy field. Policy numbers can be found on the token device’s About window.

4 Click the Search button. The list of desired policies appears.

Editing existing policies

To edit an existing policy, do the following:



69


3 Select the desired policy name to edit from the list of existing policies, click the Edit button, make the desired changes, and then click the Save button.

Deleting policies

To delete a policy, do the following:



3 Select the policy to delete from the list of existing policies.

Tip: You will not be able to delete a policy if there are any users assigned it for self-enrollment.

4 Click the Delete button.

5 Click the Yes button to confirm the deletion.

6 Click OK. The policy is successfully deleted.

70

Chapter 4: Using the MobilePASS featureConfiguring MobilePASS features

Configuring MobilePASS features

Administrators can assign MobilePASS software tokens to users with the Administration Console’s MobilePASS Enrollment tool, or they can allow users to self enroll. The following features should be configured before enrolling MobilePASS users:

• Install the MobilePASS Portal

• Generate and import MobilePASS tokens

• If users will self-enroll, set up a reservation for them (see “Allowing users to self-enroll with the Enrollment Portal” on page 85)

• Configure reenrollment (see “Allowing reenrollment” on page 79)

Note: If administrators will allow users to reenroll a MobilePASS token, the allow reenrollment feature can only be used for users with one (1) MobilePASS token assigned to them.

• Configure SoftPIN collection emulation

• Configure token nickname collection

• Configure passphrase retention

The sections that follow provide configuration information for these features.

Installing the MobilePASS Portal

The MobilePASS Portal can be installed on the same machine where SafeWord PremierAccess core servers are installed, or it can be installed on another Solaris machine in the network. The following should be completed before installing the MobilePASS Portal:

• SafeWord PremierAccess version 3.2.1.06 should be installed

• SafeNet MobilePASS should be installed on the user’s client device

• The SafeWord administrator account should be set up and the default SafeWord administrator password should be reset with a new password

• Java Runtime Environment version 1.6.0 should be installed in the environment where the MobilePASS Portal will be installed

Note: Ensure JRE_HOME environment variable points to the correct JRE.

• Tomcat version 6.0 or later should be installed in the SafeWord PremierAccess environment

Note: Ensure CATALINA_HOME environment variable ponts to the location where you installed Tomcat.

71


• Tomcat must be running before installing the MobilePASS Portal.

Important: To start the Tomcat for the MobilePASS Portal when the SafeWord PremierAccess Enrollment Server is installed on the same machine, you must either (1) ensure Tomcat for the SafeWord PremierAccess Enrollment Server and Tomcat for the MobilePASS Portal are running on different ports, or (2) stop the Tomcat for the SafeWord PremierAccess Enrollment Server before starting the Tomcat for the MobilePASS Portal.

When all the requirements have been satisfied, install the MobilePASS Portal by doing the following:

1 Locate the files provided for this patch (they can be found in the directory where you untarred SPA 3.2.1.06). You should see InstallPortal.sh and MPPortal.

2 Copy the MobilePASS files mentioned in Step 1 to the machine where you wish to install the MobilePASS Portal, and then run the following command:

./installPortal.sh

3 When prompted by the script, enter the host name or IP address of the SafeWord server.

4 When prompted by the script, enter the port number of your Administration Server.

5 Modify the datastore.txt file to reflect the updated administrator credentials that were set for the administrator account. The datastore.txt file is located in the <apache_install_dir>/webapps/portal/WEB-INF/conf directory.

Note: As an alternative to modifying the datastore.txt file, you may open a browser on the local machine, connect to the MobilePASS Enrollment Portal, and set up the administrative password. Once the password has been submitted, continue to step 6 below.

6 Restart the MobilePASS Tomcat server.

Important: The SafeWord PremierAccess MobilePASS Enrollment Portal requires that Internet Explorer Active Scripting is enabled in order to render web pages.

72


Configuring the user’s maximum MobilePASS tokens

SafeWord can be customized to allow up to three (3) MobilePASS tokens per user. To allow a user more than one MobilePASS token, do the following:

1 Locate the smswebapp.ini file. It can be found at <tomcat install directory>/webapps/portal/WEB-INF/conf.

2 Open the file using Notepad or another text editor.

3 Add the following line to the file, including the chosen number of tokens you wish to allow users to enroll:

MaxMPTokensAllowed=[1][2][3]

4 Save and close the file.


To allow users with multiple tokens assigned to them to use any of their tokens, you must configure an AllowAnyToken personalization data attri-bute for those users. See “Configuring the AllowAnyToken attribute” on page 73 for details.

Important: The MobilePASS reenrollment feature is only available when users are assigned one (1) MobilePASS token. If you have assigned more than one token, ensure that the AllowedToReenroll line is set to false or the line is not present in the smswebapp.ini file.

Configuring the AllowAnyToken attribute

When a user has more than one token assigned to them, you must create a personalization data attribute that will allow that user to authenticate with any of his assigned tokens. To create the AllowAnyToken personalization data attribute for a user, do the following:

1 In the Administration Console, highlight the user name, and then select Configuration > Personalization Data.

2 Click the Add button to create a new personalization data attribute. The Create a Personalization Data Attribute window appears.

3 Enter the name AllowAnyToken in the Attribute field.

4 Enter a useful description for this attribute in the Description field. (For example, “Your Authenticator Passcode”.)

5 Select the Allow any value option.

6 Click OK.

7 Select Insert > Role.

8 Name the new role AnyTokenUsers.

73


9 Click OK.

10 Select Insert > ACL > Login.

11 Name the Login ACL Any Token, then add the following:

a On the Subject tab, select the Some Users option, click the Role check box, and then select AnyTokenUsers from the drop-down list.

b Select the Restrictions tab, click the Enabled option, select 15 from the Minimum Authentication Strength list.

c Select the Return tab, choose Success from the Authentication status list, click the Return a value on successful authentication check box, click the Personalization Data option, and select AllowAnyToken from the list, and then click OK.

12 Locate the AnyTokenUsers role you created by selecting Find > Roles, selecting Find all available > Find, double-clicking on the AnyTokenUsers role, and then clicking the Edit button.

13 Select Any Token from the Login ACL list.

14 Edit the profile for the desired user by assigning the role AnyTokenUsers and the personalization data attribute AllowAnyToken to that user. Ensure that the authenticator strength for all tokens assigned is 15.

74


Using the device nickname feature

The MobilePASS device nickname feature allows administrators and users to assign names to their assigned token devices. Nicknames make it easier for administrators to distinguish tokens for troubleshooting when a single user has multiple MobilePASS tokens assigned to them, (for example, a BlackBerry, an iPhone and an iPad). By default, the device nickname feature is not enabled. Administrators configure it by editing lines in the client.ini and the smswebapp.ini files prior to MobilePASS token enrollment.

Note: The device nickname feature is global, and applies to all future MobilePASS enrollments until the feature is set to false.

Configuring the Admin Console to collect device nicknames

1 Open the Administration Console’s client.ini file using your preferred text editor. The file is located at <install_dir>/PremierAccess/AdminConsole.

2 Edit the CollectTokenNickname parameter in the client.ini file to match the following:CollectTokenNickname=true.

3 When the feature has been set to true, save and close the file.

4 Stop and restart the Administration Console.

Configuring the MobilePASS Portal to collect device nicknames

1 Open the MobilePASS Portal’s smswebapp.ini file using your preferred text editor. The file is located at install_dir>/webapps/portal/WEB-INF/conf.

2 Add the following line or edit it to the match the following:CollectTokenNickname=true.

3 When the feature has been set to true, save and close the file.

4 Restart the MobilePASS Tomcat server by locating the <tomcat_install_dir>/bin directory, issuing the ./shutdown command, and then issuing the ./startup command.

5 Open the Administration Console and continue to either “Collecting device nicknames (admin-driven enrollment)” on page 76 or “Collecting device nicknames (user-driven enrollment)” on page 77.

75


Collecting device nicknames (admin-driven enrollment)

Administrators who choose to enroll token devices for their users, can also assign those tokens nicknames to distinguish them when multiple tokens are assigned to the same user. When configured, nicknames are collected and stored in the token records, providing administrators with an easy way to identify a specific token when a user has multiple tokens assigned to them. To enroll a token and specify a token nickname, do the following:

1 In the Administration Console, highlight the user name, and then select Tools > MobilePASS Enrollment.

2 Select Enroll Now.

3 Select the appropriate token policy, and then click Next.

4 On the device where MobilePASS is installed, start MobilePASS, complete the manual activation, and then enter the policy string that was displayed on the Administration Console wizard.

Figure 27: SelectDevice Name

5 Return to the Admin Console and select a device nickname from the predefined list, or specify your own name by selecting Other (Please Specify), and then click Next.

6 A summary screen appears. Click Finish.

7 Enter the Activation Code provided by the device into the field on the Administration Console, and then click Next.

76


Figure 28: ActionsPerformed

8 Click the Finish button on the Administration Console’s MobilePASS Enrollment wizard.

9 On the token device, click the Confirm Now button.

10 Enter and reenter a device PIN, and then click Set PIN (if required).

11 A successful activation window appears on the token device along with a new passcode.

Collecting device nicknames (user-driven enrollment)

To collect devices nicknames when users self-enroll their tokens, do the following

1 In the Administration Console, highlight the user name, and then select Tools > MobilePASS Enrollment.

2 Select User will self enroll.

3 Select the appropriate token policy, and then click Next.

4 Enter a MobilePASS Enrollment Passphrase that the user will be required to present when they enroll on the Enrollment Portal, and then click Next. The Enrollment summary window appears with the enrollment status as pending for this user.

5 Inform the user that they may now download and install MobilePASS, and enroll their token device manually. Inform them that they should use the device nickname feature when they enroll their tokens. Ensure the user knows their enrollment passphrase, and the Enrollment Portal URL. Additionally, provide the user with the following information explaing how to manually enroll and name their token device.

77


Manually enrolling and naming a token device

To manually enroll and name a token device, do the following:

1 Download and install MobilePASS onto the token device.

2 Open MobilePASS.

3 Click the Activate Now button.

4 Click the Manual Activation button.

5 Open a browser and navigate to the MobilePASS Enrollment Portal. The Portal is located at https://<IP address or FQDN of the machine where the MobilePASS Portal is installed>:5444/portal/enroll.

6 Enter a user ID and the enrollment passphase as provided by the administrator.

7 Click the Authenticate button. The Software Token Enrollment window appears with a policy string and the option to select a device nickname.

Figure 29: SoftwareToken Enrollment window

8 Return to the MobilePASS Activation window on the token device, and enter the Policy String from the Enrollment Portal onto the Policy field on the token device.

9 Click the Continue button. An Activation Code is displayed.

10 Enter the Activation Code displayed on the device into the Enter your activation code field on the Enrollment Portal.

11 Select a Device Name from the Select a nickname for your device list, or specify your own name by selecting Other (Please Specify), and then click the Enroll Software Token button. A successful token enrollment window appears. You are now ready to test the token.

12 Return to the token device and click the Confirm Now button.

13 (Conditional) Enter and reenter a Device PIN.

78


14 Click the Set PIN button. A new passcode appears.

15 Enter the passcode into the Enter software token passcode field on the Enrollment Portal, and click the Test Software Token button.

16 The successful test message appears. This completes enrollment.

Allowing reenrollment

Administrators may choose to allow users to reenroll their MobilePASS token. Reenrollment is convenient because it eliminates the need for the administrator to unassign and reassign a token to the same user.

Important: In order for reenrollment to work, MaxMPTokensAllowed cannot be greater than 1.

When reenrollment is enabled, the enrollment passphrase that the user entered when they first enrolled their token is deleted upon enrollment, so the administrator will also need to set up the user with an enrollment passphrase before the user can reenroll, or set up SafeWord to retain the enrollment passphrases upon successful MobilePASS enrollment. (See “Retaining enrollment passphrases” on page 79.)

To set up reenrollment, do the following:


2 Open the file using your preferred text editor.

3 Add the following line to the file: AllowedToReenroll=true

4 Ensure that the DeleteEnrollmentPassphrase line is set to true.

5 If the MaxMPTokensAllowed parameter exists in the file, ensure that its value is set to 1.



Note: When a token is reenrolled, the same serial number is assigned to that token as was previously assigned.

Retaining enrollment passphrases

To configure SafeWord to retain the enrollment passphrases of users upon successful MobilePASS enrollment, do the following:

1 Locate the smswebapp.ini file. It can be found at <tomcat install

79


directory>/webapps/portal/WEB-INF/conf.


3 Locate the DeleteEnrollmentPassphrase line, and set the parameter to false.



Configuring SoftPIN collection emulation

Account harvesting is a method attackers use to determine the legitimacy of user names based on mobile device behavior. SoftPIN collection is a behavior pattern attackers may attempt to use to harvest accounts. SoftPIN collection emulation prevents determining legitimate accounts from non-existent or misconfigured accounts based on SoftPIN collection. It is configured in the sccservers.ini file. By default, the feature is not enabled. It applies to automatic enrollment only, and is not necessary for manual enrollment. To configure SoftPIN collection emulation, do the following:

1 Locate the sccservers.ini file at <install_dir>/PremierAccess/SERVERS/Shared.


3 Add the following line to the file:

SoftPinCollectionEmulation=[1][2][3], where 1=always collect SoftPINs, 2=never collect SoftPINs, and 3=randomly collect SoftPINs based on the user’s ID. By default, this option is not enabled. Once enabled, it defaults to SoftPinCollectionEmulation=2, (never collect SoftPINs). The option you choose should match the MobilePASS policy that you apply to your users. If the policy collects SoftPINs, then option 1 will not allow an attacker to distinguish between real and non-existent user names.

Note: The same user ID will always produce the same result regardless of case.

80

Chapter 4: Using the MobilePASS featureAssigning software tokens to users

Assigning software tokens to users

You may choose to assign software tokens to users using the Administration Console, or you may allow users to self-enroll their software tokens using the MobilePASS Enrollment Portal. Users may choose to enroll manually or automatically from their mobile devices.

To assign MobilePASS software tokens to users do the following:


2 Select Tools > MobilePASS Enrollment, or highlight the user name, right- click on it, and then select MobilePASS Enrollment. The MobilePASS Enrollment window appears.

Figure 30: MobilePASSEnrollment window

3 If you will be enrolling your users, continue to “Enrolling users with the Administration Console” on page 81. If you are allowing users to self enroll, skip to “Allowing users to self-enroll with the Enrollment Portal” on page 85.

Enrolling users with the Administration Console

4 To enroll a user, do the following:

a Enter the user name in the User Name field.

Tip: You may also use the Find button to search for the user to whom you are assigning a token.

b Click the Enroll Now button.

c Select a policy to apply to this user’s token from the Token Policy list.

d Click the Next button. The Enter Policy String window appears.

81


Figure 31: Enter PolicyString window

5 Download and install MobilePASS on the user’s device, and then launch it.

6 Proceed through the Wizard, and when prompted, enter the policy string from the Admin Console display into the prompt on the user’s device.

7 Click the Continue button. An activation code is displayed on the device.

Figure 32: ActivationCode window

8 Return to the Administration Console, and then click the Next button. The Enter Activation Code window appears.

82


Figure 33: EnterActivation Code window

9 Enter the Activation Code from the device into the Activation Code field, and then click the Next button.

Figure 34: Confirmationwindows

10 Return to the client device, click Confirm Activation, and then click Confirm Now. If applicable, the Enter a device PIN window appears. If a PIN is not required, continue to step 12.

83


Figure 35: Enter adevice PIN window

11 If prompted, enter a 4-digit device PIN, re-enter the same device PIN, and then click the Set PIN button.

Figure 36: SuccessfulActivation window

12 Your token device displays a successful activation message and a new passcode. The Admin Console displays the status of the user token and the token policy. Click the Finish button on the Administration Console window.

84


Allowing users to self-enroll with the Enrollment Portal

1 If you will allow users to self-enroll, do the following:

a From the Administration Console, select Tools > MobilePASS Enrollment. The MobilePASS Enrollment window appears.

b Enter a user name in the User Name field, or click the Find button to search for the user to whom you are assigning a token.

c Click the User will self-enroll button.

d Select a policy to apply to this user’s token from the Token Policy list.

e Click the Next button. The Enrollment Passphrase window appears.

Note: The passphrase must be at least four (4) characters in length.

Figure 37: EnrollmentPassphrase window

2 Choose a MobilePASS enrollment passphrase and enter it in the field. Users will be required to enter this passphrase when they self-enroll.

Important: You must ensure that the user knows the passphrase they will need to enter when they self-enroll using the Enrollment Portal.

3 Click Next. The Enrollment Status window appears displaying the enrollment status as Pending.

Figure 38: EnrollmentStatus - Pending window

85


4 Click the Finish button.

5 Notify your user to download and install the MobilePASS application on their mobile device, and enroll their token device with the MobilePASS Enrollment Portal. For detailed information about using MobilePASS, administrators and users should refer to the SafeNet MobilePASS Administration Guide, which is available for download from the corporate site at http://www3.safenet-inc.com/safeword/docs/swpa.aspx.

Note: Administrators may configure up to three (3) MobilePASS tokens for a user. If a user will be enrolling more than one token, they cannot use the reenrollment feature. See “Configuring the user’s maximum MobilePASS tokens” on page 73 and “Allowing reenrollment” on page 79 for details.

Verifying enrollment reservations

To verify that your users can enroll their tokens using the Enrollment Portal, do the following:

1 Open the Administration Console.

2 Locate the user for whom you are verifying the enrollment reservation.

3 Right-click on the user name and select the Edit option.

4 Select the Personalization Data tab.

5 Verify that the MPEnrollmentPwd PD attribute with an encrypted value exists for the user and the MPPolicyAssigned PD attribute exists with the correctly assigned policy for this user. By default, both PDs are removed from the personalization data upon successful activation.

Note: The MPEnrollmentPwd PD attribute component is a new feature. There is an existing DeleteEnrollmentPassphrase parameter in the smswebapp.ini file that allows you to delete or retain the enrollment passphrase after a successful manual or automatic enrollment. By default, both PD attributes will be removed. Administrators may set the DeleteEnrollmentPassphrase parameter to false to keep the PD attributes and retain the existing passphrase, even after a successful manual or automatic enrollment. For details, see “Retaining enrollment passphrases” on page 79. If you wish to allow users to reenroll their MobilePASS token, refer to “Allowing reenrollment” on page 79.

If you wish to allow users to reenroll their MobilePASS token, refer to “Allowing reenrollment” on page 79.

Note: Ensure that the MPEnrollmentPwd PD attribute does not get deleted until all users with the attribute have successfully enrolled.

For more detailed information about personalization data, see “Understanding personalization data” on page 161.

86



Disabling the software token enrollment feature

To disable the software token enrollment feature, do the following:


2 Locate the following line:

DisableSoftwareTokenEnrollment

3 Set the parameter to true.



Disabling software token manual enrollment

To disable software token manual enrollment, do the following:


2 Open the file using Notepad or another text editor

3 Locate the following line:

DisableManualEnrollment

Important: When this parameter is set to true, only manual enrollment is disabled; automatic enrollment will remain enabled.

4 Set the parameter to true. By default it is set to false.



87

Chapter 4: Using the MobilePASS featureSoftware token enrollment

Software token enrollment

Users can enroll their software tokens without the assistance of the administrator using the MobilePASS Enrollment Portal. The sections that follow describe how to use MobilePASS Enrollment Portal.

Using the MobilePASS Portal

The MobilePASS Portal provides end users with a convenient interface for enrolling software tokens without the help of the administrator. For organizations with a large number of users, this feature lightens the administrative effort when tokens are assigned to users. Once software tokens are enrolled, users can request token passcodes from their device, and use them to log into resources protected by SafeWord.

Changing and updating your admin server credentials

The first time you access the MobilePASS Enrollment Portal, you are required to update the administrator credentials. If you have not done so yet, you must update these credentials before users can access the MobilePASS Portal. To update the administrator credentials, do the following:

1 Open a web browser on the machine where MobilePASS is installed, and browse to the MobilePASS Portal URL (https://<machine_name:port>/portal/enroll). The default MobilePASS port is 5444.– If this is a new installation, the Admin Credentials window appears

(Figure 39 on page 88) with instructions for changing your administration server credentials. In this case, continue to step 2.

– If this is an update to an existing installation, and you have changed the default administration password, the Update Admin Server Credentials window appears (Figure 40 on page 89). In this case, skip to step 3.

Figure 39: ChangeDefault Admin Server

Credentials window

88


2 Before continuing, change the password for the administrator account on the administration server by doing the following:

a Launch the Admin Console.

b Expand the Reserved folder, click Users, and then highlight the username Administrator.

c Click the Edit button, select the Authenticator tab, then click Properties.

d Change the default administrator password.

e Restart the SafeWord Administration Server service.

3 Update the administration server credentials.

Note: The MobilePASS Portal will only allow access to the administrative password pages from a localhost internet browser connection.

Figure 40: UpdateAdmin Server

Credentials window

4 Enter your Admin Server user ID and your Admin Server password.

5 Click the Update Credentials button. The next SafeWord MobilePASS Portal window appears with a prompt to restart the SafeWord MobilePASS Portal service. Close the Web browser.

Figure 41: MobilePASSPortal Restart Services

window

89


6 Restart the MobilePASS Portal service using the following commands:– <tomcat_install_dir>/bin/shutdown.sh– <tomcat_install_dir>/bin/startup.sh

90


Using the Enrollment Portal

Software token users can enroll and test their tokens using the SafeWord Enrollment Portal. To open the portal and enroll, do the following:

1 Browse to the SafeWord Enrollment Portal at https://<servername:port>/portal/enroll. The SafeWord Software Token Enrollment page appears. By default, port 5444 is used.

Figure 42: Pre-authentication window

1 Enter your user name and the passphrase provided to you by your administrator, and then click Authenticate. The Activation Code window appears.

Figure 43: ActivationCode window

2 If your software token supports policy string entry, enter the number displayed on the Console into the Policy field on the token to display your activation code, and then click Continue. Otherwise, ignore this information and continue to the next step.

91

https://localhost:5444/portal/enroll


3 Enter the 20-digit Activation code that displayed on your device when you ran the MobilePASS software.

4 Click Enroll Software Token. The Test Software Token window appears.

Figure 44: TestSoftware Token window

5 Confirm the activation on your device. After confirming the activation, MobilePASS will generate a passcode. Enter this passcode in the browser’s Software Token Passcode field, and then click the Test Token Software button.

Figure 45: Token TestResults windows

6 Either a Successful Token Test window or a Failed window will appear. • If your test failed, the Failed Results window appears, enter a new

passcode in the Enter software token passcode field, and click the Test Software Token button.

• If your test was successful, the Successful Token Enrollment window appears. You may close the browser.

A. Failed Token Test window

B. Successful Token Test window

92

5CHAPTER Setting Up Access

Controls

In this chapter...

Editing the PremierAccess configuration........................................94

Working with admin groups, ACLs and roles ...............................100

Implementing your access control policy......................................113

Understanding Web ACLs............................................................115

93

Chapter 5: Setting Up Access ControlsEditing the PremierAccess configuration

Editing the PremierAccess configuration

As a system administrator, you have access to screens that allow you to edit the PremierAccess configuration to meet your organization’s individual needs. Table 12, “Configuration fields and functions,” lists the tabs, fields, and functions that are available to you.

Table 12: Configuration fields and functions

Tab Field Function

General Attacks before lockout

Sets the number of unsuccessful authentication attempts before the user is locked out of the system. This protects your users from brute force attacks.

AAA clears attack locked account

Clears an account that was locked as a result of a brute force attack.

Clear lockout after (min)

Sets the minimum lockout time value. This is the period after which the attack lock will automatically reset.

Note: The attack lock will not be cleared until the first successful authentication after the minimum duration has elapsed.

Agent polling interval (min)

Sets the time interval with which the UWA will poll the AAA Server for updates to Web ACLs.

Max search results

Large search results will be returned in batches of this size. The console will feel more responsive with a lower batch size.

Unregistered User ID

The username under which authentication will proceed if an invalid username is supplied. Changing these values is not recommended.

Default Role System default -- points to the default ACL. This value is customizable.

Default Login ACL

System default -- no restrictions. This value is customizable.

Use verbose logging

Allows for more extended entries in a log file.

Servers Log Server TCP address and port of the Admin Server that functions as the Logging server.

More...

94


There are three tabs related to configuration settings. The sections that follow describe how to reconfigure the options on each of them.

Configuring General settings

To reconfigure the General tab settings, from the Admin Console, select Configuration -> PremierAccess. The Edit PremierAccess Configuration window displays the General tab.

Figure 46: EditPremierAccess

Configuration window(General tab)

)

Sessions Session Duration Timeout (Number of hours/minutes)

Sets the maximum time limit for user sessions in hours and minutes.

Session Inactivity Timeout (Number of hours/minutes)

Sets the time limit before automatic logoff for inactive user sessions in hours and minutes.

Tab Field Function

95


Reconfiguring attack lockout options

One of the many security features of PremierAccess is attack lockout. If a user account becomes the target of a brute force attack, PremierAccess will lock out the user record, rendering the attack powerless. To change the attack lock out setting:

1 In the Attacks before lockout field, specify the number of consecutive unsuccessful login attempts that will constitute a brute force attack. Once an account has been locked, it will remain so for a configurable amount of time.

2 Clear the AAA clears attack-locked accounts check box if you do not what PremierAccess to clear the locked out user automatically.

3 In the Clear lockout after field, specify the minimum duration that the account will remain locked.

Note: The attack lock will not be cleared until the first successful authentication after the minimum duration has elapsed. As an alternative, administrative users can clear the lock at any time by editing the locked user account.

Reconfiguring agent polling intervals and maximum results

To change the time intervals or the length of results for the Universal Web Agent to poll the AAA Server for updates to the Web ACL:

1 In the Agent polling interval (min) field, enter the time interval that will lapse before the UWA polls the AAA Server.

Note: The UWA periodically gets access policy updates, invalidated sessions, and other data from the AAA Server.

2 In the Max search results field, enter the maximum number of results to be returned. Large search results will be returned in batches of this size.

Tip: The console will feel more responsive with lower batch sizes.

Reconfiguring the unregistered user ID

The unregistered user ID field contains the name BAD_USER_ID. When an unregistered user attempts to log in, the BAD_USER_ID is triggered and it prompts the unregistered user to enter a platinum token-generated passcode. In most instances, you would not want to change this field, however some organizations do choose to change the field in order to trigger a prompt that is consistent with that of their other users. In that case you would:

1 (Optional) Change the BAD_USER_ID properties so the passcode prompt matches the authenticator used by your other users.

2 (Optional) In the Unregistered User ID field, specify a user ID under which authentication should proceed if an invalid username is supplied.

96


Reconfiguring the default role

If a user is not assigned specific roles, they are automatically assigned the default role by PremierAccess. To change the default role that gets assigned to these users, in the Default role field, highlight the default role, and enter a new role in its place. This is the role that will automatically be assigned to users if they have no roles explicitly assigned.

Reconfiguring the default login ACL

All requests for access to resources are processed through one or more access control lists (ACLs). These ACLs are a collection of access rules that are defined for a set of resources being protected. All users must be authorized by a login ACL, and if none is explicitly assigned, the default login ACL is applied.

To change the default ACL, in the Default Login ACL field, highlight the existing text, and enter a different login ACL in its place. If none of the user’s roles (explicit or implicit) refer to a login ACL, the AAA Server consults this ACL during authorization.

Reconfiguring logging

Each time there is an access request, the date and time of the request, whether the authentication passed or failed, and any authorization violations are logged in an audit log file. To allow more extended entries in the log file, click the Use verbose logging check box.

Configuring the log server

The Servers tab is used to specify the IP address and the port of the log server that handles all audit log archive operations. If your deployment includes more than one admin server, you must designate which one will perform audit log operations. If your deployment only has one admin server in it, that server’s IP address and port number are automatically populated in the hostname log server and port fields. To access the Servers tab, from the Admin Console, select Configuration -> PremierAccess.

1 When the Edit PremierAccess Configuration window appears, click the Servers tab.

97



Configuration window(Servers tab)

2 Set or confirm the following Servers tab configurations:

a In the Log Server field, enter the Hostname or IP Address of the Admin Server in your network that will perform audit log operations. The Admin Server handles audit log archive operations.

b In the Port field, enter the Port that the Admin Server is using.

Configuring Sessions

The Sessions tab allows you to set the duration sessions will last. You can also set the duration before a session times out as a result of inactivity. To set these options, from the Admin Console window, select Configuration -> PremierAccess, and then click the Sessions tab.


Configuration window(Sessions tab)

98


As of this release, only the Web agents create a session upon a user’s successful authentication. This enables our single sign-on solution across our Web agents.

1 On the Sessions tab, specify the maximum lifetime of a single session by selecting the Number of Hours and Number of Minutes for user sessions.

2 You can force a session to expire if the user has been idle or inactive for a period of time. To force a timeout, select the Use session inactivity timeout check box.

3 Select the Number of Hours and the Number of Minutes of inactivity to allow before the session automatically times out.

4 Click OK.

5 Restart your servers as directed by the Admin Console. The latest configuration settings will then take effect. For information about starting and stopping servers, refer to your Installation Guide.

99

Chapter 5: Setting Up Access ControlsWorking with admin groups, ACLs and roles

Working with admin groups, ACLs and roles

The sections that follow describe how to create admin groups and subgroups, login ACLs, and roles.

Creating admin groups and subgroups

There are two types of admin groups in PremierAccess, global and nonglobal. Global groups contain data any administrator, no matter what level they have been designated, can access. This means system level administrators, local administrators, and helpdesk staff can all view data contained in these groups. Non-global groups contain data whose access is restricted to system and lower-level administrators with specific management duties for the particular groups. When you create a new group, you specify whether or not it will be global.

Important: Users cannot be placed into global groups, thus preventing local administrators and helpdesk staff from having unintended access to data they do not have permission to access.

To create a new admin group or subgroup, on the left panel of the Admin Console, select the Admin Group under which you want the new group or subgroup to appear (USERS, for example). If the group is to be a top-level group, select the top-most group folder (for instance, Admin Groups). Subgroups are groups nested beneath admin-level groups. Administrators who manage a group also manage the subgroups inside their group.

1 Select Insert -> Admin Group. If this is a subgroup (as in Figure 49), the parent group is identified in the Parent Group field.

Figure 49: Create a NewAdmin Group window

2 Enter a name in the Admin Group field. The name should be something meaningful, such as a region or department.

3 (Optional) Select the Globally Visible check box if this is a group that will not contain users. This allows other administrative-level users access to this group’s contents.

4 Click OK to create the group.

100


Creating login ACLs

Access Control Lists contain the access rules that define your security policy. PremierAccess uses two types of ACLs, login ACLs that govern who gets into your network, and Web ACLs that govern access to your Web resources. Your software comes pre-populated with a default login ACL and a default Web ACL. You can use the default ACLs as templates when you create your own ACLs.

Important: We strongly recommend that the default ACLs, DEFAULT_WEB_ACL and DEFAULT_LOGIN_ACL be left intact. This will keep you from accidently locking yourself out of your system. Please use care if you decide to modify the default ACLs.

Login ACLs work with non-Web-related PremierAccess agents to restrict access to your network services. You can restrict access based on a PremierAccess agent, an individual user, an application, IP address, or a role.

1 To create a login ACL, select Insert -> ACL -> Login.

Figure 50: Create a newLogin ACL

2 Enter a name for this ACL in the ACL field.

3 From the Admin Group list, select the admin group to which you want to assign the ACL. You may use the GLOBAL_DATA admin group, or select another one for this ACL.

4 (Optional) Enter comments you wish to display to users in the Comments field.

5 Click OK. The initial set up of this login ACL is complete, and you are returned to the main Admin Console window. You can define access rules within this ACL by referring to “Creating login ACL entries” on page 104. To create roles to assign to users, refer to “Creating roles” on page 102.

101


Understanding roles

Before creating roles, you must have at least one login ACL created, as each role must point to a login ACL. Additionally, a role can only point to one login ACL. As you create each role, you point it to the ACL that provides the security policy definition for it, specifically, the ACL that contains an entry with that role as its subject.

If you have not created a login ACL, refer to “Creating login ACLs” on page 101. When you have created a login ACL, you are ready to start creating roles to assign to your users.

Roles are not required, but they can be very powerful tools to help you manage the access needs of your users. A role is a tag that identifies a user’s access privileges. Roles are generally associated with login ACLs. In PremierAccess, a role is only a label, and is generally meaningless without a supporting login ACL.

Tip: One important thing to remember when naming your roles, is to use a naming convention that describes what the role does, or who the role affects. For example, role names such as “Executive_role”, “HR_role”, Weekday_dayshift_role”, or “No_weekend_role” offer visual clues about the function of those roles. Note however, that this convention only works if the access rules that you define in the associated login ACL provide relevant security policy definitions for that role. For example, a role called “nightshift” should point to an ACL that defines an access rule that maps the “nightshift” role to the blocks of time within the work week that comprise the nightshift within your organization.

Creating roles

To create a role, from the Admin Console, select an Admin Group where the roles will be placed. Generally, roles are placed in a global group that will be accessible to all administrators. If you want to restrict accessibility, select a non-global admin group. Select Insert -> Role. The Create a New Role window appears with the General tab displayed.

102


Figure 51: Create a newrole (General tab)

1 Enter a name in the Role field.

2 Select a group from the Admin Group list. The Admin Group is the group to which this new role will be assigned. The default setting is based on the group that was highlighted at the time you began the role-creation process. You can select another if desired.

3 Select a login ACL from the Login ACL list. A role must point to a login ACL. If no login ACL is selected, the default login ACL, as specified in your PremierAccess configuration (see “Reconfiguring the default login ACL” on page 97), will be used.

Note: The Personalization Data tab is discussed in “Understanding personalization data” on page 161.

4 Select a priority from the Priority list. The valid input range is 1 to 999. Priorities come into play when a user has more than one role assigned to them. During authorization, the AAA Server works with only one role at a time. It will choose the highest priority role or the default role if no role was assigned. If no match within the role’s referenced login ACL is found, the next lower priority role is checked. This process continues until a match is found that meets whatever criteria is relevant to the login attempt.

5 Enter any comments in the Comments field. At this point there is no personalization data available to apply to this role. If you want to add data to the role, see “Understanding personalization data” on page 161. Otherwise your new role is complete.

6 Click OK to create the role.

103


Understanding login ACL entries

The most important components of an ACL are the individual entries contained within it. They specify the access rules of your security policy. When a user attempts to access your network, the circumstances of that attempt (day/time, requested resource, etc.) must meet the permission criteria of at least one matching ACL entry in order for successful authentication and authorization to occur. The wide range of ACL entries gives you a great deal of flexibility in how you define the access permissions for your users. Each entry is defined by the data you specify in three ACL entry panels. These panels are:

• the subject panel (where the user, role, IP address, or agent information for this entry is specified)

• the restrictions panel (where restrictions placed on the subject are listed)

• the return value panel (where values that will be returned to an agent upon either successful or unsuccessful authentication attempts are specified)

The login ACL entry targets users by subject (the user, role, application, IP address range, etc.), and can allow unrestricted access or allow no access at all. It can restrict by a combination of authentication strength, date ranges, or times of day.

Creating login ACL entries

The procedure that follows includes steps for creating ACL entries for new ACLs and for existing ones.

Creating entries for a new ACL

To create ACL entries for a new login ACL, from the Admin Console:

1 Select Insert -> ACL -> Login.

2 Enter a name for the new ACL.

3 Click the New button.

To define the subject for this ACL entry, refer to “Defining an entry’s subject” on page 105. To define restrictions for this ACL entry, refer to“Defining entry restrictions” on page 106. To specify return values for an entry, see “Specifying return values for an entry” on page 110.

Creating entries for an existing ACL

To create ACL entries for an existing login ACL, from the Admin Console, select Find -> ACLs ->Login.

1 When the Find ACLs window appears, choose Find all available to locate the ACL to which you want to add entries.

104


2 In the Find Results ACLs list, double-click the ACL to which you want to add entries. The View ACL window appears.

3 Click the Edit button to display the ACL you want to modify.

To define the subject for this ACL entry, refer to “Defining an entry’s subject” on page 105. To define restrictions for this ACL entry, refer to“Defining entry restrictions” on page 106. To specify return values for an entry, see “Specifying return values for an entry” on page 110.

Defining an entry’s subject

The Subject is the first part of the ACL entry. It defines the set of users to whom the other parts, the Restrictions and the Return values of the entry will apply.

Figure 52: New ACLEntry window (Subject

tab)

Tip: Minimize creating ACL entries that have a single user ID as the subject. If your organization has a large number of users, the number of ACL entries would become quite overwhelming. Instead, identify the common access requirements across your users, and factor those common requirements out. For example, you might identify common roles or machine IP addresses. An ALL entry should target a specific userid only if that user has a particularly unique access control requirement.

1 To select the Subject for this entry, either click All Users to apply this rule to all users, then skip to “Defining entry restrictions” on page 106, or click Some Users to narrow down the set of users to which this entry applies. If you choose this option, continue to the next step.

2 Choose from the following options to apply to the entry:– Click Role to apply this access rule to users with a specified role. If you

have already created roles, and you want to apply one to this entry, select it from the Role list.

105


– Click IP to apply this access rule to users attempting to access a specific resource’s IP address, or resources within a specified range of IP addresses (including wildcards, for instance 196.168.24.* or 192.168.24.1-100). You can also use the host name in place of the IP address.

Note: The IP address can vary depending on the agent type. For instance, if you are using RADIUS, you would enter the IP address of the RADIUS client (for instance, VPN Concentrator), but if you are using SID2, you would enter the IP address of the UNIX box. In the first case, the IP address is not the IP address of the agent. The agent is technically the RADIUS Server, but, in order for the rule to make sense, you would use the IP address of the RADIUS client (the machine you are trying to protect). In the second case, you are using SID2 as the agent. The agent is on the machine you are trying to protect, so that is the IP address you would use. Each agent falls into one of these two categories.

– Click Agent/Application to apply this access rule to users attempting to access resources via a particular PremierAccess agent or custom application.

– Click User to permit or deny access to a specific user. You may not specify a user by alias, you must use their primary name.

Defining entry restrictions

To define restrictions for an ACL entry, from the New ACL Entry window, click the Restrictions tab. Restrictions apply to the users targeted on the Subject tab whenever those users request access.

1 Select the Define a set of restrictions check box. The other options on the window become active. If you do not want to define restrictions for this entry, leave the Define a set of restrictions check box clear and continue to “Specifying return values for an entry” on page 110.

Important: Clearing the check box disables all other selections in this panel, and results in no restrictions being defined for this ACL entry. Restrictions will be taken from the next matching ACL entry. Generally, your ACL entries will define a set of restrictions.

2 Choose either to allow unrestricted access, to allow no access, or to define access restrictions.– By selecting Unrestricted Access, users who are targeted on the

Subject tab will be given access to the requested resource if they pass authentication. No authorization phase will be conducted.

– By selecting No Access, users who are targeted in the Subject tab will not be given access to the requested resource, even if they pass the authentication phase.

If you select unrestricted access or no access, continue to “Specifying return values for an entry” on page 110.

106


– Click Grant access if the user meets these restrictions to define restrictions. The Minimum Authentication Strength restriction is automatically selected.

Figure 53: New ACLentry (Restrictions tab)

Defining an authentication strength restriction

If you do not want to restrict this entry by authentication strength, select Disabled and skip to “Defining a date range restriction” on page 108. To restrict access by authentication strength, select Enabled, select a Minimum Authentication Strength from the list, and then click OK. The New ACL Entry window appears with the minimum strength defined.To restrict access by authentication strength, click the Edit button. The Edit Restriction window appears.

Figure 54: Editrestriction window

Authenticator profiles define the characteristics of a class of authenticators. One characteristic is the strength of a particular type of authenticator. It represents how “strong” (and thus how secure) the class of authenticators are considered to be. For details about authenticator profiles, see “Adding, changing or removing authenticators” on page 144.

By setting authenticator strengths for protected resources you can pre-determine what type or combination of authenticators will be required for access to those resources.

107


For example, if you created an ACL entry that protects a Web-based banking application with an authentication strength of 17, a user attempting access must possess sufficient authenticators that also sum or surpass 17 (possibly a fixed password of strength 5 and a hardware authenticator of strength 15). The higher the number, the greater the required strength for access.

Table 13, “Authenticator strengths,” outlines default authenticator strengths for some of the authenticators supported by PremierAccess.

Table 13: Authenticator strengths

Defining a date range restriction

Selecting a date range means users attempting access to the resources targeted in the Subject panel must do so within the specified dates.

Authenticator Type Default Strength

Fixed password 5

Emergency fixed password 20

Alpine token 10

MobilePASS authenticator 10

Silver hardware authenticator 15

Gold 20

Platinum 20

eTokenPASS 10

Digital certificate (see note) 10

SofToken II 10

Note: A digital certificate stored in a smart card is much stronger than the same certificate stored in your browser, so you may want to adjust the strength of digital certificate authenticators depending on your method for implementing this technology.

Note: The Emergency fixed password should only be used by administrators or helpdesk staff to temporarily assign a fixed password when a user has lost or otherwise compromised their authenticator.

108


Figure 55: Range ofdates restrictions window

If you do not want to restrict this entry by date range, click Disabled, then skip to “Defining day/time restrictions” on page 109. To set a date range when access will be restricted for the users or resources targeted in the Subject panel, double-click Range of Dates (or select it and click Edit), then click Enabled. Set the Beginning with date by month, day, and year, and then set the Ending with date by month, day, and year. When you are done, click OK. The New ACL Entry window appears with the range of dates defined.

Defining day/time restrictions

To restrict access for the users or resources targeted in the Subject panel by time of day, double-click Time of Day (or select it and click Edit) to specify hours and days for access. The Day/Time Restrictions window appears.

Figure 56: Day/TimeRestrictions window (withexample M-F 0730-1700)

Users will only pass authorization if they meet the day/time criteria you set here. If you do not want to restrict this entry by time of day, click Disabled, then skip to step on page 110. To restrict the entry, click (and hold) in the grid box that intersects the day and start time (e.g. Mon 0700), and drag to the stop time (e.g. Fri 1630). This sets access times for Mon-Fri, 0700 to 1630. The entire field of access time will highlight in green. Click OK to set your time choices.

109


Specifying return values for an entry

To specify return values for this entry, from the New ACL Entry window click the Return tab.

Figure 57: New ACLEntry (Return tab)

Generally, you do not need to use this tab unless you are defining access rules for resources protected by PremierAccess SSL agents. If you are creating an ACL entry where the Subject tab targets a particular resource protected by SSL, or a custom agent created using the Authentication SDK, you will need to specify return value information. The return value is not presented to the user, it is used by the SSL agent after an authentication attempt. Return values also appear in the audit log when a user authenticates.

1 Select a status from the Authentication status list (either Success or Fail). If you do not want a value returned to the agent in either case, leave the Return a value on successful authentication... check box clear.

a Click OK.

b Skip to “Editing ACL entries” on page 111.

2 To return a value, select the check box. The options are activated.

a Select a value (0, 1) to return on pass or fail.

b Enter a specific text string (e.g. “Authorization Passed” or “Authorization Failed”) in the Text field. This field could also be used to pass text related to a specific role, or for Web server plugin information. You can also use this field to return an application-level role (such as “bank_app_admin”, or “bank_app_user”).

c Select an attribute from the Personalization Data list. If the user has this personalization data defined, it will be returned to the agent.

d Select PremierAccess Roles to return the user’s PremierAccess role(s) upon either successful or failed authentication.

110


3 When all choices for this ACL entry are made, click OK. The new entry appears in the Rule list under ACL Entries. Entries are numbered according to the order in which they were added. The Subject list displays the subject entry you created in the previous steps.

Figure 58: ACL windowwith entry

When you create additional entries, each one will be assigned an incre-mental number.

Editing ACL entries

To edit an ACL entry, select Find -> ACLs -> Login. The Find Login ACL entries window appears.

Figure 59: Find ACLentries window

1 Use either the Find all available, or Find all that match filters to locate the ACL you created earlier.

2 Choose one of the following:– to immediately export the data you are retrieving, click the Export button

and choose the location where you want to save the data as a report. Once the data is saved to a report, you may view the report by selecting Yes at the next prompt. If you do not want to view the data at this time, select No. You are returned to the main Admin Console window.

111


– To view the ACL without exporting the data, click Find. The Find Results: ACL Entries list appears. Continue to the next step.

3 Select the ACL you want to edit from the list of entries. The View Login ACL window appears.

4 Click the Edit button to display the ACL. The process for editing an ACL entry is the same as the process for creating entries. If you are not sure about how to edit this ACL entry, see step 1 on page 105.

Ordering ACL entries

Login ACL entries are evaluated sequentially, from the first entry in the list to the last. This processing sequence means that any user logon attempt will first be matched against the subject of the first ACL entry. If the subject matches, access and/or authorization will proceed. If not, the next entry in the ACL will be evaluated.

Since the evaluation process goes from the top entry downward, you will want to order your entries from most restrictive (top) to the least restrictive (bottom). Placing the least restrictive entries higher in the list opens your system up to a larger number of users. You may want to insert an ACL entry that targets “All Users” last in the list since it will catch all users. If you do not place an entry that targets “All Users,” and no match is discovered as the ACL is processed, the AAA Server will consult the user’s next highest priority role to determine the next ACL to process. This may or may not result in the processing of the same ACL, or an entirely different one. Any entry placed below an “All Users” entry will be ignored.

To change the order of the ACL entries, select Find ->ACLs -> Login. The Find Login ACL entries window appears.

1 Select the Find all available filter to locate all ACLs.

2 Click Find. The Find Results: ACL Entries list appears.

3 Select the ACL that you want to update.

4 Click the Edit Entry button.

5 When the Edit Login ACL window appears, select individual ACL entries and click the arrows to the right of the entry list until your ACL entries are reordered as desired.

112

Chapter 5: Setting Up Access ControlsImplementing your access control policy

Implementing your access control policy

When configuring PremierAccess, it is imperative that you have a keen understanding of your organization’s security policy. When you are confident of your security policy, you are ready to implement it. You will use the processes that have been outlined previously in this chapter to implement your policy.

There are two basic methods you can use to implement your policy. While these methods are provided for you, they are not the only ways you can implement your policy. You can vary and combine the steps, or devise your own implementation.

Method 1 - Similar users grouped by role

If your organization is composed of groups of users who are treated exactly the same as each other regardless of where they are entering your network from, this method should work best for you. For example, if all your sales staff are treated the same, all your human resources staff are treated the same, all your marketing staff are treated the same, but the three departments are treated differently, do the following:

1 Create an ACL for each group of users in your organization, for instance, one ACL for Sales, one for Resource, and one for Marketing.

a Create one access control entry (ACE) for each access point (agent) that this group will use.

b Use the agent name as the Subject for the ACE. Consult agent documentation to determine the names of your agents.

c In the Restrictions panel, choose the Unrestricted Access option to give explicit permission for those users to access this resource. If you would like to further restrict access to this resource, you may decide to grant access based on authentication strength, time of day, or range of dates. Use them as your needs require.

d Now that you have created ACL entries to which you want to allow access, you will create a final rule that denies access to any other resource. Create an ACL entry that targets “All Users,” and has a restriction of “No Access.” This way you can ensure that users being processed through this ACL are not mistakenly given access through an access point that has not been explicitly specified.

2 Create a role for each ACL, for instance, if you have created an ACL called “Sales ACL,” you will want to create a role that points to the “Sales ACL.” Repeat the same process for the other functional ACLs that you have created.

3 If your users have not been created yet, consider using the Enrollment Server, which lets your users enroll themselves into the system with a Web browser. If you users have already been created, you can use the “Apply Roles” feature of the Admin Console. Assign only one role to each user.

113

Chapter 5: Setting Up Access ControlsImplementing your access control policy

Method 2 - Multi-role users

This method is a little more complex, but is also more flexible. Users are assigned a role for each access point and each access point has an ACL. If your organization’s users are not easily grouped, and you want to use ACEs to differentiate roles, do the following:

1 Create an ACL for Agent #1 and call it ACL #1. Do not create ACEs for this ACL yet.

2 Determine the total number of ways your users are treated when they come into your network using Agent #1.

a Create a role for each way a user can be treated coming into your network using Agent #1.

b You may also want to create a role for users who will NOT be allowed to come in using Agent #1.

c Point each role for this agent to ACL #1.

3 Define one ACE for each role.

a The Subject will be the agent name and the role.

b In the Restriction field choose No Access. Authentication strength, Time of day, and Range of dates may or may not apply. Use them as your needs require.

c The Return value will be unique for each role.

4 Assign one agent-specific role to each user.

5 Repeat this process for each agent you will be using in your network.

Note: When creating the roles, select names that tell you what agent they apply to, and what level of access should be granted. For example, RADIUS_TECH, RADIUS_SALES, RADIUS_GENERAL.

114

Chapter 5: Setting Up Access ControlsUnderstanding Web ACLs

Understanding Web ACLs

A Web ACL is a list of Web ACL entries or rules that govern access to individual URLs and their content on your Web servers. Universal Web Agents use Web ACLs to enforce your Web security policy. In order to protect your Web servers, the UWA must be installed on all Web server machines you want to protect.

Each Web ACL entry has three parts:

• the protected URLs - users can specify HTTP hosts and/or path names for specific URLs, or can choose to match all URLs

• restrictions - restrict access to the URLs based on roles, IP address, time of day, date range, or authentication strength

• personalization data (optional) - allows extra information about the user to be sent to the server or back to the client (browser).

The UWA uses exactly one Web ACL to control access to the Web applications and resources that it protects. The UWA checks the rules in order until one matches the URL that is being requested by the user. When a rule matching the URL is found, that rule is checked for any restrictions (such as time of day, or role), and to see if any personalization data has been requested to be sent to the Web application or the Web browser.

115


Tip: If you require further assistance with your organization’s access control deployment, SafeNet offers an access control deployment course. Details about this course and others currently open for enrollment, can be found at www.safenet-inc.com or by contacting your sales representative.

For information about installing and configuring the Universal Web Agent, see the Universal Web Agent Administration Guide, a PDF available for download from www.safenet-inc.com.

Creating a Web ACL

To create a Web ACL, from the Admin Console, select Insert -> ACL -> Web. The Create a New Web ACL window appears.

Figure 60: Create a NewWeb ACL window

1 Enter a name in the ACL field.

2 Select an admin group for this ACL from the Admin Group list.

Tip: To view the properties of an Admin Group, click the View button next to the Admin Group field.

3 Click the New button under ACL entries. The New Web ACL window appears with the Protected URLs tab displayed.

116




Figure 61: New WebACL Entry window

(Protected URLs tab)

Specifying URLs to protect

You may choose to protect all URLs on a targeted Web server, or specific URLs. To protect all URLs, select All URLs. Choosing this option will disable all other options on this panel. If you choose this option, continue to the Restrictions tab and “Setting URL restrictions” on page 119, otherwise select Specific URLs and continue with this procedure.

Note: If the resource being used is not on the list, it is passed through unprotected.

1 Click the Add button. The Add URL window appears.

Figure 62: Add URLwindow

(O

2 (Optional) In the Domain Name field, enter the name of the location where the Web server resides. For example, if the Web server location is www.safenet-inc.com, you would enter safenet-inc.com.

Important: If you do not specify a domain name, the Web ACL applies to all Web servers. If you specify a domain name, the Web ACL applies only to that Web server.

3 Enter the path part of the URL in the Path field. This may be a path to a directory, or to a specific file or application. If a directory is specified, all subdirectories will be protected too. Asterisks can be used as wildcards. For example: /protected/* will protect all resources in the protected directory, and all resources in the subdirectories. /regforms/register.html will protect only the register.html page. /cgi_bin/bbs* will protect all applications whose name starts with bbs.

117


4 (Optional) In the Arguments field, enter the URL arguments that you want matched. You may use wildcards. If you do not enter a value here, the program automatically matches wildcards. Arguments are matched in the order they are entered.

5 When you enter arguments, you must specify how to treat escape sequences. Choose one of the following options:– Treat escape sequences as text (the default)– Treat escape sequences as binary data.

6 The UWA automatically adds headers that do not allow protected content to be cached. To turn this feature off for this URL, select the check box label Don’t add cache control HTTP headers.

Tip: The UWA does not recognize the ^ symbol in PremierAccess version 3.2.

7 Click OK. You are returned to the Protected URLs tab.

8 Under HTTP Methods:– click All to activate all available methods and disable the list. If you

choose this option, continue to “Setting URL restrictions” on page 119. – click Specific to apply specific HTTP methods for this ACL entry. If you

choose this option, continue with the following procedure.

Tip: These are the request methods that can be specified in HTTP requests. Further information on these methods can be found in RFC 2616 HTTP 1.1 spec dated June 1999.

Figure 63: ProtectedURLs HTTP Methods

panel

9 To activate specific HTTP methods, select the check boxes for the methods that apply.– GET returns whatever data is specified in the Request-URI– POST allows for such actions as posting messages to bulletin boards,

news groups, articles, mailing lists, etc., or providing a block of data such as credit card information

– HEAD tests hypertext links

Activates methodbuttons (click all that

apply)

118


– OPTIONS informs the client of requirements or capabilities associated with a resource or server without initiating data retrieval

– PUT stores supplied information in a specified URI– DELETE requests that the server delete the resource identified by the

request URI– TRACE allows the client to see what was received by the target server.

This information and is used for testing or diagnostics

By checking any of these check boxes, you are saying that this ACL entry’s restrictions apply to attempts to access the specified URLs with these spec-ified HTTP request methods. GET, POST, and HEAD are the most com-monly used methods.

10 When desired settings have been made, click the Restrictions tab.

Setting URL restrictions

The Restrictions tab defines a set of restrictions that will be applied to all users requesting access. These restrictions will be applied to the URLs and methods specified on the Protected URLs tab.

1 Select:– Unrestricted Access to permit all access. This option gives explicit

access permission to users who have successfully authenticated with SafeWord PremierAccess.

– No Access to deny all access. This option denies all access, even if the user provides correct authentication.

– Grant access if the user meets these restrictions to limit access based on restrictions including roles, authentication strength, Web browser, time of day, or range of date.

2 If you choose either of the first two options, continue to the Personalization tab and “Passing personalization data” on page 123. If you choose Grant access if the user meets these restrictions, the Restrictions and Settings are enabled and you can define your role restrictions. Continue to “Defining restrictions based on roles” on page 119.

Defining restrictions based on roles

To restrict access to a resource based on allowed roles, on the New Web ACL Entry window’s Restrictions tab, select Allowed roles. This option means users must have one of these specific roles to be granted access to the protected URLs targeted by this ACL entry.

119


Figure 64: New WebACL Entry (Restrictions

tab)

1 Click the Edit button. The Edit Restriction window appears.

Figure 65: Allowed roleswindow

2 Click Enabled to activate the window.

3 Select a role from the Roles list, then click the Add button to move the role from the left pane over to the right pane. The right pane consists of the roles users must possess in order to access URLs protected by this Web ACL.

Tip: The left pane contains the list of all available roles that define the total group of users that can access the selected URLs.

4 When you have added all the roles you want to require, click OK.

Defining restrictions based on authentication strength

To restrict users access to URLs protected by this Web ACL based on authentication strength, from the Restrictions and Settings window, select the Minimum Authentication Strength restriction.

1 Click the Edit button. The Edit Restriction window appears.

120


Figure 66: Minimumauthentication strength

window

2 Click Enabled to activate the window. This panel is used to set a minimum (combined) authenticator strength for access. The allowable range is from 1 to 60. The higher the authentication strength number, the stronger the authenticator or combination of authenticators must be in order to successfully access resources. For instance, if fixed passwords in your system have an authentication strength of 5 and Platinum tokens have an authentication strength of 20, you can restrict a resource to Platinum token users only, by setting a value of 20. Only users with a combined authentication strength of 20 or higher will be able to access this resource.

3 Select an authentication strength from the Minimum Authentication Strength list.

4 Click OK. You are returned to the Restrictions and Settings window.

Defining restrictions based on Web browser IP address

To restrict users access to protected URLs targeted by this Web ACL based on Web browser IP address, select the Web Browser IP restriction. The Edit Restriction window appears.


Figure 67: Web browserIP field

2 To define specific Web browser IP address(s) from which to allow or deny access, select:– Allow to designate the computers that will be allowed access to the

protected URLs. All other computers will be denied access.– Deny to designate the computers that will be denied access to the

protected URLs listed. All other computers will be allowed access.

121


3 Click the Add button to activate the IP address list.

4 Enter a new IP address in the IP Address field.

Note: Wildcards and ranges are allowable. All four parts of the IP address must be specified (for example 192.168.24.* or 192.168.24.2-15).

Modifying existing IP addresses

To modify a existing IP address, select it from the IP address list on the Edit Restriction window, and click the Edit button. Make the desired changes, then click OK.

Removing IP addresses from the list of restrictions

To remove an IP address from the list of addresses, on the Edit Restriction window, select the entry and click Remove. The restriction is removed and the Restrictions and Settings window reappears.

Defining restrictions based on time of day

To restrict users access to protected URLs targeted by this Web ACL based on the time of day the user seeks access, from the Edit Restriction window, select the Time of day restriction.

Figure 68: Time of daywindow

1 Click Enabled to activate the pane. The Time of day pane allows you to designate specific blocks of time when users specified in the Subject of this ACL entry can access protected URLs targeted by this Web ACL.

2 Click and drag your mouse to highlight the cells between the access start time and the stop time.

3 When the proper range is highlighted, click OK.

122


Defining restrictions based on range of dates

You may choose a range of dates when specified users can access protected URLs targeted by this Web ACL. To set a range of dates, from the Edit Restriction window, select the Range of dates restriction.


Figure 69: Date rangewindow

2 Select a month, day and year from the beginning with list.

3 Select a month, day and year from the ending with list.

4 Click OK.

Passing personalization data

The Personalization tab allows you to determine if and how personalization data will be passed via HTTP header fields. To pass personalization data, from the New Web ACL window, click the Personalization tab.

Note: The UWA prefixes all personalization data requests with “SafeWord-” when the request is passed through HTTP headers.

Figure 70: New WebACL Entry

(Personalization tab) 1. Select Web Applicationor Web Browser

2. Check to enable fields below, or clear to disable fields below

4. Select one

5. Activates availablefields

3. Optional

123


1 Configure the Personalization screen by selecting either:– Web Application from the To list for personalization data to be sent to

the Web application.

Or

– Web Browser from the To list for personalization data to be sent to the user’s browser.

Sending personalization data to the Web application is the more common option, as personalization generally takes place in the Web application on the server side, and not in the Web browser.

Tip: You can have personalization data sent to both Web applications and Web browsers. To do so, select the To Web Application option, and choose the personalization data to pass there, then select the To Web Browser option, and choose the personalization data to pass there.

2 Select the Pass data to the Web (Application/Browser) (via HTTP header) check box to activate the available options and allow selected data to be passed as required for this Web ACL entry. Then select any of the following options:– Insert userid in HTTP header to have the user’s userid included in an

HTTP header field called SafeWord-User.– Insert role data in HTTP header to have role data included in the HTTP

header field called SafeWord-Authorization.– Insert no Personalization Data in HTTP header if you do not wish to

have any of the authenticating users’ assigned personalization data inserted into the HTTP messages. If you choose this option, you have completed this procedure. Click OK. Otherwise, select one of the following then continue to the next numbered step.• To instruct the UWA to insert all of the user’s assigned

personalization data into the HTTP message, select Insert all Personalization Data in HTTP header, or

• to instruct the UWA to insert only some of a user’s assigned personalization data, select Insert some Personalization Data in HTTP header. The Available and Selected list boxes become enabled, and you are able to specify exactly which personalization data should be inserted into the HTTP request or response message.

3 Select the personalization data attribute(s) that should be inserted into the HTTP request or response message from the Available list.

4 Click the Add button to move the attribute(s) to the Selected list.

5 The information in the Available list is set in the Personalization Data Configuration window. To access that window, from the main Admin Console select Configuration -> Personalization Data. For information about creating attributes, see “Understanding personalization data” on page 161.

124


6 Click OK. The window appears with the Web ACLs listed in the box.

Figure 71: New WebACL create/edit window

The Web ACL is processed from the top down. Therefore, your most specific Web entries, those that target a narrowly defined group of users, should be placed at the top of your ACL list. More general Web entries should be placed toward the bottom of the list. The most general ACL should be the last one in the list.

Changing the order of protected Web entries

To change the order of the protected Web entries, from the ACL Entries pane of the New Web ACL window, select the URL you want to move, click the arrows to reorder it in the list of Protected URLs, then click OK to close the window.

125


126

6CHAPTER Managing User &

Authenticator Information

In this chapter...

Understanding users and access levels.......................................128

Adding and importing users..........................................................128

Adding, changing or removing authenticators ..............................144

Adding or changing authenticator profiles ....................................145

Assigning role(s) to multiple users ...............................................155

Importing user records from a third-party user database .............157

Deleting a user record ..................................................................159

Resetting a locked account ..........................................................160

Understanding personalization data.............................................161

Personalizing your Web applications ...........................................165

Session management...................................................................172

127

Chapter 6: Managing User & Authenticator InformationUnderstanding users and access levels

Understanding users and access levels

Before you begin creating user accounts, it is important to understand the various types of users and their levels of access. Users fall into two administrative levels: privileged and unprivileged. Privileged users include system administrators, local administrators, and helpdesk staff. These users each have some level of administrative responsibility. They must have access to functions such as creating regular user accounts, resetting attack-locked accounts, and assigning temporary passwords. Unprivileged users are those users who do not have any administrative privileges. They are your regular users, and they will comprise the bulk of your user population.

Adding and importing users

There are a number of ways you can bring user records into the PremierAccess system. The method you choose depends upon the source of those users and records.

If you have a large number of users to add to your system, you may choose to allow them to self-enroll, and create their own user accounts. See “Understanding Web-based, user enrollment” on page 264 for details about self enrollment. If you are importing users from another PremierAccess database, you can use our Backup and Restore feature to import their records. See “Backing up and restoring your user database” on page 199 for details.

If you are adding new users, you can manually create user accounts for them in the database. Users from SafeWord 5.x systems, can be imported using the Import Wizard feature. Finally, if your users are coming from a third-party user database, you can import their records using comma separated values.

The sections that follow describe how to create user accounts manually, how to import user records with the Import Wizard feature, and how to import users from a third-party user database using comma separated values.

128

Chapter 6: Managing User & Authenticator InformationAdding and importing users

Creating user accounts manually

To manually create a new user account, from the Admin Console, select Insert -> User. The Create a New User window appears with the General tab displayed.

Figure 72: AdvancedCreate a new user window

(General tab)

Enter the user name in the Username field and select a group from the Admin Group list. The user will be placed in this admin group. The following characters are prohibited in the Username field #=<>+,;*:\”\\()/

Tip: If the user will have a helpdesk user account, assign them to the highest-level user group in your user group hierarchy. Since they will only be able to assist users in the same group or any subgroup of their group, placing them at the highest level of your group hierarchy allows them to manage the widest distribution of users. If the user is to be designated a local (or group) administrator, assign them to whatever individual group hierarchy they will control.

Assigning roles to a user

(Optional) To assign a role to a user, from the General tab of the Create a New User window, click Select. The list of roles appears.

1 Choose the role(s) to assign to this user from the list of available roles. Use the Control key while clicking to select more than one role.

2 When you are finished assigning roles, click OK.

Security Alert: Roles should only be assigned if they conform to your security policy implementation.

129


Assigning authenticators to a user

To assign an authenticator to a user, from the Create a New User window, click the Authenticators tab.

Figure 73: Create a newuser window,

Authenticators tab

Initially, both the Passwords and Software/Hardware Authenticators, and Digital Certificates fields will be blank. Choose one of the following options:

• Add password to assign a fixed password. If you choose this option, continue to “Using a fixed password with a user account” on page 131.

• Pick authenticator to assign a hardware token or software authenticator. The Enter Serial Number window appears.

Figure 74: Enter SerialNumber window

Enter the authenticator serial number in the Serial Number field. Hardware token serial numbers are located on the back of each token. SofToken II serial numbers are listed in the SoftGen II output file, "keyphrase.txt".

130


Using SoftPINs with a user account

(Optional) SoftPINs are four-digit numerical strings that you can add to the beginning or the end of the token-generated passcodes that are entered as a response during authentication attempts. They provide two-factor authentication, and are equivalent to the hard PINs used with SafeNet’s Gold and Platinum tokens.

Tip: If you are using Silver tokens, you may want to use the SoftPIN feature. If you are using Gold or Platinum tokens, you probably will not need to use SoftPINs.

To add a SoftPIN to this account, in the SoftPIN field, enter the four digit string you want to use as the SoftPIN for this token, then click OK. The authenticator type and the serial number appear under Passwords and Software/Hardware Authenticators.

Note: By default, the AAA Server allows SoftPINs to be appended to passwords. Administrators can reconfigure the server to allow the SoftPINs to be prepended to passwords instead. For more information about reconfiguring the AAA Server so that SoftPINs can be prepended to passwords, see the SafeWord PremierAccess Installation Guide.

Using a fixed password with a user account

To use a fixed password with a user account, from the Create a New User window, click the Add Password button. The Enter a Fixed Password window appears.


If you have not created any other fixed password profiles, the default “Fixed” and “Emergency” profiles will be the only ones available. A fixed password profile describes characteristics about a common class of passwords. All passwords that reference the same fixed password profile will have the same properties. For instance, such passwords would all share the same minimum length and validity period.

1 Enter the user’s password in the Fixed Password field.

131



3 (Optional) Select the User must change password with first login. check box if you want users to change their password at the first login.

Tip: Forcing users to change their password when they first log in is often considered a good security measure. The user can have confidence that his newly chosen password is known by no one else. If you do not want this option to be available, leave this box clear.

4 (Optional) Click the View button to see or modify the profile’s properties.

5 When all selections have been made, click OK.

Using digital certificates with a user account

If your organization has deployed digital certificates, and those certificates have been exported to files which you have received, you can import a digital certificate for this user.

1 To import a digital certificate, from the Authenticators tab of the Create a New User window, click the Import button. The User Certificate Location window appears.

2 Browse to the location of the file that contains this user’s digital certificate(s). This file can also contain the user’s key pair (PKCS12 file), but it is not required.

3 Highlight the desired certificate, and then click Open.

4 Choose the digital certificate profile.

5 Click OK. The certificate is imported into PremierAccess.

132


Setting an expiration date for a user account

(Optional) One of the features available with PremierAccess is the ability to define an expiration date for a user account. This option is useful when you need to create temporary accounts. To set an expiration for a user account, from the Create a New User window, click the Advanced tab.

Figure 76: Create a NewUser window, Advanced

tab

By default, accounts are set to never expire. Select the After option, then enter the desired expiration date and time.

Note: If you prefer to set up this account so it never expires, leave the Never option set.

133


Attaching an alias to a user account

Aliases are additional names, like screen names that can be assigned to a user for login purposes. They point to the user’s record. Aliases might be variations of the user’s name. For example, aliases for MSmith might be M_Smith, or SmithM. This provides flexibility in allowable user login names.

Note: An alias must not conflict with any userids or aliases that are already in the system.

To attach an alias to the user account,

1 From the Advanced tab of the Create a New User window, click the Add button.

Figure 77: Enter an Aliaswindow

2 Enter an alias for this user, then click OK.

Note: You may optionally enter a comment in the Comment field. This information will display to your fellow administrators when they access this user record.

Setting user privileges

There are three levels of users in PremierAccess: system administrators, group administrators (which includes local administrators and helpdesk staff), and unprivileged users. Each level of user has a different set of user privileges. In short, system administrators can perform all tasks, unprivileged users can perform no tasks, and local administrators and helpdesk staff fall in between.

System administrators will be given complete access to all functions of PremierAccess. Local administrators cannot modify system configurations, but they can view audit logs and conduct authenticator management tasks (adding, changing, or modifying authenticator profiles, to name a few). Local administrators have READ/WRITE access to user records and security policy items. Helpdesk staff can be given privileges to assign, remove, and modify fixed passwords and SoftPINs, reset attack-locked accounts, view audit logs, and temporarily disable or enable users.

1 To define privileges based on administrative level, from the Create a New User window, click the Privileges tab. Figure 78 displays the unprivileged user level.

134


Figure 78: Create a NewUser, Unprivileged user

2 Based on your user’s administrative level, choose the appropriate option from the following:– If your user is an unprivileged user, that option is already selected, click

OK to complete the user privilege process.– If your user is a member of the helpdesk staff, choose

Helpdesk staff, then refer to “Defining privileges for helpdesk staff” on page 136.

– If your user is a local administrator, choose Local administrator, then refer to “Defining privileges for local administrators” on page 137.

– If your user is a system administrator, choose System administrator, then refer to “Defining system administrator privileges” on page 138.

135


Defining privileges for helpdesk staff

Helpdesk staff users have limited administrative authority. They are able to offer first tier support to your users. A helpdesk staff user should be given enough privileges to handle most of the authentication problems that your users may encounter. Figure 79 displays the privilege selections available for helpdesk staff.

Figure 79: Helpdeskstaff privilege settings

1 Ensure that Helpdesk staff is selected under Administrative Level. Then choose from the following privileges.– Select Remove software/hardware authenticators to allow this user to

remove software and hardware authenticators from a user record. For example, a helpdesk user will be able to remove a user’s hardware token if a user reports that his hardware token has been stolen or destroyed.

– Select Temporarily disable/enable hardware authenticators to allow authenticators to be disabled or enabled by helpdesk staff. For example, helpdesk staff will be able to temporarily disable a user’s hardware token if that token has been lost or forgotten for a period of time.

– Select Add/Remove fixed passwords to allow helpdesk staff to remove old, compromised, or unneeded fixed passwords from a user record. Helpdesk staff will be able to grant and remove temporary emergency passwords for users who have lost their hardware tokens. Clicking this option will check and disable the Change existing fixed password option.

– Select Change existing passwords to allow helpdesk staff to change user’s existing passwords. Helpdesk staff will be able to field requests for password changes.

– Select Add/Remove SoftPINs to allow helpdesk staff to add or delete SoftPINs, (additional pin numbers that provide two-factor authentication when prepended or appended to hardware or software tokens) from a user record. Helpdesk staff will be able to allow a user to secure his

136


token with a SoftPIN. Clicking this option will disable the Change existing SoftPIN option.

– Select Change existing SoftPINs to allow SoftPINs be changed for a user. Helpdesk staff will be able to field requests for SoftPIN changes.

– Select Reset attack lock to allow a user account that has been attack locked (locked from repeated unsuccessful authentication attempts) to be cleared by helpdesk staff.

– Select Temporarily disable or enable users to allow helpdesk staff to temporarily disable or enable users. Helpdesk staff will be able to temporarily disable a user if it is expected that this user will not be authenticating for a known period of time. This feature is useful during a user leave of absence.

– Select View audit logs to allow helpdesk staff to view audit logs that show a history of user authentication activity within PremierAccess.

2 When you are finished, click OK.

Defining privileges for local administrators

Local administrators have considerable administrative authority. They are able to oversee the user management of a subset of the PremierAccess user database, and they may be given the authority to create other local administrators with equal or fewer privileges. Figure 80 displays privilege settings for local administrators.

Figure 80: Localadministrator privilege

settings

1 Ensure the Local administrator option is selected under Administrative Level if this user will be given local administrator privileges.

2 Choose from the following options. When you have made all your selections, click OK.– User records READ/WRITE allows the local administrator to only read,

or to read and write parts of a user’s record. A local administrator would

137


need READ/WRITE privileges to create, modify, and delete users within his group hierarchy.

– Security policy READ/WRITE allows the local administrator to read, or create and modify security policy elements (i.e. ACLs, ACL entries, and roles). Local administrators can be given complete control of the security policy within a subset of the your deployment. For instance, if the user population is organized by physical location, the local administrator for that location can be given the authority to create or modify the location’s security policy.

– View audit logs allows the local administrator to view audit logs that show a history of user authentication activity within PremierAccess.

– Select Authenticator management to allow the local administrator to create, modify, and delete authenticator profiles, and import hardware authenticators.

– Select Edit local administrator to allow administrators to edit other local administrator’s properties.

Note: Local administrators can only use these privileges within their assigned group hierarchy.

Defining system administrator privileges

System administrator is the highest level administrator, having complete access to all privileges within PremierAccess. Ensure that System administrator is selected under Administrative Level, then click OK. Figure 81 shows system administrator level with the full range of privileges.

Figure 81: Systemadministrator privilege

settings

138


Modifying personalization data

Administrators may choose to store personal information about users in the application. Personalized data is configured using specific attribute-value pairs called personalization data elements. These elements can be inserted into HTTP messages as HTTP header fields that are bound for Web applications on your Web servers. Personalization data elements can be stored at the user record level or at the role level. A user may also inherit elements from the roles that he has been granted. Before an administrator can begin assigning personalization data elements to users, he must define and enter the set of attributes into the PremierAccess database. For more information about setting up personalization data attributes, see “Creating personalization data attributes” on page 162. The following sections describe how to modify attributes in a user’s record.

Modifying a user’s attributes

To add, edit, or remove a user’s attributes, from the Create a New User window, select the Personalization Data tab.

Figure 82: Create a NewUser window

(Personalization data tab)

Adding an element

To add an element to a users’ record, click the Add button.

Figure 83: Add attributevalue window

139


1 Select an attribute from the Name list.

2 Enter a Value or select one from the Value list depending upon the attribute you have chosen.

3 (System Admins only) If you are a system administrator, you can click the Add New Personalization Data button to invoke the screen that allows you to introduce new personalization data attributes into the system. This set of attributes can be thought of as a “dictionary” of PremierAccess personalization data. For information about adding new attributes, see “Understanding personalization data” on page 161.


Editing an element

To edit an element in a user’s record, from the Personalization Data tab of the Create a New User window, highlight the element to be edited. Click Edit, make the desired changes, then click OK.

Removing an element

To remove an element from a user’s record, from the Personalization Data tab of the Create a New User window, highlight the element to be removed. Click Remove, then click OK.

Adding unprivileged users with the user wizard

Unprivileged users are users who do not have administrative-level privileges. They are also referred to as “regular” users in PremierAccess. These users can quickly be added into the system using the user wizard. To add an unprivileged user with the user wizard, from the Admin Console, select a non-global group into which you want to add a user, then do the following:

1 Select Insert -> User with wizard.

Figure 84: Enter aUsername window

2 Enter the new user’s user ID in the User field.

3 Click Next. The Select an Authenticator Type window appears.

140


Figure 85: Select anauthenticator type window

4 Select an authenticator type for this user from the Authenticator Type list.

5 Click Next.– If you selected Software/Hardware Authenticator, the Enter Serial

Number window appears. Enter the serial number for the authenticator you will be issuing to the new user in the Serial Number field.

– If you selected fixed password as the authenticator type, the Select a Fixed Password Profile window appears. Select a password type from the Fixed Password Profile list. The available profiles are fixed and Emergency. You will see others if you have already created additional profiles.

6 Click Next.

Important: The Emergency fixed password profile should only be used by administrators or helpdesk staff who need to assign a temporary fixed password authenticator to a user whose hardware authenticator has been lost or compromised.

Tip: If you want to see the properties of the selected fixed password profile, after selecting it, click the View button.


7 Enter a password for this user in the Fixed Password field, then re-enter the same password in the Confirm Password field.

Leave this box checked so the user must designatetheir own fixed passwordwhen they log in.

141


Important: Leave the User must change password with first login check box selected. This forces the user to select a password known only to them when they log in. Users always have the option to change their password, whether or not you check this option. This forces them to do so the first time they log into PremierAccess.

8 Click Next. The Add Another Authenticator window appears. If you want to add additional authenticators, click Yes, then repeat the process for adding an authenticator. If you do not want to add another authenticator, click No and continue to step 9.

Tip: A user can be assigned up to three authenticators in any combination. PremierAccess allows a user to possess multiple authenticators for various authentication scenarios. For instance, your security policy might require that a user present a one-time password from a hardware authenticator when authenticating remotely, but that the user only present a fixed password when authenticating internally.

Figure 87: Select anAdmin Group window

9 When the Select an Admin Group window appears, select thenon-global group to which this user will be assigned from the Admin Group list.

10 Click Next. The Assign Roles window appears.

Figure 88: Assign roleswindow

142


11 Assigning roles is optional, and you may prefer to assign them to multiple users at once. For more information about doing so, see “Assigning role(s) to multiple users” on page 155. If no role is to be assigned, click Finish. If you want to assign a role to this user, click Select. The Assign Roles for your user window appears.

Figure 89: Add UserRoles

12 Select the role(s) you want to assign to this user. Use the Control and Shift keys to select more than one role. The Assign Roles window appears with the roles listed under Role Names.

13 Click Finish to complete the procedure.

143

Chapter 6: Managing User & Authenticator InformationAdding, changing or removing authenticators

Adding, changing or removing authenticators

At times, you will need to add an additional authenticator to a user account, or remove one. There will also be times when a user who has lost or misplaced his hardware token, will need to have a temporary fixed password assigned to his account so that he can log into the system. The following example explains how to remove a lost hardware token, and assign a temporary fixed password:

1 From the Admin Console, use Find to locate the desired user. For detailed information about using Find, see “Finding entries in PremierAccess” on page 57.

2 Select the Edit icon. The Edit User window appears.

3 Select the Authenticators tab and complete one of the following:– Select Pick authenticator to add an additional authenticator to the

account. Refer to “Assigning a token to your primary working account” on page 50 for further details.

– Select Add password to add another fixed password. Referto “Assigning a password to the default account” on page 55 for further details.

– Select Remove to remove the existing authenticator, then click the button associated with the new authenticator you wish to add.

Note: If dealing with a user who has lost or compromised their token, a temporary fixed password may need to be assigned so that the user can still access their authorized resources. When the authenticator has been replaced, the temporary fixed password should be removed.

144

Chapter 6: Managing User & Authenticator InformationAdding or changing authenticator profiles

Adding or changing authenticator profiles

You can change the characteristics of all fixed passwords in your system that reference the fixed password profile by modifying the default fixed password profile. Or, you can create several classes of fixed passwords in your system, by creating new fixed password profiles. The process of creating a profile is no different than the act of editing one. The next section explains both procedures.

Fixed password profiles

A fixed password profile defines the attributes associated with a particular password. These may include the authenticator strength, a minimum password length, and the duration of the password’s validity. To modify an existing fixed password profile, from the Admin Console, select Find -> Authenticator Profiles -> Fixed Password.

1 Select Find all available, then click the Find button.

2 Select fixed from the Profile list. This is a default fixed password profile that is shipped with your system.

3 Click the Edit icon. The Edit Fixed Password Profile window appears with Fixed displayed in the Profile field.

Figure 90: Edit FixedPassword Profile window

Tip: When creating profiles, consider using a naming convention that offers visual cues as to the function of the profile (e.g. Medium Strength Fixed, or High Strength Fixed, etc.).

4 Set an Authenticator Strength for this profile. This is the numerical strength value for this authenticator type. The strength is used by the AAA Server to determine if sufficient strength exists to access a resource protected by a fixed numerical authenticator strength. For more information about authenticator strengths, see Table 13 on page 108.

145


Tip: The strengths you assign should reflect how effective you consider this type of authenticator to be. You may want to give this profile a higher strength if you increase the minimum password length, and you set passwords to expire in a shorter length of time.

5 Select a global group for this profile from the Admin Group list.

Tip: To view the properties for this group, click the View button next to the Admin Group field.

6 Enter a name for this profile in the Display Name field. This might be a user-friendly version of the profile name. This name will be displayed to your users while they authenticate.

7 Enter any supportive or defining comments in the Comments field.

8 Click the Configure tab.

Figure 91: FixedPassword Profile

(Configure tab)

9 Set a Minimum Password Length. The higher the minimum length, the more secure the password since it will be harder to guess.

10 Set the Passwords to remember. This is the number of expired passwords that will be remembered by the system. A higher setting means your fixed password is more secure. A setting of 6, for example, will result in the user having to come up with 7 different passwords before they can use any one of them over again.

Important: The Passwords to remember feature affects administrator removal/replacement of fixed password authenticators. You cannot remove a fixed password and assign the same one to replace it. The user cannot use the same password again until the number of passwords to remember has been exceeded.

11 Select the Passwords are case sensitive check box to make the passwords case sensitive. Requiring that passwords are case sensitive makes them more secure.

146


12 Passwords that expire often are more secure than those that expire infrequently, or not at all. To set the expiration life span of this password, select the Password will expire check box, then choose from the following options:– after this many days refers to the number of days you set in the Max

password age field.– with this many warning days is the number of days lead time a user will

be advised that their password is about to expire.

13 Click OK when done.

Digital certificate profiles

This section describes how to set up a digital certificate profile. There are two kinds of profiles in PremierAccess. The first profile describes certificates that have already been created and certified by a proprietary, or well-known certificate authority. The second profile describes certificates that can be assigned to a user record and presented to SafeWord agents that accept digital certificates (UWA).

To set up a certificate profile, from the Admin Console, select Insert -> Authenticator Profile -> Digital Certificate Profile. The Create a New Digital Certificate Profile window appears with the General tab displayed.

Figure 92: Create a NewDigital Certificate Profile

window (General tab)

147


General tab settings

On the General tab, do the following:

1 Enter a name for this digital certificate profile in the Profile field.

Tip: Consider using a naming convention based on the certificate authority that generated the user certificates this profile can verify; for instance Entrust or PremierAccess.

2 Set the Authenticator Strength for certificates verified under this profile (range is 1-20, with 20 being the highest strength). For more information about authenticator strengths, see Table 13 on page 108.

Tip: Digital certificate authenticators vary in strength depending on how carefully the user protects their private key. Smart card storage is more secure than a disk-held private key. If your users are storing their private keys in their browsers, a setting of 5 to 10 might be appropriate.

3 Enter any relevant Comments.

4 Select an Admin Group from the list of groups. Generally you place profiles in global groups.

Note: Click the View button to see or edit the properties for this group.

5 Click the Certificate Generation tab.

Certificate Generation tab settings

The choice you make on this tab determines the kind of digital certificate profile you are creating.

1 Select one of the following Certificate Generation options:– Enroll existing certificate: Allows a user to enroll with an existing

certificate that is generated by a third-party certificate authority such as Verisign, Entrust, Microsoft, or Baltimore.

– Create new certificate with PremierAccess: This option allows a user to enroll a certificate generated by PremierAccess.

2 Click the CA Certificates tab.

CA Certificates tab settings

The options on this tab permit you to import a Trusted Root CA Certificate from PremierAccess or from a Certificate file into this profile. You also can control how certificates enrolled with this profile will be verified. Imported certificates must be self-signed, and must be presented in Privacy Enhanced Mail (PEM) or raw Distinguished Encoding Rules (DER) format. The trusted root certificate sources are listed in the Trusted Root Certificates window.

148


Figure 93: Create a NewDigital Certificate Profilewindow (CA Certificates

tab)

Intermediate CA Certificates may also be imported. These are certificates that you don’t explicitly trust. Intermediate CA certificates may be used when your certificates are generated by a 3rd party CA that is part of a hierarchy of CAs, where certificate chains from the root certificate to the end user are more than one level deep.

If this profile describes the verification of certificates generated by a third-party CA (such as Baltimore), you must obtain the CA’s self-signed trusted root certificate and add it to this profile. To import a certificate, do the following:

• If you are importing a PremierAccess-generated root certificate, select PremierAccess from the Trusted Root CA Certificate list, then click Import. The root certificate generated by the Admin Server is imported into this profile.

• If you are importing a root certificate from a file, select Certificate file, then click the Import button.

If you selected “Enroll existing certificate” on the previous tab, you will be clicking the option for Certificate file, and selecting the file that contains the root certificate of the third-party CA. If you selected “Create a new certificate with PremierAccess” on the previous tab, you will be clicking the PremierAccess option, and selecting the file that contains the certificate of the PremierAccess CA (cacert.pem).

Importing Intermediate CA certificates

To import Intermediate CA certificates, click the Import button next to the Intermediate CA Certificates field.

149


Figure 94: ChooseCertificate File window

Tip: Use your Browser’s Help information to learn how to import a Web server certificate into your browser.

Browse to, locate, and select the appropriate file (.cer, .crt, .pem, .txt, or .der format). Click Open. The certificate file you have chosen appears in the Intermediate CA Certificates field of the Certificate Profile window.

Certificate verification policies

Certificate Policy Enforcement allows you to control the method by which certificate policies are handled during verification. A complete description of certificate policies is beyond the scope of this guide.

1 (Optional) To set up the method by which certificates policies are handled during verification, click the Policies tab.

Figure 95: Create a newdigital certificate profile

(Policies tab)

2 The X.509 certificate standard contains a mechanism to map certificate policies from one organization to another. Mapping is implemented within certificates using the extension mechanism.

Certificate Verificationarea

150


Note: As an example of policy mapping, the US Department of Defense may wish to accept Canadian “SECRET” certificates as equivalent to U.S. “SECRET” certificates.

a Select one or both of the following:

• Inhibit Policy Mapping: Disallows the use of policy mapping extensions anywhere within the certificate chain.

• Require Explicit Policy: Requires every certificate in a certificate chain to exhibit an allowed policy.

b List any specific policies you want checked when the certificates are verified. Certificate policies are entered in numeric object identifier (OID) format.

Important: An empty list means that any policy is acceptable. If you list specific policies to be checked, you should enable the Require Explicit Policy option.

Note: In general, certificates can be marked with identifiers describing the conditions under which they were created. Certificate policies are normally used as quality indicators.

3 Select a Revocation Policy. The revocation policy options listed here allow you to control how revocation checking is done when verifying certificates. Choose either:– None to specify that no revocation checking will be done. If you are

generating certificates using the PremierAccess Server, you must specify this option because PremierAccess does not issue revocation lists.

– Certificate Revocation List to specify that CRL checking is to be done. If you specify this option, you must also specify an LDAP Server for the AAA Server to contact to retrieve CRLs.

The standard method for certificate revocation is for the CA to periodically publish a Certificate Revocation List (CRL). There are times when certifi-cates may need to be revoked before they expire. To revoke certificates without waiting for a CRL, see “Revoking digital certificates” on page 152.

4 (Optional) Click the LDAP tab. The External Servers window appears. You may specify an external LDAP Server that the AAA Server can use to retrieve CRLs and CA certificates.

Note: External Servers features are disabled if the host name field is blank.

151


Figure 96: Create a NewDigital Certificate Profile

window (Verification 2tab)

5 To use an external LDAP Server, select Use external LDAP Server. This options allows PremierAccess to contact the specified LDAP Server to fetch certificates and certificate revocation lists. The Hostname, Port, and Timeout values must be specified when using this option.– Enter the Hostname of the machine where the LDAP Server is located,

and enter the Port for the LDAP Server.– Select the Timeout (seconds), which is the period for which the system

attempts to contact the LDAP Server you specified in the Purpose field.

6 Click OK when your settings are complete.

Enrolling digital certificates

To use a digital certificate as an authenticator within PremierAccess, a user must enroll his digital certificate within PremierAccess. This is typically done through the Enrollment Server. As an alternative, the user can deliver his client certificate in a file to an administrator, and the administrator can manually import the certificate using the Admin Console. For details about using the Enrollment Server to enroll digital certificates, see “Creating enrollment reservations” on page 269.

Revoking digital certificates

You must revoke the digital certificate used to identify an employee when the private key that is associated with the certificate is compromised or lost, or when the employee is terminated or transferred. To immediately revoke a certificate, from the Admin Console, select Find ->User ->[specific username].

1 Click the Find button.

152


2 Select the Authenticators tab, and select the digital certificate you want to revoke from this user.

3 Click the Remove button, then click OK to save the user without the digital certificate.

Modifying hardware authenticator profiles

This section describes how to modify hardware authenticator profiles. You cannot create a hardware authenticator profile. They are created as tokens, and imported using the Admin Console.

Tip: We recommend you only modify the authentication strength values of hardware authenticator profiles.

To modify the authentication strength value of an existing hardware authenticator profile, from the Admin Console, select Find -> Authenticator Profiles -> Software/Hardware Authenticator.

1 Select Find all available, then click the Find button.

2 Select the desired profile from the Profile list, then click the Edit icon to display the Edit Hardware Authenticator window. The name of this profile is displayed in the Profile field.


window

3 Set the Authenticator Strength for this profile. Authenticator strength sets the numerical value for this authenticator type. It can be used by the AAA Server to determine whether sufficient strength exists to access a resource protected by a fixed numerical strength.

Tip: Assigned strengths should reflect how effective you perceive this type of authenticator to be. You may give this profile a higher strength if you also increase the minimum password length, and set passwords to expire in a shorter length of time.

153


4 Select a group for this profile from the Admin Group list.

Note: You can view the properties for this group by clicking the View button next to the Admin Group field.

5 The Display Name field allows you to customize the field your users will see when they enter their passcode. Enter your user’s authenticator type (SafeWord Silver, SafeWord Platinum, etc.).

6 Enter any supportive or defining comments in the Comments field.

7 Click the Configure tab. The configuration settings for this profile appear.


(Configure tab)

8 Clear the Password is echoed on input check box if you do not want the one-time password for this profile to be displayed by the SafeWord agent while the user is authenticating.

9 Click OK.

154

Chapter 6: Managing User & Authenticator InformationAssigning role(s) to multiple users

Assigning role(s) to multiple users

When assigning roles, it may be more convenient to assign them to a large number of users who are already a part of a particular group. The PremierAccess Admin Console allows this to be done quickly and easily. To assign one or more roles to a particular group of users, from the Admin Console, select a user group from the left pane.

Figure 99: Adminconsole with names

selected

1 Select a group of users from the list in the right pane, then select Tools -> Assign Roles. The Select Users window appears.

Figure 100: Select Userswindow

Tip: If you highlight users directly from the right pane of the Admin Console, those user names appear in the Selected Users field of the Select Users window.

2 Click Find -> Users. The Find User entries window appears.

3 Select Find all that match.

155

Chapter 6: Managing User & Authenticator InformationAssigning role(s) to multiple users

Tip: The Find all available option is not recommended if you have a large user population. It is best to narrow down your search results by supplying search criteria with the Find all that match option.

4 Click Find. The Select Users window appears.

5 If your search yielded any users, those users appear in the Available Users list. Click the Add button to move the users to the Selected Users list.

6 Click Next when you have identified and moved all your intended users to the Selected Users list. The Choose Roles window appears.

Figure 101: ChooseRoles window

7 Select one or more roles to assign to these users from the Available Roles list and click Add to place them in the Roles to Assign list.

8 (Optional) Select the Remove user’s current roles check box to remove any roles the user was previously assigned.

9 Click Finish when you are done.

156

Chapter 6: Managing User & Authenticator InformationImporting user records from a third-party user database

Importing user records from a third-party user database

The PremierAccess import feature allows you to move large numbers of users from a third-party user database into PremierAccess. When you import a large number of users, you must save the file as an ASCII file, with either a .csv or a .txt extension, and you must use commas as delimiters. The use of commas as delimiters is important because if the user database to be exported has the user name syntax “Last name, First name”, the comma between the last and first name would be interpreted as a delimiter, and the output file would have only last name in the user name field, then first name in the comment field. The only required field in each user record is the user name; all other fields are optional. The following other rules apply:

• These characters are prohibited: #<>+,;*:"()?|/\

• Blank spaces are allowed

• Maximum length for each userid is 128 characters

• Syntax for each user entry is: userid,comments

• If comments are not used, the user record can be terminate after the user name

• If a user record contains aliases, they are allowed by syntax: userid:alias1:alias2 (For example: mike_smith:msmith:smithm,comments)

To import users, from the main menu, select File -> Import -> User (CSV). The Import User-Select File window appears.

1 Click Browse. The Browse Import File window appears.

Figure 102: Import FileLocation window

2 Browse to locate the previously exported comma separated value- (CSV) formatted user file you want to import.

3 Click the Open button when the file has been located and selected. The Import User - Select Admin Group window appears.

4 Select a non-global Admin Group from the Admin Group list. All your imported users will be placed into this admin group, then click Next. The Select Role(s) window appears.

157

Chapter 6: Managing User & Authenticator InformationImporting user records from a third-party user database

Figure 103: Import User:Select Role(s) window

5 Select a role(s) to give to your imported users from the AvailableRoles list, then click Add to place that role in the Selected Roles list.

6 Click Import. The Import Completed window appears with the status of your import.

7 Click OK. The Import User Continue window appears and asks if you want to import more users. Click Yes to import more users or clickNo if you are finished importing users. If you selected yes, repeat the process to import users. If you selected no, you are returned to the Admin Console where the left pane of the Admin Console displays the tree view of admin groups.

8 Select the Admin Group where you just imported your user records.

Figure 104: Adminconsole with imported

users

The right pane shows a list of the users you just imported. Their icons are gray, indicating that they do not yet have authenticators assigned to them. Now that you have imported your user records into the system, you will need to assign authenticators to them. A user needs an authenticator, such as a hardware token or a fixed password, to authenticate to PremierAc-cess. You can do this manually by editing each user record, or you can automate the process using the Enrollment Server. If you choose to use the

158

Chapter 6: Managing User & Authenticator InformationDeleting a user record

Enrollment Server, you need to create a reservation for users. For informa-tion on creating enrollment reservations, see Chapter 12, Setting Up Web-based Enrollment.

Tip: Once a user is assigned an authenticator, their icon no longer displays in gray, indicating that they can authenticate to PremierAccess.

Deleting a user record

Certain events, such as an employee leaving an organization, require the deletion of a user record. To delete a user record, at the Admin Console, select Find -> Users. The Find User entries dialog box appears.

1 Enter the username in the far right field.

Figure 105: Find Userentries with username

2 Click Find. The Find results: User entries window appears with the requested username listed.

Figure 106: Find resultswindow

3 To delete the user’s record, highlight the name, then click the Delete icon. The Confirm Deletion window appears, asking if you want to delete the user entry.

4 To permanently delete this user record, click Yes.

159

Chapter 6: Managing User & Authenticator InformationResetting a locked account

Resetting a locked account

Attack lock is a feature in PremierAccess that prevents “brute-force” attempts to gain access to a user’s account by repeatedly trying to log in with different passwords. You can determine the number of attempts that are allowed before PremierAccess locks the account, thus preventing any further attempts by reconfiguring the attack lock settings on the Admin Console’s General tab. See “Configuring General settings” on page 95 for details. Occasionally, a user may inadvertently self-trigger the attack lock feature with repeated unsuccessful login attempts. Or a user may be locked out because someone else has tried to access their account unsuccessfully. In either case, their account can be restored by resetting the attack lock.

To reset a locked account, from the Admin Console, select Find -> Users and locate the user account that needs to be reset. For more information about finding users, see “Finding entries in PremierAccess” on page 57.

Tip: A user’s account will automatically reset after a configurable amount of time as long as the AAA clears attacked -locked accounts option is selected. This option is on the General tab when you configure PremierAccess.

Figure 107: Searchresults window

1 From the Find results: User entries window, select the user’s name, then right-click your mouse button and select Edit. A window appears stating that this user’s account has been attack locked.

2 Click OK. The Edit User window appears.

3 Clear the Account locked out check box.

4 Click OK and inform the user their account has been reset.

Note: If users are assigned hardware tokens, they can unlock their account by successfully authenticating using personalization data and the User Change Pin feature. For more information about the User Change Pin feature, refer to “User ChangePin feature” on page 298.

160

Chapter 6: Managing User & Authenticator InformationUnderstanding personalization data

Understanding personalization data

PremierAccess allows you to store personal data about the users who access your resources. Your UWA-protected Web applications can deliver data personalized for a user by language preference, employee ID number, or organizational department for example. Your helpdesk staff might also use personalized data to verify information about a user. This could prove helpful before assigning a temporary authenticator, or when you need to change a user’s SoftPIN.

Data elements

Personalized data is configured using specific attribute-value pairs called personalization data elements. These elements can be inserted into HTTP messages as HTTP header fields that are bound for Web applications on your Web servers. Personalization data elements can be stored at the user record level or at the role level. A user may also inherit elements from the roles that he has been granted.

When the user authenticates to PremierAccess through the Web Login Server, the AAA Server creates a session, and collects and stores all of the user’s personalization data in the session. The personalization data is available to the Universal Web Agent, and with the help of a properly configured Web ACL, propagated to Web applications protected by the UWA.

The data dictionary

Before the administrator can begin to assign personalization data elements to users and roles, the administrator must enter the personalization data attributes into the database. By entering these attributes, the administrator creates a data dictionary of personalization attributes. Since system administrators are ultimately in control of the kinds of data that are stored about a user, only system administrators are allowed to edit this data dictionary. These administrators will optionally be able to specify a range of allowable values for any given personalization data attribute.

161


Creating personalization data attributes

To create personalization data attributes, from the Admin Console, click Configuration -> Personalization Data. The Personalization Data Configuration window appears. Initially, no values are listed.

Figure 108: Personaliza-tion Data Configuration

window

1 To add a personalization data attribute, click the Add button.

Figure 109: Create anew Personalization Data

Attribute window

2 Enter a name in the Attribute field. For example, enter "Full Name" to collect the full names of your users.

3 (Optional) Enter descriptive information in the Description field. Descriptions state the purpose of the attribute to fellow administrators.

Once your data dictionary is complete, you may begin defining data at the user and role record level. You define data by setting up value restrictions for your attributes. For example, you might enter the full names and lan-guage preferences of each user on their user records.

162


Restricting the values of attributes

You can place restrictions on the values of personalization data attributes. As an administrator you have the choice of allowing any value for a given attribute, or allowing only one value from a set of predefined values.

Allowing any value

Click Allow any value to create an attribute like "Full Name", that does not lend itself to a discrete set of possible values. If you choose Allow any value, click OK to complete the attribute.

Restricting a value

You can also restrict the value of an attribute. A good example of an attribute you would restrict is language preference. You would restrict the value of this attribute by defining a set of allowable languages.

1 To restrict an attribute’s value, select Allow only the following values.

Figure 110: Addingvalues to attributes

2 When you restrict a value, you must also supply the list of allowable values. For instance, if you have a Web application that can output text in one of four possible languages, you would add an allowable value for each language option available. To add allowable values:

a Click the Add button.

b Enter an allowable value for the personalization data attribute that you are creating under Allow only the following values.

c Click the Add button again to enter additional values.

d When you are finished adding values, click OK.

163


Figure 111: Listed dataattributes window

3 The attributes and any descriptions appear in the attribute list. Click OK.

Editing personalization data attributes

To edit an attribute or its description, from the Admin Console, select Configuration -> Personalization Data.

1 When the Personalization Data Configuration window appears, select the attribute you want to edit from the list of attributes.

2 Click the Edit button.

3 Change the attribute or its description, then click OK. The edited attribute appears in the list of attributes.

Removing personalization data attributes

To remove an attribute from the list of attributes, from the Admin Console, select Configuration -> Personalization Data.

1 When the Personalization Data Configuration window appears, select the attribute you want to remove from the list of attributes.

2 Click the Remove button.

3 Click OK. Once your data dictionary is complete, you may begin defining data at the user and role record level.

164

Chapter 6: Managing User & Authenticator InformationPersonalizing your Web applications

Personalizing your Web applications

Data about users can be passed to Web applications. This data can include the user IDs, users roles, and personalization data. The process is controlled through Web ACLs. Web ACLs contain entries that specify what data will be passed for a particular URL. When a UWA decides that a user is authorized to access a particular URL, it looks at the relevant ACL entry to determine which, if any, personalization data to insert into intercepted HTTP request and/or response messages.

PremierAccess distinguishes between server side and client side Web applications. User data can be sent directly to either one. In the case of server side applications, data is inserted into the HTTP request message by the UWA. The server side application then accesses the data by reading one or more header fields that contain the data. This is the typical scenario as personalization is performed by Web applications running behind the Web server.

If a Web client application needs the user ID, user roles, or personalization data, there are several methods available. Typical client applications running in a browser are implemented with JavaScript and/or Java applets. In this environment, the easiest solution is to pass the data to a server side Web application, and have the Web application pass the data on to the client application. This is usually done by sending the data in a cookie, or by inserting it in hidden fields of an HTML form.

In some cases, passing the data via a server side application is not appropriate. A Web application may not be available to pass the data on, or the client application may not be able to process cookies or page content. In this case, you can configure the Web ACL to send the data directly to the client. The UWA inserts the headers into the HTTP response message, and the client application reads the response headers to acquire the data. In Figure 112, the UWA modifies the incoming request before sending it to the server side Web application.

165


Figure 112: Personali-zation data delivery to

Web applications

If an ACL entry for that URL is properly configured in the UWA’s Web ACL, the UWA will pass zero or more of the following kinds of personalization data to the requested server side Web application: user ID, role list, and generic personalization data.

HTTP header messages

The UWA can insert personalization data as HTTP header fields into incoming HTTP requests and into outgoing HTTP responses.

Client-side Web application support

JVM: applet support

and

JavaScript engine

Popular Web browser

HTTP request (with session ID)

Universal

Authorizes access with the help of a Web ACL and session data

Modified HTTP request (includes person-alization data)

Web Agent

Server-side Web application support

Servlets

JSP, ASP

ASP, SSI, etc...

CGI

UWA-protected popular Web/application

server

HTTP response

Modified HTTP response (includes person-alization data)

166


Figure 113: HTTPrequest or response

message

If the UWA has been instructed to pass the user’s user ID along, it creates an HTTP header field named SafeWord-USER and assigns the user ID as its value. If the UWA has been instructed to pass the user’s list of assigned roles along, it creates an HTTP header field named SafeWord-AUTHORIZATION and assigns the role list as its comma- separated value. The generic personalization data is handled similarly. For each personalization data element that is assigned to a user, an HTTP header field is created with a name corresponding to the name of the personalization data element and a value corresponding to the value of the personalization data elements.

As an example, suppose a user with user ID Franz has been assigned the roles "Engineer" and "Team Leader". He also has two personalization data elements defined in his user record. His "Employee-number" is "2112" and "Language-preference" is "German". The "Engineer" role also has a personalization data element defined: "Department" is "23". Franz accesses a Web application protected by the UWA and a Web ACL that is configured to pass all available personalization data to that application.

The UWA would then modify the HTTP message destined for the Web application by adding the HTTP header fields shown in Table 14.

Table 14: HTTP headers fields added to HTTP request messages

The UWA converts certain characters in different ways depending upon where they are used. Table 15 displays the varying treatment of these characters.

Modified HTTPRequest or Response Message

Can contain:* User’s user ID* User’s list of roles* All, some, or none of user’s generic personalization data

Web application

Header name Header value

SafeWord-User Franz

SafeWord-Authorization Engineer, Team Leader

SafeWord-Employee-number 2112

SafeWord-Language-preference German

SafeWord-Department 23

167


Table 15: Treatment of spaces, dashes, and underscores in the UWA.

Personalization data: basic example

The following describes how you create a Web application that delivers text to a user in the user’s preferred language.

Company A, an English-speaking company, has developed a Web-based service for users around the world. The company would like PremierAccess to handle all of the authentication and authorization duties. In addition, they would like PremierAccess to store language preference information about each user so that they can deliver personalized content for each user. Using PremierAccess, this can be achieved by doing the following:

1 The system administrator installs PremierAccess.

2 The system administrator installs a Universal Web Agent, which sits in front of the Web server that hosts the Web-based service. A Web Login Server is also installed.

3 The system administrator creates a new personalization data attribute called "Language-Preference" and creates values for each of the languages that Company A will support.

4 The system administrator creates a Web ACL for the installed UWA.

5 The system administrator creates an ACL entry that targets the Web-based service.

6 The system administrator then selects the "Insert some Personalization Data" option from the Personalization Data tab of the Web ACL entry window. The administrator selects the "Language-Preference" attribute.

7 The system administrator sets up the Enrollment Server for customers of the Web-based service. The Enrollment Server is configured to collect language preference information from new users.

CharacterPersonalization data name

HTTP header name

CGI environment variable name

Space (" ") Space (" ") Dash ("-") Underscore ("_")

Dash ("-") Dash ("-") Dash ("-") Underscore ("_")

Underscore ("_")

Underscore ("_")

Underscore ("_")

Underscore ("_")

168


8 The Web-based service is modified to expect the user’s language preference information stored in each HTTP request. If no language preference information is received, this service will deliver content in English.

At this point, once a user has enrolled himself into A’s PremierAccess data-base, he can access the Web-based service. When the user accesses the service, the following sequence of events take place.

a The user accesses the Web-based service by its URL.

b The UWA intercepts the HTTP request for the service.

c The UWA redirects the user to the WLS for authentication.

d The user authenticates using PremierAccess.

e The AAA Server collects all relevant personalization data about the user and stores it in the user’s new session.

f The WLS redirects the user back to the originally requested Web service.

g The UWA intercepts the request, but detects that the user has authenticated.

h The UWA authorizes the user based on rules defined in its Web ACL.

i The UWA prepares the HTTP request message that it will forward to the intended Web service. It consults the Web ACL to determine which data it must insert into the message as HTTP header fields.

j The Web ACL instructs the UWA only to pass the Language-Preference element to the server-side Web application.

k The UWA inserts the user’s language preference “use English words here” as an HTTP header field in the modified HTTP request message with the name: SafeWord-Language-Preference.

l The protected Web application received the request for service. It can retrieve the authenticated user’s language preference from the HTTP header field in the HTTP request message. If no preference is received, the Web application can resort to a default language preference.

169


Personalization data: advanced example

The following describes how you modify an existing set of sensitive Web applications to defer authentication duties to PremierAccess. The motivation for this would be to upgrade from simple fixed-password access to these applications to a stronger authentication mechanism such as SafeWord hardware authenticators.

Company B has an existing set of Web applications that run on top of an Oracle database. The database contains a user record for each user in the company. Company B now wants these users to strongly authenticate to their existing Web applications. Using PremierAccess, this can be achieved by doing the following:

1 The system administrator installs PremierAccess.

2 All the Oracle-enrolled employees are introduced into PremierAccess using the PremierAccess Enrollment Server or another enrollment method. Each user is assigned a strong authenticator, such as a hardware token.

3 In this example, the user’s PremierAccess user ID matches their Oracle user ID.

4 The IT staff modifies their existing Web applications by removing any authentication logic covered explicitly in the Web applications.

5 All authentication duties will now be handled by PremierAccess. The Web applications will now expect to retrieve each user’s user ID from PremierAccess as personalization data stored in an HTTP header field.

6 The system administrator installs the Universal Web Agent, which sits in front of the Web server that hosts the Oracle-based Web applications.

7 The system administrator creates a Web ACL for the installed UWA.

8 The system administrator creates an ACL entry that targets the Web application’s URL for each ACL entry.

9 The system administrator then selects the Pass only the user’s user ID option from the Personalization Data tab of the Web ACL entry window.

This option allows only the user’s user ID to be passed up to the Web appli-cation. The UWA will not pass any role information or generic personaliza-tion data elements in either direction. No data is sent to the Web browser; it is sent to the Web application on the Web server only.

170


At this point, when a Company B user accesses one of the company’s Web applications, the following sequence of events takes place:

a The user requests the Web application using its URL.

b The UWA intercepts the HTTP/S request.

c The UWA redirects the user to the WLS for authentication.

d The user strongly authenticates using PremierAccess with his strong authenticator.

e The AAA Server collects all relevant personalization data about the user, and stores it in the user’s new session.

f The WLS redirects the user back to the originally requested Web application.

g The UWA intercepts the request, but detects that the user is authenticated.

h The UWA authorizes the user based on rules defined in its Web ACL.

i The UWA prepares the HTTP request message that it will forward to the intended Web application. It consults the Web ACL to see which data it must insert into the message as HTTP header fields.

j The Web ACL instructs the UWA to pass only the user’s userid to the server side Web application.

k The UWA inserts the user’s user ID as an HTTP header field in the modified HTTP request.

l The protected Web application receives the request for service. It can assume that the user has authenticated to PremierAccess when it finds the user’s user ID stored in an HTTP header.

m The Web application can continue to deliver personalized content based on the identity and permission set of the authenticated user.

171

Chapter 6: Managing User & Authenticator InformationSession management

Session management

When a user authenticates through the Web Login Server, the AAA Server creates a session for the user, then stores data about the user in that session. You can view or revoke user sessions using the Admin Console. To access a user’s session, from the Admin Console, select Find ->Sessions. The Find Session Entries window appears.

Figure 114: FindSession window

1 Locate the desired session by selecting:

a Find all available.

b Find all that match, then selecting specific search criteria with which to search for the desired session.

c Search for sessions based on the Match Session Start Time.

2 To automatically export this data into a report and save it, click the Export button and follow the prompts to save the report. Otherwise, click the Find button. The Find Results: Sessions window appears.

Figure 115: FindResults: Session Entries

window

172


3 Double-click the desired session. The View Sessions window appears.

Figure 116: ViewSession window

Revoking sessions You can revoke user sessions from the View Sessions window. To revoke a session, thereby ending this user session, click the Revoke button. The Prompt for Revoke window appears. Click Yes. The session is revoked, and the Confirm window appears.

173


174

7CHAPTER Monitoring

PremierAccess Activity

In this chapter...

Understanding audit logs..............................................................176

Troubleshooting with the Audit Log Monitor .................................180

Generating reports from the Admin Console................................182

Generating reports from the command line..................................186

Exporting data into Excel worksheets ..........................................188

175

Chapter 7: Monitoring PremierAccess ActivityUnderstanding audit logs

Understanding audit logs

This chapter describes how to monitor PremierAccess activity using its audit logs. The chapter contains the following topics:

PremierAccess records all authentication and administration activity into audit logs. These audit logs are stored in the PremierAccess database, and are easily accessible for monitoring enterprise activity and for creating reports. The audit logs are viewable by all system administrators, and by local administrators and helpdesk staff who have been given the appropriate privileges.

Querying audit logs

PremierAccess allows you to query specific audit logs using a variety of search parameters. You may choose to search for all audit logs, search for those that match a specific date range, and/or search using specific parameter filters that you define. Table 16 lists the search parameter filters and their functions.

Table 16: Audit Log search parameter filters

Search Parameter Filter Function

Performed by Use this filter to identify authenticator and administrative activity performed by a specific user (by userid). For authentication audit logs, this specifies the user that attempted authentication to PremierAccess. For all other event types, this specifies the user that performed the particular action described by the audit log.

Event type Use this filter to search by:

• Authentication

• Insertion

• Deletion

• Modification

• Authenticator import

• Backup or restore

• Data error

• Log archive operation

• Administrative session

• User session start

• Resign operation

More...

176


Searching the audit logs

To search the audit logs, from the Admin Console, select Find -> Audit Logs. The Find Audit Log Entries window appears.

Figure 117: Find AuditLog entries window

1 Select Find all available, or refine your search using the search filters.

Authentication status Use this filter to specify a search of authentication activity that resulted in either success or failure. Though this filter is relevant only for searches on authentication activity, it is not necessary to specify an ‘Event type’ filter with a value of ‘Authentication’, since it is implicitly assumed.

Admin Group Use this filter to narrow down the authentication and administration activity specific to a particular admin group.

Logins where role Use this filter to specify a search of authentication activity in which users were either granted or denied access due to a particular role. Though this filter is relevant only for searches on authentication activity, it is not necessary to specify an ‘Event type’ filter with a value of ‘Authentication’, since it is implicitly assumed.

Database entry Use this filter to narrow down the audit logs that pertain to administrative activity on a specific entry in the database (for instance, a specific user account or token record). This filter is relevant only for audit logs that do not describe authentication attempts, and therefore is ideal for tracking the modification history of specific database entries.

Search Parameter Filter Function

177


2 Select the Match dates check box to search for audit logs in a date range that you will specify, or clear the Match dates check box to return all available audit logs, regardless of date. You may use the Match dates check box with Find all available or Find all that match.

3 Click the Find button. If the system locates one or more audit log entries that match the search criteria you selected, they will be listed.

Viewing a specific user’s authentication activity

To view a specific user’s authentication attempts, from the Admin Console select Find -> Audit Logs. The Find Audit Log entries window appears.

Figure 118: FindSpecific Audit Log entries

1 Select Find all that match, then enter the user’s name in the far right box.

2 Select the More button.

3 Select an Event type from the left side drop-down box, then select Authentication from the right side drop-down box.

4 If desired, specify a date and time range to narrow down the results, then click the Find button.

Figure 119: FindResults: Audit Log Entries

window

The Find Results: Audit Log Entries window appears with the user’s authentication activity for the specified period.

178


Viewing specific entry details

Log summaries allow you to review the details of an audit log. To review an entry’s details, find the specific log you are interested in, and from the Search Results: Audit Log Entries window, double-click on the entry. The View Audit Log Entry window appears with detailed information about the specific audit log. Click OK when you are done.

Figure 120: ViewSpecific Audit Log entry

summary screen

179

Chapter 7: Monitoring PremierAccess ActivityTroubleshooting with the Audit Log Monitor

Troubleshooting with the Audit Log Monitor

The Audit Log Monitor allows you to troubleshoot authentication and administration activity in realtime. For example, when an end user calls into a helpdesk about an authentication problem, the helpdesk staff can invoke the Audit Log Monitor to display only authentication events concerning the end user. As the administrator coaches the user through successive authentications, logs describing these attempts automatically appear in the Audit Log Monitor.

The Audit Log Monitor is similar to the traditional mechanism for viewing audit logs, but the difference is that the Audit Log Monitor continues to refresh the log output periodically, sparing administrators from having to manually perform the refresh function.

The Audit Log Monitor is available to the same set of users who are allowed to view audit logs. Therefore, system administrators can use it, and helpdesk staff and local administrators may use it if they have been given the privilege to view audit logs in PremierAccess.

Note: If the Audit Log Monitor is run on a remote Admin Console (a machine other than the PremierAccess Server machine), synchronizing the clocks on the two machines results in optimal performance. This applies regardless of differences in time zones.

Invoking the Audit Log Monitor

To invoke the Audit Log Monitor, select Tools -> Audit Log Monitor. The Monitor Audit Log Entries window appears.

Figure 121: MonitorAudit Log Entries window

180

Chapter 7: Monitoring PremierAccess ActivityTroubleshooting with the Audit Log Monitor

Choosing logs to monitor

You may choose to monitor all available audit logs or a particular subset. For example, to debug all authentication activity by an end user named Jerry, you would monitor all audit logs that match the event type authentication and userid jerry. Figure 122 demonstrates how you would configure the Audit Log Monitor to display the authentication activity of user Jerry.

Figure 122: Configuringthe Audit Log Monitor to

display specific user ’sauthentication activity

1 To monitor a specific user’s events, specify the user and the types of audit logs that you wish to monitor.

2 Click the Find button. The Monitor Results: Audit Log Entries window appears displaying all authentication activity performed by the user. The administrator can review the authentication process with the end user, and use the audit logs to debug the user’s authentication problem.

Important: By default, the Audit Log Monitor refreshes every two seconds. You may find that a different refresh period works better for your particular environment. To manually set the refresh period, change the value in the Monitor_interval_in_seconds property in the Admin Console’s client.ini file. After changing the value, restart the Monitoring tool for the changes to take effect.

181

Chapter 7: Monitoring PremierAccess ActivityGenerating reports from the Admin Console

Generating reports from the Admin Console

PremierAccess includes a general-purpose facility to enable the generation of reports that summarize and detail your organization’s administrative and authentication activity. The Admin Console contains features that allow you to export raw data that can easily be imported into a third-party reporting package. Such a package will give you with the ability and flexibility to convert raw logging data into highly-customized reports describing your organization’s activity.

Along with audit logs, you can export any subset of the PremierAccess data elements that you have introduced or created, including users, admin groups, roles, and authenticators. For example, with the appropriate raw data, you can easily generate reports that identify users who do not yet have an authenticator assigned, and identify the authenticators that remain unassigned to users. Once you have exported your raw data, the reporting possibilities are endless.

PremierAccess exports the raw data that you specify into Microsoft Excel worksheet files. With good use of Excel macros, you may find that a third-party reporting package is not even necessary to generate useful reports. However, if you have a favorite reporting package, it will certainly accept data from either the native Excel worksheet format (XLS), or from the CSV (comma separated value) format (which Excel is capable of generating).

182


Creating reports

To create reports, connect to an Admin Server, and select Tools -> Reports. The Report Definition window appears. To generate a report, you must define the categories of raw data that you would like to export. Although you are given the ability to export almost every entry in the PremierAccess database, in practice, you will usually just export audit log data, user data, and perhaps software/hardware authenticator data. For example, administrators interested in generating reports concerning the authentication activity will want to export authentication audit logs. Administrators interested in generating reports on users who are attack-locked, or are otherwise disabled, will want to export user data. Administrators interested in generating reports on unassigned tokens will want to export software/hardware authenticator data.

Figure 123: The ReportDefinition window

1 Select the check boxes in the Included column for the categories of raw data that you wish to include in your report.

Tip: To clear all the check boxes, select the Include None button.

2 (Optional) To refine the criteria for this report, select the Refine Criteria button and use Find to refine the category.

3 (Optional) To view a summary of the report criteria, select the Content Summary button. The View Report Filter Details window appears summarizing the report’s contents. When you are finished viewing the summary, click OK.

4 Once the data is in Excel, you can sort rows by any of the column headers, or use Excel macros to generate pie charts and bar graphs to summarize authentication activity. You can also move the data to your reporting package.

183


Report templates

The report generation window allows you to specify the types of raw data to export. By checking the check box associated with a category, you are adding that report filter to a report template. A report template simply defines a set of data to export. This set may comprise a single category (e.g. only audit logs) or several categories (e.g. audit logs, users, authenticators).

Saving a report template

The Save Template button allows you to store the settings of a particular report as a report template. Figure 124 shows the details of a report template that fetches all authentication audit logs, users and authenticators in an admin group called Pacific.

Figure 124: Filter Detailswindow

Loading a report template

The Load Template button on the report generation window allows you to retrieve a report template from disk. Templates allow you to define a report that will be run frequently and thus ensure that you always fetch the same categories of raw data. For example, if on a weekly basis, you would like to analyze the authentication activity of the users in the Pacific admin group, you might create and save a report template called weekly-pacific_auth.tpl that fetches authentication audit logs. Then, once a week, you would invoke the report definition dialog, load this report template, and execute the report.

184


Report worksheet generation

The Admin Console will sometimes generate more than one worksheet for a given report template. When a report template contains more then one categories (e.g. users and tokens), an Excel worksheet file will be created for each data type. In addition, the Number_of_lines_per_Excel_sheet property in the Admin Console configuration file (client.ini) governs the number of rows that will be written to any one particular worksheet file. By default, this property is set to 10000. For example, if you export 15000 audit logs during the report generation process, the first 10000 rows will be stored in one worksheet file (e.g. with the name “weekly-logs.xls”) and the remaining 5000 rows will be stored in a second worksheet file with a similar name (e.g. “weekly-logs_0.xls”).

Whenever the Admin Console creates more than one worksheet file for a single report, it will also create a VBScript file that can be used to merge all of the individual files into one file with a worksheet for each file. This VBScript can only be used on Windows platforms. This script file will be named similarly to the generated worksheet files. To continue the example, this script file would be called “merge-weekly-logs.vbs”. The output of this script would be a single Excel worksheet file called “merged-weekly-logs.xls”.

Note: If you change the value of the Number_of_lines_per_Excel_sheet property in the Admin Console configuration, you must restart the Admin Console for the new value to take effect.

185

Chapter 7: Monitoring PremierAccess ActivityGenerating reports from the command line

Generating reports from the command line

In addition to using the PremierAccess Admin Console to generate reports, you may also generate reports using a command line tool that is packaged with the Admin Console. This gives you the ability to create your own shell scripts that can trigger the creation of several reports in one pass. Additionally, you can use your operating system’s native scheduling features to call your custom shell scripts on scheduled intervals. By doing so, you can automate the process of generating periodic reports (for example, to track authentication activity on a weekly basis).

The command line reporting tool can be found in the Admin Console installation directory (<install_dir>./PremierAccess/AdminConsole). On Solaris operating systems, the tool is called report.sh. In the same way that the Admin Console can be installed and executed on a remote machine (i.e. executing on a machine other then the PremierAccess server machine), so also can the command line reporting tool.

As the command line reporting tool is simply a text-based shell script, it is easily configurable. You will need to specify the name of the PremierAccess server machine, the port on which the Admin Server is listening, and the userid and password of an administrative user through which the report queries can be executed. Table 17 on page 186 details the variables that are defined in both versions of the shell script.

Table 17: Shell script variables

Variable Name Purpose

ADMIN_HOST Specify the IP address or hostname of the machine on which the PremierAccess Admin Server is installed

ADMIN_PORT Specify the port number on which the PremierAccess Admin Server is listening. (By default, this port number is 5040.)

ADMIN_USER Specify the userid of the administrative user account that will execute the desired report queries. This user account must use a fixed password to authenticate to PremierAccess.

ADMIN_PASSWORD

Specify the password for the named administrative user. This value need not be defined in the shell script as it can be supplied as a command line argument to the reporting tool. If you do decide to define the password in the shell script, you should ensure that the script is properly secured, either via operating system security features or via physical machine security.

186

Chapter 7: Monitoring PremierAccess ActivityGenerating reports from the command line

Using the command line reporting tool

Solaris: report.sh template-file report-output-file [password]

The first two arguments are required. The first argument specifies the location of a saved report template. Refer to “Report templates” on page 184 for instructions on how to define and save a report template. By default, report templates are saved in the “templates” subdirectory of the Admin Console installation. The second argument specifies the location of the target Excel worksheet file. The Admin Console installer creates a subdirectory called “reports” which can be used to contain all of your generated reports.

The third argument is optional and allows you to specify the password of the administrative user that is used to execute the desired report queries. This is useful in situations where it is not appropriate to store the cleartext fixed password in the shell script. This might be because you wish to run reports from a remote machine that is not physically secured.

For example, assume you have created a report template called “all-logs.tpl” that fetches all available audit log data in the PremierAccess database and you wish to store this data in an Excel worksheet file called “all-logs.xls”.

From the Solaris command line, you might use: report.sh templates/all-logs.tpl reports/all-logs.xls mypassword

187

Chapter 7: Monitoring PremierAccess ActivityExporting data into Excel worksheets

Exporting data into Excel worksheets

An additional method exists for exporting data into Excel spreadsheets. The dialogs that appear when you choose categories from the Find menu have a button called Export. Choosing this button causes the Admin Console to export the search results data directly into an Excel spreadsheet. You can export any data contained within PremierAccess, including audit logs, admin group data, user data, login and Web ACL data, roles, profiles, tokens, and sessions data. Figure 125 shows the Export button on the Find Users window.

Figure 125: ExportButton on the Find User

Entries window

When you select the Export button, PremierAccess prompts you to name the Excel worksheet file it will create. All data resulting from your search is written directly to the new worksheet file.

188

8CHAPTER Maintaining

PremierAccess

In this chapter...

Understanding audit log archives .................................................190

Replication and fault tolerance .....................................................194

Optimizing archiving, authentication, and replication performance ....196

Backing up and restoring your user database..............................199

Repairing invalid entries ...............................................................202

Managing the Admin and AAA Server keys .................................203

189

Chapter 8: Maintaining PremierAccessUnderstanding audit log archives

Understanding audit log archives

This chapter describes the most common PremierAccess maintenance tasks. The chapter contains the following topics:

Every event that occurs in your system is recorded into audit logs. Over time, these logs can become quite large, and can negatively affect performance if they remain on the database server. To avoid this situation, older logs are archived. You archive audit logs by configuring PremierAccess to remove the log entries from the database and save them to a local file after a set period of time, thereby decreasing the load on the database. The Admin Server handles all audit log archive operations.

The Admin Server constantly monitors the age of the audit log data stored in the PremierAccess database. Once particular audit log entries reach a certain age, the Admin Server removes the entries from the database and archives them to a local file. Once these entries have been archived, the Admin Console and the command line reporting tool cannot retrieve them.

Managing audit log archives

Each time audit logs are archived, a file is created and given a name based on the date and time of the first log in the archived set. To manage your audit log archive sets, from the Admin Console, select File -> Log Archives. The Manage Audit Log Archives window appears.

Figure 126: ManageAudit Log Archives

window

The Manage Audit Log Archives window displays all previously archived sets of audit logs. The sections that follow explain how to load, unload, delete, and configure the time when logs are archived.

Tip: If you have not archived any audit logs yet, the list here will be empty.

190


Loading an archived audit log file

The Manage Audit Log Archives window lists all existing archive sets, and indicates whether or not the sets are currently loaded. When archive sets are loaded, the logs contained in them are available for searches and reports.

To load a previously archived file, from the list on the Manage Audit Log Archives window, select the desired archive set, then click Load. If the load was successful, the word Yes appears in the Loaded column. The audit logs from the archive file are now available in the PremierAccess database. Click OK to close the window.

Unloading an archive set

The Manage Audit Logs Archives window allows you to unload archive sets from the database server. Unloading an archive set deletes its previously loaded contents from the PremierAccess database, but has no affect on the disk file where the archived set is stored.

To unload a set from the database, select the archive set you want to unload from the list on the Manage Audit Log Archives window, then click Unload. When the archive set is successfully unloaded, the word No appears in the Loaded column. The log entries from that set are no longer available on the database server, but they are archived on the Admin Server. Click OK to close the window.

Important: Loading and unloading archives start new connections to the Admin Server. Login credentials will be requested again for those new connections if the initial Admin Console login was performed more than eight hours ago.

Deleting an archived audit log file

When you want to completely remove an archive set from the system, you use the Delete button on the Manage Audit Log Archives window.

To delete an archive file from the system, from the list on the Manage Audit Log Archives window, select the file you want to delete, then click Delete and answer Yes to the prompt asking you to confirm your decision. When the file is successfully deleted, it will be removed from the list. Click OK to close the window.

Important: This will permanently delete the archive set.

191


Configuring the archival of audit logs

To archive audit logs you must designate a period of time after which audit logs of a chosen age will automatically get archived. The Audit Log Archival pane on the Manage Audit Log Archives window allows you to define the age (in hours) after which the designated logs automatically are archived into an archive set.

Automatically archiving audit logs

To automatically archive audit logs of a certain age, on the Manage Audit Log Archives pane, in the Archive Audit Logs Older Than field enter the number of Hours that logs should exist before they are archived. Click OK to save this value.

Archiving audit logs immediately

To archive off all the audit logs immediately, click Now on the Manage Audit Log Archives pane. PremierAccess archives off to files all of the audit logs currently stored in the database and removes them from the system. This may take a few minutes in larger databases. Once done, the archived log sets appear in the list window.

Figure 127: ManageAudit Log Archive window

with archived log

When you are done, click OK to close the window.

Log archival impact on reporting

The most common reporting scenarios will involve the export of audit log data. With audit logs, you can determine many useful statistics that describe the authentication activity in your organization. However, you must ensure that the appropriate amount of audit log data stays resident within the Admin Server for long enough so that it can be exported through the new reporting mechanism. Specifically, you must ensure that the audit log archival period is sufficiently large. If you intend to run weekly reports based on a week’s worth of audit log data, then you must ensure that your audit log archival period is at least seven days.

192


Using advanced archiving features

One of PremierAccess’s advanced features is the audit logs archives keywords functionality. Table 18 lists keywords that can be used when loading and unloading archive files. The values here can be customized to best suit your environment by changing them in the ...\PremierAccess\SERVERS\Shared\sccservers.ini file.

Table 18: Audit log archives keywords

Keyword FunctionRecommended Setting Parameter

ArchiveWorkerThreads=20 Controls the number of threads used for loading archive sets. The higher the number, the faster the loading operation will work, but the more memory it will require.

Optimum values will vary from system to system, but a range of 5 to 40 threads is reasonable.

Set to 0 to revert back to the single thread implementation of versions prior to version 3.1.

ArchiveLogsInBatch=50 Controls the number of logs in a batch per thread.

Optimum values will vary from system to system, but a range of 20 to 100 logs is reasonable.

193

Chapter 8: Maintaining PremierAccessReplication and fault tolerance

Replication and fault tolerance

Replication plays a key part in the fault tolerance scheme within PremierAccess. It is the process of duplicating or copying database information from one machine to one or more other remote machines. Replication is implemented in the Admin Server of each PremierAccess installation.

Ring topology architecture

PremierAccess uses a bidirectional ring topology architecture. In a ring topology, each machine is known as a replication peer, and these replication peers are arranged in a logical loop. Each replication peer has a unique address, and it communicates with up to two neighbors: the logical next replication peer, and the logical previous replication peer in the ring. Multiple peer replication is shown in Figure 128.

Figure 128: Multiplepeer replication

If there are only two replication peers in the ring, each will only have a Next replication peer neighbor as shown in Figure 129.

Figure 129: Two peerreplication

Previous Next Next

NextNextPrevious

Previous

Previous

Next

Next

194

Chapter 8: Maintaining PremierAccessReplication and fault tolerance

How replication works

PremierAccess replication tracks all relevant database changes in realtime. Information about each change is written into change records in a special section of the main database known as the change log. The change records are used to propagate changes to the participating neighbor replication peers in the ring. Once all neighbors have been updated, the change log entry is deleted from the database.

Note: The change log (QueryChangeLog.bat) is not modifiable; it is only available to view database changes. It is an internal mechanism that PremierAccess uses to reliably track changes to its database.

Tip: To obtain the total number of change log records without displaying the text of each record that is found, use ./runsql .shCheckChangeLogCount.sql or ./MonitorChangeLog.sh from the Database/bin directory.

Change record creation and change propagation are independent actions, which means you can track database changes, but delay their replication to other replication peers until a later time. For detailed information about setting up a replication ring, refer to your SafeWord PremierAccess Installation Guide.

195

Chapter 8: Maintaining PremierAccessOptimizing archiving, authentication, and replication performance

Optimizing archiving, authentication, and replication performance

In some environments, it may become necessary to minimize replication traffic and remove resource contention issues between replication and authentication. The following sections describe how to configure your software for optimal results.

Archiving during minimal activity periods

You can optimize your environment by archiving during your organization’s minimal activity periods. For example, if your organization is busiest between the hours of 7 a.m. and 7 p.m, then archiving after 7 p.m. and before 7 a.m. reduces the database resource contention between archiving and authentication.

Changing the default archive value

The sccservers.ini file contains the entry that determines when archiving occurs. By default the value is set to archive logs every hour. To change the setting and force log archiving to only occur during minimal activity periods, you must uncomment the attribute and change the range specifier value to the hour or range of hours when you want archiving to occur.

To enable archiving times during minimal activity periods, browse to the ...\PremierAccess\SERVERS\Shared\sccservers.ini file.

1 Find the following entry: #SkipArchivingHours=6-18.

2 Uncomment the line by removing the # symbol from its beginning.

3 On the same line, specify the hours when you do not want to log archives by entering the specific hour or range of hours. The following rules apply when setting your hours:

4 Archiving hours are 0-based and use a 24-hour clock.

5 Entries can be either a specific number or a dash-separated range of numbers. For example, the value 0, 6-18, 23 would skip archiving during the hours of 11 p.m. and 1 a.m., and from 6 a.m. to 7 p.m.

6 Spaces are ignored and individual entries are comma-delimited.

7 Restart the Administration Server.

Note: Use of this feature does not affect how the audit log archives are created. Instead, it only affects when the administration server performs the archiving.

196


Using multiple database connections

You may choose to fine tune database and networking throughput for replication if your network topology has higher than normal network latencies. By default, the number of replication threads is set to one (1). Increasing the number of replication threads may improvereplication performance in your environment.

To change the number of replication threads, browse to the ...\PremierAccess\SERVERS\Shared\sccservers.ini file.

The file contains the entry that sets the number of threads and database connections the replication engine uses to propagate changes to this peer.

1 Find the following entry: #ReplPrev_ReplWorkerThreadCount=1

2 Uncomment the line by removing the # symbol from its beginning.

3 Change the value currently set to one (1) to the number of threads you want to be used for replication. Reasonable values for this attribute are in the range of 1 to 15 threads.

4 The example in step 1 configures replication thread count for the previous peer in the replication ring. To configure thread count for the next peer, locate and modify the following entry: #ReplNext_ReplWorkerThreadCount=1

5 Restart the Administration Servers in the system.

Tip: Experiment with the number of threads to determine the best replication throughput for your network.

Running without an archive log master

Configuring individual server log archiving in a multi-server system allows each server in the ring to perform its own archiving; each effectively becomes a log master on which archive operations can be performed. In this mode, each server in the system archives the local audit logs and removes them from the local database. The deletions are not replicated to other servers in the ring; instead, the archive manager on each server explicitly archives the logs.

Additionally, when you load or unload archive sets, the logs in the archive are only imported into the local machine. Insertions and deletions are not replicated throughout the system. This mode greatly reduces the replication traffic caused by both day-to-day operation of the system and the occasional loading and unloading of archive sets.

197


Note: Another positive side effect of running without an archive log master is that the archived audit log files are effectively replicated on all servers in the system.

Enabling individual server log archiving

1 To enable individual server log archiving, connect to the current log master server.

2 Select Configuration -> PremierAccess.

3 Select the Servers tab.

4 Select the All admin servers are log servers option.

5 Restart the administration servers in the system.

198

Chapter 8: Maintaining PremierAccessBacking up and restoring your user database

Backing up and restoring your user database

PremierAccess offers a means by which your user database can be backed up to a specific file. This allows you to maintain a backup file that can be used to restore settings, user information, and logs if corruption of your system occurs. Frequent backups can prevent significant losses of user data.

Important: All configuration data is overwritten when you restore your database. If your current license is different from the license in effect at the time of database backup, you must reapply your license and reactivate following restoration of your database.

Important: To maintain existing configuration data when there is an LDIF file to be restored on a newly installed database, the backup LDIF file must be restored before doing anything else on the system. This ensures the database will not be corrupted after restoration. If there are already users in the database, before restoring an LDIF file, ensure that the Overwrite existing entries check box is cleared. You must also review the list of objects in the reject file that is generated after restore, then update your system.

Backing up your database

Important: Backing up, restoring, and log archive operations start new connections to the Admin Server. Login credentials will be requested again for those new connections if the initial Admin Console login was performed more than eight hours ago.

To create a backup file, at the Admin Console, select File -> Backup Database. The Backup Database window appears.

Figure 130: BackupDatabase window

1 Enter the file name in the Backup to file field. Enter the path and name manually, or click Browse to locate a specific directory and/or filename.

2 (Optional) Select the Do not backup audit logs check box if you prefer to not back up these files.

3 (Optional) Select the Encrypt records check box if you wish to encrypt the records.

199


4 Enter the entire encryption key string in the Encryption key field.

5 Retype the Encryption key to confirm it.

Note: The key text string you use here must be used again if you restore your database from this backup file. Be sure to keep the key text string in a safe, but accessible place.

6 Click OK. When the export is complete, the Export Completed window appears to confirm the number of records exported.

Figure 131: Exportcompleted dialog box

7 Click OK.

Restoring your database

If your database becomes corrupted, you can use a backup file to restore settings and user information.

Important: Backing up, restoring, and log archive operations start new connections to the Admin Server. Login credentials will be requested again for those new connections if the initial Admin Console login was performed more than eight hours ago.

Tip: Before initiating this procedure, log out of the Admin Console, then log back in again. If you have a clean database (or a newly installed database), we recommend that you restore your LDIF file before doing anything (like adding entries) in the database.

To restore your database from a previously saved backup file, At the Admin Console, select File -> Restore Database. The Restore Database window appears.

Figure 132: RestoreDatabase window

200


1 Enter the filename for the backup file to be used. Either manually type the full path and filename, or click Browse to find the directory and file.

2 If an encryption key was used, check the Decrypt records with key check box, and supply the encryption key string.

3 (Optional) Check the Log restored records check box if you want a log entry to be created for every record restored from a backup.

4 (Optional) Check the Re-sign restored records check box to have the system compute a new signature for each record restored from the backup. You would want to use this option if, for instance, the Admin Server key used for signing records was compromised (see “Admin and AAA Server key management” on page 2-25). This is required if the new system has a different signature key than the system that produced this backup file.

5 By default, the Overwrite existing entries box is checked. This setting enables the Admin Server to overwrite existing records in the database with those from the backup file. If cleared, the Admin Server will return “Duplicate Entry Error Messages” during the restore operation.

6 Click OK. A status window appears in which the status of your backup is shown. When the backup is completed, another dialog box will inform you of the number of successfully imported records.

Backing up your database using the command line

Occasionally, it is convenient to back up or restore data quickly, without the usual data validation and processing overhead of the standard PremierAccess Backup/Restore functionality. In such cases, you can use two low-level QBackup and QRestore utilities that back up and restore the raw database data. These work quickly because they simply export and import the PremierAccess tables to a text file. They are convenient as quick utilities that can be scheduled to run periodically to take snapshots of the data.

Note: These utilities cannot be used to back up and restore data between different versions of PremierAccess. They are not compatible with the file format used by the standard PremierAccess Backup/Restore functionality. Files produced by QBackup can only be used by QRestore. These scripts must not be used as a replacement for the standard backup operation performed via the PremierAccess Admin Console.

The scripts are located in the <INSTALL_DIR>\PremierAccess\SERVERS\Database\bin directory and can be used as follows: QBackup filename to back up the data, and QRestore filename to restore it.

201

Chapter 8: Maintaining PremierAccessRepairing invalid entries

Repairing invalid entries

If an unauthorized party attempts to modify an entry, an entry with an invalid signature may occur. To repair this type of entry, select Tools -> Invalid Entries. The Entries with Invalid Signatures window appears.

Figure 133: Entries withInvalid Signatures window

Select the entry ID requiring repair, then click Repair. A summary window appears with the details for this signature.

Figure 134: View Userwindow

Visually verify that these settings are correct. Click Repair again. If you have more invalid signatures, repeat this process for each one.

Note: External factors such as network latencies and failures during replication can occasionally invalidate database signatures. Presence of an invalid signature does not necessarily indicate an attack on your database. It is however, imperative that you carefully review the validity of the entry data whose signature was found to be invalid.

Note: If you are a local administrator, you will need to have read/write access to audit logs. For information about changing access privileges, see “Setting user privileges” on page 5-21.

202

Chapter 8: Maintaining PremierAccessManaging the Admin and AAA Server keys

Managing the Admin and AAA Server keys

The Admin Server and AAA Server hold several cryptographic keys. The one held by the Admin Server is used for signing entries written into the directory. This assures integrity of the data. On a regular basis, or if either of these keys is (or is suspected to be) compromised, you will want to change the key and re-sign all database entries.

To change the Admin Server signing key, back up your PremierAccess system database.

1 At the local machine (on which the Admin Server is installed), log on as an administrator.

2 CD to the directory PremierAccess/SERVERS/Shared.

3 Locate and open the file signers.cfg for editing. The file format is shown below.

4 Modify the following lines:– SccAdminServer. Remove default value (after DES,) and add another

key string (which can be numerics, or a combination of letters and numbers). For signing, the key must contain 8 characters minimum.

– SccAuthServer. Remove default value (after DES,) and add another key string (which can be numerics, or a combination of letters and numbers). For signing, the key must contain 8 characters minimum.

Important: Do not modify the dbCipher lines.

5 Restart the Admin Server (and/or AAA Server) using the Installation and Management Utility.

Restore the database, with Re-sign restored records checked. This will sign all entries with the new key.

Signers configuration file# Multiple signers are supported for verification, but the first one found with# a name matching a particular component will be used for signing for that# component## Currently supported algorithm types for signing and encryption are “DES”# and “3DES”#SccAdminServer, DES, 12345678SccAuthServer, DES, 87654321dbCipher, 3DES, 1234abcd4321dcbadbCipher, DES, 1234abcd

To change the Admin Server key, modify this value

To change the AAA Server key, modify this value

203

Chapter 8: Maintaining PremierAccessManaging the Admin and AAA Server keys

204

9CHAPTER Managing the PremierAccess

RADIUS Server

In this chapter...

Overview of the PremierAccess RADIUS Server .........................206

Prerequisites ................................................................................209

PremierAccess RADIUS configuration files..................................210

Authorization and configuration groups........................................210

Authenticators ..............................................................................214

Troubleshooting common problems .............................................219

Diagnostic traces during correct operation...................................222

Diagnostic traces with incorrect configuration ..............................238

References ...................................................................................247

205

Chapter 9: Managing the PremierAccess RADIUS ServerOverview of the PremierAccess RADIUS Server

Overview of the PremierAccess RADIUS Server

This chapter explains how to manage and troubleshoot the PremierAccess Remote Authentication Dial In User Service (RADIUS) Server. This chapter is intended for PremierAccess administrators using communication servers with RADIUS, or any other clients that use RADIUS and PremierAccess authentication.

As networks grow and branch out to remote locations, network security increases in importance and administration complexity. Customers need to protect networks and network services from unauthorized access by remote users. RADIUS is one of the protocols commonly used to provide these solutions in today's internetworks.

RADIUS protocol

Authentication is the process of identifying and verifying a user. Several methods can be used to authenticate a user, but the most common includes a combination of user name and password. Once a user is authenticated, authorization to various network resources and services can be granted. Authorization determines what a user can do, and accounting is the action of recording what a user is doing or has done.

The RADIUS protocols define the exchange of information between these components in order to provide authentication, authorization, and accounting functionality. The RADIUS protocol, as published by Livingston, is a method of managing the exchange of authentication, authorization, and accounting information in the network. RADIUS draft was submitted to the Internet Engineering Task Force (IETF) as a draft standard in June, 1996. RADIUS is a fully open protocol.

PremierAccess RADIUS Server

The PremierAccess RADIUS Server is an authentication protocol server daemon that has been interfaced with PremierAccess through SafeNet’s own proprietary protocol EASSP. It supports all of the RADIUS functionality documented in Internet RFC 2138, and all functionality as documented in the PremierAccess publications, with minor restrictions on multiple simultaneous dynamic passcode authenticators. The PremierAccess RADIUS Server can be located on a separate computer, distinct from any computer that houses the PremierAccess authentication server. It can also be located on the same computer as the PremierAccess authentication server.

206


PremierAccess RADIUS Server features

• Fully RFC 2138 compliant

The PremierAccess RADIUS Server is fully RFC 2138 compliant.

• Supports group authorization

The PremierAccess RADIUS Server supports authorization and configura-tion groups named in the PremierAccess directive. The PremierAccess record for any user can list the name of a group record defined in the RADIUS users file.

Most users can be treated as members of a group of users that will receive identical treatment with regard to network authorization. For example, a company with 500 employees may have a group of 40 salespersons that all need permission to dial into the corporate network via modem, and that all need access to the computer hosting the sales database. This group mech-anism allows all 40 of those salespersons to be assigned to the sales group and to be administered simultaneously. Any administrative change to the definition of the sales record will immediately affect all 40 sales users.

• User-specific attributes support

Some RADIUS attributes are closely associated with a specific user, and do not lend themselves well to administration as part of a large group of users. For example, it may be desirable to assign a specific IP address to a spe-cific person every time he or she is attached to the Internet. The PremierAc-cess RADIUS Server supports user-specific RADIUS attributes matching a user or group name in the user’s file. This user-specific mechanism allows PremierAccess administrators to store arbitrary RADIUS attributes directly inside the return field of the appropriate ACL entry.

• CHAP support

The PremierAccess administrators can manage CHAP authenticators in the same way they support all other authenticator types.

• Vendor-Specific Attributes support

The PremierAccess RADIUS Server provides full support for Vendor-Spe-cific Attributes (VSAs) in accordance with the provisions of RFC 2138. VSAs allow vendors of routers, communication servers, or other RADIUS-compatible clients to take full advantage of the unique features of their equipment. Under the provisions of the current RADIUS protocol, any ven-dor can teach his RADIUS-compatible client equipment to accept and carry out one or more vendor-specific commands through the RADIUS protocol.

The PremierAccess RADIUS Server is capable of sending any RADIUS-compliant VSA to any RADIUS client after authentication, whenever the data associated with an authenticated user references a VSA.

• RADIUS Proxy support

The RADIUS Server was enhanced with the ability to support informal “RADIUS proxy forwarding.”

207


• RADIUS accounting support

The RADIUS protocol includes provisions for storing messages from RADIUS clients. These are generally used to keep records of network access activity for accounting purposes. The RADIUS Server can store these messages in a file for offline analysis.

• Extensive diagnostics level

The PremierAccess RADIUS Server provides extensive diagnostic levels to help troubleshoot RADIUS authentication sessions.

208

Chapter 9: Managing the PremierAccess RADIUS ServerPrerequisites

Prerequisites To run the PremierAccess RADIUS Server, you need the following:

• At least one RADIUS-compatible client

The PremierAccess RADIUS Server will listen for RADIUS requests from RADIUS clients. Therefore, at least one RADIUS-compatible client is required. A RADIUS-compatible client may be a router, communication server, VPN, firewall, or an application.

• PremierAccess Authentication, Authorization and Accounting (AAA) Server

The RADIUS authentication requests received by the RADIUS Server from the RADIUS client(s) must be forwarded to thePremierAccess authentication server daemon.

The PremierAccess RADIUS Server issues a request that is formatted according to the conventions of SafeNet’s authentication protocol, and transmits it across the network. If an authentications server is listening for such requests, it can be serviced.

• RADIUS users registered in the PremierAccess User database

All users that need to be authenticated by PremierAccess must be regis-tered in the PremierAccess User database. Users must be registered in the PremierAccess database if the Authentication Broker is not going to be used.

209

Chapter 9: Managing the PremierAccess RADIUS ServerPremierAccess RADIUS configuration files

PremierAccess RADIUS configuration files

The PremierAccess RADIUS Server has five configuration files:

• clients

• dictionary

• users

• radius.cfg

• authfile

The PremierAccess RADIUS configuration files, clients, and the RADIUS.cfg can be configured automatically during a custom installation, and can be edited manually, if needed.

Authorization and configuration groups

The PremierAccess RADIUS Server supports authorization and configuration groups named in the PremierAccess databases.

Creating an ACL entry and role for RADIUS

The following steps will take you through the process of adding an ACL entry and role for your RADIUS users.

To create an ACL entry, create either a new ACL just for RADIUS users (see “Adding or changing authenticator profiles” on page 145), or add a RADIUS-specific entry to an existing ACL (see “Understanding login ACL entries” on page 104).

1 Create a role for this set of users (see “Creating roles” on page 102).

2 In the ACL entry, click the Subject tab, and set the following parameters:– Some Users.– Role = (whatever role you created in step 1).

3 Click the Restrictions tab, and set restrictions for these users.

4 Click the Return tab, and set the following parameters:– Authentication Status = Success– Select the Return a value on successful authentication box– Click the Text option– Enter group=Develop in the text field.

Note: The Develop group must exist in the users file. It is case-sensitive.

5 Create the users that will use the role you have created.

210

Chapter 9: Managing the PremierAccess RADIUS ServerAuthorization and configuration groups

Configuring the groups in the Users file

The Users file defines the names of all users and the type of authentication that will be demanded of each user. Everything handled by the industry-standard Livingston RADIUS Server is handled in the same way by the PremierAccess RADIUS Server. In addition, the following items can be inserted into the users file when used with the PremierAccess RADIUS Server:

• SAFEWORD (as a password indicator)

• Authorization and configuration group records

When the special keyword “SAFEWORD” is inserted into the users file, it must follow the special keywords “Password =”. This indicates that authentication for the user described in the associated record must come from PremierAccess.

Authorization and configuration group records (or group records) are unique to the PremierAccess RADIUS Server, and are not familiar to administrators that have been working with the Livingston RADIUS Server. Like the familiar “user” records that dominate the bulk of Livingston's Users file, group records always begin with a name. However, instead of representing an individual with a name like “fred,” group records represent multiple people and tend to use descriptive names, such as “Developers” or “Sales.” Unlike user records, group records never contain a “Password =” attribute, because they are always authenticated through PremierAccess. Group records can contain any combination of legal RADIUS attributes, and are used to configure data communication parameters and authorization privileges for groups of users after their identities have been positively authenticated by PremierAccess.

The DEFAULT user record

The record in the Users file that specifies the username as “DEFAULT” deserves special attention. It is used to handle all users whose names do not match the names of any other user records in the Users file. Thus, the DEFAULT record can be set up to demand PremierAccess authentication and is sometimes the only user record in the Users file. Most PremierAccess administrators take full advantage of this mechanism to simplify their administrative duties. The sample Users file on page 250 illustrates this type of setup. This arrangement minimizes the need to edit the Users file.

Although the PremierAccess RADIUS Server supports all of the features of the Livingston users file, in practice the Users file in PremierAccess RADIUS Server situations is generally much simpler than the corresponding file used by Livingston RADIUS Servers. This is because the high-performance PremierAccess database can better handle user authentication, assigns each user to an appropriate group record, and can supplement the group record attributes with any required user-specific attributes. Therefore, a typical Users file might contain only one “DEFAULT” user record and a small number of group records that are rarely changed.

211


Configuring the RADIUS proxy

The PremierAccess RADIUS Server supports the proxy mechanism to another RADIUS Server. The authfile is used in support of the increasingly popular “RADIUS proxy forwarding” mechanism.

When present, the authfile defines the relationships between cooperating pairs of RADIUS Servers so that they can use “RADIUS proxy forwarding” to send RADIUS requests and replies to one another. SafeNet’s interpretation of the contents of authfile is a compatible subset of the well-known conventions established by Merit Networks Incorporated and has been distributed as a part of their free enhanced RADIUS Server since they introduced RADIUS proxy forwarding to the RADIUS community.

Understanding RADIUS proxy forwarding and the authfile requires prior understanding of the following concepts and definitions:

• Specially formatted usernames

If a username contains an embedded @ sign, then the PremierAccess RADIUS Server will interpret it in two separate portions in support of RADIUS proxy forwarding. Any text to the left of the @ will be interpreted as the PremierAccess-compatible user name. Any text to the right of the @ represents what Merit calls a “realm” and, after an authfile lookup, leads to the location of another RADIUS Server, which should know how to proceed further. Thus, if the RADIUS username field contained “Bob@NYC,” then the name of the realm is “NYC.” You can override the default site character by running RADIUS with the argument -r <char>. By default, it is “-r @”.

• Realms

The authfile associates realm names with specific RADIUS Servers. Inside the authfile, separate lines of printable text always begin with the name of separate realms. After the realm name, each line also contains the special keyword “RADIUS” (indicating that the RADIUS protocol will be used to authenticate users associated with this realm) and then the DNS name or IP address of a RADIUS Server where requests can be forwarded to satisfy the authentication requirements of that realm.

The destination RADIUS server is the one whose name matches the realm part of the username. It follows the site character. For example, in the auth file entry “NYC RADIUS 192.168.14.23”, for the user Bob@NYC, NYC is the realm. Packets will be forwarded to the IP address 192.168.14.23 on the port (taken from the users file) of 1812.

It is possible to proxy to other RADIUS servers running on a different port. To enable this, the clients file is consulted.

212


Table 19: Sample client file entries

• Server position

When RADIUS proxy forwarding is in use, each RADIUS Server can be a member of a chain of cooperating RADIUS severs, and within that chain, each server can perform any of three distinct roles, depending on whether its position is first in the chain, last in the chain, or somewhere in between. The first RADIUS Server in the chain is the only one that ever communi-cates directly withthe originating RADIUS client. The “middle” RADIUS Servers simply forward RADIUS requests to the next member of thechain after adding a tiny place-marker attribute to the packet. The Premier-Access RADIUS Servers remove their own place marker attributes from the resulting response packets on the return trip, before forwarding those responses back to the next link of the chain in the opposite direction. There-fore, although “later” links in the chain can see the place markers of earlier links, earlier links in the chain never see any of the attributes of the later links, and by the time the response packet arrives back at the originating RADIUS client, all routine proxying information is removed so it can look just like a “normal” packet that has never been forwarded.

The last link in the chain of RADIUS Servers determines that it is the last link by consulting the authfile and identifying its own name as the RADIUS Server associated with the realm in use. The PremierAccess RADIUS Server will then make the final determination as to the identity of the requesting user, construct the reply packet granting or denying access, and return it to the RADIUS Server that sent the request packet.

IP [:port] Keyword [NAS: PROXY]

192.168.1.100 1234 NAS

192.168.14.23 MySecret PROXY

192.168.14.23:1812 TooManySecrets PROXY

213

Chapter 9: Managing the PremierAccess RADIUS ServerAuthenticators

Authenticators The RADIUS Server supports all hardware and software authenticators that are compatible with PremierAccess. PremierAccess allows you to assign up to three authenticators per user. You can specify their use in any combination, but you may only require any combination of two authenticators per authentication. For more information on assigning authenticators to a user’s record, refer to “Creating user accounts manually” on page 129.

You can assign two authenticators to a user by assigning a memorized password and a dynamic passcode authenticator. However, you cannot assign two memorized passwords or two dynamic passcode authenticators to a user.

RADIUS-encrypted memorized passwords

A memorized password is best handled by typing it at the RADIUS password prompt. For example:

Username: Fred

Password: *******

In the above example, the user, Fred, typed his memorized password at the RADIUS password prompt. The RADIUS client obscures unauthorized viewing of the password response by displaying asterisks in place of the actual keystrokes.

214


Memorized passwords appended to usernames

As an alternative, a memorized password can be handled by typing it into the RADIUS username field, separated from the username by a comma. For example:

Username: Fred,password123

Password:

In the above example, a user, Fred, typed his memorized password, “password123” at the RADIUS username prompt, separating it from his username with a comma. The password prompt was left blank. This method does not obscure memorized passwords from view of passerbys. The entire contents typed at the username prompt, including the password in this case, are always transmitted in clear text across the network inside RADIUS packets. For these reasons, this method is not recommended for general use, but may be useful when troubleshooting a system if it is necessary to trace accurate delivery of a password.

Note: Because a comma is a special character used to separate usernames from passwords, a username cannot contain a comma, and memorized passwords cannot contain a comma if they are ever to be appended to usernames, as illustrated above.

RADIUS encrypted synchronous dynamic passcodes

A synchronous dynamic passcode may be typed into the RADIUS password prompt. For example:

Username: Fred

Password: ******

In the above example, Fred obtains the proper synchronous dynamic passcode by activating a button on his hardware or software authenticator, and enters the displayed value into the RADIUS password field after seeing the Password prompt. The RADIUS client obscures the passcode by displaying asterisks in place of Fred's actual keystrokes.

215


Synchronous dynamic passcodes appended to usernames

As an alternative, a synchronous dynamic passcodes may be typed into the RADIUS username prompt, separated from the username by a comma. For example:

Username: Fred,139ac2

Password:

In the above example, Fred typed his dynamic passcode at the RADIUS username prompt, separating it from his username with a comma. The password prompt was left blank.

Note: This method does not obscure dynamic passcodes as they are typed, and the entire contents of the Username field, including the passcode in this case, are always transmitted in clear text across the network inside RADIUS packets. However, this does not present a security risk because the dynamic passcode is nonreplayable. Also note that because a comma is a special character used to separate usernames from passwords, usernames can never have commas in them.

Shared tokens with memorized passwords

There may be times when end users may have both a memorized password and a dynamic synchronous passcode authenticator. This occurs when several people share one token, but each has their own memorized password. When authenticating to RADIUS, special handling of these passwords is necessary to correctly authenticate.

The following two examples show how to correctly enter passwords in this situation:

Example 1: Enter the dynamic after the username in the format: Username: “<name>,<dynamicPW>”Password: “<fixed>”

Username: Fred,23E4A7Password: password123

216


Example 2: Enter the dynamic and the memorized in the password field:Username: “<name>”Password: “<dynamic>,<fixed>”

Username: FredPassword: 23E4A7,password123

Note: When entering passwords in the Password field, the entries will be obscured.

Asynchronous dynamic passcode authenticators

A user who has an asynchronous challenge/response authenticator is unable to determine the proper dynamic passcode until after he or she has received a “challenge” from PremierAccess. Their RADIUS dialog always has two phases, as in the example below.

Username: Fred

Password:

Challenge: 1251

Response: 2ap9

In the first phase, a user named Fred types his username and presses the Enter button at the Password prompt. A challenge is displayed almost immediately, which he types into his authenticator. Fred receives a new passcode response from his authenticator, and types the passcode at the response prompt.

CHAP-authenticated transparent memorized passwords

Windows workstations capable of supporting PPP (Point-to-Point Protocol) as their TCP/IP transport mechanism are frequently able to use transparent “CHAP” mode authentication, by which it is possible to confirm the identity of their workstation with a high degree of certainty. This is very convenient for users in environments that might not require true user authentication.

Within this dialog, the user's workstation and the router or communication server silently exchange enough information to successfully ask PremierAccess for help authenticating the identity of the workstation, and the RADIUS protocol is automatically used to send the resulting query to the PremierAccess RADIUS Server.

Note: Passwords encrypted using the CHAP algorithm may need to be entered in uppercase if the fixed password profile designates the password as code-sensitive.

217


CHAP-encoded encapsulated dynamic passwords

Some RADIUS clients (e.g., Microsoft's Windows NT RAS) always insist on CHAP-encoding the RADIUS password field, which renders the data inside that field useless in dynamic password situations such as those generally desired by customers. (The CHAP authentication algorithm encodes the data as one-way, which cannot be decoded.)

In order to compensate, a user may type his or her dynamic password adjacent to their username in the RADIUS username field, separated by a comma. For example, if Fred’s synchronous dynamic password is 1316, the RADIUS sign on dialog will look like this:

Username: fred,1316

Password:

If Fred were using an asynchronous, challenge-response dynamic password authenticator, the dialog would look like this:

Username: fred

Password:

Challenge: 2155

Username: 2900

In the above example, the first comma after “fred” informs the PremierAccess RADIUS Server that the username field will be used to communicate the dynamic password after the challenge is displayed. In most implementations, the username “fred” is persistent and need not be entered twice, even though it's illustrated twice above. Instead, after the challenge is displayed, the operator simply grabs the mouse pointer, clicks after the comma, and types the dynamic password.

Because of how the RADIUS protocol works, if the PremierAccess RADIUS Server receives a RADIUS access-request packet containing only a RADIUS-encapsulated, CHAP-encoded memorized password, which is evaluated as correct, it always responds with an access-accept packet, as RADIUS-oriented customers would expect. Therefore, if administrators want to confirm identity with a stronger authenticator, they should register ONLY that stronger authenticator (e.g., a SafeWord Silver, Gold/Platinum authenticator) in the PremierAccess database, and not allow the option of entry with a memorized password at all. Alternatively, administrators may set the minimum authenticator strength in the ACL to be higher than the value of a fixed password.

218

Chapter 9: Managing the PremierAccess RADIUS ServerTroubleshooting common problems

Troubleshooting common problems

This section provides assistance for specific problems you may encounter with the PremierAccess RADIUS Server.

Check the radius.cfg configuration files

Verify that the radius.cfg file exists in the directory and make sure the contents are correctly formatted. The RADIUS Server’s Authentication SDK interface is configured via the radius.cfg file. Sample settings for the radius.cfg file are shown below.

02 SafeWord Authen. Server Name: 192.168.13.54 0 0 5031

16 Send Status Messages to Console:ERROR

17 Send Status Messages to Log File:ALL

18 Status Message Log Filename:radius.log

20 Max log file length in KB:64K

23 Status Message Label:radius

27 Client Type:RADIUS

55 Eassp Version:201

57 SSL Enable:ON

58 SSL Cipher:DEFAULT

The most common problem area in the radius.cfg file is Line 02. Ensure that you have the correct hostname or IP address of the authentication server. Additionally, verify the port and the EASSP version match each other.

Tip: For EASSP 101, use port 5030. For EASSP 201, use port 5031.

The clients file

The clients file is usually located in the RADIUSServer directory. The most common problem in the clients file is a wrong or missing RADIUS-encryption key. RADIUS packets will be dropped if a client is not listed.

The users file

The users file is usually located in the RADIUSServer directory. The most common problem in the users file is an incorrect or missing DEFAULT profile entry.

The dictionary file

The dictionary file is usually located in the RADIUSServer directory.

219


Launch the PremierAccess RADIUS Server in debug mode

For examples and help with the syntax this Server daemon uses, invoke the following command:

./radiusd -h or radiusd /?

The response you will see will appear similar to the example below:

Usage: ./radiusd [ -a acct_dir ] [ -s ] [ -S name ] [ -x [debuglevel]] [ -d db_dir ] [-l [logdir]] [-A AccountingPort]

• -a acct_dir specifies an alternate directory for RADIUS accounting.• -s runs RADIUS in single-threaded mode without spawning a child

process to handle each authentication request.• -S name allows two or more RADIUS Servers to run simultaneously

on the same computer, each one uniquely named and accessing a separate port through the /etc/services database.

• -A <port> specifies the port on which the Accounting Server listens for accounting packets. For example if you assign a port number 0 to <port>, the accounting server will start on the port number specified in the services file. If the -A option is not specified, the accounting process will not start, but authorization packets will still be authenticated.

• -r <char> overrides the proxy site char.• -w to run as windows service.• -x [debuglevel] displays a verbose log of diagnostic messages. The

optional debuglevel is a decimal number from 1 to 32767, bitcoded as follows:

Bit 15 displays advanced timestamp informationBit 14 displays information during CSP device authenticationBit 13 displays information during RADIUS proxyingBit12= Display audit information for accounting purposesBit11= Display debug messages in Vendor-Specific areasBit10= Display debug messages in user exits areasBit 9= Display timestamps as RADIUS request packets arriveBit 8= Display important trace info. in Authorization areasBit 7= Display incoming RADIUS packet summaryBit 6= Display outgoing RADIUS packet summaryBit 5= Display incoming Safeword Parameter BlocksBit 4= Display outgoing SafeWord Parameter BlocksBit 3= Display messages on entry to each function callBit 2= Display important trace info in SafeWord areasBit 1= Display important trace info in nonSafeWord areasBit 0= Attach RADIUS packet details to summaries

220


• -d db_dir sets the path of the RADIUS user database directory (db_dir) where a dictionary file is located.

• -1 writes a log file called audit.log in the same directory as the binary.• -1 <path> writes audit.log to the path the user gives.• No -1 will not write the log file.

Note: The log name audit.log cannot be modified by users.

• -v displays the PremierAccess RADIUS Server version number.• & when added at end of command line, runs the radiusd server

process in the background.

221

Chapter 9: Managing the PremierAccess RADIUS ServerDiagnostic traces during correct operation

Diagnostic traces during correct operation

Start the PremierAccess RADIUS Server in debug mode using the debug level of 999, as shown below.

./radiusd -x 999 -d .

Authentication with a PremierAccess password

The following example shows a diagnostic trace recording successful authentication of a user named “super” that uses only a memorized password:

The RADIUS Server started in debug modeMon Jan 21 18:58:57 PST 2002

debugLevel 999 requested.

debugFlagBits 999 confirmed.

Displayed debug information will include all of:

Timestamps

Authorization areas

Incoming RADIUS packets

Outgoing RADIUS packets

EASSP protocol handling areas

Important trace notices in SafeWord areas

Important trace notices in non-SafeWord areas

Detailed contents of RADIUS packets

Using RADIUS database directory at SWP_RADIUS

SafeWord EASSP Client V3.01.00 using TCPIP transport.

RADIUS authentication request ID 240 is received from the RADIUS client

radrecv: Packet from host c0a8184f, port=1645

Incoming RADIUS Packet:

Examining RFC 2138 Access-Request Packet:Identifier=240. Packet length=63.

Packet Authenticator=5c 60 62 c5 16 19 e0 fa 7a 5a b2 7b 2c 76 41 86

RFC 2138 Attribute=4: (NAS-IP-Address) Length=4

Value=c0 a8 18 4f

RFC 2138 Attribute=5: (NAS-Port) Length=4

Value=0 0 0 1

RFC 2138 Attribute=61: (NAS-Port-Type) Length=4

Value=0 0 0 0

RFC 2138 Attribute=1: (User-Name) Length=5

Value=super

RFC 2138 Attribute=2: (User-Password) Length=16

222


Value= (Hex dump of RADIUS-encrypted value)

cf 97 4c ff 2c 66 d8 cc 16 99 d6 83 3a 84 da 7a

NAS-IP-Address = 192.168.23.69

NAS-Port = 1

NAS-Port-Type = Async

User-Name = “super”

User-Password = “\317\227L\377,f\330\314\026\231\326\203:\204\332z”

rad_authenticate() 970717a: Username=super

userparse() 06.00: Attribute: User-Password = "SAFEWORD"

userparse() 06.00: Attribute: Service-Type = Framed

userparse() 06.00: Attribute: Framed-Protocol = PPP

userparse() 06.00: Attribute: Framed-IP-Address = 10.20.0.1

userparse() 06.00: Attribute: Framed-IP-Netmask = 255.255.255.0

rad_authenticate() 970717b: UserName=super

SafeWordAuthenticate(): Got PW_USER_NAME attribute

SafeWordAuthenticate(): namepair->strvalue=super

SafeWordAuthenticate(): UserNamePassWord=super

SafeWordAuthenticate(): Processed UsernamePassWord

SafeWordAuthenticate(): UserName[]=super

SafeWordAuthenticate 980707a: Got RADIUS-encrypted password

SafeWordAuthenticate() 02a: Decoded RadiusPassword as:border

SafeWordAuthenticate 980707d: Got RADIUS-encrypted password

SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:border

SafeWordAuthenticate() 03: UserName[]=super

SafeWordAuthenticate() 04: RadiusPasswordOne[]=

SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=border

SafeWordAuthenticate() 08.00: No stateInfoReceived

SafeWordAuthenticate() 08.12: Calling SafeWord via swecAuthen()

SafeWordAuthenticate() 980716a: authenRec.userId=super

swec registered

openConnection() 991221a: Calling swecopen():

openConnection() 991221b: returned from swecopen()

Before call to swecAuthen:

SwecAuthenRec.waitTime=10

SwecAuthenRec.userId=super

223


SwecAuthenRec.passUserFlag=0

SwecAuthenRec.resultCode=0

SwecAuthenRec.actionDataLength=0

SwecAuthenRec.peerAddr=192.168.23.69

SwecAuthenRec.statusText=

After call to swecAuthen:






SwecAuthenRec.actionData=/bin/csh


SwecAuthenRec.statusText=User passed

SWEC deRegistered

After returning from SafeWord swecAuthen():

SafeWordAuthenticate() 08.2: Passed SafeWord

SafeWordAuthorize() 01.00: No 'group=' in user record

rad_authenticate(): SafeWordResult=0

ApproveAccept() 01.00 user_reply before approval:

Service-Type = Framed

FindParms() 02.10: Successfully opened RADIUS database file.

FindParms() 02.20: Found group name.

FindParms() 02.30: Found group by virtue of DEFAULT match





FindParms() 09.00: Function Complete. Closing Users file.

FindParms() 09.01: reply_pairs after Approval:


ApproveAccept() 03.00: user_reply after approval:


Sending Ack of id 240 to c0a8184f (192.168.23.69)


Framed-Protocol = PPP

Framed-IP-Address = 10.20.0.1

Framed-IP-Netmask = 255.255.255.0

Outgoing RADIUS packet:

224


RADIUS access-accept packet ID 240 is sent to the RADIUS client

Examining RFC 2138 Access-Accept Packet:Identifier=240. Packet length=44.

Packet Authenticator=a4 4f 2f b b 3c 57 63 1a 49 8e a0 da 0 48 a5

RFC 2138 Attribute=6: (Service-Type) Length=4

Value=0 0 0 2

RFC 2138 Attribute=7: (Framed-Protocol) Length=4

Value=0 0 0 1

RFC 2138 Attribute=8: (Framed-IP-Address) Length=4

Value=a 14 0 1

RFC 2138 Attribute=9: (Framed-IP-Netmask) Length=4

Value=ff ff ff 0

Authentication with a simple synchronous authenticator

The following example shows diagnostic trace recording successful authentication of a user named “supertest” that uses only a synchronous dynamic password authenticator:

RADIUS authentication request ID 241 is received from the RADIUS clientradrecv: Packet from host c0a8184f, port=1645


Examining RFC 2138 Access-Request Packet:Identifier=241.

Packet length=67.

Packet Authenticator=c9 98 8f ee d7 c0 34 d 9e 90 e7 88 a1 84

84 bf


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=supertest



c5 59 94 b7 61 92 13 ef f2 a4 89 65 d b6 5 43


NAS-Port = 1

225



User-Name = “supertest”

User-Password =

“\305Y\224\267a\222\023\357\362\244\211e\015\266\005C”

rad_authenticate() 970717a: Username=supertest




userparse() 06.00: Attribute: Framed-IP-Address =

10.20.0.1

userparse() 06.00: Attribute: Framed-IP-Netmask =

255.255.255.0

rad_authenticate() 970717b: UserName=supertest


SafeWordAuthenticate(): namepair->strvalue=supertest

SafeWordAuthenticate(): UserNamePassWord=supertest


SafeWordAuthenticate(): UserName[]=supertest


SafeWordAuthenticate() 02a: Decoded RadiusPassword as:5ph20p


SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo

as:5ph20p

SafeWordAuthenticate() 03: UserName[]=supertest


SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=5ph20p


SafeWordAuthenticate() 08.12: Calling SafeWord via

swecAuthen()

SafeWordAuthenticate() 980716a: authenRec.userId=supertest

swec registered





SwecAuthenRec.userId=supertest





226





SwecAuthenRec.userId=supertest







SWEC deRegistered













10.20.0.1


255.255.255.0











227





Packet Authenticator=f6 e8 dd 8c 79 6f 5f 0 62 c 6a 8e c2 c0 5d 14


Value=0 0 0 2


Value=0 0 0 1


Value=a 14 0 1


Value=ff ff ff 0

Authentication with an asynchronous authenticator

The following example shows diagnostic trace recording successful authentication of a user named “user_asyn” that uses a simple asynchronous password authenticator:





Packet Authenticator=99 69 c6 9c 32 b9 cb 35 42 ed f8 3a fe 99 2f 34


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=user_asyn



f3 de f6 63 78 65 ad 56 64 c7 bb 2d f7 53 fe c1


228


NAS-Port = 1


User-Name = “user_asyn”

User-Password = “\363\336\366cxe\255Vd\307\273-\367S\376\301”

rad_authenticate() 970717a: Username=user_asyn






rad_authenticate() 970717b: UserName=user_asyn


SafeWordAuthenticate(): namepair->strvalue=user_asyn

SafeWordAuthenticate(): UserNamePassWord=user_asyn


SafeWordAuthenticate(): UserName[]=user_asyn


SafeWordAuthenticate() 02a: Decoded RadiusPassword as:

SafeWordAuthenticate() 03: UserName[]=user_asyn


SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=



SafeWordAuthenticate() 980716a: authenRec.userId=user_asyn

swec registered





SwecAuthenRec.userId=user_asyn








229







SwecAuthenRec.statusText=User aborted

SWEC deRegistered


SafeWordAuthenticate() 09: SafeWord sent Challenge

Sending Challenge of id 242 to c0a8184f (192.168.23.69)

Access-challenge request packet ID 242 is sent to the RADIUS client


Examining RFC 2138 Access-Challenge Packet:Identifier=242. Packet length=58.

Packet Authenticator=9d 3d be b1 df 44 39 3a 90 d4 62 ce 2b 22 52 95

RFC 2138 Attribute=18: (Reply-Message) Length=28

Value=Challenge: 1 1275 Response?

RFC 2138 Attribute=24: (State) Length=6

Value=31 20 31 32 37 35


rad_authenticate(): SafeWord sent access_challenge. Returning

230


The RADIUS client send a response to the challenge packet ID 243




Packet Authenticator=79 f0 16 92 51 4 e7 31 fe f5 e2 64 5f c2 d 28


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=user_asyn



4d 4c fe a6 47 ab e6 8e d3 ea ae 41 2b 6 6 b2

RFC 2138 Attribute=24: (State) Length=6

Value=31 20 31 32 37 35


NAS-Port = 1


User-Name = “user_asyn”

User-Password = “ML\376\246G\253\346\216\323\352\256A+\006\006\262”

State = “1 1275"

rad_authenticate() 970717a: Username=user_asyn






rad_authenticate() 970717b: UserName=user_asyn


SafeWordAuthenticate(): namepair->strvalue=user_asyn

SafeWordAuthenticate(): UserNamePassWord=user_asyn


SafeWordAuthenticate(): UserName[]=user_asyn

231



SafeWordAuthenticate() 02a: Decoded RadiusPassword as:19pc


SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:19pc

SafeWordAuthenticate() 03: UserName[]=user_asyn


SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=19pc

SafeWordAuthenticate() 04.1: Found State attrib

SafeWordAuthenticate() 07: stateInfoReceived


swec registered



SafeWordAuthenticate() 991215a: Before call to swecAuthen:

















SWEC deRegistered

SafeWordAuthenticate() 07.70: returned from swecAuthen()






232


















RADIUS access-accept packet ID 243 is sent to the RADIUS clientOutgoing RADIUS packet:

Examining RFC 2138 Access-Accept Packet:Identifier=243.

Packet length=44.

Packet Authenticator=7a be d6 6b 2a 84 84 5 e1 c2 d5 8b 86 7

51 9b


Value=0 0 0 2


Value=0 0 0 1


Value=a 14 0 1


Value=ff ff ff 0

233


Authentication with a CHAP authenticator for “user_chap”

The following example shows a diagnostic trace recording successful authentication of a user named “user_chap” that uses only a simple CHAP password authenticator:

RADIUS authentication request ID 244 is received from the RADIUS clientradrecv: Packet from host c0a8184f, port=1645


Examining RFC 2138 Access-Request Packet:Identifier=244.

Packet length=79.

Packet Authenticator=6a 13 89 5b 87 40 1 e4 74 d9 2 73 8c 9c

8f 51


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=user_chap



7 38 cf 89 37 fe 9b c0 a3 79 64 de 37 7e 94 ed


Value=0 0 0 2


Value=0 0 0 1


NAS-Port = 1


User-Name = “user_chap”

User-Password =

“\0078\317\2117\376\233\300\243yd\3367~\224\355”

radrecv() 971118a: Received User-Service-Type attribute

value=0



rad_authenticate() 970717a: Username=user_chap

234






10.20.0.1


255.255.255.0

rad_authenticate() 970717b: UserName=user_chap


SafeWordAuthenticate(): namepair->strvalue=user_chap

SafeWordAuthenticate(): UserNamePassWord=user_chap


SafeWordAuthenticate(): UserName[]=user_chap


SafeWordAuthenticate() 02a: Decoded RadiusPassword

as:chap_password


SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo

as:chap_password

SafeWordAuthenticate() 03: UserName[]=user_chap


SafeWordAuthenticate() 04.01:

RadiusPasswordTwo[]=chap_password


SafeWordAuthenticate() 08.12: Calling SafeWord via

swecAuthen()

SafeWordAuthenticate() 980716a: authenRec.userId=user_chap

swec registered





SwecAuthenRec.userId=user_chap








SwecAuthenRec.userId=user_chap

235








SWEC deRegistered













10.20.0.1


255.255.255.0











236





Packet Authenticator=df fd 6c 4d 6f fc 85 d4 e9 34 ba a0 3c 9f 4b 6d


Value=0 0 0 2


Value=0 0 0 1


Value=a 14 0 1


Value=ff ff ff 0

237

Chapter 9: Managing the PremierAccess RADIUS ServerDiagnostic traces with incorrect configuration

Diagnostic traces with incorrect configuration

Start the PremierAccess RADIUS Server in debug mode using the debug level of 999, as shown below.

./radiusd -x 999 -d .

radius.cfg missing

The following example shows sample output with a missing radius.cfg file.

Mon Jan 24 19:18:00 PST 2000




Timestamps

Authorization areas







Using RADIUS database directory at SWRADSRV






Packet Authenticator=b1 8a b4 49 33 5e 5c 57 e0 1c 3f fc ac f 64 39


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=super



238


47 f6 72 8e 9e d 34 d3 1 34 f2 b9 f4 ea 52 c1


NAS-Port = 1



User-Password = “G\366r\216\236\0154\323\0014\362\271\364\352R\301”














SafeWordAuthenticate() 02a: Decoded RadiusPassword as:border


SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:border



SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=border




Error reading file:

RegisterSwec FAILED.

[Error reading file message means that the SafeWord RADIUS server is unable to process the configuration file radius.cfg]

239


RADIUS secret incorrect

The following example shows sample output with an incorrect RADIUS secret.

RADIUS authentication request ID 246 is received from the RADIUS client for a user named super and a fixed password border




Packet Authenticator=e6 1e 91 3d 43 5c 34 a1 44 e3 86 b3 f e 2e 84


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=super



ce 9e 42 50 1a d3 1e db f5 b4 9c e4 e 58 ec b4

240



NAS-Port = 1



User-Password = “\316\236BP\032\323\036\333\365\264\234\344\016X\354\264”














SafeWordAuthenticate() 02a: Decoded RadiusPassword as:__˜‡_ý§"¿¢-_{Y‰


SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:__˜‡_ý§"¿¢-_{Y‰



SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=__˜‡_ý§"¿¢-_{Y‰




swec registered






241













SwecAuthenRec.actionData=0


SwecAuthenRec.statusText=Failed authentication

SWEC deRegistered


SafeWord 08.3: Failed SafeWord


Failed SafeWord authentication

rad_authenticate(): Requirements not met. Sending reject.

RADIUS access-reject packet ID 246 is sent to the RADIUS client

the RADIUS server did interpret the fixed password as : :__˜‡_ý§”¿¢-_{Y‰ because of the wrong key

Outgoing RADIUS Packet:

Examining RFC 2138 Access-Reject Packet:Identifier=246. Packet length=20.

Packet Authenticator=62 55 c4 84 2 ca 41 be f3 88 93 c7 4 b9 de 92

Sending Reject of id 246 to c0a8184f

242


Dictionary file problems

The following example shows sample output with dictionary file problems.

Mon Jan 24 20:08:08 PST 2000




Timestamps

Authorization areas













Packet Authenticator=cb e7 fa 12 aa 1b 16 e9 57 f5 c6 f3 a3 9 24 25


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=super



7a 2a 6c 26 f8 f5 4d a1 b0 87 89 fd ed 89 b8 93


NAS-Port = 1


243


radrecv() 970808a: Received unknown attribute 1

radrecv() 970808a: Received unknown attribute 2

rad_authenticate 980203a: No user name

The RADIUS Server is unable to interpret the attribute #1 and attribute #2 because of dictionary problems. Either the two attributes are missing or they are not properly formatted.

244


Users file problems

All usernames must be defined within the Users file, either by a direct username record or through the "DEFAULT" record. If the DEFAULT record is missing and an access-request packet is received wherein the User-Id attribute does not match any user record definitions in the Users file, a diagnostic trace at level 999 will reveal the following:

Mon Jan 24 20:21:43 PST 2000




Timestamps

Authorization areas













Packet Authenticator=cd bd 1a 76 f0 b0 79 62 2b a4 d7 43 7c 47 eb 61


Value=c0 a8 18 4f


Value=0 0 0 1


Value=0 0 0 0


Value=super



b1 6 9e b4 e0 5d d7 b0 e2 64 a 2f 44 75 26 bd

245



NAS-Port = 1



User-Password = “\261\006\236\264\340]\327\260\342d\012/Du&\275”


RADIUS database cannot process this user. No matching entry, or entry is incomplete or inconsistent, or required attribute(s) are not present, or unknown attribute is listed in this entry.

An access-reject packet ID 254 is sent to the RADIUS client because of Users file problems

Outgoing RADIUS Packet:

Examining RFC 2138 Access-Reject Packet:Identifier=254. Packet length=20.

Packet Authenticator=c5 7a 86 7a c7 8d 29 12 f5 eb d8 34 72 65 80 3

Sending Reject of id 254 to c0a8184f

246

Chapter 9: Managing the PremierAccess RADIUS ServerReferences

References • RFC 2138• Sample files (see below)

Sample Dictionary file

The example below shows a sample Dictionary file that is known to be compatible with version RFC 2138.970909 of the PremierAccess RADIUS Server. Lines that begin with a pound sign (#) are comments that are not interpreted by the PremierAccess RADIUS Server as it scans for dictionary information. Those lines contain information intended to help administrators understand the meaning, context, and format of the Dictionary file.

ATTRIBUTE User-Name 1 string

ATTRIBUTE Password 2 string

ATTRIBUTE CHAP-Password 3 string

ATTRIBUTE Client-Id 4 ipaddr

ATTRIBUTE Client-Port-Id 5 integer

ATTRIBUTE User-Service-Type 6 integer

ATTRIBUTE Framed-Protocol 7 integer

ATTRIBUTE Framed-Address 8 ipaddr

ATTRIBUTE Framed-Netmask 9 ipaddr

ATTRIBUTE Framed-Routing 10 integer

ATTRIBUTE Filter-Id 11 string

ATTRIBUTE Framed-MTU 12 integer

ATTRIBUTE Framed-Compression 13 integer

ATTRIBUTE Login-Host 14 ipaddr

ATTRIBUTE Login-Service 15 integer

ATTRIBUTE Login-TCP-Port 16 integer

ATTRIBUTE Old-Password 17 string

ATTRIBUTE Port-Message 18 string

ATTRIBUTE Dialback-No 19 string

ATTRIBUTE Dialback-Name 20 string

ATTRIBUTE Expiration 21 date

ATTRIBUTE Framed-Route 22 string

ATTRIBUTE Framed-IPX-Network 23 ipaddr

ATTRIBUTE Challenge-State 24 string

ATTRIBUTE Vendor-Specific 26 string

ATTRIBUTE Called-Station-Id 30 string

ATTRIBUTE Calling-Station-ID 31 string

ATTRIBUTE Acct-Status-Type 40 integer

ATTRIBUTE Acct-Delay-Time 41 integer

ATTRIBUTE Acct-Session-Id 44 string

ATTRIBUTE Acct-Authentic 45 integer

ATTRIBUTE Acct-Session-Time 46 integer

ATTRIBUTE NAS-Port-Type 61 integer

247


VENDORATTR 9 cisco-avpair 1 string

#

# Integer Translations

#

# User Types

VALUE User-Service-Type Login-User 1

VALUE User-Service-Type Framed-User 2

VALUE User-Service-Type Dialback Login-User 3

VALUE User-Service-Type Dialback-Framed-User 4

VALUE User-Service-Type Outbound-User 5

VALUE User-Service-Type Shell-User 6

VALUE User-Service-Type NAS-Prompt 7

VALUE User-Service-Type Authenticate-Only 8

VALUE User-Service-Type Callback-NAS-Prompt 9

# Framed Protocols

VALUE Framed-Protocol PPP 1

VALUE Framed-Protocol SLIP 2

# Framed Routing Values

VALUE Framed-Routing None 0

VALUE Framed-Routing Broadcast 1

VALUE Framed-Routing Listen 2

VALUE Framed-Routing Broadcast-Listen 3

# Framed Compression Types

VALUE Framed-Compression None 0

VALUE Framed-Compression Van-Jacobsen-TCP-

248


IP 1

# Login Services

VALUE Login-Service Telnet 0

VALUE Login-Service Rlogin 1

VALUE Login-Service TCP-Clear 2

VALUE Login-Service PortMaster 3

# Status Types

VALUE Acct-Status-Type Start 1

VALUE Acct-Status-Type Stop 2

# Authentication Types

VALUE Acct-Authentic None 0

VALUE Acct-Authentic RADIUS 1

VALUE Acct-Authentic Local 2

# NAS-Port-Types

VALUE NAS-Port-Type Async 0

VALUE NAS-Port-Type Sync 1

VALUE NAS-Port-Type ISDN_Sync 2

VALUE NAS-Port-Type ISDN_Async_V.120 3

VALUE NAS-Port-Type ISDN_Async_V.110 4

VALUE NAS-Port-Type Virtual 5

VALUE NAS-Port-Type PIAFS 6

VALUE NAS-Port-Type HDLC_Clear_Channel 7

249


VALUE NAS-Port-Type X.25 8

VALUE NAS-Port-Type X.75 9

Sample Users file

The example below shows a sample Users file known to be compatible with the current version of the PremierAccess RADIUS Server. All lines beginning with a pound sign (#) are comment lines. The PremierAccess RADIUS Server ignores them. They are intended to provide guidance for PremierAccess RADIUS Server administrators.

#

# Group of PPP users

#

ppp

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

Framed-Netmask = 255.255.255.255,

Framed-Routing = None,

Framed-Compression = Van-Jacobsen-TCP-IP,

Framed-Filter-Id = "std.ppp.in"

Framed-MTU = 1500

#

# Group of SLIP users

#

slip


Framed-Protocol = SLIP,

Framed-Netmask = 255.255.255.255,


Framed-Compression = None,

Framed-MTU = 1006

#

# Group of cslip users

#

cslip


Framed-Protocol = SLIP

Framed-Netmask = 255.255.255.255,



Framed-MTU = 1006

250


#

# Example Group of Developers using Dialup connections, whose privileges are limited

# by filters on the RADIUS client named "Developers" and "Dialin"

#

Develop


Framed-Protocol = PPP,

Framed-Netmask = 255.255.255.128,



Framed-MTU = 1500,

Filter-Id = Developers,

Filter-Id = Dialin

#

# By default, use SafeWord for authentication and SafeWord will assign users to one of the Group Records defined above. (SafeWord should also generally be set up to assign any static IP addresses.)

#

DEFAULT Password = "SAFEWORD"

Sample authfile

The example below shows a sample authfile configured to demand RADIUS authentication for the DEFAULT domain through a server which is known as “last.samplecompany.com.”.

#

This file contains a list of separate “realms” that use the RADIUS protocol to authenticate users requesting access, together with the DNS name or IP address of a RADIUS server to which RADIUS requests should be forwarded for that domain. This allows several RADIUS servers to share the burden of authenticating a large population of users, with each RADIUS server handling a separate, named group or “domain” of authorized users.

#

The first field of each line is a realm name. All realm names must be unique within a separate IP network, and all must be referenced with the exact same name in all authfiles of all cooperating RADIUS servers.

251


#

The second field identifies the type of authentication required by the associated realm. For this version of the SafeWord RADIUS server, the only authentication allowed is “RADIUS”.

#

The third field contains the DNS name or IP address of the RADIUS server that is equipped to provide further authentication services for this domain. In a chain of forwarding RADIUS servers, it points at the next RADIUS server in the chain. For the #last server in the chain, this field will contain the DNS name or IP address of the host #containing this file. (The last server in the chain will use this field to point to itself.) #Each of the DNS names or IP addresses referenced in this file must match an entry in the “clients” file so that a corresponding cryptographic key can be located.A DEFAULT entry may be included in this file which indicates how to handle authentication requests specifying realm names not explicitly included in this file. It will specify an available RADIUS server to which this request should be relayed.

#

252


Here are some sample entries for realms called “first”, “middle”, and “last” respectively, to illustrate how to configure a chain of RADIUS servers. In these examples, the three RADIUS servers belong to a company called “samplecompany.com”.

first RADIUS middle.samplecompany.com

middle RADIUS last.samplecompany.com

last RADIUS last.samplecompany.com

Finally, this “DEFAULT” entry says to pass requests with authentication realm names which didn't appear in this file along to another RADIUS server called “last.samplecompany.com”:

DEFAULT RADIUS last.samplecompany.com

253


254

10CHAPTER Managing the RADIUS

Accounting Server

In this chapter...

Understanding the RADIUS Accounting Server ...........................256

How the server works...................................................................256

Configuring the server ..................................................................256

Starting the server ........................................................................257

255

Chapter 10: Managing the RADIUS Accounting ServerUnderstanding the RADIUS Accounting Server

Understanding the RADIUS Accounting Server

This chapter explains how to manage the PremierAccess RADIUS Accounting Server.

The RFC 2139 describes a protocol for carrying accounting information between a Network Access Server (NAS) and a shared accounting server. The NAS operates as a client of the RADIUS Accounting Server. The client is responsible for passing user accounting information to a designated RADIUS Accounting Server. The RADIUS Accounting Server then receives the accounting request and returns a response to the client indicating that it has successfully received the request.

The received information from the client(s) by the RADIUS Accounting Server includes:

• The time the session started for the user

• The time the session ended for the user

• System events

The received information is usually used for billing purposes.

How the server works

The PremierAccess RADIUS Accounting Server listens for RADIUS accounting packets formatted according to the guidelines found in Internet RFC 2139. Whenever this server receives a properly formatted RADIUS accounting-request packet, it writes the contents of that packet to a disk file and then responds with a RADIUS accounting-response packet.

• The RADIUS accounting information is stored in a plain text file on the same machine where the radacctd daemon is located.

• The PremierAccess RADIUS Accounting Server software is a standalone daemon and service it does not interface with PremierAccess, so it does not use the Authentication SDK.

Configuring the server

The PremierAccess RADIUS Accounting Server contains two configuration files: clients and dictionary (it does not need a users file). You must edit the clients file and provide the IP addresses and “RADIUS secrets” used by your RADIUS clients.

The PremierAccess RADIUS Accounting Server daemon listens to RADIUS accounting requests on port 1646 UDP, the /etc/services file must contain a line, such as:

radacct 1646/udp

The RADIUS accounting must be enabled in the client(s) (comm server(s)).

256

Chapter 10: Managing the RADIUS Accounting ServerStarting the server

Starting the server

To start or stop the PremierAccess RADIUS Accounting Server daemon, launch the PremierAccess Installation and Management Utility, and choose “Start or Stop PremierAccess Servers” from the main menu.

When the Start or Stop Servers panel appears, select the Accounting RADIUS Server and click on Start. For details on the Installation and Management Utility, refer to the PremierAccess Installation Guide.

You can also start the RADIUS Accounting Server in debug mode from the command line, where you can specify different levels of diagnostics.

The following is an example of a typical command to start the RADIUS Accounting Server:

./radacctd -a . -d . -x 1 &

where

• -a specifies the directory to store accounting file detail• -d specifies the location of clients and dictionary files• -x specifies the level of debug (up to 8191)

Example: Enabling accounting on Cisco router

radius-server host 192.168.24.42 auth-port 1645 acct-port 1646

• aaa accounting system start-stop radius• aaa accounting network start-stop radius• aaa accounting connection start-stop radius• aaa accounting exec stop-only radius• aaa accounting command 1 stop-only radius• aaa accounting command 15 wait-start radius

Sample accounting data

This sample shows an administrator telnetting to the router.

Fri Jan 1 03:38:35 1999

• NAS-IP-Address = 192.168.24.115• NAS-Port = 11• NAS-Port-Type = Virtual• User-Name = “super”• Calling-Station-Id = “192.168.24.76”• Acct-Status-Type = Stop• Acct-Authentic = RADIUS

257

Chapter 10: Managing the RADIUS Accounting ServerStarting the server

• Service-Type = NAS-Prompt• Acct-Session-Id = “00000026”• Acct-Session-Time = 3• Acct-Delay-Time = 0

Fri Jan 1 03:38:40 1999

• NAS-IP-Address = 192.168.24.115• NAS-Port = 11• NAS-Port-Type = Virtual• User-Name = “super”• Calling-Station-Id = “192.168.24.76”• Acct-Status-Type = Stop• Acct-Authentic = RADIUS• Service-Type = NAS-Prompt• Acct-Session-Id = “00000026”• Acct-Session-Time = 3• Acct-Delay-Time = 5

258

11CHAPTER Managing the RADIUS

Server for Ascend

In this chapter...

PremierAccess interface to the Ascend RADIUS Server .............260

Prerequisites ................................................................................260

Troubleshooting............................................................................260

References and additional resources...........................................261

259

Chapter 11: Managing the RADIUS Server for AscendPremierAccess interface to the Ascend RADIUS Server

PremierAccess interface to the Ascend RADIUS Server

This chapter explains how to manage the PremierAccess RADIUS Server for Ascend. This chapter applies to you if you are using communication servers that use Ascend RADIUS or any client using Ascend RADIUS that will use PremierAccess authentication.

Ascend Communications has long published their Ascend Free RADIUS Server with an interface to PremierAccess. The PremierAccess interface to the Ascend RADIUS Server offers several enhancements and adds all new features, including the following:

• Support for the “groups=” feature (as in the PremierAccess RADIUS Server)

• Support for the “CHAP=” feature (as in the PremierAccess RADIUS Server)

• Support of the same kind of comprehensive run-time diagnostic reporting as the PremierAccess RADIUS Server

Prerequisites This version of the Ascend RADIUS Server should only be used with Ascend router and communication server equipment, as follows:

• Host computer running a UNIX-compatible operating system supported as the PremierAccess software suite

• Ascend-compatible routers and communication servers configured to request RADIUS services

• Authorized users equipped with PremierAccess-compatible authenticators and registered inside the PremierAccess database

Troubleshooting An example of how to configure the MAX 1800 for Ascend RADIUS is provided below. If you have another type of Ascend router, you will need to consult the specific vendor documentation.

To configure the Max 1800 for Ascend RADIUS, telnet to the Max 1800, then set up the following:

• Ethernet -> Answer -> Profile Req=Yes

• Ethernet -> Answer -> PPP Options -> Bridge=Yes

• Ethernet -> Answer -> PPP Options -> Recv Auth=Either

• Ethernet -> Mod Config -> Auth -> Auth=RADIUS

• Ethernet -> Mod Config -> Auth -> Auth Host=xxx.xxx.xxx.xxx

• Ethernet -> Mod Config -> Auth -> Auth Port=1645

• Ethernet -> Mod Config -> Auth -> Auth Timeout=10

• Ethernet -> Mod Config -> Auth -> Auth Key=secret_key

260

Chapter 11: Managing the RADIUS Server for AscendReferences and additional resources

If you encounter problems, check the following configuration files:

• Check the Clients file. The most common problem in the Clients file is a wrong or missing RADIUS-encryption key.

• Check the Users file. The most common problem in the Users file is an incorrect or missing DEFAULT profile entry.

• Check the Dictionary file.

• Check the RADIUS Ascend NETAPI configuration file asc_radius.cfg.

• Launch the Ascend daemon in debug mode:

./asc_radiusd -x 999 -d .

References and additional resources

For more information on managing the Ascend RADIUS Server, refer to RFC 2138.

261

Chapter 11: Managing the RADIUS Server for AscendReferences and additional resources

262

12CHAPTER Setting Up Web-based

Enrollment

In this chapter...

Understanding Web-based, user enrollment ................................264

Customizing enrollment configurations ........................................264

Customizing enrollment forms......................................................267

Enrollment reservation overview ..................................................269

Advanced Mode option features...................................................283

Other enrollment tasks .................................................................289

User ChangePin feature...............................................................298

263

Chapter 12: Setting Up Web-based EnrollmentUnderstanding Web-based, user enrollment

Understanding Web-based, user enrollment

Imagine you are the network system administrator of a large organization with a sales force of 1500 people scattered around the country. They need to be enrolled into your network, and need access to customer databases and sales information. You could manually create 1500 individual user records, or you can automatically generate and provide a pass phrase to the sales personnel which, when entered at the login prompt of a Web page on their browser, automatically assigns them to the proper group, and gives them the access privileges they require.

The Enrollment Server allows you to create enrollment reservations that simplify the task described above. By using enrollment reservations, users can visit a Web page, supply their username and pass phrase provided by you, and enroll themselves and their authenticators securely into your network. Enrollment must occur before any user can authenticate using the PremierAccess system. Enrollment associates a specific kind of authenticator (fixed password, hardware, or digital certificate), group affiliation, and access permissions to the username as stored in the PremierAccess database. Once a user successfully completes the enrollment process, they have immediate access to your resources. Immediately after enrollment, they are given the option to test their new authenticator.

Customizing enrollment configurations

Before creating your reservations, you may want to customize certain enrollment process attributes of the Enrollment Server. You can change the number of words included in system-generated pass phrases, your Enrollment Server information, and the default certificate values for user certificates generated by PremierAccess.


To modify enrollment attributes, from the main console, click Configuration -> Enrollment. The Edit Configuration window appears with the General tab displayed.

Figure 135: EditConfiguration window

(General tab)

264

Chapter 12: Setting Up Web-based EnrollmentCustomizing enrollment configurations

Under Enrollment Server Address is the Fully qualified hostname field, which is set to localhost, and the HTTPS Port field, which is set to 443.

The values listed in the Fully qualified hostname and the HTTPS Port fields were set during installation (localhost and 443).

Important: The Enrollment Server address and port number are used in forming the Enrollment URL shown in reservation dialogs. You must use the fully qualified hostname for this configuration in order for your users to access the Enrollment Server using the specific URL.

1 Enter the Fully qualified hostname of the machine on which the Enrollment Server is installed.

2 Enter the HTTPS Port number you specified for HTTPS traffic when you installed this software.

Important: When generating an enrollment reservation, the server address value is a crucial part of the enrollment Web page URL where your end users will go when they are self-enrolling.

3 Under Passphrase, select the number of words for system-generated pass phrases from the Number of Words in Generated Passphrase list.

4 If you are not deploying PremierAccess-generated user certificates as authenticators, you will not need to configure any settings on the Certificate tab. If you are ready to create enrollment reservations, continue to “Enrollment reservation overview” on page 269.

5 If you are deploying PremierAccess-generated user certificates, click the Certificate tab and continue with the next procedure.

Figure 136: Editenrollment configuration-

Certificate tab

265

Chapter 12: Setting Up Web-based EnrollmentCustomizing enrollment configurations

Certificate tab settings

This tab contains the default values that will appear in PremierAccess-generated certificates. Specifically, when a user visits the Web page to enroll for a PremierAccess-generated certificate, these values will appear as the default values in the Web form. The user will have the opportunity to override these values. To change these values:

1 Enter a mail domain in the Mail Domain field.

2 Enter the department name in the Department field.

3 Enter your organization in the Organization field.

4 Enter a locality in the Locality field.

5 Enter your State’s name in the State field.

6 Enter your Country’s name in the Country field.

7 Click OK.

Important: If you made changes in the Certificate tab, a message appears stating that you need to restart the Enrollment Server in order for the changes to take effect.

266

Chapter 12: Setting Up Web-based EnrollmentCustomizing enrollment forms

Customizing enrollment forms

Customization falls into three levels: simple, intermediate, and advanced. The amount of customization increases as the level increases. If you only want to change the server side file banner.shtml to reflect your corporation’s information, or change the content of a generated form, use the simple customization procedures. If you want to customize all the forms you generate, use the intermediate customization procedures. If you want to introduce your own forms into the system, use the advanced customization procedures.

Simple customization

The simple types of customization are limited in scope and effect. Examples of simple customization are changing the server side file banner.shtml to reflect your corporation's information, or changing the content of a generated form.

There are three instances of the banner.shtml file, one in each of the following directory locations (on the machine where the Enrollment Server is installed):

• PremierAccess/SERVERS/Web/WebPlatform/webapps/servlets/www/Enrollment

• PremierAccess/SERVERS/Web/WebPlatform/webapps/servlets/www/Enrollment/help

• PremierAccess/SERVERSWeb/WebPlatform/webapps/servlets/www/Enrollment/test

The help files in the help directory all include the banner stored in the help directory. The test pages in the test directory all include the banners stored in the test directory.

A file named AdminHelp.shtml will be displayed to users in the event of certain errors. This file contains access information for PremierAccess administrators. You should tailor the information in this file to whatever is appropriate for your environment.

The AdminHelp.shtml file can be found in PremierAccess/SERVERS/Web/WebPlatform/webapps/servlets/www/Enrollment/help

There are two other opportunities for simple customization. When an enrollment succeeds, the user will be redirected to a file call EnrollmentSuccess.shtml. When an enrollment fails, the user will eventually be redirected to a file called EnrollmentFailure.shtml. Each of these files can be found in PremierAccess/SERVERS/Web/WebPlatform/webapps/servlets/www/Enrollment. By default, when an enrollment succeeds, the user will be presented with a button called "CONTINUE" which, when selected, will take the user to the main page of the PremierAccess Web server. You can change this form so that the user will be redirected to the URL of your choosing. Similarly, you can change EnrollmentFailure.shtml to display any information or

267

Chapter 12: Setting Up Web-based EnrollmentCustomizing enrollment forms

coaching to your user, specific to his or her enrollment attempt.

Intermediate customization

Intermediate customization involves modifying the “base” enrollment forms. By modifying the base enrollment forms, all future forms that are generated would be generated with the new modifications. All hidden values and the Enrollment Server Tags should be left in place. These tags begin with <!-PremierAccess_ or <!-- /PremierAccess_ .

The base forms can be found in PremierAccess/SERVERS/Web/tomcat/webapps/servlets/forms.

Advanced customization

The most advanced form of customization is to introduce your own forms into the enrollment process. This requires modification of the enrollment.conf file, found in PremierAccess/SERVERS/Web/tomcat/webapps/servlets.

Each reservation is identified by a tag, (e.g. P_U__1_U_3E4FA2B7). The tag associates all of the files, and the sequence in which those files are to be displayed. The Enrollment Server maintains state based on the form's ID value.

To introduce new forms, add the forms to the list in the order in which you want them to appear. Note that forms with modifiers (e.g. success) are optional and do not necessarily get called. The following are modifiers that identify forms as optional:

• success

• successful test

• recoverable

• critical

The Enrollment Server processes files in a top-down order until all mandatory files are processed. Optional files may not ever be displayed in the enrollment process. The mandatory forms are an initial form, the login form, and the test form(s).

268

Chapter 12: Setting Up Web-based EnrollmentEnrollment reservation overview

Enrollment reservation overview

When you create enrollment reservations, you decide how you will allow your users to enter your network, what kind of authenticator they will use, to which group they will belong, and to what resources they will have access.

An enrollment reservation allows you to make your choices ahead of time, and have those selections cover a large number of users. Once the reservation is made, you supply a Web page address to your users. In one supported scenario, users access that Web page and supply a username (pre-assigned or of their choice), and a pass phrase. A pass phrase, which is described later, is a text string that you give your users before they enroll. It ensures that the right person is accessing your resources.

Sample enrollment scenario

As an example, your company has a accounting office in Chicago, with a staff of 60 users. Earlier, you organized your user groups according to your company’s structure. You created a group called USERS, under which is a sub-group called DIVISIONS, and nested under DIVISIONS are further sub-groups. You assigned one of the Chicago staff as the group administrator for CHICAGO. You created a role called CHICAGO_STAFF, that points to your company’s ACL. This ACL contains entries that allow access to the server on which accounting information is stored during the hours of 0730 to 1800 for role CHICAGO_STAFF.

So, you now create an enrollment reservation in which you have the system generate 60 random pass phrases, or one for each of the accounting staff in Chicago. Under this reservation, they are also allowed to select a fixed password of their choosing, provided it meets the 8-character minimum you specified in the 8_CHAR_FIX_PW profile you created. You have your Chicago group administrator give each staffer the URL for the enrollment Web page, and one of the 60 pass phrases. Each accounting staffer logs onto the Web site, enters a username, the enrollment pass phrase given to them, and a password of their choice. Each one has now enrolled themselves into your system, and has immediate access to the accounting server.

Creating enrollment reservations

Enrollment reservations are a pre-defined set of values that link a user to an authenticator and a range of access privileges. The parameters that comprise an enrollment reservation are in turn, linked to a specific enrollment pass phrase. When the user successfully enrolls, they are automatically assigned the access privileges associated with that reservation.

Important: In order to use self-enrollment, your end users must have their browsers configured to enable JavaScript.

269


Figure 137 on page -270 shows a high-level overview of the process for creating a reservation with the enrollment reservation wizard.

Figure 137: Enrollmentreservation process using

reservation wizard

Using the reservation wizard

This section guides you through the creation of a practice reservation using the reservation wizard. These procedures are meant to help you understand the process of creating basic reservations, and to give you an idea of how to create working reservations that best suit your organization’s needs. When you are ready to start creating working reservations, you will be using the procedures outlined in this section. You will also be able to create reservations using advanced mode options. For more information about advanced mode options, refer to “Advanced Mode option features” on page 283.

SelectEnroll. Resv.

Supply resvname

User enrollw/fixed

password

No

UserYesenroll w / hdwr

authent?

Userenroll w /digital

certif?

Usersselect own

names?

Adminselect existing

users?

Adminadd/importnew user(s)

Specify role(s)?Specifyrole(s)

No

No

No

Yes Yes

No

Yes

Yes Generatepass phrases

Summaryscreen ofchoices

Select admingroup

Any/allcan be

combined

270


1 To create a new enrollment reservation, at the Admin Console, select one of the non_global groups shown in the left panel.

Note: You cannot create a user enrollment reservation that belongs to a global group. As discussed previously, global groups contain objects such as your ACL, roles, authenticators, and authenticator profiles. which are visible to all administrator levels.

Important: The group you select is the one into which the users who enroll under the reservation will be placed.

2 Select Insert -> User Reservation with wizard. The Create a New User Reservation window appears.

Figure 138: New UserReservation window

3 Enter a unique reservation name (or ID) into the Name field. If you are creating a working reservation, consider using a naming convention that quickly indicates the users who will be affected by this reservation (e.g. “chicago_staff”, “outside_sales”, “executive_users”, etc.).

4 Select a non-global admin group from the Admin Group list. If you are creating a working reservation, you would want to associate this reservation with the admin group to which the users will belong after successful enrollment.

Note: An existing user enrolling under this reservation will not be removed from their existing group and placed in the group you select here.

5 Click Next. The Authenticator Options window appears.

271


Figure 139: Authenti-cator Options window

6 Specify the authenticator(s) your enrolling user(s) will receive upon enrollment by selecting one or more of the option check boxes. You may choose more than one.– Software/Hardware Authenticator. The user will be prompted to enter

the authenticator’s serial number (located on the back of the hardware token). If you choose this option, you must have already imported the authenticator programming files that came with your hardware authenticators These procedures are outlined in Chapter 3.• If you choose this option, you may select the SoftPIN check box to

prompt users for a SoftPIN when they enroll. For more information about SoftPINs, see “Using SoftPINs with a user account” on page 131.

– Digital Certificate Profile. If you have not created digital certificate profiles yet, refer to “Digital certificate profiles” on page 147 before continuing with this procedure. Otherwise, select from the list of existing digital certificate profiles.• Enroll an existing certificate, in which case the user will be prompted

to select a certificate.• Generate a new certificate that they can place in any location

accessible from their browser (including a smart card), and as before, the enrolling user will be prompted for certificate generation parameters.

– Fixed Password Profile. This option allows users to enroll with a fixed password of their choice. The password they choose must conform to the parameters in the fixed password’s profile. For information about fixed password profiles, see “Fixed password profiles” on page 145.

Note: The properties of any profile available in the expanding menu can be viewed and/or modified by clicking the View button.

7 When the authenticator options have been chosen, click Next. The User Options window appears.

272


Figure 140: UserOptions window

.

8 Click the appropriate check box to choose to allow users to:– Specify ID during enrollment: Allows users to specify a username for

themselves. The system will check to verify that another identical username does not already exist in the system.

– Specify existing IDs: Allows you to add authenticators for a set of previously-enrolled users, or if you have imported a database in which existing users are listed (for more information about importing users, refer to “Adding and importing users” on page 128).

– Specify new IDs: Allows you to manually enter one or more usernames, or import a database of users who will enroll under this reservation.

9 (Optional) Select a role (or roles) from the Available Roles list.

10 Click Add to move the role to the Selected Roles list. This role will be applied to the users who enroll under this reservation. If no role is assigned, users will be assigned the default role upon enrollment. For existing users, the role(s) you select here will not change their previously assigned role(s), but will be added to those they have already been assigned.

11 When your selections have been made, click Next.

The next set of actions you take will depend on the selections you made in step 8. Read the next section called “Passphrases and usernames”, then follow the directions that are specific to the choices you made in step 8.

273


Passphrases and usernames

Passphrases are text strings that are used to secure access to the enrollment process. Users must use their pass phrase to link up to the specific reservation where they will enroll. There are two methods for creating passphrases, allowing the system to generate them, or creating them manually.

System-generated passphrases can be relatively simple, or fairly complex (e.g. chintz_outward_peaceful). The passphrase is not echoed back (displayed in clear text) to the user as they enter it, so advise your users to enter the string slowly and carefully to avoid a failed enrollment. If you have relatively inexperienced users, you may want to create simpler passphrases of your own. If you create your own, keep in mind that the passphrases should be complex enough to keep them from being easily guessed, but not so difficult as to be unmanageable to your users.

Usernames are the main identifier for the users in your system. You can allow your users to select their own name (the system will verify that it is unique, and not already registered by another user), specify existing names, or specify a new name.

• To allow users to select their own usernames, proceed to “Individual Pass Phrases, Users Select Names” on page 275.

• To specify existing usernames, proceed to “Individual Pass Phrases, Existing Users” on page 277.

• To specify new usernames, proceed to “Individual Pass Phrase, New Users” on page 279.

274


Individual Pass Phrases, Users Select Names

If the reservation you are creating is intended to allow users to choose their own username, the Individual Pass Phrases, Users Select Names window appears.

Figure 141: IndividualPass Phrases, Users

Select Names window

1 You may allow the system to generate pass phrases or enter them yourself. If you choose to allow the system to generate pass phrases,

a Specify the number of pass phrases to generate in the Number of Pass Phrases field.

b Click the Generate Pass Phrase button.

Tip: You can generate additional pass phrases later if you prefer.

If you choose to enter custom pass phrases, note that they must be unique, then click the Custom Pass Phrase button. The Custom Pass Phrase win-dow appears (not shown).

a Enter pass phrases of your choosing into the pass phrase field.

b Click OK.

The Current Capacity counter displays the number of users who have yet to enroll under this reservation. The pass phrase(s) appear in the Enroll-ment Pass Phrase pane.

275


Figure 142: Window withgenerated pass phrases

2 Once all needed pass phrases have been generated, click Next. A Summary window displays for this reservation.

Figure 143: Summarywindow

The Enrollment URL field lists the location URL for the enrollment Web page. The Enrollment URL field will not highlight as other fields do.

3 (Optional) If something in the summary needs to be changed, click Back to return to whichever window needs modification.

4 If the information in the summary accurately reflects what you intended, click Finish.

Note: If you have the enrollment server running, you can cut and paste the enrollment URL into your browser to see the enrollment form your end users will see.

276


For an explanation of Advanced Mode, refer to the section called “Advanced Mode option features” on page 283.

To capture the enrollment URL, then see what your end users will see during Web-based enrollment, refer to the section called “Capturing the enrollment URL” on page 289.

Individual Pass Phrases, Existing Users

If the reservation you are creating requires you to select existing users, the Individual Pass Phrase, Existing User window appears.

Figure 144: IndividualPass Phrase/Existing

User window

1 Select Select User. The Find User entries window appears.

2 Select Find all available to see the entire user list, or Find all that match to locate a specific user. The Users for Reservation: (reservation name) window appears.

Figure 145: User forReservation: (reservation

name) window

3 Double-click the user name from the list to add them to the username column of the pass phrase window (or Shift-click to select several users at a time).

277



User window withselected users

4 For each user listed, there must be an associated pass phrase. Click Generate Pass Phrase to have pass phrases automatically generated for all users listed in the list field. You can also manually enter a passphrase for a user (or users). To do this, click in a pass phrase cell for a particular user, and type in a pass phrase.

Tip: You can check attributes for each listed user by highlighting the username, and clicking Properties.

All users now have pass phrases associated with their names.


Users (with pass phrases)

5 If no other choices are needed, click Next. A Summary window appears that reflects the choices you have made.

278


Figure 148: Summaryscreen, specified users

6 (Optional) If something in the summary needs to be changed, click Back to return to the window requiring modification.

7 Click Finish to set the configurations you have just made.

For an explanation of Advanced Mode, refer to “Advanced Mode option features” on page 283.

To capture the enrollment URL, then see what your end users will see dur-ing Web-based enrollment, refer to “Capturing the enrollment URL” on page 289.

Individual Pass Phrase, New Users

If the reservation you are creating requires you to add or import new users, the Individual Pass Phrase, New User window appears.

Figure 149: IndividualPass Phrase, New User

window

279


You can either manually enter the name into the User Name field, or Import a user file from another source. To import a user file from another source, click the Import button and skip to “Importing users into a reservation” on page 281. To manually enter usernames, continue with step 1 below.

1 Manually enter each username in the User Name field, then click <<Add User (or press the Enter key). Each name will appear, as entered, in the User Name list.

Figure 150: IndividualPass Phrase, New User

window (with names)

2 Once all names have been entered, click Generate Pass Phrase to have the system generate pass phrases for each user. All users now have pass phrases associated with their names.

Figure 151: IndividualPass Phrase/New User

window (with passphrases)

3 Click Next. A Summary window appears listing the choices you have made for this reservation.

280




5 Click Finish to set the configurations you have just made.


To capture the enrollment URL, then see what your end users will see during Web-based enrollment, refer to the section called “Capturing the enrollment URL” on page 289.

Importing users into a reservation

You can import users from a previously exported database file (in the .csv file format) directly into an enrollment reservation, thereby allowing you to set up a reservation containing the names of existing users who need only enroll themselves and the authenticator chosen for them. To import users directly into a reservation, from the Individual Pass Phrase/New User window, click Import.

Figure 153: Browserwindow

1 When the Browser window appears, locate the .csv or .txt file containing the users you want to import into the reservation.

2 Click Open. The Individual Pass Phrase/New User window appears.

281


Figure 154: IndividualPass Phrase/New User

window

As displayed, a user database has been imported. Pass phrases are already assigned to these users because in the export database file that was created, the Comments field contained their original password, which then becomes their enrollment pass phrase.

3 Click Next. The Summary window for this reservation appears.



5 Click Finish.


To capture the enrollment URL, then see what your end users will see dur-ing Web-based enrollment, refer to the section called “Capturing the enroll-ment URL” on page 289.

282

Chapter 12: Setting Up Web-based EnrollmentAdvanced Mode option features

Advanced Mode option features

The Advanced Mode features go beyond those present in the basic enrollment reservation wizard. When you complete the reservation wizard, you have a basic reservation. Additional features available to in Advanced Mode include setting a fixed expiration date for a reservation or user record, and additional pass phrase options (shared, individual, or no pass phrase).

Tip: Clicking Advanced Mode from one of the summary windows opens the series of windows that allow you to set the advanced enrollment features described above.

Important: While editing an existing reservation, that reservation is locked. The Enrollment Server cannot write to it, and users cannot enroll under that reservation.

Tip: The screens under Advanced Mode are also accessible from Insert -> Reservation.

Setting advanced mode options

To set Advanced Mode options, from any summary screen, click Advanced Mode. The New Enrollment Reservation window appears.

Figure 156: Create anew User Reservation -

General tab


On the General tab, the Enrollment Reservation Name field displays the name of the reservation to be edited (in this case, Reservation_Sales). The Enrollment URL field shows the URL for the Enrollment Server.

1 Choose whether to set an expiration date for this reservation. If a reservation expires, users can no longer enroll under it. Select either:

283


– Never. Reservation remains in effect until changed by you. Continue to the next step.

– Expire on. Allows you to select an exact expiration date by month, day, year, and time. If you choose this option, select the date and time for expiration.

– Duration. Allows you to set a life span expressed in minute(s), hour(s), day(s), week(s), month(s), or year(s). If you choose this option, select the duration for the reservation.

Tip: The system retains all reservations, even those that have expired, until explicitly deleted. You can edit an expired reservation and change the expiration date to make it valid again.

2 (Optional) Enter any desired Comments for this reservation.

3 Select an Admin Group for the reservation. Accept the default, which is based on the selection you made earlier, or choose another user group into which users who enroll under this reservation will be placed.

4 To view the properties of this admin group, click the View button.

5 To set user data options, click the User Data tab, and continue to the next section. If you are finished choosing options click OK.

Figure 157: Create anew User Reservation -

User Data tab

User data tab settings

1 If you want to set a fixed expiration date for user records created under this enrollment, select the Activate User Expiration Date check box, then set the date and time of expiration. Otherwise, leave the box clear.

2 If you want to add a role or roles in addition to the ones you added earlier in the reservation process, select the role name from the Available Roles list, then click Add.

284


3 To make another authenticator available for this reservation, click the check box next to it.

4 When your choices have been made, click the Validation tab to set validation options, or click OK to complete the process.

Figure 158: Create anew Reservation -

Validation tab

Validation tab settings

On the Validation tab, the settings in the ID Assignment pane reflect the settings you made in the User Options window of the reservation wizard. To recap those options:

• Specify ID during enrollment allows users to specify a username for themselves. The system checks to verify that another identical username does not already exist in the system.

• Specify existing IDs allows you to add authenticators for a set of previously-enrolled users, or to specify users from an imported database file.

• Specify new IDs allows you to manually enter a user name(s), or to import a database of users who will enroll under this reservation.

1 The Enrollment Pass Phrase pane allows you to choose between:– Shared pass phrase: Enrolling users will share a single enrollment pass

phrase made known to all of them.– Individual pass phrases: Individual enrollment pass phrases will be

assigned to each user.– No pass phrase: Users may enroll without an enrollment pass phrase.

Note: For non-pass phrase protected reservations, user names cannot be listed in more than one reservation of the same type. With no pass phrase protection, reservations are identified by their type during enrollment. Duplicate user names on reservations of this type would prevent the system from identifying the correct reservation.

285


2 Click the User & Pass Phrase button. The window summarizes your previous choices. For example, if you selected Specify ID during enrollment (as in the case above), clicking the User & Pass Phrase button shows a screen listing a series of pass phrases equivalent in number to the number of pass phrases you specified.

Figure 159: User & PassPhrase summary window

User and Pass Phrase summary options

If the settings you made earlier need to be changed, you may do so from this window. Choose from the following options:

• To import a user file from another source, click the Import button and refer to “Importing users into a reservation” on page 281.

• To manually enter user names enter each name in the User Name field, then click <<Add User (or press the Enter key). Each name will appear, as entered, in the User Name list.

• When all names have been entered, click Generate Pass Phrase to have the system generate pass phrases for each user. All users now have pass phrases associated with their names.

• You may remove a name or all names by selecting the Remove or the Remove All buttons.

Table 20 outlines the results of username and pass phrase choices that are available on the Validation tab.

286


Table 20: Name to enrollment pass phrase choice matrix

3 Under the Personalization Data Attributes pane, select the attributes you

With this Username choice...

...and this Enrollment pass phrase choice...

...you will follow-up with these actions

Users select own name

Shared pass phrase

• Set max number of users for this reservation.

• Accept the default, or enter/generate a new pass phrase.

Individual pass phrase

• Select number of pass phrase(s) to generate.

• Generate pass phase(s). (See note)

No Pass phrase • Set max number of users for this reservation.

Specify existing users

Shared pass phrase

• Select existing user(s).

• Accept default pass phrase, or enter/ generate a new pass phrase.


• Select existing user(s).

• Generate (or manually enter) new pass phrase(s) for each user.

No pass phrase • Select existing user(s).

Specify new users Shared pass phrase

• Add (type) new name, or,

• Import users from a file.

• Accept default or enter/generate a new pass phrase.


• Enter a new name, or,

• Import users and optional associated pass phrases from a file.

• Generate new pass phrase for each user (that does not have one).

No pass phrase • Enter a new username(s), or,

• Import users from a file.

Note: Enter the number of pass phrases (if more than one) that you want to generate.

287


want to be collected for this reservation from the Available list.– Click the Add button to move the selected attributes to the Selected list.– Click Remove to remove an attribute from the Selected list.– Change the order of attributes by selecting the attribute you want to

move, then use the arrows next to the Selected list to move it up or down in the list. This is the order in which the attributes will appear on the Reservation Web page.

4 When your configuration choices have been made, click the History & Print tab. The History & Print window appears.

Figure 160: NewEnrollment Reservation,

History & Print tab

History and Print settings

The History pane contains information about users who have enrolled under the reservation you created. Their username (either selected by them or designated by you), the pass phrase they used to enroll, their authenticator ID, or the name of the password profile they used, and the date of enrollment are displayed.

The options under Print are as follows:

• Print Summary: Prints a summary of the entire reservation.

• Print User Pass Phrase: Prints a list of the usernames (if present) and pass phrases (if present) that could be used for enrollment under this reservation.

• One User/Pass Phrase Per Page: Prints a single username and enrolling pass phrase per sheet of paper.

Click Print to print the summary or Save As to save it to a location on your computer. Click OK to close the window, and save any configuration changes you may have made.

288

Chapter 12: Setting Up Web-based EnrollmentOther enrollment tasks

Other enrollment tasks

In addition to creating basic and advanced enrollment reservations and pass phrases for your users, the PremierAccess system tools also allow you to review existing reservations, and to capture enrollment URLs to supply to your users.

Reviewing reservations

To locate and review a reservation, from the Admin Console, click Find ->User Reservations. The Find Enrollment Reservations Entries window appears.

1 If you do not know the specific name of the reservation you want to review, select Find all available. If you know the name, use the (default) Find all that match option, and specify the name.

2 Click Find. The reservation search results list appears.

Figure 161: Find results:Enrollment Reservation

Entries window

3 Double-clicking an entry brings up a View (summary) window.

4 Select the Edit button to make changes to this reservation.


Capturing the enrollment URL

Once you create an enrollment reservation and display the summary window, you will see the enrollment page URL displayed in the Enrollment URL field. This URL must be distributed to your end users so they can self-enroll.

Important: In order for the correct hostname to appear in the Enrollment URL, it must have first been entered in the Enrollment configuration window. See “Customizing enrollment configurations” on page 264.

289


To capture the URL for distribution by whatever means you have pre-determined, do the following:

1 From the summary window, choose the option you wish to print, then click the Print button.

Figure 162: SummaryPrint window

2 Click the Save As... button. When the Save window appears, save the file as a text file into a directory (suggested) within the path of your PremierAccess installation.

3 Use a text editor and open the file you just saved. You can then cut the URL and paste it into an e-mail or separate text file for hardcopy print.

What your end users see

After you create your reservations and capture the URL for the Web page location, you will distribute that URL and pass phrase(s) to your end users. This is the Web page they will visit to enroll themselves into the system.

The type of Web page displayed to your users will depend on the type of authenticator (fixed password, hardware authenticator, or digital certificate) with which they will enroll.

Enrolling users can supply personalization data for their user record. This information can be used as additional data to authenticate a user, or as administrative-tracking data associated with that user. For example, if a user loses their authenticator and they call the helpdesk, this additional data can be used to verify that user’s identity. Personalization data can also be used to allow users to change their SoftPIN without the assistance of helpdesk staff. The following are examples of what users will see when doing self-enrollment.

290


Users enrolling a fixed password

When users enroll themselves and their fixed password on the enrollment Web page, they may find it helpful to understand what is required of them. The following summarizes what a typical user will need to do.

1 The user accesses the URL that you (the administrator) supply. The Authenticator Enrollment Web page appears.

Figure 163: EnrollmentWeb page, fixed password

2 The user enters the required information into the appropriate fields. Required information (Username, Enrollment Passphrase, Desired password, and Confirm password) is indicated by an asterisk.

3 The users click the Next button. The Confirmation page appears.

Figure 164: EnrollmentWeb page, Confirmationand Fixed Password test

page

This page indicates successful enrollment.

291


4 The user clicks the Test button to test their authenticator (here a fixed password). The Fixed Password test page appears.

5 The user enters the password they designated on the initial enrollment screen.

6 The user clicks the Next button. The Authenticator Test Successful page appears, and indicates a successful test.

Figure 165: Authenti-cator Test successfulpage and Enrollment

processing complete page

7 The user clicks the Next button to finish. The Enrollment processing complete page appears, and indicates a successful test.

8 The user clicks the Continue button. If no customizations have been made to the enrollment forms, the user will be taken to the main page of the PremierAccess Web server. However, with one simple customization, you can direct your newly enrolled users to the URL of your choosing. See “Simple customization” on page 267 for details.

Users enrolling a hardware authenticator

If your users will be enrolling a hardware authenticator, they may find it helpful to understand what will be expected of them. The following summarizes what a typical user will need to do.

1 The user accesses the URL you (the administrator) supply. The Token Authenticator Web page appears.

292


Figure 166: TokenAuthenticator Enrollment

Web page and EnrollmentConfirmation page

2 The user enters their desired username and the Enrollment passphrase that was provided by the Administrator.

3 The user enrolls for a hardware authenticator by entering the serial number that is printed on the back of the token.

4 The user then enters their SoftPIN in the Enter your SoftPIN field, then re-enters it to confirm. SoftPINs are optional, and only appear on Web pages if the enrollment reservation is configured to ask for a SoftPIN. For more information about setting up enrollment reservations, see “Creating enrollment reservations” on page 269.

5 The user clicks Next. The Enrollment Confirmation window appears with the successful enrollment message.

Testing an authenticator

A user may choose to test their authenticator from the Enrollment Confirmation window. To test their authenticator, the user clicks the Test button.

293


Figure 167: TokenAuthenticator Test pageand Test Authentication

Successful page

1 The user enters their token-generated password in the Token Password field.

2 The user adds their SoftPIN before or after their password. This must be done every time they enter a token-generated password if they chose to use a SoftPIN. The SoftPIN will be prepended or appended depending upon how the AAA Server is configured.

3 By default, SoftPINs must be appended to passwords. Administrators can change the SoftPIN setting in the AAA Server if they prefer to have SoftPINs pre-pended to passwords. For more information, see “Using SoftPINs with a user account” on page 131.

4 Click Next. The Test Authentication Successful page appears.

5 Click Next.

294


Figure 168: EnrollmentProcess Completion page

The user is informed that they have successfully enrolled into PremierAc-cess.

Users enrolling a digital certificate

If your users will be enrolling a digital certificate, they may find it helpful to understand what will be expected of them. The following summarizes what a typical user will need to do.

1 The user accesses the URL you (the administrator) supply. The New Digital Certificate Enrollment Web page appears.

Figure 169: New DigitalCertificate Enrollment

page

2 The user enters their desired Username and the Enrollment passphrase that was provided by the administrator.

3 The user enters their full (common) name in the Common Name field.

The common name and the next six values will be inserted into the user’s digital certificate. When using digital certificates on your hard drive, during authentication, the name of the certificate will appear in a pick list in your browser. It must be selected.

295


The defaults provided on the Web form are configurable.

4 The user clicks Next.

Figure 170: DigitalCertificate Successful

Enrollment page and NewDigital Certificate Test

page

296


If the user enrolled using a PremierAccess-generated certificate, when the Digital Certificate Successful Enrollment page appears, the user clicks the Download the Certificate button to download their newly generated certifi-cate. The user clicks the Test button to test the authenticator, then they click the Next button. If the user enrolled using a third-party certificate, the process will be slightly different.

Figure 171: DigitalCertificate Test page and

Successful EnrollmentCompletion page

5 The Authenticator Test page appears confirming that the authentication test was successful. The user clicks Next to continue.

6 The Enrollment Completion page appears confirming the user has successfully enrolled. The user clicks the Continue button and is returned to the Enrollment Center Welcome window.

297

Chapter 12: Setting Up Web-based EnrollmentUser ChangePin feature

User ChangePin feature

There may be times when a user will want or need to change their SoftPIN without the assistance of the helpdesk staff. PremierAccess allows users to do this using ChangePin function within the Enrollment Center. To allow users to change SoftPINs without helpdesk staff assistance, you must configure the server where the Enrollment Server is installed to request other personalized attributes about the user. Then, if the user supplies the correct values for the personalized attributes, they may change their SoftPIN themselves.

Configuring the server

To configure the server, do the following:

1 From the machine where the Enrollment Server is installed, edit the ../SERVERS/Web/WebPlatform/webapps/servlets/conf/changepin.conf file.

2 Locate the line with “#Example: Personalization_Data_Field_1=Mother’s Maiden Name”.

3 Below that line, add the following: “Personalization_Data_Field_1=<Personalization Data>”.

4 Personalization data that is specified here should be common to all users that have SoftPINs in their authenticators. For example, Social Security Number)

5 Restart the Servlets and Web servers.

User instructions

Instruct users to do the following:

1 From the Enrollment Center Welcome window (http://<machine_name.domain_name>/platform/toc.jsp), select Change your SoftPIN here. The Login page appears.

2 The user should click the Login button.

298


Figure 172: Login pageand Personal Data page

3 The user enters their username in the UserName field.

4 The user enters the appropriate personalization data in the next field.

5 This box requests whatever personalization data the Administrator specified or collected during user enrollment.

6 The user should click the Submit button.

299


Figure 173: ChangeSoftPIN page and

Successful SoftPINChange page

7 The Change SoftPIN page appears. The user should enter their 4-digit SoftPIN the Enter your SoftPIN field.

8 The user should re-enter their 4-digit SoftPIN in the Confirm your SoftPIN field.

300


9 You must use a new SoftPIN when changing your SoftPIN. You cannot use one that you have used in the past.

10 The user should click the Submit button. The Successful SoftPIN Change page appears.

11 The user should click the Test button to test their change by authenticating using their token and the new SoftPIN.

Figure 174: Test SoftPINpage and SoftPIN

Successful page

12 The user should enter their token-generated password along with the new SoftPIN pre-pended or appended to it, in the Password field, then click OK. The Success page appears confirming that the user has successfully changed their SoftPIN.

301


302

13CHAPTER Troubleshooting

In this chapter...

Common problems.......................................................................304

Where are the servers installed?..................................................308

Troubleshooting the Enrollment Server ........................................309

Problems connecting to the Admin Server ...................................312

Finding the Enrollment List HTML page .......................................313

303

Chapter 13: TroubleshootingCommon problems

Common problems

This chapter provides troubleshooting and corrective action instructions for PremierAccess.

Most unsuccessful authentication attempts can be traced back to simple things such as incorrectly entering user names, forgetting fixed passwords, or errors entering hardware authenticator responses. Other, perhaps less frequent factors include users trying to use an authenticator that is not assigned to them, or forgetting to append a SoftPIN to the response displayed by their authenticator.

If multiple users share a workstation, login or authentication errors can result if they forget to select their user name from the login dialog box and attempt authentication with the previous user’s name. Access denial error messages are most often the result of a user trying to access a restricted resource.

Table 21 on page 305 provides a quick matrix view of some common problems, and offers possible explanations and corrective actions for each.

304


Table 21: Problems and corrective actions

Subject Problem Solution

Authentication Authentication fails 1 Verify proper entry of password displayed by authenticator.

2 Verify that authenticator has been imported.

3 Verify match between serial number of authenticator, and serial number of assigned authenticator in user record.

4 Verify user properly entered their user name at login.

5 Verify that the digital certificate authenticator is the first authenticator presented to the WLS. (Certificates cannot be used for re-authentication.)

Successful authentication, but access is denied

1 Check user access.

2 View audit logs (refer to “Viewing a specific user’s authentication activity” on page 178).

3 Verify user name equals userid of the person having trouble.

4 Check user status (account expired, account locked, etc.).

5 Check user role. Is it correct?

6 Check the ACL pointed to by the user’s role. Is is correct?

7 Check ACL entry. Does the entry restrict access to the requested resource?

Configuration changes Configuration was changed, but is not implemented

1 Verify that appropriate server was restarted after configuration change was entered.

2 Verify configuration change was entered properly.

More...

305


Enrollment Enrollment fails 1 Verify proper enrollment page URL.

2 Verify assigned pass phrase was entered correctly.

3 Check to see if the reservation is locked. If locked, the browser displays a message saying object is locked.

4 Verify that the reservation was found.

5 Check the reservation’s expiration date.

Enrollment forms corrupted On the local machine, go to whatever directory specified during installation as the web directory, and delete the forms.

Enrollment Server Visiting an enrollment URL results in an error page indicating the server or page cannot be located

1 Ensure that the URL is correct.

2 Ensure that the base URL specified for the Enrollment Server is correct.

3 Ensure that the port number of the Enrollment Server is correct.

The Web server cannot be started

1 Check Web server configuration.

2 Check to see if there are any applications running on the same port.

Enrollment of an existing certificate never prompts for an existing certificate

1 Shutdown all browser windows and retry user enrollment process.

2 Check to ensure that the existing certificate is still valid and has not expired.

Certificate test fails after successfully enrolling a certificate.

1 Verify that the digital certificate profile associated with the certificates specified in this reservation contains the proper root CA certificate.

2 Check AAA log for details on why the certificate verification failed.

When enrolling an existing certificate, the desired certificate is not given as an option.

1 Verify the desired certificate and associated private key are present in the browser.

2 Check to ensure that the desired certificate is still valid and has not expired.

More...


306


Importing authenticators

All import records rejected Check to see if the authenticators had been previously imported (use audit log, check by event type).

Some import records rejected

Check to see if the authenticators had been previously imported (use audit log, check by event type).

Ports How to determine if a port is active?

Use the netstat -a | grep PORTnumber command. If a line is returned with the port number specified on the left, and the word listen near the right of that line, then the portnumber is considered active.

Servers Server(s) not responding 1 Use installation and management utility to determine if servers are running.

2 Restart server(s).

Need to restart server(s) Refer to the PremierAccess Installation Guide, the section called “Manually starting and stopping the PremierAccess servers.”


307

Chapter 13: TroubleshootingWhere are the servers installed?

Where are the servers installed?

The PremierAccess servers are installed in the following directory tree (where $ROOTDIR is topmost directory in the PremierAccess server installation tree)

$ROOTDIR/PremierAccess/SERVERS

./Directory (location of the LDAP directory)

./AAAServer (location of the AAA Server)

./AdminServer (location of the Admin Server)

./RADIUS/RADIUSServer (location of the RADIUS Server)

./RADIUS/RADIUSAccountingServer (location of the RADIUS Account-ing Server)

./RADIUS/RADIUSServer4Ascend (location of the RADIUS for Ascend Server)

./Web/apache (location of the embedded Apache Web Server)

./Web/WebPlatform (location of the embedded Jakarta Tomcat servlet server)

./Web/WebPlatform/webapps/servlets (location of the Enrollment Server application)

./Web/WebPlatform/webapps/wls (location of the Web Login Server application)

308

Chapter 13: TroubleshootingTroubleshooting the Enrollment Server

Troubleshooting the Enrollment Server

This section provides information and suggested corrective actions for the embedded Apache server. Additional information for installing or re-installing any of the listed servers can be found in the PremierAccess Installation Guide.

To troubleshoot the embedded Apache server, do the following:

1 Verify proper Enrollment Server configuration.

Visit the URL:

https://machine:port/servlets/www/Enrollment/EnrollmentList.jsp

Here, machine is the DNS name of the machine hosting the Enrollment Server and port is the port on which you installed the server (443 by default).

This should bring up a page listing all of the reservations currently present in the directory.

Note: If you receive a message indicating a secure channel cannot be established, you are probably using an older version of Internet Explorer as the browser. Try updating the SSL settings under advanced internet options to disallow the use of SSLv3.

2 Restart your browser, try connecting again.– If you receive a message indicating that the server cannot be located,

your Apache server is probably not running.– Verify that you typed the page URL correctly.– If you receive a message indicating that an internal server error

occurred, your servlet engine is probably not running.– If you receive an empty list of reservations when you know you have

created reservations, then your servlet engine is probably unable to connect to your Administration server.

3 Next, click on a link to bring up the enrollment page for one of the reservations.

If this does not work, check the urlRoot specified in the file:

PremierAccess/Servers/Web/WebPlatform/webapps/servlets/WEB-INF/web.xml

Make sure it matches the machine and port you are using for the Enroll-ment Server. If for some reason, you update the urlRoot in web.xml, be aware that any forms generated in...

PremierAccess/Servers/Web/WebPlatform/webapps/servlets/www/Enroll-ment

and

PremierAccess/Servers/Web/WebPlatform/webapps/servlets/www/Enroll-ment/test

...will still have the old urlRoot. These files have the form P_*shtml or O_*shtml. These files should be removed.

309


4 Verify the following file:

PremierAccess/Servers/Web/WebPlatform/webapps/servlets/enroll-ment.conf

This file lists the reservation types for which forms have been generated. If you delete all of your old form files, you can simply delete enrollment.conf, too.

Errors that occur during enrollment

Errors during enrollment will send an error messages to the browser for display to the user. In addition, a message is logged to PremierAccess/Servers/Web/WebPlatform/logs/servlet-yyyymmdd.log where "yyyymmdd" refers to the time stamp that represents when your server was last started. This often can shed light on the problem.

After any updates are made to the configuration of Apache or the servlet engine, you should restart both the Web server and the servlet server. You can do this by using the swpWP script.

310


Problems starting Apache and the Servlet engine

The following should be checked if you have problems starting Apache and the Servlet engine:

1 Verify that Apache has started successfully.– Check the apache/logs directory for the presence of the file called

httpd.pid – If this file exists, the contents specify the process id for Apache. Use the

ps command to verify that this process is running.

If the process is not running, consult the file apache/logs/error_log to see why the process is not running.

2 Determine whether the servlet engine is running.– Check the logs under PremierAccess/Servers/Web/WebPlatform/logs.

The servlet yyyymmdd should contain a line– SCC PremierAccess Enrollment Version: xxx– where xxx is the version number of the installed software.

Why Apache or the servlet engine might fail to start

A port needed by Apache or the servlet engine is already in use by another process. By default, Apache will use port 8007 and 8009. If any of the ports you specified during installation are already in use, you should use the PremierAccess Configuration Utility to change the port numbers to be used by the PremierAccess Web and servlet servers.

311

Chapter 13: TroubleshootingProblems connecting to the Admin Server

Problems connecting to the Admin Server

If you suspect your servlet engine is unable to connect to the Admin Server, first you should:

1 Verify that your Admin Console is able to connect.

2 Use the PremierAccess Configuration Utility to specify the correct Admin Server for your Enrollment Server.

3 If a DNS name is used to specify the host, make sure it is resolvable on the machine hosting the Enrollment Server.

4 Verify that the password for the Enrollment Server user account is correctly configured in the Enrollment Server configuration file. The Enrollment Server authenticates to PremierAccess as the ENROLL_SYS_ADMIN user by default. This is specified as the adminuser argument in $ROOTDIR/PremierAccess/SERVERS/Web/WebPlatform/webapps/servlets/WEB-INF/web.xml.

This user account authenticates with a fixed password that is configured as the adminpwd argument in the same file. The value for this argument must contain the user’s fixed password as stored in the PremierAccess data-base. Therefore, whenever you change the password for the ENROLL_SYS_ADMIN user, you must propagate that change to the web.xml file of any PremierAccess Enrollment Server that you have deployed.

If you are not prompted for a certificate when enrolling an existing certificate, then you probably have forgotten to set the protection level for the Enrollment/SSL_Test directory to require a client certificate. This configuration step should be done automatically as part of the install of Apache.

312

Chapter 13: TroubleshootingFinding the Enrollment List HTML page

Finding the Enrollment List HTML page

You can easily find the list of open user and device reservations by using the URL:

https://machine:port/servlets/www/Enrollment/EnrollmentList.jhtml

In addition, by accessing the URL: https://machine:port/ you will be brought to a table of contents page that contains links to all the installed Web applications on your PremierAccess Web server.

313

Chapter 13: TroubleshootingFinding the Enrollment List HTML page

314

AAPPENDIX PremierAccess in DoD

PKI Environments

In this appendix...

Overview ......................................................................................316

Installing DoD PKI trust points......................................................316

Removing non-DoD trust points ...................................................317

Importing certificates ....................................................................317

Installing Uniform Resource Indicators for DoD PKI services ......317

Using PremierAccess in DoD PKI environments..........................317

Protecting private keys from loss or compromise.........................318

PKI User’s Responsibilities ..........................................................319

315

Appendix A: PremierAccess in DoD PKI EnvironmentsOverview

Overview This appendix describes how to install, configure, and use SafeWord™ PremierAccess™ to operate within Department of Defense (DoD) Public Key Infrastructure (PKI) environments.

PremierAccess is interoperable with industry standard X.509 DoD Public Key Infrastructure (PKI) digital certificates that provide a high degree of pre-entry user authentication and authorization to move and work within secure networks.

Private keys and digital certificates

Private keys and public keys work together to authenticate messages and documents. A private key is used to decrypt a message that has been encrypted with a corresponding public key. A private key can also be used to digitally sign messages.

A digital certificate is a data structure digitally signed by a Certificate Authority (CA), or a signature source users can trust. The certificate contains values such as the certificate name and usage, information identifying the owner of the public key, the public key itself, an expiration date, and the CA name that generated the certificate.

Trust points

A trust point is the trusted Root CA certificate or local/enterprise (intermediate) CA certificate which sits at the top level of a certificate chain, and can be used to validate the subordinate certificates which reside below it. Its trustworthiness comes from the assumption that it is from a list of implicitly trusted certificates held by a user, and the certificate has been securely maintained by the user.

Installing DoD PKI trust points

PremierAccess uses CAs as its equivalent to trust points. PremierAccess’ digital certificate handling capabilities import and use industry standard digital certificates deemed trustworthy under DoD PKI requirements as an effective means of authenticating and authorizing users seeking access to secure networks. PremierAccess validates end-user certificates as part of a certificate handling policy created for that user.

Complete procedures for installing PremierAccess are located in the PremierAccess Installation Guide . For a discussion of digital certificate profiles refer to “Digital certificate profiles” on page 147.

316

Appendix A: PremierAccess in DoD PKI EnvironmentsRemoving non-DoD trust points

Removing non-DoD trust points

Removing trust points from PremierAccess is done by deleting the certificate from its profile. Once the certificate has been removed, any and all users to whom this profile applied will not be able to authenticate to PremierAccess protected resources. See “Revoking digital certificates” on page 152 for procedures for removing a digital certificate from its profile.

Importing certificates

PremierAccess allows you to import trusted certificates from external trusted certificate authorities such as VeriSign, RSA Data Security, or Thawte Consulting. Though PremierAccess generates its own self-signed certificates, they are not trusted for use in DoD-compliant PKI environments. Procedures for importing trusted certificates into PremierAccess are located in the PremierAccess Installation Guide, under the heading “Trusted root certificates, obtaining and using.”

Installing Uniform Resource Indicators for DoD PKI services

You can configure PremierAccess to allow external Lightweight Directory Access Protocol (LDAP) servers to act as contact points for the retrieval of Certificate Revocation Lists (CRLs) issued by agencies that generate them, though PremierAccess does not automatically update CRLs. This feature is part of the PremierAccess’ digital certificate profile options. To create digital certificate profiles, refer to “Digital certificate profiles” on page 147.

Using PremierAccess in DoD PKI environments

PremierAccess’ Administration Console and user management tools allow X.509 digital certificates to be imported into, and become part of a digital certificate profile. This profile will be assigned to one or more users. When the network administrator creates this profile, intermediate or trusted digital certificates obtained from a DoD PKI approved Certificate Authority (CA) will be selected for use as part of the profile.

This same profile can be modified to designate an explicit policy for handling and verifying certificates, to determine whether the certificate is to be mapped (allowed by more than one agency), and how, and under when the certificate can or will be revoked.

Digital certificate profiles must be created by the PremierAccess system administrator. Complete instructions on how to create digital certificate profiles, import trusted digital certificates, and set handling and mapping attributes can be found in Chapter 6, Managing User & Authenticator Information of this guide.

317

Appendix A: PremierAccess in DoD PKI EnvironmentsProtecting private keys from loss or compromise

31

Protecting private keys from loss or compromise

Private keys decrypt and digitally sign messages. They are critical pieces of the network security puzzle. As such, they must be safeguarded with sufficient protective measures as to prevent their disclosure to, or compromise by unauthorized parties. If private keys have been compromised, the security of a network is also compromised.

Private keys are never stored on any PremierAccess servers or modules. This ensures that their security is never compromised. However, private keys can be stored on an end-users PC, in software modules, or on hardware devices like smart cards or hardware authenticators (also referred to as tokens).

Often these devices are protected with a password, even though passwords are the least secure method for protecting keys and systems. Passwords written down and left in plain sight, passwords given to coworkers, or systems left unlocked or unsecured while unattended are open invitations to private key compromise. Ultimate responsibility for safeguarding private keys rests with the end user.

Some effective measures for protecting password-protected private keys include:

• Keep your passwords private, and not written down where they may be easily discovered.

• Use passwords of sufficient complexity that they cannot be easily guessed. Passwords should not be family or pet names, birthdates, or any other personal information that may be known about you.

• Passwords should contain a mixture of letters (of mixed cases, or combinations of capital and lower case letters), numbers, and certain symbols. These combinations are the most difficult to guess by unauthorized users.

• Change passwords regularly.

• Lock and/or secure computer systems when not in use.

8

Appendix A: PremierAccess in DoD PKI EnvironmentsPKI User’s Responsibilities

PKI User’s Responsibilities

A key is considered compromised if a user other than the person to whom the key was issued has gained access to and used that key. Evidence of compromise may include (but not be limited to):

• Unauthorized entry into a secure network by a user claiming to be the authorized user.

• Access to protected applications or resources from a user’s machine when that user is/was not present.

• The inadvertent disclosure of a password.

• The loss of a computer on which the private key was/is stored.

If the slightest suspicion arises that a key has been compromised, it must be immediately reported to the network administrator, security coordinator, or other such cognizant authority for prompt action. Failure to report a compromised or suspected compromised private key can result in compromise of classified information (and damage to national security), loss of critical data, intentional destruction of files, or other such severe actions.

Once reported, the network administrator must immediately revoke the certificate containing the compromised key to prevent its continued unauthorized use.

There are two methods by which a digital certificate can be revoked; deleting the digital certificate from the user’s profile, and adding digital certificates to a published, external CRL. For procedures for using the PremierAccess Administration Console to revoke a digital certificate from a user’s profile refer to “Digital certificate profiles” on page 147.

Note: It should be noted that deleting the digital certificate from the user’s profile in PremierAccess will only prevent authentication to PremierAccess-protected resources.

Digital certificate revocation via CRL is dependent upon the CRL method used, and is beyond the scope of this guide.

319

Appendix A: PremierAccess in DoD PKI Environments

320

BAPPENDIX Setting Up Plugins

In this appendix...

Using the Password Checker plugin ............................................322

Using the Authentication Broker plugin ........................................323

321

Appendix B: Setting Up PluginsUsing the Password Checker plugin

Using the Password Checker plugin

The AAA Server includes a feature that allows a customer-supplied plugin to enforce password rules. This feature can be used by an agent to ensure that their specific policy for fixed passwords is enforced. The plugin is called when a user changes their password. It is only called if all standard checks that the AAA Server performs are OK. The plugin may reject the new password, and optionally set a status message to be displayed and logged.

PremierAccess includes a sample plugin that is named in a way that causes the AAA Server to ignore it. To activate it you must customize the file so that the AAA Server loads it. The sample is stored in the PremierAccess/SERVERS/AAAServer/plugins/SccAAAPlugins.jar.

This JAR file contains the Java source files and class files for the example. You can modify the example to enforce your custom set of password rules.

Important: The procedure that follows assumes you are familiar with Java development and Java code. If you are not skilled in these areas, we recommend delegating this customization to someone who possesses the proper skills and understanding.

1 To customize the plugin, change your current directory to PremierAccess/SERVERS/AAAServer/plugins.

2 Extract the jar file contents by entering the command jar xf SccAAAPlugins.jar.

3 Once the jar file has been extracted, use a text editor to edit the file: securecomputing/yellowstone/authserver/plugins/SamplePasswordChecker.java to add or change the code to perform any special password rules.

This file may be renamed, or a new class may be created, as long as the class implements the SccPasswordchecker interface. This interface requires the three methods implemented in the example.

Note: The example file is included for you to use to test the plugin. If you want to run the example as a test, remove the .example extension and repackage the jar file using the command: jar cf SccAAAPlugins.jar securecomputing.

4 To compile the Java file, enter javac -classpath ../SccAuthServer.jar securecomputing/yellowstone/suthserver/plugins/SamplePasswordChecker.java. If there are any compile errors, fix the source, and recompile before moving on to the next step.

5 Rebuild the jar file with the modified plugin by entering jar cf SccAAAPlugins.jar securecomputing/yellowstone/authserver/plugins.

6 Restart the AAA Server to enable the new plugin.

322

Appendix B: Setting Up PluginsUsing the Authentication Broker plugin

Using the Authentication Broker plugin

The Authentication Broker (also referred to as the “Broker”) is a PremierAccess AAA Server component that resides on the same machine as the PremierAccess AAA Server. It extends access to resources protected by PremierAccess to other user databases in your network. There are two plugins associated with the Authentication Broker, the LDAP (Lightweight Directory Access Protocol) plugin and the RADIUS (Remote Authentication Dial-in User Service) plugin. When a plugin is enabled, PremierAccess calls the external database to authenticate usernames, and fixed passwords or authenticator-based one-time passwords.

Using the Broker reduces the need to immediately migrate all your users to or create duplicate user records in PremierAccess. Instead, you are able to maintain the user and password account where it already exists. This allows you to continue using user management tools with which you are comfortable and familiar. The Broker also allows easy and gradual migration of users from legacy token authentication systems. For example, you may have an existing system with tokens that expire at various dates. The Broker allows you to replace expired tokens for some users with SafeWord authenticators, while brokering authentication for other users until their legacy tokens expire. This makes it painless for you to roll out new SafeWord authenticators at your own pace. Figure 175 shows the Authentication Broker key components.

Figure 175: ConfiguredAuthentication Brokerwithin PremierAccess

PremierAccess

database

LDAPdatabase

databaseRADIUS

AAAserver

RADIUSplugin

LDAPpluginAuth.

Broker

Third-partyservers

with or withoutusers roles

SafeWord

PA PA

PAWLS

PA = PremierAccessWLS = Web Login Server

323


The outer box represents the computer where PremierAccess is installed and inside that is another representing the software. The PremierAccess AAA Server is authenticating users in the PremierAccess LDAP database on the same machine. Additionally, the Authentication Broker is enabled, and configured to broker authentication via the plugins to user databases on other systems within the organization’s network.

Important: The Authentication Broker and its related documentation are sold as a separate, licensed component of PremierAccess. For information about purchasing this plugin, contact your SafeNet Corporation reseller, or visit our Web site at www.safenet-inc.com.

Broker requirements

Before configuring the Broker, you must install a PremierAccess system on a Solaris server in your network. Use of the Authentication Broker is limited to licensed customers. Authentication Broker user licenses are not included with SafeWord PremierAccess.

Note: To use the Authentication Broker, the PremierAccess core servers must be running. The Broker is an optional extension of the AAA Server, so the AAA Server must be running for authentication brokering to work. For details about starting and stopping server components, see the SafeWord PremierAccess Installation Guide.

How the Authentication Broker works

The Broker component runs on the SafeWord PremierAccess AAA Server. When a plugin is configured and an authentication request for a particular user arrives at the AAA Server, the request is routed to the plugin. The plugin brokers authentication to the external directories and RADIUS-compatible systems within your organization. You can optionally configure the plugins to check the PremierAccess database first, eliminating the need to broker the authentication if the user has already been migrated to PremierAccess.

Role-based authorization

Along with brokering authentication, PremierAccess provides role-based authorization by checking users authorization rules. These rules are based on the users role(s). Roles are the tags that PremierAccess uses to identify access privileges. They are the means by which you permit or restrict users access to specific Web and network resources. Role data are specified in the AuthBroker.cfg file. If no role data are specified, the default role is applied.

324

http://safenet-inc.com/

http://safenet-inc.com/


Extended access control

You can configure plugins for all the servers in your network that have user databases on them, as long as the servers are compatible with the Authentication Broker. This gives you the power to deploy PremierAccess agents to control the access of users outside the PremierAccess server, while allowing users to keep their traditional passwords to access Web resources, RADIUS and VPN connections, and any other resources that can be protected by a PremierAccess agent. More agents are added to the list of PremierAccess compatible agents on a regular basis, so check the SafeNet Web site often for updates.

Important: The Authentication Broker and its related documentation are sold as a separate, licensed component of PremierAccess. For information about purchasing this plugin, contact your SafeNet Corporation reseller, or visit our Web site at http://www3.safenet-inc.com/safeword/docs/swpa.aspx.

325




326

GLOSSARY

ACL - Access Control List

In PremierAccess, ACLs are a critical element of an organization’s security policy. An ACL consists of one or more ACL entries that define access restrictions. During access attempts, the user’s credentials are used to determine their role; that role, in turn, points to the ACL that defines the access rights granted to that role. The individual entries within the ACL are sequentially checked until an entry is located that matches the current login scenario.

ACL Entries - Access Control List Entries

Individual entries within an ACL that specify user access restrictions, that could apply to some or all users, and could be based on (for example) time of day, IP address range, type of agent, authenticator strength, role, or a combination of these elements. In PremierAccess, the ACL entries give real enforcement to an organization’s security policy.

Administration Console (AC)

Java-based GUI that provides the primary interface into the PremierAccess system. It allows for the management of users, authenticators, and a security policy that defines access to protected resources. It runs on either Windows 95/98, or NT, or Solaris 2.7. The AC uses Secure Socket Layer (SSL) encryption for secured communications with the Administrative Server (AS).

Administration Server (AS)

A primary PremierAccess component that executes commands and instructions issued by the Administration Console, and gives secure access to the Lightweight Directory Access Protocol (LDAP) directory by requiring proper authentication before allowing access to information stored in the directory.

Agent A process or small program that runs on another vendor’s server and communicates with the AAA Server via the PremierAccess network Application Program Interface (API). Agents support and enable communication to a variety of hardware and software authenticators. (All hardware and software authenticator supported by PremierAccess require an agent.)

API Application Program Interface is a stable, published software interface to an operating system or specific software program by which a programmer writing a custom application can make requests of the operating system or specific software program. (An API provides an easy and standardized connection to a particular software component.)

327

Glossary

Authentication A process that verifies the authenticity of an entity. Especially important as related to network security for the purpose of verifying the authenticity of a person's claimed identity before allowing him or her access to a network system or service.

Authentication, Authorization and Accounting (AAA) Server

Authentication, Authorization and Accounting Server. A primary PremierAccess component that provides authentication, authorization, and accounting services. The AAA Server is the heart of PremierAccess environment, controlling where a network user can connect. It services authentication requests that originate from a variety of PremierAccess agents.

Authenticator A device or mechanism used to verify the identity of an individual logging onto a network, application, or computer. As used in SafeWord documentation, a dynamic password generator (either hardware or software based device). Some previous SafeWord documentation uses the word “token” instead of authenticator.

Certificate See digital certificate.

Certificate Authority (CA) An entity that issues and revokes certificates for a set of subjects, and is ultimately responsible for their authenticity. In order to maintain its trusted status, the CA must be administered by someone with a high level of trust in the community. The CA uses its private key to sign the user certificates it generates, and therefore validates the authenticity of a certificate.

Challenge A set of random numbers generated by the computer being accessed. The numbers are entered into the authenticator, which then generates a password. You can set some authenticators to generate a password in response to a challenge.

CHAP Challenge-Handshake Authentication Protocol. Used only in Access-Request packets.

Client A program or user that requests network service(s) from a server. For example, a Web browser user effectively makes client requests for data from Web servers on the Internet. The Web browser itself is a client by its relationship with the computer that is getting and returning the requested HTML file. The computer handling the client’s request and sending back the HTML file is a server.

Client server software Software designed so that back-end processing tasks, (those that are not apparent to the end user) take place on a server, while front-end processing (the portions of the program that directly interact with the user) are handled by smaller programs (called clients) that are distributed to the client workstations. PremierAccess is client server software.

CSP Crypto Service Provider.

In the realm of PremierAccess, the term client refers to software code that runs on behalf of the end user, on an end-user’s workstation/PC.

328

Glossary

Daemon A server implemented in software, especially when running under the UNIX operating system.

Data Encryption Standard (DES)

A data encryption specification developed in 1975 under direction of the US National Bureau of Standards (NBS), and accepted as an international standard. DES is a strong encryption algorithm that has been used extensively in financial and other business applications. SafeWord tokens use DES encryption to produce one-time passwords according to a banking industry standard. Today, the 56-bit key size of DES is considered somewhat weak, and its use is being replaced by stronger algorithms, such as 3-DES. The National Institute of Standards and Technology (NIST, the successor to NBS) is in the process of defining the successor to DES, called the Advanced Encryption Standard (AES), due to be published in 2001.

Digital certificate A digital certificate is a data structure that is digitally signed by a Certificate Authority (CA), or a signature source that users can trust. The certificate contains a series of values, such as the certificate name and usage, information identifying the owner of the public key, the public key itself, an expiration date, and the name of the CA that generated the certificate.

Dynamic password A password that is unique each time it is used. Like a standard fixed (or memorized) password, the controlling software demands that authorized users enter the correct value to confirm their identity. Unlike a standard fixed (or memorized) password, however, the authorized user does not know the correct value unless he is equipped with some kind of authenticator that can issue them in response to user input. Typically, authorized users are equipped with a handheld, specially programmed calculator or “super-smart card” authenticator that issues a different dynamic password each time an Enter button is pressed. Sophisticated authenticators are equipped with compact keypads and demand that authorized users enter the correct memorized PIN number before they will generate the correct dynamic password. Because dynamic passwords are different each time they are used, they expire automatically and cannot be used again even if captured on a public network such as the Internet.

EASSP Extended Authentication and Single Sign on Protocol — This is SafeNet’s proprietary authentication protocol, but because it is “open,” free, and published, it is supported by several software and hardware vendors. It can be implemented wherever SafeWord agents or servers need to communicate with other authentication agents/clients or authentication servers across a network.

Encryption Data encryption uses a secret code to scramble information so that it can be read only by computers using the same code or encryption technology. While encryption reduces the risk of unauthorized access, it does not create a totally safe networking environment on its own.

329

Glossary

Enrollment Server (ES) A PremierAccess component that provides a secure mechanism for transferring the user data entry task from the Administrator to the end user. It provides a means for users to activate or fill in a user data form that is based on a pre-defined authentication profile. Using a Web browser, users essentially “self register” into the PremierAccess environment according to, and within specific access policies.

Fixed password A string of characters, of varying lengths and composition (text and/or numerics) used to identify a user attempting access into a network. Fixed passwords remain unchanged unless given a finite life span. Fixed passwords are also known as Memorized Passwords.

Global data Data that is visible to all levels of administrators

Group In PremierAccess, groups are virtual containers that can hold users or objects (such as authenticators, ACLs, ACL entries, roles, etc.). Groups can be organized in various schemes to make management of users more efficient. Groups can be either global (i.e. visible and accessible to users with administrative privileges), or non-global (visible only to administrators who have direct control over that particular group).

Hardware authenticator Also referred to as tokens. Hardware authenticators are hand-held devices that use an internally held cryptographic variable to generate a dynamic (single-use) password. The cryptographic key generation variable held by the hardware authenticator is known to the host system, which can then anticipate a valid reply. These passwords can be used as a means of identifying a user attempting access into protected resources. There are two types of hardware authenticators; Synchronous, and Asynchronous. Synchronous hardware authenticators generate a dynamic password in response to each depression of the Enter or On key. Asynchronous hardware authenticators generate a dynamic password in response to user input of a host system’s challenge.

Installation and Management Utility

The Installation and Management Utility is the installer used to install all components of PremierAccess including the servers, and Admin console. For information on how to use the Installation and Management Utility, refer to the PremierAccess Installation Guide.

Interface A shared boundary through which information can be exchanged. An interface may be a shared portion of computer software accessed by two or more programs, a hardware component linking two devices, or a device or program allowing a user to communicate and use the computer or program.

Key pair The reference to a private key and a mathematically-related public key. The private key is safeguarded by the owner, and known only to them. The public key can be distributed to anyone. This allows one key to be used for encryption, and the other key to be used for decryption.

Key pair generation The process of generating mathematically-related public/private key pairs.

LDAP Lightweight Directory Access Protocol. An internet standard for directory services that run over TCP/IP.

330

Glossary

MobilePASS SafeWord’s software token solution that allows users to generate software token passcodes on their iPhone/iPod touch and their BlackBerry devices.

Passwd A UNIX command that lets you change your login password after you are registered as a user in the system. The UNIX passwd file is also called passwd.

Password The most common form of computer security. Some networks require multiple levels of passwords to gain access to various servers or databases. Passwords become weak links when they are shared among colleagues, stolen, written down, or created in such a way that they can be easily guessed.

PIN A personal identification number known only by an individual for the purpose of helping identify a person during a computer-based authentication process. PINs should be memorized by the individual.

PKI Public Key Infrastructure. A PKI is a system for distributing public cryptographic keys within a community of interested users. The predominant model (based on X.509) makes use of digital certificates generated by certificate authorities. A PKI enables secure remote communication in a number of network application areas.

Plugin An optional software module that relies on a well-defined interface to add functionality to a popular software product. Vendors that create general-purpose software products such as Internet browsers often insert well-defined points within their logical flow where execution checks for the existence of an external module and executes it if it is present, passing related information back and forth according to established patterns. This allows customers or other vendors to customize specific product areas. The concept has been known by a variety of other names, including “exits” or “user exits”.

PremierAccess A full-featured, directory-enabled authentication, authorization, and accounting system that uses standards-based technologies to positively identify users before they are allowed to access your organization’s protected systems. These systems, such as networks, operating systems, applications, and Web servers (and the content they protect) can only be accessed by users who successfully pass through PremierAccess’ strong authentication.

Private key The private key is used to decrypt messages that were encrypted with the corresponding public key. A private key can also be used to digitally sign messages. The recipient can use the corresponding public key to verify the authenticity of the message.

Public key A public key is used to encrypt messages that only the holder of the corresponding private key can decrypt. Public keys can also be used to verify the authenticity of digitally-signed documents.

Public Key Cryptography A class of cryptographic methods that employ a pair of keys for encrypting and decrypting messages. A message encrypted with the public key can only be decrypted with the corresponding private key. Within a public key crypto

331

Glossary

system, the public key may be made public without compromising the encrypted data. Public key cryptography enables encryption and digital signatures, and simplifies cryptographic key distribution through the use of a public key infrastructure.

RADIUS Remote Authentication Dial-In User Service. An authentication protocol developed by Livingston Enterprises Inc. Recognized by the Internet Engineering Task Force (IETF) as a dial-in security solution on the Internet.(RFC 2138)

Role In PremierAccess, roles are tags or labels that makes user management easier. Roles are part of the means by which access is permitted or restricted. Users can be assigned one or more roles. In PremierAccess, each role points to (or is linked to) one ACL, and it’s the ACL that gives enforcement to the role. Though not a required attribute of a user record, roles are an important tool for controlling user access into protected resources.

SafeWord Citrix Access Gateway (CAG) Agent

A PremierAccess software module, installed on a Citrix Server, that provides a security enhancement to the Citrix environment. The SafeWord CAG Agent supports SafeWord authentication for both remote and console user logon attempts.

SafeWord Domain Login Agent (DLA)

A PremierAccess software module that enables a company secure access to its Domain-based network using SafeWord authentication technology. The module consists of three components: subauthentication filter, agent, and agent service, that you can install separately or in combination with each other.

SafeWord Outlook Web Access (OWA) Agent

SafeWord’s agent that works with the Microsoft Exchange Server to provide strong authenticated access through the Microsoft Exchange Outlook Web Access component.

SafeWord PAM (Pluggable Authentication Module)

A PremierAccess software module, installed on certain UNIX servers that allows you to make use of SafeWord authentication in PAM-compliant applications, such as login, telnet, and FTP supplied by Sun and other vendors. PAM is an integrated feature of Sun’s Solaris operating system starting with release 2.6.

332

Glossary

Server (industry usage) An entity that waits for and answers requests from one or more clients. Servers can be implemented in hardware or software. The term server is known throughout the computer networking industry and is an important part of Internet standards such as the “RFC” documents that define Internet behavior. A server is the opposite of a client. It is important to recognize that because certain powerful servers sometimes make requests of simpler or more basic servers in order to provide more comprehensive service, it is commonplace for one server to act as a client of another server. Certain SafeNet products consist of suites of clients and servers that are configured to help one another. Suites of clients and servers are usually installed on separate computers that communicate across a network, but they can be configured to work properly even if installed on the same computer.

Single sign-on The ability of a user to authenticate once and then have access to protected content on sites in multiple internet domains.

333

Glossary

Smartcard A hardware device that can contain a password or cryptographic keys that can identify a user, but cannot be used without an additional smartcard reader because it contains no keyboard or display.

Established international standards define the size of smartcards and the shape and location of the electrical connections they must use to communicate with smartcard readers. (Smartcards are not very popular with computer users because of the cost and size of the readers.) Until recently, very few software applications knew how to use or test for the presence of a smart card and reader, but this is changing with the emergence of popular interface standards and support within operating systems and Internet browsers.

Software tokens a software version of a hardware token

Token See Hardware authenticators.

User/end user A collection of specific data elements that identify the user to the system, define the resources to which they have access, the administrative group to which they belong, and their role within a network structure. In PremierAccess, the three required attributes for every registered user are user name, and group affiliation.

User database A major component of PremierAccess, containing all the information PremierAccess knows about users.

334

INDEX

A

AAA 4Access rules 7accounting 10ACL

creating entries for a new 104creating entries for an existing 104

ACL entrieschanging order of 112defining an authentication strength

restriction 107ordering 112sequential evaluation 112sorting 112

ACLs 7creating login ACLs 101creating Web 116day/time restrictions 109entries 7subjects 105

adding 144unprivileged users with the user

wizard 140admin groups

creating 100Administration Console

enrolling users with 81Administration Server 11administrators

local administrators 23system administrators 23

agent polling intervals 96agents 16, 21alias

attaching to user accounts 134Allow Policy Downgrade 64AllowAnyToken attribute 73AllowedToReenroll 79Alpine tokens 15archive sets

unloading 191archived audit log files

deleting 191loading 191

archivingadvanced features 193changing the default value 196

archiving during minimal activity periods 196

archiving, authentication, and replication performanceoptimizing 196

Ascend RADIUS serverinterface to 260Managing 260

assigning a temporary fixed password 144

Assigning role(s) to multiple users 155asynchronous authentication 12, 13attack lockout 96attack locks 94

resetting 160attribute

AllowAnyToken 73attributes

DeleteEnrollmentPassphrase 86MPEnrollmentPwd 86MPPolicyAssigned 86

audit log archivesmanaging 190

audit logs 176accounting information 11archiving 192archiving automatically 192configuring archiving 192finding 177

AuthBroker.cfg 324authentication

asynchronous 12, 13challenge-response 12event synchronous 12

335

Index

synchronous 12time synchronous 12

authentication activityviewing 178

Authentication Brokerextended access control 325how it works 324requirements 324role-based authorization 324

Authentication Broker plugin 323Authentication Engine 13authentication examples

CHAP authenticator 234authenticator profiles

adding 145changing 145

authenticator strengths 108minimum 107

Authenticatorsstrengths 153

authenticators 214adding 144assigning to users 130changing 144hardware 292strengths 54, 145

authfileRADIUS sample 251

Authorization 210authorization 5

B

backing up your database 199backing up your database using the

command line 201BlackBerry devices 14, 60

C

Certificate Revocation List 151certificate revocation policy 151certificate verification policies 150challenge- response mode 30challenge-response 12, 13change logs 195ChangePin 298clients file

RADIUS troubleshooting 219Collect SoftPIN 64

components 16core components 16creating

login ACL entries 104login ACLs 101personalization data attributes 162primary working account 49roles 102sub-groups 100Web ACLs 115

credentials 88CRL 151cryptographic keys 203customization

advanced customization 268enrollment forms 267intermediate customization 268simple customization 267

D

debug modeRADIUS 220

default authenticator strengths 108default login ACL

reconfiguring 97default role

reconfiguring 97DEFAULT_LOGIN_ACL 7DEFAULT_WEB_ACL 7DeleteEnrollmentPassphrase 80DER 148device nicknames 75device-specific applications 14diagnostic traces

correct operation 222incorrect configuration 238SafeWord RADIUS server 222

dictionary fileproblems 243RADIUS sample 247RADIUS troubleshooting 219

digital certificate authenticatorsprofiles 147

digital certificatesas authenticators

generating 148enrolling 148, 152profiles 147revocation 151

336

Index

revoking 152using with user accounts 132verification 151

DoD PKI 315overview 316

E

EASSP 329enrolling

digital certificates 295fixed passwords 291hardware authenticators 292

enrolling digital certificates 152enrollment

disabling software token 87enrollment configurations 264enrollment forms

locating 268modifying 268

enrollment passphrasesetting 77

enrollment passphrasesretaining 79

Enrollment Portal 14, 91enrollment reservations 86

Advanced Mode 283allowing users to select names 273creating

269selecting existing names for 273specifying new names 273

enrollment URLs 289entry restrictions

defining 106event sync 30event synchronous 12expiration date

setting for user account 133Exporting data 57

F

fault tolerance 194file types

.cer 150

.crt 150

.der 150DER 148

PEM 148signers.cfg 203

fixed password 291fixed password profiles 145fixed passwords

using with user accounts 131

G

general tab settings 95GLOBAL DATA 7groups 7

admin groups 24and subgroups 24global 25non-global 25parent groups 100RESERVED 49subgroups 100

H

Hardware authenticator fileslocation 45

hardware authenticator profilesmodifying 153

hardware tokens 15HTTP headers 166

I

Importingusers into a reservation 281

importing users 128individual server log archiving

enabling 198installation

Installation and Management Utility 203, 307, 330

invalid entries 202IP address

modifying an existing restriction 122removing from list of restrictions 122

iPhone/iPod touch devices 60

J

J2ME-enabled devices 14

337

Index

K

key management 203keywords

with archives 193

L

log search 10logging

reconfiguring 97login ACL entries

creating 104understanding 104

login ACLs 7

M

mappingcertificates 151

menus 42MobilePASS 14, 39, 60

enrollment portal 85MobilePASS Factory 14, 39, 60MobilePASS policies

configuring 63MobilePASS Portal 14, 60, 88

installing 72MobilePASS software tokens

generating and importing 61MobilePASS tokens

maximum per user 73multiple database connections 197

N

nicknamesdevice 75

O

objects 24optional components 16

P

pass phrases and usernames 274Passcode Length 64

passphrases 274password

change administrator account password 89

RADIUS operation, asynchronous dynamic authenticators 217

synchronous dynamic appended to usernames 216

Password Checker plugin 322passwords

CHAP encoded, RADIUS encapsulated dynamic 218

CHAPauthenticated inside RADIUS packets 217

fixed 55memorized and appended to usernames

215memorized appended to usernames 215memorized RADIUS-encrypted 214RADIUS-encrypted, memorized 214synchronous dynamic RADIUS

encrypted 215PEM 148personalization data

advanced example 170basic example 168passing 123setting up 162

personalization data attributesediting 164removing 164

personalizing Web applications 165PKI

user’s responsibilities 319Platinum tokens 15Pluggable Authentication Module 21plugins

Authentication Broker plugin 323Password Checker 322

policies 63certificate verification 150custom 64deleting 70duplicating 69editing 69MobilePASS policies 30searching existing 69standard 64

primary working account authenticator properties

338

Index

editing 53priority

in roles 103valid range 103

private keys 318privileged users 22

help desk staff 23local administrators 23system administrators 23

profilesdigital certificates 147

programming fileshardware 45

R

RADIUSconfiguration files 210creating an ACL entry and role for 210Default user record 211protocol 206proxy, configuring 212server 206

RADIUS accounting servermanaging 256

RADIUS serverfeatures 207launching in debug mode 220

reenrollment 79References

SafeWord Ascend RADIUS server 261references

SafeWord RADIUS server 247removing a lost hardware token 144replication 194, 195

multiple peer 194ring topology 194two peer 194

report templates 184report worksheet generation 185reporting

log archival impact on 192reports 182

creating 183resetting an attack-locked account 160restoring your database 200restrictions 8

based on authentication strength 120based on range of dates 123based on roles 119

based on time of day 122based on Web browser IP address 121day/time 109

reviewing reservations 289revocation policy 151ring topology architecture 194role

priority 103roles 102

9assigning to users 129creating 102

rules 5Running without an archive log master 197

S

SafeWordRADIUS server

Configuration files 210Universal Web Agent 21

SafeWord Ascend RADIUS serverPrerequisites 260

SafeWord Gold tokens 15SafeWord RADIUS server 206scenarios 33

Strong authentication for a VPN connection 33

Strong authentication for Web sites and their content 35

Strong authentication to wireless LANs using tokens 37

Strong authentication using Mobile phones, pagers, and PDAs 39

Using Cisco devices with PremierAccess 40

secure mode 65security policy 5, 7server key management 203servers tab settings 97sessions

viewing user 172Silver tokens 15smart cards 334smart phones 14SoftPIN collection emulation 80SoftPINs

changing without help desk staff 298using 131using with user accounts 131

339

Index

software tokensassigning to users 81

strengths 5Strong authentication 4subgroups 100subjects 8

in ACLs 105synchronous authentication 12

T

task buttons 42Testing your primary account 55time sync 30time synchronous 12token type

Custom Challenge Response 68Custom Event Sync 66Custom Time Sync 67Standard Challenge Response 66Standard Event Sync 65Standard Time Syn 65

tokensAlpine 15eToken PASS 15hardware 15Platinum 15SafeWord Gold 15Silver 15

TroubleshootingSafeWord Ascend RADIUS server 260

troubleshootingcommon problems 219radius.cfg file 219

trust points 316installing 316removing non-DoD 317

trusted root certificatesDER format 148PEM format 148

types of groups 25

U

Uniform Resource Indicatorsinstalling for DoD PKI services 317

unprivileged users 23adding 140

unregistered user ID 96updating admin server credentials 88

user privilegessetting 134

user recordsdeleting 159

user self enrollmentWeb-based 264

user sessionsrevoking 173

user wizard 140Username to enrollment pass phrase

choices 287users

adding user accounts manually 129aliases for 134assigning a fixed password to 131assigning roles to 129importing 128privileged users 22session management 172system administrator 23unprivileged 23

Users fileRADIUS Troubleshooting 219

users fileconfiguring groups in 211problems 245RADIUS sample 250

Usingthe Password Checker plug-in 322

usingaudit logs 176the Authentication Broker plug-in 323

W

Web ACL entries 115personalization data 115protected URLs 115restrictions 115

Web ACLs 7, 115Web entries

reordering 125Web-based enrollment 263

340

Software Administration Guide

SafeNet MobilePASS®

www.safenet-inc.com4690 Millennium Drive, Belcamp, Maryland 21017 USATelephone: +1 410 931 7500 or 1 800 533 3958

©2010 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners.

Documents

SafeWord PremierAccess Administration Guide version - SafeNet