SafeWord PremierAccess. Administration Guide

Transcription

1 SafeWord PremierAccess Administration Guide

2 Millennium Drive, Belcamp, Maryland USA Telephone: or SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners.

3 Software Version: Documentation Version: Part Number: , Rev. A 2012 SafeNet, Inc. All rights reserved. Preface All intellectual property is protected by copyright. All trademarks and product names used or referred to are the copyright of their respective owners. No part of this document may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, chemical, photocopy, recording or otherwise without the prior written permission of SafeNet. SafeNet makes no representations or warranties with respect to the contents of this document and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, SafeNet reserves the right to revise this publication and to make changes from time to time in the content hereof without the obligation upon SafeNet to notify any person of organization of any such revisions or changes. SafeNet invites constructive comments on the contents of this document. These comments, together with your personal and/or company details, should be sent to the address below Millennium Drive Belcamp, Maryland USA Disclaimers The foregoing integration was performed and tested only with specific versions of equipment and software and only in the configuration indicated. If your setup matches exactly, you should expect no trouble, and Customer Support can assist with any missteps. If your setup differs, then the foregoing is merely a template and you will need to adjust the instructions to fit your situation. Customer Support will attempt to assist, but cannot guarantee success in setups that we have not tested. This product contains software that is subject to various public licenses. The source code form of such software and all derivative forms thereof can be copied from the following website: The use of this product or service is subject to the reasonable, non-discriminatory terms in the Intellectual Property Rights (IPR) Disclosure of Certicom Corp. at the IETF for Suite B Profile for Transport Layer Security (TLS) implemented in the product or service. We have attempted to make these documents complete, accurate, and useful, but we cannot guarantee them to be perfect. When we discover errors or omissions, or they are brought to our attention, we endeavor to correct them in succeeding releases of the product. Technical Support f you encounter a problem while installing, registering or operating this product, please make sure that you have read the documentation. If you cannot resolve the issue, please contact your supplier or SafeNet support. SafeNet support operates 24 hours a day, 7 days a week. Your level of access to this service is governed by the support plan arrangements made between SafeNet and your organization. Please consult this support plan for further information about your entitlements, including the hours when telephone support is available to you. Technical Support Contact Information: Phone: , support@safenet-inc.com i

4 ii

5 CONTENTS CHAPTER 1 PremierAccess Overview An introduction to PremierAccess The AAA solution Understanding strong authentication Authorization Accounting Authenticating with tokens Synchronous authentication Asynchronous authentication SafeWord MobilePASS MobilePASS software authenticators SafeWord hardware tokens Component overview Supported agents overview User privileges and permissions Privileged users Unprivileged users Administrative groups Groups and subgroups Types of groups CHAPTER 2 Administration Overview Required administrative tasks Optional administrative tasks Usage scenarios Strong authentication for a VPN connection Strong authentication for Web sites and their content Strong authentication to wireless LANs using tokens Strong authentication using phones, pagers, and PDAs Using Cisco devices with PremierAccess CHAPTER 3 Basic System Tasks Using the Admin Console Task bar icons Starting the Admin Console iii

6 Table of Contents iv Organizing authenticator files Where to find the hardware programming files Importing the authenticator programming files Setting up and maintaining administrator accounts Cloning the default system administrator account Creating a primary working account Assigning roles to the primary working account Assigning a token to your primary working account Testing your primary working account Assigning a password to the default account Other basic tasks Finding entries in PremierAccess Editing admin group properties CHAPTER 4 Using the MobilePASS feature Understanding MobilePASS Generating and importing MobilePASS software tokens Activating MobilePASS seats Using MobilePASS licensing and legacy licensing simultaneously. 65 Disabling enrollment Configuring MobilePASS policies Defining policies Duplicating policies Searching existing policies Editing existing policies Deleting policies Configuring MobilePASS features Installing the MobilePASS Portal Configuring the user s maximum MobilePASS tokens Configuring the AllowAnyToken PD attribute Using the device nickname feature Allowing reenrollment Retaining enrollment passphrases Configuring SoftPIN collection emulation Assigning software tokens to users Enrolling users with the Administration Console Allowing users to self-enroll with the Enrollment Portal Verifying enrollment reservations Disabling the software token enrollment feature Disabling software token manual enrollment Software token enrollment Using the MobilePASS Portal Changing and updating your admin server credentials Using the Enrollment Portal CHAPTER 5 Setting Up Access Controls

7 Table of Contents Editing the PremierAccess configuration Configuring General settings Configuring the log server Configuring Sessions Working with admin groups, ACLs and roles Creating admin groups and subgroups Creating login ACLs Understanding roles Creating roles Understanding login ACL entries Creating login ACL entries Editing ACL entries Ordering ACL entries Implementing your access control policy Method 1 - Similar users grouped by role Method 2 - Multi-role users Understanding Web ACLs Creating a Web ACL Passing personalization data CHAPTER 6 Managing User & Authenticator Information Understanding users and access levels Adding and importing users Creating user accounts manually Setting user privileges Modifying personalization data Adding unprivileged users with the user wizard Adding, changing or removing authenticators Adding or changing authenticator profiles Fixed password profiles Digital certificate profiles Certificate verification policies Enrolling digital certificates Revoking digital certificates Modifying software and hardware authenticator profiles Assigning role(s) to multiple users Importing user records from a third-party user database Deleting a user record Resetting a locked account Understanding personalization data Data elements The data dictionary Creating personalization data attributes Restricting the values of attributes Editing personalization data attributes Removing personalization data attributes v

8 Table of Contents vi Personalizing your Web applications HTTP header messages Personalization data: basic example Personalization data: advanced example Session management CHAPTER 7 Monitoring PremierAccess Activity Understanding audit logs Querying audit logs Viewing specific entry details Troubleshooting with the Audit Log Monitor Invoking the Audit Log Monitor Choosing logs to monitor Generating reports from the Admin Console Creating reports Report templates Report worksheet generation Generating reports from the command line Using the command line reporting tool Exporting data into Excel worksheets CHAPTER 8 Maintaining PremierAccess Understanding audit log archives Managing audit log archives Configuring the archival of audit logs Using advanced archiving features Replication and fault tolerance Ring topology architecture How replication works Optimizing archiving, authentication, and replication performance Archiving during minimal activity periods Using multiple database connections Running without an archive log master Backing up and restoring your user database Backing up your database Restoring your database Backing up your database using the command line Repairing invalid entries Managing the Admin and AAA Server keys CHAPTER 9 Managing the PremierAccess RADIUS Server Overview of the PremierAccess RADIUS Server RADIUS protocol PremierAccess RADIUS Server PremierAccess RADIUS Server features Prerequisites

9 Table of Contents PremierAccess RADIUS configuration files Authorization and configuration groups Creating an ACL entry and role for RADIUS Configuring the groups in the Users file Configuring the RADIUS proxy Authenticators RADIUS-encrypted memorized passwords Memorized passwords appended to usernames RADIUS encrypted synchronous dynamic passcodes Synchronous dynamic passcodes appended to usernames Shared tokens with memorized passwords Asynchronous dynamic passcode authenticators CHAP-authenticated transparent memorized passwords CHAP-encoded encapsulated dynamic passwords Troubleshooting common problems Check the radius.cfg configuration files The clients file The users file The dictionary file Launch the PremierAccess RADIUS Server in debug mode Diagnostic traces during correct operation Authentication with a PremierAccess password Authentication with a simple synchronous authenticator Authentication with an asynchronous authenticator Authentication with a CHAP authenticator for user_chap Diagnostic traces with incorrect configuration radius.cfg missing RADIUS secret incorrect Dictionary file problems Users file problems References Sample Dictionary file Sample Users file Sample authfile CHAPTER 10 Managing the RADIUS Accounting Server Understanding the RADIUS Accounting Server How the server works Configuring the server Starting the server Example: Enabling accounting on Cisco router Sample accounting data CHAPTER 11 Managing the RADIUS Server for Ascend PremierAccess interface to the Ascend RADIUS Server Prerequisites vii

10 Table of Contents viii Troubleshooting References and additional resources CHAPTER 12 Setting Up Web-based Enrollment Understanding Web-based, user enrollment Customizing enrollment configurations General tab settings Certificate tab settings Customizing enrollment forms Simple customization Intermediate customization Advanced customization Enrollment reservation overview Sample enrollment scenario Creating enrollment reservations Using the reservation wizard Passphrases and usernames Importing users into a reservation Advanced Mode option features Setting advanced mode options Other enrollment tasks Reviewing reservations Capturing the enrollment URL What your end users see User ChangePin feature Configuring the server User instructions CHAPTER 13 Troubleshooting Common problems Where are the servers installed? Troubleshooting the MobilePASS Portal Troubleshooting the Enrollment Server Errors that occur during enrollment Problems starting Apache and the Servlet engine Why Apache or the servlet engine might fail to start Problems connecting to the Admin Server Finding the Enrollment List HTML page APPENDIX A PremierAccess in DoD PKI Environments Overview Private keys and digital certificates Trust points Installing DoD PKI trust points Removing non-dod trust points Importing certificates

11 Table of Contents Installing Uniform Resource Indicators for DoD PKI services Using PremierAccess in DoD PKI environments Protecting private keys from loss or compromise PKI User s Responsibilities APPENDIX B Setting Up Plugins Using the Password Checker plugin Using the Authentication Broker plugin How the Authentication Broker works Agent compatibility Broker requirements Broker configuration options Glossary Index ix

12 Table of Contents x

13 1 CHAPTER PremierAccess Overview In this chapter... An introduction to PremierAccess...2 The AAA solution...7 Authenticating with tokens...13 SafeWord MobilePASS...16 MobilePASS software authenticators...16 SafeWord hardware tokens...17 Component overview...18 Supported agents overview...23 User privileges and permissions...24 Administrative groups

14 Chapter 1: PremierAccess Overview An 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 of user types and access methods Remote Users Customers/Suppliers Business Partner Internal Users Dial in Web VPN Windows Citrix Telnet/FTP IAS Browser Dial in Router Firewall VPN Gateway PremierAccess Agent PremierAccess Agent PremierAccess Agent PremierAccess Agent PremierAccess Agent RADIUS Client RADIUS Client RADIUS Client PremierAccess Agent Data Data Data Applications Administrator PremierAccess controls access to your data and applications 2

15 Chapter 1: PremierAccess Overview An 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 35 in this guide. Figure 2: Product Overview Dial-in access using hardware token Dial-up router Web access control gateway Firewall and VPN gateway Internet Web server Access Point Messaging server VPN access using software token 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 Chapter 1: PremierAccess Overview Chapter 2: Administration Overview Chapter 3: Basic System Tasks Description Provides an overview of SafeWord PremierAccess. Provides an overview of the administrative tasks associated with PremierAccess. Provides detailed system task procedures. More... 3

16 Chapter 1: PremierAccess Overview An introduction to PremierAccess Chapter Title Chapter 4: Using the MobilePASS feature Chapter 5: Setting Up Access Controls Chapter 6: Managing User and Authenticator Information Chapter 7: Monitoring PremierAccess Activity Chapter 8: Maintaining PremierAccess Chapter 9: Managing the PremierAccess RADIUS Server Chapter 10: Managing the RADIUS Accounting Server Chapter 11: Managing the RADIUS Server for Ascend Chapter 12: Setting Up Web-based Enrollment Chapter 13: Troubleshooting Appendix A: PremierAccess in DoD PKI Environments Description Provides detailed information related to the MobilePASS software token application. Provides detailed procedures to customize PremierAccess. Provides detailed procedures for setting up personalization data, adding and importing users, and other tasks in PremierAccess. Describes how to monitor PremierAccess activity using its audit logs. Describes common PremierAccess maintenance tasks. Provides management information for the RADIUS Server. Provides management information for the RADIUS Accounting Server. Provides management information for the RADIUS Server for Ascend. Provides descriptions of the enrollment reservations process, which allows users to self-enroll via their Web browser. Provides troubleshooting and corrective action instructions for PremierAccess. Provides information about using PremierAccess within Department of Defense Public Key Infrastructure environments. More... 4

17 Chapter 1: PremierAccess Overview An introduction to PremierAccess Chapter Title Appendix B: Setting Up Plugins Glossary Index Description Provides information about the the Password Checker plugin and the Authentication Broker plugin. Defines PremierAccess- and networkingrelated terminology. Provides a cross-reference to important terms used in this guide. 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 Document PremierAccess Installation Guide for Solaris Authenticators Administration Guide SafeNet MobilePASS Software Administration Guide SafeNet MobilePASS User Guide Agent Administration Guide Description Provides specific information for installing the SafeWord PremierAccess product on Solaris operating systems. This document is available as a PDF at Describes the hardware tokens supported by SafeWord PremierAccess. This document is available as a PDF at Provides information about MobilePASS Software and Messaging tokens. This document is available as a PDF at www3.safenet-inc.com/safeword/docs/ swpa.aspx. Describes installing, upgrading, and running MobilePASS on mobile devices or desktop machines. This document is available as a PDF at safeword/docs/swpa.aspx. Describes the individual software modules (agents) supported by SafeWord PremierAccess. This document is available as a PDF from the SafeWord PremierAccess Agent Admn Guide. More... 5

18 Chapter 1: PremierAccess Overview An introduction to PremierAccess Document Card Programmer Software User Guide etoken Hardware Programmer Administrator s Guide Token Programmer Online Help Latest information about PremierAccess and other SafeNet network security products MobilePASS SDK SafeWord PremierAccess Administration SDK, version Description Describes the Windows menu-driven software that allows you to program SafeWord hardware tokens. This document is available by request. 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. Describes how to program the Alpine token. This document is available by request. 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. The SafeNet home page at Enables developers to embed MobilePASS functionality into a Java/J2ME application. The MobilePASS SDK is available at SafeWord PremierAccess MobilePASS SDK Enables developers to integrate SafeWord PremierAccess administration functions into other administrative systems. The SafeWord PremierAccess Administration SDK is available at SafeWord PremierAccess Administration SDK 6

19 Chapter 1: PremierAccess Overview The AAA solution 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 ), a password may be sufficient for access. However, for other users, who need access to more sensitive network resources, you may 7

20 Chapter 1: PremierAccess Overview The AAA solution 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 security policy: the authentication phase Phase 1 AAA Server Phases Authentication Are you who you claim to be? Phase 2 Authorization Phase 3 Accounting 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 116. 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. Figure 4: Your security policy: the authorization phase Phase 1 AAA Server Phases Authentication Are you who you claim to be? Phase 2 Authorization Are you allowed access to the requested Web or network resource? Phase 3 Accounting 8

21 Chapter 1: PremierAccess Overview The AAA solution 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 9

22 Chapter 1: PremierAccess Overview The AAA solution 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. 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. 10

23 Chapter 1: PremierAccess Overview The AAA solution Figure 5: Role to login ACL relationship Individuals or groups of users... can have multiple roles... that point to a login ACL... that contains entries which can map access restrictions to individual roles. J_Jones R_Cordrey H_Parsons M_West L_Barry J_May J_Gilbert F_Flores M_Gilbert J_McAbee Mmgt_staff Admin_staff Weekend_day Weekend_swing IT_staff Sales_server HR_server Company Login ACL ID Subj / Restrict Subj=Role: Management Restrict: Unrestricted Subj=Role: Administrative Restrict: M-F Subj=Role: IT_staff Restrict: Unrestricted Subj=IP: XX.XX Restrict: day/time K_Allison P_Wren H_Parsons R_Fowler Application_server 10 Subj=IP: XX.XX Restrict: Auth Strength 12 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. 11

24 Chapter 1: PremierAccess Overview The AAA solution 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. Figure 6: Your security policy: the accounting phase Phase 1 AAA Server Phases Authentication Are you who you claim to be? Phase 2 Authorization Are you allowed access to the requested Web or network resource? Phase 3 Accounting Pass or fail is recorded. 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. 12

25 Chapter 1: PremierAccess Overview Authenticating 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 , 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 67. 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. 13

26 Chapter 1: PremierAccess Overview Authenticating with tokens 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. 14

27 Chapter 1: PremierAccess Overview Authenticating 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. 15

28 Chapter 1: PremierAccess Overview SafeWord MobilePASS SafeWord MobilePASS MobilePASS software authenticators 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. 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 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. Figure 7: Authentication Options 16

29 Chapter 1: PremierAccess Overview SafeWord hardware tokens 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 SafeWordissued challenges into the token. SafeWord supports the following token types from SafeNet: SafeWord Gold etoken PASS SafeWord Alpine SafeWord Platinum SafeWord Silver 17

30 Chapter 1: PremierAccess Overview Component 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) Authentication Authorization and Accounting (AAA) Server 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 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 X More... 18

31 Chapter 1: PremierAccess Overview Component overview Component Function summary Core Opt. Admin Console (AC) Enrollment Server (ES) Web Login Server (WLS) 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 provides Web-based user selfenrollment allows enrolling users to test their authenticators once they have enrolled 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 X X More... 19

32 Chapter 1: PremierAccess Overview Component overview Component Function summary Core Opt. RADIUS-based servers Note: Optional servers used for VPNs and remote dial-in configurations. Authentication Broker plugin 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 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 X More... 20

33 Chapter 1: PremierAccess Overview Component overview Component Function summary Core Opt. MobilePASS allows users to generate passcodes from mobile devices and their Mac and Windows Desktops. (See MobilePASS software authenticators on page 16 for support details.) X MobilePASS Enrollment Portal Password Checker plugin allows users to enroll their software token device without administrative assistance allows a customer to further define what constitutes a valid fixed password for their organization X X Core and optional server components, and some of the agents available for use with the components are shown in Figure 8. 21

34 Chapter 1: PremierAccess Overview Component overview Figure 8: Core and optional components [Access points via PremierAccess agents] Universal Web Agent PAM agent [Access point via Dial-in/VPN] Terminal Services agent Windows Domain Login agent OWA. agent RADIUS client EASSP protocol RADIUS protocol PremierAccess System Web Server Web Login Server Enrollment Server Optional Admin Server Admin Console Authentication Server (AAA) Database Server Core components EASSP protocol RADIUS Server Auth. Broker Optional 22

35 Chapter 1: PremierAccess Overview Supported 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 Agent Universal Web Agent (UWA) SafeWord Agent for PAM SafeWord IAS/ NPS Agent Outlook Web Access Agent Agent for Web Interface Description 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. 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. 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. The Outlook Web Access (OWA) Agent works with the Microsoft Exchange Server to provide SafeWord strong authentication through the Microsoft Exchange OWA component. The Agent for Web Interface is the authentication component for use on the Citrix Web Interface server. 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. 23

36 Chapter 1: PremierAccess Overview User 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 Level Privileged Unprivileged System administrators Group administrators (local administrators and helpdesk staff) X X Regular users X 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. 24

37 Chapter 1: PremierAccess Overview User privileges and permissions Table 6: Privileged user types and permissions Privileged user type Privilege level Permissions System administrator Local administrator Helpdesk staff Highest level of permissions Middle level of permissions Lowest level of permissions Exercise all administrative tasks including: Modify system configurations (preferences) Backup and restore the database Create other administrative users Administer groups created by system administrator and assigned to them Administer data elements (users, tokens, roles, etc.) that reside in their assigned group hierarchy Modify specific segments of user records for groups and subgroups to which they are assigned 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. 25

38 Chapter 1: PremierAccess Overview Administrative 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. 26

39 Chapter 1: PremierAccess Overview Administrative groups 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

40 Chapter 1: PremierAccess Overview Administrative groups 28

41 2 CHAPTER Administration Overview In this chapter... Required administrative tasks...30 Optional administrative tasks...32 Usage scenarios

42 Chapter 2: Administration Overview Required 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 1 Starting the Admin Console 2 Creating a primary working account Overview and references The Admin Console (AC) is the main interface into the PremierAccess system. See Starting the Admin Console on page 45. 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 51. 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 102. More... 30

43 Chapter 2: Administration Overview Required administrative tasks Task 4 Creating a login ACL 5 Creating login ACL entries 6 Ordering ACL entries Overview and references 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 109. 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. 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 109. 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 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 110. 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 9 Assign roles to users PremierAccess provides several ways to bring users into the system. To add users manually, see Creating user accounts manually on page 137. To add users with the wizard, see Adding unprivileged users with the user wizard on page 148. To add users from a SafeWord 5.x database, see Adding and importing users on page 136. To import users from other SafeWord PremierAccess databases, see Backing up and restoring your user database on page 207. To allow self enrollment, see Understanding Webbased, user enrollment on page 272. 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. 31

44 Chapter 2: Administration Overview Optional 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 Task 1 Import token programming files and generate MobilePASS licenses Overview and references 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 47 and Generating and importing MobilePASS software tokens on page 63 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 challengeresponse 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 67. More... 32

45 Chapter 2: Administration Overview Optional administrative tasks Task 3 Create groups and subgroups Overview and references 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 108. 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 5 Create Web ACL entries 6 Add or modify authenticators 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 123. 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. 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. 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 152. 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... 33

46 Chapter 2: Administration Overview Optional administrative tasks Task 7 Configure the Password Checker plugins 8 Install the Authentication Broker Overview and references The Password Checker plugin is available for extending your authentication needs. For more information see: Using the Password Checker plugin on page 332. 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

47 Chapter 2: Administration Overview Usage 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: Strong authentication for a VPN connection Corporate Office Application Server VPN Gateway Remote Users Telecommuter VPN Client Authentication Server RADIUS Authentication Token Internet User Workstation Road Warrior VPN Client with MobilePASS 35

48 Chapter 2: Administration Overview Usage scenarios 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. 36

49 Chapter 2: Administration Overview Usage scenarios 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: Strong authentication for Web sites and their content Universal Web Agent (1) Public Pages (2) Employee Pages (3) Manager Pages Server Web Login Server Role Manager Employee Pages (1) (2) (3) (1) (2) 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. 37

50 Chapter 2: Administration Overview Usage scenarios 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 To set up this configuration: 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. 38

51 Chapter 2: Administration Overview Usage scenarios 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: Strong authentication to wireless LANS using tokens 1 RADIUS Wireless client with software such as Windows XP or Funk Odyssey EAP Authentication server running Cisco Secure ACS, Funk Odyssey or FreeRADIUS 2 Access Control Gateway RADIUS Firewall-like devices (Vernier Networks or Bluesocket for example) Web Browser Internal or external network 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. 39

52 Chapter 2: Administration Overview Usage scenarios Setting it up To set up this configuration: 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. 40

53 Chapter 2: Administration Overview Usage scenarios 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: Strong authentication with digital devices Enter phone passcode 82P16H + PIN Universal Web Agent Authorized Web pages and applications MobilePASS Digital phone, pager or PDA MobilePASS Wireless Service Provider passcode 82P16H Server Web Login Server Username Type of authenticator Token secret key Device address Authorized roles 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 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 To set up this configuration: 1 Install PremierAccess core servers. 2 Generate and import MobilePASS licenses. For more information about MobilePASS, see Chapter 4, Using the MobilePASS feature. 41

54 Chapter 2: Administration Overview Usage scenarios 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 Cisco devices with PremierAccess RADIUS Authentication Server LAN RADIUS Cisco Secure ACS Cisco Dialup Router Cisco Secure PIX Firewall 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 To set up this configuration: 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. 42

55 3 CHAPTER Basic System Tasks In this chapter... Using the Admin Console...44 Organizing authenticator files...47 Setting up and maintaining administrator accounts...49 Other basic tasks

56 Chapter 3: Basic System Tasks Using 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... 44

57 Chapter 3: Basic System Tasks Using the Admin Console Icon Function 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. 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. 45

58 Chapter 3: Basic System Tasks Using the Admin Console 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

59 Chapter 3: Basic System Tasks Organizing 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 63), 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 49. 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. 47

60 Chapter 3: Basic System Tasks Organizing 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 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. 48

61 Chapter 3: Basic System Tasks Setting 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 administrative users to have access to them. Using a RESERVED admin group lets you delegate the administrative duties of specific groups to specific administrators. 49

62 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts Figure 14: Admin console 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 104. 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

63 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts 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 New User 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 52. 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. 51

64 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts Figure 16: Pick roles window 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. 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 52. 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 55. 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. 52

65 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts 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 Serial Number 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 53

66 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts 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 63. 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 55. Figure 19: Serial number locations (back of authenticator) E 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 new user 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. 54

67 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts 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 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 139. Figure 21: Create a New User with Hardware Authenticator 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. 55

68 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts Figure 22: Edit Hardware 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 58. 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. 56

69 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts 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 57. 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 Fixed Password window Note: Since you are creating this password for yourself, clear this box, otherwise, you will be forced to change your password the next time you login. 57

70 Chapter 3: Basic System Tasks Setting up and maintaining administrator accounts 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 153. Table 10: Default fixed password profile attributes Fixed password profile name Strength Minimum password length Minimum password Age No. of warning days fixed 5 4 Never expires N/A Emergency (see note) 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. 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 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. 4 Re-enter the same password in the Confirm Password field. 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. 58

71 Chapter 3: Basic System Tasks Other 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 ACL entries 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

72 Chapter 3: Basic System Tasks Other 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. 60

73 4 CHAPTER Using the MobilePASS feature In this chapter... Understanding MobilePASS...62 Generating and importing MobilePASS software tokens...63 Configuring MobilePASS policies...67 Configuring MobilePASS features...78 Assigning software tokens to users...89 Software token enrollment

74 Chapter 4: Using the MobilePASS feature Understanding 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 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. 62

75 Chapter 4: Using the MobilePASS feature Generating and importing MobilePASS software tokens 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: MobilePASS Token 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. 63

76 Chapter 4: Using the MobilePASS feature Generating 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. 64 Activating MobilePASS seats MobilePASS seats are contained in the standard PremierAccess license file, key.html. This file contains your MobilePASS seat count information. By default, seats from the key.html license are the first seats that will be used at enrollment. If a seat is available at enrollment, a MobilePASS token record is created with a random serial number with the SF prefix, and a MobilePASS type subcode. Note: If the maximum number of seats are not defined in the key.html file, enrollment will revert to the legacy licensing model. To activate the key.html seats, do the following: 1 Locate the key.html file provided to you with your MobilePASS product. 2 Copy the file into the following location: /<install_dir>/servers/ AdminServer/activation. 3 Stop the Administration Server. 4 Stop the AAA Server.

77 Chapter 4: Using the MobilePASS feature Generating and importing MobilePASS software tokens 5 Restart the Administration Server. 6 Restart the AAA Server. 7 Launch the Administration Console, and then select Configuration > Activation. The Activation Information window appears. Figure 26: Activation Information window 8 The Activation Information window displays the MobilePASS Pooled Seat information. Click OK to close the window. Important: The Pooled licensing for MobilePASS seats does not create MobilePASS token records until activation time. Software authenticators will be added when users are associated. Using MobilePASS licensing and legacy licensing simultaneously Transient pooled authenticators are the software authenticators that become available when a key.html license is activated. Database record pooled authenticators are the records generated with legacy MobilePASS activations. Important: By default, MobilePASS uses the Transient MP Pooling seats first, and then uses the legacy MobilePASS authenticators (if available). 65

78 Chapter 4: Using the MobilePASS feature Generating and importing MobilePASS software tokens To use MobilePASS licensing and legacy licensing simultaneously, ensure the following: The key.html file is activated (see Activating MobilePASS seats on page 64). There is an entry with MobilePASS pooled seating information in the Activation Information window. Legacy MobilePASS tokens are generated and imported into the SafeWord database. Important: Once a token has been enrolled with the transaction signing feature, to disable the feature, the token must be reenrolled and the transaction signing feature left disabled. Disabling enrollment By default, PremierAccess uses the Transient MP Pooling seats first, and then, it uses the legacy MobilePASS authenticators (if available). When both sets of authenticators have been assigned, if a user attempts to enroll, the enrollment will fail. You may disable use of the Transient MP Pooling or use of the legacy MobilePASS authenticators. To disable either mechanism, do the following: 1 Locate the sccservers.ini file at <install_dir>/premieraccess/servers/ Shared. 2 Open the file using your preferred text editor. 3 Add one or both of the following lines to the file: DisableTransientMPPooling = true DisableDBRecordMPPooling = true Restart the AAA Server and the Administration Server. 66

79 Chapter 4: Using the MobilePASS feature Configuring 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. Important: 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 MobilePASS in order to generate passcodes. 67

80 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Figure 27: MobilePASS Policy Configuration window Defining policies Policies communicate the specific capabilities of a token between the MobilePASS clients and the MobilePASS portals and servers. To define policies, do the following: 1 Launch the Administration Console. 2 Select Configuration > MobilePASS Policy. The MobilePASS Policy Configuration window appears. There are no existing policies at this time. 3 The New policy button is selected by default. To create a new policy, leave the New button selected, and then specify a name for the policy. You may use Default as the name for your policy, or you may create a new name. 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 on page 69 provides specific policy parameters for each token type. Note: Standard policies include commonly used features and are easy to implement. Shorter policy strings are easier for users to enter, and may result in less user entry errors. Customized policies will lengthen the policy strings. 68

81 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Table 11: MobilePASS token types and capabilities Token Type Parameters Parameter Options Standard Event Sync Standard Time Sync Passcode Length Device PIN Length Use Attack Delay Use Attack Lockout Force Device PIN Change Allow Policy Downgrade Collect SoftPIN Passcode Length Device PIN Length Use Attack Delay Use Attack Lockout Force Device PIN Change Time Sync Interval Allow Policy Downgrade Collect SoftPIN 6 digits (fixed) 4 digits (fixed) Disabled (fixed) Enabled 10 (fixed) Disabled (fixed) Enabled or Disabled Enabled or Disabled 6 digits (fixed) 4 digits (fixed) Disabled (fixed) Enabled 10 invalid attempts (fixed) Disabled (fixed) 30 seconds (fixed) Enabled or Disabled Enabled or Disabled More... 69

82 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Token Type Parameters Parameter Options Standard Challenge Response Passcode Length Challenge Length Device PIN Length Use Attack Delay Use Attack Lockout Force Device PIN Change Allow Policy Downgrade Collect SoftPIN 8 digits (fixed) 8 (fixed) 4 (fixed) Disabled (fixed) 10 (fixed) Disabled (fixed) Enabled or Disabled Enabled or Disabled 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: a value between 3 and 20 invalid attempts Note: The number of attacks before lockout should always be greater than the number of attacks before an attack delay. More... 70

83 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Token Type Parameters Parameter Options Force Device PIN Change Enable or Disable When enabled, successful uses before device PIN change: 128, 256, or 384 Allow Policy Downgrade Collect SoftPIN Enabled or Disabled Enabled or Disabled Custom Time Sync Passcode Length 6 or 8 Time Sync Interval 20, 30, or 60 seconds Use Device PIN Enable or Disable 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. Use Attack Lockout Enable or Disable When enabled, attacks before lockout: a value between 3 and 20 invalid attempts Note: The number of attacks before lockout should always be greater than the number of attacks before an attack delay. Force Device PIN Change Enable or Disable When enabled, successful uses before device PIN change: 128, 256, or 384 More... 71

84 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Token Type Parameters Parameter Options Allow Policy Downgrade Collect SoftPIN Enabled or Disabled Enabled or Disabled Custom Challenge Response Passcode Length 6 or 8 Challenge Length 6 or 8 Use Device PIN Enable or Disable 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 Use Attack Lockout Enable or Disable When enabled, attacks before lockout: a value between 3 and 20 invalid attempts Note: The number of attacks before lockout should always be greater than the number of attacks before an attack delay. Force Device PIN Change Enable or Disable When enabled, successful uses before device PIN change: 128, 256, or 384 Allow Policy Downgrade Collect SoftPIN Enabled or Disabled Enabled or Disabled 72

85 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies 4 On the Policy Settings tab, 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 synchronous, time synchronous, and challenge response modes, see Authenticating with tokens on page Select a passcode length from the Passcode Length list. You may choose a six-digit or an eight-digit passcode. If you choose a standard policy, the length of passcode option is disabled, and the default setting displays. Note: Connected mode (transaction signing with automated challenge response) only allows eight-digit passcodes and eight-digit challenges. It does not allow six-digit passcodes or six-digit challenges. 6 (For custom challenge-response tokens only). Select a challenge length from the list. You may choose a six-digit or an eight-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 (For 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 are detected. Note: When secure mode is enabled, application updates may result in MobilePASS disabling clients that do not meet their defined security mode. 9 Transaction Signing provides the ability to encrypt and verify the integrity of online transactions for supported MobilePASS clients. Transaction signing is available on custom event synchronous, custom time synchronous, and custom challenge response tokens. Select the Enable Transaction Signing Mode check box to enable this feature. 10 Under PIN Options, do the following: SafeWord SoftPINs are optional PINs that administrators may require users set up when enrolling a token, and then append or prepend to the passcode when they authenticate. This is not the user s device PIN. Important: Using SoftPINs and transaction signing together is not recommended. a 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. 73

86 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies b c Device PINs 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 or device in order to generate passcodes. Select the Use Device PIN check box, and then select a PIN length from the PIN Length list (4, 6, or 8 digits). The attack delay feature allows you to set the number of invalid attempts that can be made before attack delay begins. Select the Use Attack Delay check box, and then select the number of attacks to allow before delay begins (2, 4, or 8 attacks). Note: The initial delay is one minute. The delay increases by one minute for each failed attempt. Delay reaches a maximum at 20 minutes, and resets only upon successful device PIN entry. d The attack lockout feature allows you to set the number of attacks before lockout. The number of attacks before lockout should always be greater than the number of attacks before an attack delay. Select the Use Attack Lockout check box to enable this feature, and then select the number of attacks before lockout occurs (a value between 3 and 20). Note: The attack lockout feature works on devices in disconnected mode (no transaction signing and basic challenge response), as well as on those in connected mode. e The Force Device PIN Change feature allows you to set the number of successful PIN uses before the device PIN must be changed. Select the Force Device PIN Change check box, and then select the number of successful uses before a change is required (128, 256, or 384). 74

87 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies 11 Select the Legacy Clients tab. Figure 28: Legacy Clients tab 12 If you are using client devices that do not support policies (MobilePASS version 8.0), and you wish to allow these devices to enroll and ignore the specified policy options, select the Allow enrollment to non policy-based clients check box. 13 If client devices accept policies (MobilePASS versions 8.1 and 8.2), but do not accept the attack lock values as specified for your policy (values other than 3, 6, or 10), to allow enrollment, select the Allow enrollment check box, and then select a value (3, 6 or 10) from the 8.1/8.2 Attacks before lockout list. 14 Click the Save button. You have finished creating policies for this token type. Configure another token policy, or close the window. 75

88 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Duplicating policies To duplicate an existing policy, do the following: 1 Launch the Administration Console. 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: 1 Launch the Administration Console. 2 Select Configuration > MobilePASS Policy. The MobilePASS Policy Configuration window appears. 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: 1 Launch the Administration Console. 2 Select Configuration > MobilePASS Policy. The MobilePASS Policy Configuration window appears. 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. 76

89 Chapter 4: Using the MobilePASS feature Configuring MobilePASS policies Deleting policies To delete a policy, do the following: 1 Launch the Administration Console. 2 Select Configuration > MobilePASS Policy. The MobilePASS Policy Configuration window appears. 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. 77

90 Chapter 4: Using the MobilePASS feature Configuring 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. These features should be configured before enrolling 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 93) Configure reenrollment (see Allowing reenrollment on page 87) 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 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 or higher 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 Port 5444 is available Command hostname yields the host name Command nslookup yields the FQDN, (fully qualified domain name) when given the host name Java Runtime Environment version should be installed in the environment where the MobilePASS Portal will be installed Note: Ensure JRE_HOME environment variable points to the correct JRE. Apache 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. 78

91 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features 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. Java 6 should be installed in the SafeWord PremierAccess environment Note: Ensure JAVA_HOME environment variable ponts to the location where you installed Tomcat. 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 ). 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. Note: For detailed instructions for upgrading or repairing an existing MobilePASS Portal installation, refer to the MPPortal_Patch_Only README.txt file. That document is available at <install_dir>/mpportal_patch_only/. 79

92 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features Configuring the user s maximum MobilePASS tokens SafeWord can be customized to allow up to ten (10) MobilePASS tokens per user. If users will not be self-enrolling MobilePASS tokens, see Configuring the MaxAuthenticators PD attribute in the Administration Console on page 80. If users will be self-enrolling with the MobilePASS Portal, see Configuring the MaxMPTokensAllowed value in smswebapp.ini on page 80. Configuring the MaxAuthenticators PD attribute in the Administration Console To configure the MaxAuthenticators PD attribute, do the following: 1 On the Administration Console, select Configuration > Personalization Data. The Personalization Data Configuration window appears. 2 Click the Add button, and then do the following: a Enter MaxAuthenticators in the Attribute field. b Specify the Allow any of the following values option. c Enter the desired number of authenticaors your users will be allowed (up to 10 total). 3 Click OK. MaxAuthenticators should now appear in the list of available attributes in the Personalization Data Configuration window. 4 Restart the Administration Server and the AAA Server. 5 Close and reopen the Adminstration Console. Important: Each time the value of the MaxAuthenticators PD attribute is changes, you must restart the Administration Server and the AAA Server, and then close and reopen the Administration Console for the changes to take effect. Note: The MaxAuthenticators PD attribute is a global attribute. It does not need to be assigned to users or roles individually. Configuring the MaxMPTokensAllowed value in smswebapp.ini To configure the MaxMPTokensAllowed value, 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. 80

93 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features 3 Add the following line to the file, including the chosen number of tokens you wish to allow users to enroll (The maximum token value is 10.): MaxMPTokensAllowed=[a value between 1 and 10] Important: When you specify token values in the smswebapp.ini file, you must also specify the same values in the Administration Console. See Configuring the MaxAuthenticators PD attribute in the Administration Console on page 80 for details. 4 MobilePASS reenrollment is only available when users are assigned one (1) MobilePASS token. To ensure the MaxMPTokensAllowed feature works, if the AllowedToReenroll line is present in the smswebapp.ini file, set the value to false or remove the line completely. 5 Save and close the file. 6 Restart the MobilePASS Tomcat server. To allow users with multiple tokens assigned to them to use any of their tokens, you must configure an AllowAnyToken personalization data attribute for those users. See Configuring the AllowAnyToken PD attribute on page 81 for details. Configuring the AllowAnyToken PD attribute When a user has more than one token assigned to them, the AllowAnyToken Personalization Data attribute allows that user to authenticate with any of the tokens, regardless of the order of those tokens in the user s record. Important: If a fixed password will be used with other tokens, the fixed password must be listed first in the list of tokens in the user s record in order for the AllowAnyToken feature to work. Important: If challenge response tokens are used, they must all be programmed with the same values (for example, a six character challenge length and an eight character password length) in order for the AllowAnyToken feature to work. 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. 81

94 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features 6 Click OK. 7 Select Insert > Role. 8 Name the new role AnyTokenUsers. 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. Note: The AllowAnyToken PD attribute is not global. It must be added to each user or group individually. 82

95 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features 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 file (see Configuring the Admin Console to collect device nicknames on page 83) and the smswebapp.ini file (see Configuring the MobilePASS Portal to collect device nicknames on page 83) 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 84 or Collecting device nicknames (user-driven enrollment) on page

96 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features Figure 29: Select Device Name 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. Important: The following characters cannot be used in device nicknames for the Administration Console or the MobilePASS Portal: =<>+,;* \ \\. 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. 84

97 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features Figure 30: Actions Performed 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 explaining how to manually enroll and name their token device. 85

98 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features Figure 31: Software Token Enrollment window 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 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 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. Important: The following characters cannot be used in device nicknames for the Administration Console or the MobilePASS 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.

99 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features 12 Return to the token device and click the Confirm Now button. 13 (Conditional) Enter and reenter a Device PIN. 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 88.) To set up reenrollment, 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 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. 6 Save and close the file. 7 Restart the MobilePASS Tomcat server. Note: When a token is reenrolled, the same serial number is assigned to that token as was previously assigned. 87

100 Chapter 4: Using the MobilePASS feature Configuring MobilePASS features 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 directory>/webapps/portal/web-inf/conf. 2 Open the file using your preferred text editor. 3 Locate the DeleteEnrollmentPassphrase line, and set the parameter to false. 4 Save and close the file. 5 Restart the MobilePASS Tomcat server. 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. 2 Open the file using your preferred text editor. 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. 88

101 Chapter 4: Using the MobilePASS feature Assigning software tokens to users Assigning software tokens to users You may choose to assign software tokens to users via the Administration Console, or you may allow users to self-enroll their software tokens using the MobilePASS Enrollment Portal. When a user is set up to self-enroll, they may choose to enroll manually or automatically from their mobile devices. To assign MobilePASS software tokens to users do the following: 1 Launch the Administration Console. 2 Select Tools > MobilePASS Enrollment, or highlight the user name, rightclick on it, and then select MobilePASS Enrollment. The MobilePASS Enrollment window appears. Figure 32: MobilePASS Enrollment window 3 If you will be enrolling your users, continue to Enrolling users with the Administration Console on page 89. If you are allowing users to self enroll, skip to Allowing users to self-enroll with the Enrollment Portal on page 93. Note: Your SafeWord product also provides pre-enrollment configuration and enrollment expiration options via the Administration SDK. The Administration SDK and the PremierAccess addendum named MobilePASS Enrollments and the Administration SDK are included with the PremierAccess product. 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 c d Click the Enroll Now button. Select a policy to apply to this user s token from the Token Policy list. Click the Next button. The Enter Policy String window appears. 89

102 Chapter 4: Using the MobilePASS feature Assigning software tokens to users Figure 33: Enter Policy String window Figure 34: Activation Code 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. 8 Return to the Administration Console, and then click the Next button. The Enter Activation Code window appears. 90

103 Chapter 4: Using the MobilePASS feature Assigning software tokens to users Figure 35: Enter Activation Code window 9 Enter the Activation Code from the device into the Activation Code field, and then click the Next button. Figure 36: Confirmation windows 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

104 Chapter 4: Using the MobilePASS feature Assigning software tokens to users Figure 37: Enter a device PIN window Figure 38: Successful Activation window 11 If prompted, enter a 4-digit device PIN, re-enter the same device PIN, and then click the Set PIN button. 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. 92

105 Chapter 4: Using the MobilePASS feature Assigning software tokens to users Allowing users to self-enroll with the Enrollment Portal 1 If you will allow users to self-enroll, do the following: a b c d e From the Administration Console, select Tools > MobilePASS Enrollment. The MobilePASS Enrollment window appears. 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. Click the User will self-enroll button. Select a policy to apply to this user s token from the Token Policy list. Click the Next button. The Enrollment Passphrase window appears. Note: The passphrase must be at least four (4) characters in length. Figure 39: Enrollment Passphrase 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 40: Enrollment Status - Pending window 93

106 Chapter 4: Using the MobilePASS feature Assigning software tokens to users 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 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 80 and Allowing reenrollment on page 87 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 88. If you wish to allow users to reenroll their MobilePASS token, refer to Allowing reenrollment on page 87. If you wish to allow users to reenroll their MobilePASS token, refer to Allowing reenrollment on page 87. 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

107 Chapter 4: Using the MobilePASS feature Assigning software tokens to users Disabling the software token enrollment feature To disable the software token enrollment feature, do the following: 1 Locate the smswebapp.ini file. It can be found at <tomcat install directory>/webapps/portal/web-inf/conf. 2 Locate the following line: DisableSoftwareTokenEnrollment 3 Set the parameter to true. 4 Save and close the file. 5 Restart the MobilePASS Tomcat server. Disabling software token manual enrollment To disable software token manual enrollment, 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 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. 5 Save and close the file. 6 Restart the MobilePASS Tomcat server. 95

108 Chapter 4: Using the MobilePASS feature Software 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 ( portal/enroll). The default MobilePASS port is If this is a new installation, the Admin Credentials window appears (Figure 41 on page 96) 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 42 on page 97). In this case, skip to step 3. Figure 41: Change Default Admin Server Credentials window 96

109 Chapter 4: Using the MobilePASS feature Software token enrollment 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 42: Update Admin 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 43: MobilePASS Portal Restart Services window 97

110 Chapter 4: Using the MobilePASS feature Software token enrollment 6 Restart the MobilePASS Portal service using the following commands: <tomcat_install_dir>/bin/shutdown.sh <tomcat_install_dir>/bin/startup.sh 98

111 Chapter 4: Using the MobilePASS feature Software token enrollment 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 portal/enroll. The SafeWord Software Token Enrollment page appears. By default, port 5444 is used. Figure 44: Preauthentication 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 45: Activation Code 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. 99

112 Chapter 4: Using the MobilePASS feature Software token enrollment Figure 46: Test Software Token window 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 47: Token Test Results windows 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. A. Failed Token Test window 100 B. Successful Token Test window 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.

113 5 CHAPTER Setting Up Access Controls In this chapter... Editing the PremierAccess configuration Working with admin groups, ACLs and roles Implementing your access control policy Understanding Web ACLs

114 Chapter 5: Setting Up Access Controls Editing 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 AAA clears attack locked account Clear lockout after (min) Agent polling interval (min) Max search results Unregistered User ID Default Role Default Login ACL Use verbose logging Sets the number of unsuccessful authentication attempts before the user is locked out of the system. This protects your users from brute force attacks. Clears an account that was locked as a result of a brute force attack. 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. Sets the time interval with which the UWA will poll the AAA Server for updates to Web ACLs. Large search results will be returned in batches of this size. The console will feel more responsive with a lower batch size. The username under which authentication will proceed if an invalid username is supplied. Changing these values is not recommended. System default -- points to the default ACL. This value is customizable. System default -- no restrictions. This value is customizable. 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

115 Chapter 5: Setting Up Access Controls Editing the PremierAccess configuration Tab Field Function Sessions Session Duration Timeout (Number of hours/ minutes) Session Inactivity Timeout (Number of hours/ minutes) Sets the maximum time limit for user sessions in hours and minutes. Sets the time limit before automatic logoff for inactive user sessions in hours and minutes. 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 48: Edit PremierAccess Configuration window (General tab) ) 103

116 Chapter 5: Setting Up Access Controls Editing the PremierAccess configuration 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. 104 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.

117 Chapter 5: Setting Up Access Controls Editing the PremierAccess configuration 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 list (ACL). ACLs are a collection of access rules that are defined for a set of protected resources. 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. 105

118 Chapter 5: Setting Up Access Controls Editing the PremierAccess configuration Figure 49: Edit PremierAccess 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. Figure 50: Edit PremierAccess Configuration window (Sessions tab) 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. 106

119 Chapter 5: Setting Up Access Controls Editing the PremierAccess configuration 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. 107

120 Chapter 5: Setting Up Access Controls Working 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 51), the parent group is identified in the Parent Group field. Figure 51: Create a New Admin 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. 108

121 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 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 52: Create a new Login 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 112. To create roles to assign to users, refer to Creating roles on page

122 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 109. 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. 110

123 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles Figure 53: Create a new role (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 105), will be used. Note: The Personalization Data tab is discussed in Understanding personalization data on page 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 170. Otherwise your new role is complete. 6 Click OK to create the role. 111

124 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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. 112 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 113. To define restrictions for this ACL entry, refer to Defining entry restrictions on page 114. To specify return values for an entry, see Specifying return values for an entry on page 118. 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.

125 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 113. To define restrictions for this ACL entry, refer to Defining entry restrictions on page 114. To specify return values for an entry, see Specifying return values for an entry on page 118. 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 54: New ACL Entry 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 114, 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. 113

126 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 * or ). 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 118. 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

127 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles Click Grant access if the user meets these restrictions to define restrictions. The Minimum Authentication Strength restriction is automatically selected. Figure 55: New ACL entry (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 116. 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 56: Edit restriction 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 152. By setting authenticator strengths for protected resources you can predetermine what type or combination of authenticators will be required for access to those resources. 115

128 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 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. 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. 116

129 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles Figure 57: Range of dates 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 117. 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 58: Day/Time Restrictions window (with example M-F ) 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 118. 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 The entire field of access time will highlight in green. Click OK to set your time choices. 117

130 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles Figure 59: New ACL Entry (Return tab) Specifying return values for an entry To specify return values for this entry, from the New ACL Entry window click the Return tab. 118 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 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 c d 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 ). Select an attribute from the Personalization Data list. If the user has this personalization data defined, it will be returned to the agent. Select PremierAccess Roles to return the user s PremierAccess role(s) upon either successful or failed authentication.

131 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 60: ACL window with entry When you create additional entries, each one will be assigned an incremental number. Editing ACL entries To edit an ACL entry, select Find -> ACLs -> Login. The Find Login ACL entries window appears. Figure 61: Find ACL entries 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. 119

132 Chapter 5: Setting Up Access Controls Working with admin groups, ACLs and roles 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 113. 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. 120

133 Chapter 5: Setting Up Access Controls Implementing 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. 121

134 Chapter 5: Setting Up Access Controls Implementing 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. 122

135 Chapter 5: Setting Up Access Controls Understanding 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. 123

136 Chapter 5: Setting Up Access Controls Understanding Web ACLs 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 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 Figure 62: Create a New Web ACL window 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. 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. 124

137 Chapter 5: Setting Up Access Controls Understanding Web ACLs Figure 63: New Web ACL 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 127, 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 64: Add URL window (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 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. 125

138 Chapter 5: Setting Up Access Controls Understanding Web ACLs Figure 65: Protected URLs HTTP Methods panel 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 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 127. 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 Activates method buttons (click all that apply) 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 126

139 Chapter 5: Setting Up Access Controls Understanding Web ACLs 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 specified HTTP request methods. GET, POST, and HEAD are the most commonly 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 131. 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 127. 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. 127

140 Chapter 5: Setting Up Access Controls Understanding Web ACLs Figure 66: New Web ACL Entry (Restrictions tab) Figure 67: Allowed roles window 1 Click the Edit button. The Edit Restriction window appears. 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. 128

141 Chapter 5: Setting Up Access Controls Understanding Web ACLs Figure 68: Minimum authentication 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. 1 Click Enabled to activate the window. Figure 69: Web browser IP 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. 129

142 Chapter 5: Setting Up Access Controls Understanding Web ACLs 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 * or ). Figure 70: Time of day window 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. 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. 130

143 Chapter 5: Setting Up Access Controls Understanding Web ACLs 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. 1 Click Enabled to activate the window. Figure 71: Date range window 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 72: New Web ACL Entry (Personalization tab) 1. Select Web Application or Web Browser 3. Optional 2. Check to enable fields below, or clear to disable fields below 4. Select one 5. Activates available fields 131

144 Chapter 5: Setting Up Access Controls Understanding Web ACLs 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

145 Chapter 5: Setting Up Access Controls Understanding Web ACLs 6 Click OK. The window appears with the Web ACLs listed in the box. Figure 73: New Web ACL 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. 133

146 Chapter 5: Setting Up Access Controls Understanding Web ACLs 134

147 6 CHAPTER Managing User & Authenticator Information In this chapter... Understanding users and access levels Adding and importing users Adding, changing or removing authenticators Adding or changing authenticator profiles Assigning role(s) to multiple users Importing user records from a third-party user database Deleting a user record Resetting a locked account Understanding personalization data Personalizing your Web applications Session management

148 Chapter 6: Managing User & Authenticator Information Understanding users and access levels Understanding users and access levels Adding and importing users 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. 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 272 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 207 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. 136

149 Chapter 6: Managing User & Authenticator Information Adding 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 74: Advanced Create 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 highestlevel 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. 137

150 Chapter 6: Managing User & Authenticator Information Adding and importing users Figure 75: Create a new user window, Authenticators tab Assigning authenticators to a user To assign an authenticator to a user, from the Create a New User window, click the Authenticators tab. Figure 76: Enter Serial Number window 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 139. Pick authenticator to assign a hardware token or software authenticator. The Enter Serial Number window appears. 138 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".

151 Chapter 6: Managing User & Authenticator Information Adding and importing users 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. Figure 77: Enter a Fixed Password window 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. 139

152 Chapter 6: Managing User & Authenticator Information Adding and importing users 2 Re-enter the same password in the Confirm Password field. 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. 140

153 Chapter 6: Managing User & Authenticator Information Adding and importing users 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 78: Create a New User 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. 141

154 Chapter 6: Managing User & Authenticator Information Adding and importing users Figure 79: Enter an Alias window 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. 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 80 displays the unprivileged user level. 142

155 Chapter 6: Managing User & Authenticator Information Adding and importing users Figure 80: Create a New User, 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 144. If your user is a local administrator, choose Local administrator, then refer to Defining privileges for local administrators on page 145. If your user is a system administrator, choose System administrator, then refer to Defining system administrator privileges on page

156 Chapter 6: Managing User & Authenticator Information Adding and importing users Figure 81: Helpdesk staff privilege settings 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 81 displays the privilege selections available for helpdesk staff. 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 144

157 Chapter 6: Managing User & Authenticator Information Adding and importing users 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 82 displays privilege settings for local administrators. Figure 82: Local administrator 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 145

158 Chapter 6: Managing User & Authenticator Information Adding and importing users 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. Figure 83: System administrator privilege settings 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 83 shows system administrator level with the full range of privileges. 146

159 Chapter 6: Managing User & Authenticator Information Adding and importing users 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 171. 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 84: Create a New User window (Personalization data tab) Adding an element To add an element to a users record, click the Add button. Figure 85: Add attribute value window 147

160 Chapter 6: Managing User & Authenticator Information Adding and importing users 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 When you are finished, click OK. 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. Figure 86: Enter a Username window 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 nonglobal group into which you want to add a user, then do the following: 1 Select Insert -> User with wizard Enter the new user s user ID in the User field. 3 Click Next. The Select an Authenticator Type window appears.

161 Chapter 6: Managing User & Authenticator Information Adding and importing users Figure 87: Select an authenticator 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. Figure 88: Enter a Fixed Password window Leave this box checked so the user must designate their own fixed password when they log in. 7 Enter a password for this user in the Fixed Password field, then re-enter the same password in the Confirm Password field. 149

162 Chapter 6: Managing User & Authenticator Information Adding and importing users Figure 89: Select an Admin Group window 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 90: Assign roles window 9 When the Select an Admin Group window appears, select the non-global group to which this user will be assigned from the Admin Group list. 10 Click Next. The Assign Roles window appears. 150

163 Chapter 6: Managing User & Authenticator Information Adding and importing users 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 164. 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 91: Add User Roles 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. 151

164 Chapter 6: Managing User & Authenticator Information Adding, 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 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 52 for further details. Select Add password to add another fixed password. Refer to Assigning a password to the default account on page 57 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. 152

165 Chapter 6: Managing User & Authenticator Information Adding 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 92: Edit Fixed Password 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

166 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles Figure 93: Fixed Password Profile (Configure tab) 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 userfriendly 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. 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. 154

167 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles 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 94: Create a New Digital Certificate Profile window (General tab) 155

168 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles 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 116. 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 diskheld 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. 156

169 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles Figure 95: Create a New Digital Certificate Profile window (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. 157

170 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles Figure 96: Choose Certificate 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. Figure 97: Create a new digital certificate profile (Policies tab) 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. Certificate Verification area 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.

171 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles 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 b 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. 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 certificates may need to be revoked before they expire. To revoke certificates without waiting for a CRL, see Revoking digital certificates on page (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. 159

172 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles Figure 98: Create a New Digital Certificate Profile window (Verification 2 tab) 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 277. 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. 160

173 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles 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 software and hardware authenticator profiles This section describes how to modify software and hardware authenticator profiles. You cannot create authenticator profiles. They are created as tokens, and imported using the Admin Console. Tip: We recommend you only modify the authentication strength values of authenticator profiles. To modify the authentication strength value of an existing software or 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 if your are modifying a hardware token, or the Edit Token Profile window if you are modifying a software authenticator. The profile name is displayed in the Profile field. 161

174 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles Figure 99: Edit Hardware Authenticator/ Edit Token Profile window 3 Set the Authenticator Strength for this profile. Authenticator strength sets the numerical value for this authenticator type, which can be used by the AAA Server to determine whether sufficient strength exists to access a resource protected by a fixed numerical strength. Note: Default authenticator strength values are listed in Table 13 on page 116. For information about modifying strength values globally so they work with strength login access control lists (ACLs), see Modifying software and hardware authenticator profiles on page 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 sooner. 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.).

175 Chapter 6: Managing User & Authenticator Information Adding or changing authenticator profiles 6 Enter any supportive or defining comments in the Comments field. 7 Click the Configure tab (hardware authenticators only). The configuration settings for this profile appear. Figure 100: Edit Hardware Authenticator (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. 163

176 Chapter 6: Managing User & Authenticator Information Assigning 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 101: Admin console 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 102: Select Users window 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. 164

177 Chapter 6: Managing User & Authenticator Information Assigning 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 103: Choose Roles 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. 165

178 Chapter 6: Managing User & Authenticator Information Importing 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 104: Import File Location 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. 166

179 Chapter 6: Managing User & Authenticator Information Importing user records from a third-party user database Figure 105: Import User: Select Role(s) window 5 Select a role(s) to give to your imported users from the Available Roles 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 click No 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 106: Admin console 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 PremierAccess. 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 167

180 Chapter 6: Managing User & Authenticator Information Deleting a user record Enrollment Server, you need to create a reservation for users. For information on creating enrollment reservations, see Chapter 12, Setting Up Webbased 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 107: Find User entries with username 2 Click Find. The Find results: User entries window appears with the requested username listed. Figure 108: Find results window 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. 168

181 Chapter 6: Managing User & Authenticator Information Resetting 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 103 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 59. 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 109: Search results 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

182 Chapter 6: Managing User & Authenticator Information Understanding 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. 170

183 Chapter 6: Managing User & Authenticator Information Understanding personalization data 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 110: Personalization Data Configuration window 1 To add a personalization data attribute, click the Add button. Figure 111: Create a new 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 language preferences of each user on their user records. 171

184 Chapter 6: Managing User & Authenticator Information Understanding personalization data Figure 112: Adding values to attributes 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. 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. 172

185 Chapter 6: Managing User & Authenticator Information Understanding personalization data Figure 113: Listed data attributes 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. 173

186 Chapter 6: Managing User & Authenticator Information Personalizing 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 114, the UWA modifies the incoming request before sending it to the server side Web application. 174

187 Chapter 6: Managing User & Authenticator Information Personalizing your Web applications Figure 114: Personalization data delivery to Web applications Popular Web browser Client-side Web application support JVM: applet support and JavaScript engine HTTP request (with session ID) Modified HTTP response (includes personalization data) Universal Web Agent Authorizes access with the help of a Web ACL and session data Modified HTTP request (includes personalization data) HTTP response UWA-protected popular Web/ application server Server-side Web application support Servlets JSP, ASP ASP, SSI, etc... CGI 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. 175

188 Chapter 6: Managing User & Authenticator Information Personalizing your Web applications Figure 115: HTTP request or response message Modified HTTP Request 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 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 Header name SafeWord-User SafeWord-Authorization Header value Franz Engineer, Team Leader SafeWord-Employee-number 2112 SafeWord-Language-preference German SafeWord-Department 23 The UWA converts certain characters in different ways depending upon where they are used. Table 15 displays the varying treatment of these characters. 176

189 Chapter 6: Managing User & Authenticator Information Personalizing your Web applications Table 15: Treatment of spaces, dashes, and underscores in the UWA. Character Personalizatio n data name HTTP header name CGI environment variable name Space (" ") Space (" ") Dash ("-") Underscore ("_") Dash ("-") Dash ("-") Dash ("-") Underscore ("_") Underscore ("_") Underscore ("_") Underscore ("_") Underscore ("_") 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. 177

190 Chapter 6: Managing User & Authenticator Information Personalizing your Web applications 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 database, 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 f g h i j k l The AAA Server collects all relevant personalization data about the user and stores it in the user s new session. The WLS redirects the user back to the originally requested Web service. The UWA intercepts the request, but detects that the user has authenticated. The UWA authorizes the user based on rules defined in its Web ACL. 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. The Web ACL instructs the UWA only to pass the Language-Preference element to the server-side Web application. 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. 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. 178

191 Chapter 6: Managing User & Authenticator Information Personalizing your Web applications 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 application. The UWA will not pass any role information or generic personalization 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. 179

192 Chapter 6: Managing User & Authenticator Information Personalizing your Web applications 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 e f g h i The user strongly authenticates using PremierAccess with his strong authenticator. The AAA Server collects all relevant personalization data about the user, and stores it in the user s new session. The WLS redirects the user back to the originally requested Web application. The UWA intercepts the request, but detects that the user is authenticated. The UWA authorizes the user based on rules defined in its Web ACL. 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. 180

193 Chapter 6: Managing User & Authenticator Information Session 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 116: Find Session 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 117: Find Results: Session Entries window 181

194 Chapter 6: Managing User & Authenticator Information Session management Figure 118: View Session window 3 Double-click the desired session. The View Sessions window appears. 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. 182

195 7 CHAPTER Monitoring PremierAccess Activity In this chapter... Understanding audit logs Troubleshooting with the Audit Log Monitor Generating reports from the Admin Console Generating reports from the command line Exporting data into Excel worksheets

196 Chapter 7: Monitoring PremierAccess Activity Understanding 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 Performed by Function 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

197 Chapter 7: Monitoring PremierAccess Activity Understanding audit logs Search Parameter Filter Authentication status Admin Group Logins where role Database entry Function 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. Use this filter to narrow down the authentication and administration activity specific to a particular admin group. 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. 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. 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 119: Find Audit Log entries window 1 Select Find all available, or refine your search using the search filters. 185

198 Chapter 7: Monitoring PremierAccess Activity Understanding audit logs Figure 120: Find Specific Audit Log entries 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 121: Find Results: Audit Log Entries window 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. The Find Results: Audit Log Entries window appears with the user s authentication activity for the specified period. 186

199 Chapter 7: Monitoring PremierAccess Activity Understanding audit logs 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 122: View Specific Audit Log entry summary screen 187

200 Chapter 7: Monitoring PremierAccess Activity Troubleshooting 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 123: Monitor Audit Log Entries window 188

201 Chapter 7: Monitoring PremierAccess Activity Troubleshooting 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 124 demonstrates how you would configure the Audit Log Monitor to display the authentication activity of user Jerry. Figure 124: Configuring the Audit Log Monitor to display specific user s authentication 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. 189

202 Chapter 7: Monitoring PremierAccess Activity Generating 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). 190

203 Chapter 7: Monitoring PremierAccess Activity Generating reports from the Admin Console 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 125: The Report Definition 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. 191

204 Chapter 7: Monitoring PremierAccess Activity Generating reports from the Admin Console Figure 126: Filter Details window 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 126 shows the details of a report template that fetches all authentication audit logs, users and authenticators in an admin group called Pacific. 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. 192

205 Chapter 7: Monitoring PremierAccess Activity Generating reports from the Admin Console 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 For example, if you export audit logs during the report generation process, the first 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. weeklylogs_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. 193

206 Chapter 7: Monitoring PremierAccess Activity Generating 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 194 details the variables that are defined in both versions of the shell script. Table 17: Shell script variables Variable Name ADMIN_HOST ADMIN_PORT ADMIN_USER ADMIN_PASSWO RD Purpose Specify the IP address or hostname of the machine on which the PremierAccess Admin Server is installed Specify the port number on which the PremierAccess Admin Server is listening. (By default, this port number is 5040.) 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. 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. 194

207 Chapter 7: Monitoring PremierAccess Activity Generating 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 192 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/alllogs.tpl reports/all-logs.xls mypassword 195

208 Chapter 7: Monitoring PremierAccess Activity Exporting 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 127 shows the Export button on the Find Users window. Figure 127: Export Button 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. 196

209 8 CHAPTER Maintaining PremierAccess In this chapter... Understanding audit log archives Replication and fault tolerance Optimizing archiving, authentication, and replication performance Backing up and restoring your user database Repairing invalid entries Managing the Admin and AAA Server keys

210 Chapter 8: Maintaining PremierAccess Understanding 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 128: Manage Audit 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. 198

211 Chapter 8: Maintaining PremierAccess Understanding audit log archives 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. 199

212 Chapter 8: Maintaining PremierAccess Understanding audit log archives Figure 129: Manage Audit Log Archive window with archived log 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. 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. 200

213 Chapter 8: Maintaining PremierAccess Understanding audit log archives 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 ArchiveWorkerThreads=20 ArchiveLogsInBatch=50 Function 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. Controls the number of logs in a batch per thread. Recommended Setting Parameter 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. Optimum values will vary from system to system, but a range of 20 to 100 logs is reasonable. 201

214 Chapter 8: Maintaining PremierAccess Replication 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 130. Figure 130: Multiple peer replication Previous Next Next Previous Previous Next Next Previous If there are only two replication peers in the ring, each will only have a Next replication peer neighbor as shown in Figure 131. Figure 131: Two peer replication Next Next 202

215 Chapter 8: Maintaining PremierAccess Replication 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. 203

216 Chapter 8: Maintaining PremierAccess Optimizing 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= 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. 204

217 Chapter 8: Maintaining PremierAccess Optimizing archiving, authentication, and replication performance 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 improve replication 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. 205

218 Chapter 8: Maintaining PremierAccess Optimizing archiving, authentication, and replication performance 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. 206

219 Chapter 8: Maintaining PremierAccess Backing 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 132: Backup Database 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. 207

220 Chapter 8: Maintaining PremierAccess Backing up and restoring your user database Figure 133: Export completed dialog box 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. 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. Figure 134: Restore Database window 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. 208

221 Chapter 8: Maintaining PremierAccess Backing up and restoring your user database 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. 209

222 Chapter 8: Maintaining PremierAccess Repairing 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 135: Entries with Invalid Signatures window Select the entry ID requiring repair, then click Repair. A summary window appears with the details for this signature. Figure 136: View User window 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

223 Chapter 8: Maintaining PremierAccess Managing 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 resign 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. 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 # To change the Admin Server key, modify this value SccAdminServer, DES, SccAuthServer, DES, dbcipher, 3DES, 1234abcd4321dcba To change the AAA Server key, modify this value dbcipher, DES, 1234abcd 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. 211

224 Chapter 8: Maintaining PremierAccess Managing the Admin and AAA Server keys 212

225 9 CHAPTER Managing the PremierAccess RADIUS Server In this chapter... Overview of the PremierAccess RADIUS Server Prerequisites PremierAccess RADIUS configuration files Authorization and configuration groups Authenticators Troubleshooting common problems Diagnostic traces during correct operation Diagnostic traces with incorrect configuration References

226 Chapter 9: Managing the PremierAccess RADIUS Server Overview 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, 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. 214

227 Chapter 9: Managing the PremierAccess RADIUS Server Overview of the PremierAccess RADIUS Server 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 configuration 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 mechanism 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 specific person every time he or she is attached to the Internet. The PremierAccess 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-Specific Attributes (VSAs) in accordance with the provisions of RFC VSAs allow vendors of routers, communication servers, or other RADIUScompatible clients to take full advantage of the unique features of their equipment. Under the provisions of the current RADIUS protocol, any vendor 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 RADIUScompliant 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. 215

228 Chapter 9: Managing the PremierAccess RADIUS Server Overview of the PremierAccess RADIUS Server 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. 216

229 Chapter 9: Managing the PremierAccess RADIUS Server Prerequisites 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 the PremierAccess 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 registered in the PremierAccess User database. Users must be registered in the PremierAccess database if the Authentication Broker is not going to be used. 217

230 Chapter 9: Managing the PremierAccess RADIUS Server PremierAccess 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 153), or add a RADIUSspecific entry to an existing ACL (see Understanding login ACL entries on page 112). 1 Create a role for this set of users (see Creating roles on page 110). 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. 218

231 Chapter 9: Managing the PremierAccess RADIUS Server Authorization 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 258 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. 219

232 Chapter 9: Managing the PremierAccess RADIUS Server Authorization and configuration groups 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 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 will be interpreted as the PremierAccess-compatible user name. Any text to the right of 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 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 , for the user Bob@NYC, NYC is the realm. Packets will be forwarded to the IP address on the port (taken from the users file) of It is possible to proxy to other RADIUS servers running on a different port. To enable this, the clients file is consulted. 220

233 Chapter 9: Managing the PremierAccess RADIUS Server Authorization and configuration groups Table 19: Sample client file entries IP [:port] Keyword [NAS: PROXY] NAS MySecret PROXY :1812 TooManySecrets PROXY 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 communicates directly with the originating RADIUS client. The middle RADIUS Servers simply forward RADIUS requests to the next member of the chain 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. Therefore, 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. 221

234 Chapter 9: Managing the PremierAccess RADIUS Server Authenticators 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 137. 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. 222

235 Chapter 9: Managing the PremierAccess RADIUS Server Authenticators 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. 223

236 Chapter 9: Managing the PremierAccess RADIUS Server Authenticators 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,23E4A7 Password: password

237 Chapter 9: Managing the PremierAccess RADIUS Server Authenticators Example 2: Enter the dynamic and the memorized in the password field: Username: <name> Password: <dynamic>,<fixed> Username: Fred Password: 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. 225

238 Chapter 9: Managing the PremierAccess RADIUS Server Authenticators 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 RADIUSencapsulated, 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. 226

239 Chapter 9: Managing the PremierAccess RADIUS Server Troubleshooting 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: 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: 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 For EASSP 201, use port 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. 227

240 Chapter 9: Managing the PremierAccess RADIUS Server Troubleshooting common problems 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 information Bit 14 displays information during CSP device authentication Bit 13 displays information during RADIUS proxying Bit12= Display audit information for accounting purposes Bit11= Display debug messages in Vendor-Specific areas Bit10= Display debug messages in user exits areas Bit 9= Display timestamps as RADIUS request packets arrive Bit 8= Display important trace info. in Authorization areas Bit 7= Display incoming RADIUS packet summary Bit 6= Display outgoing RADIUS packet summary Bit 5= Display incoming Safeword Parameter Blocks Bit 4= Display outgoing SafeWord Parameter Blocks Bit 3= Display messages on entry to each function call Bit 2= Display important trace info in SafeWord areas Bit 1= Display important trace info in nonsafeword areas Bit 0= Attach RADIUS packet details to summaries 228

241 Chapter 9: Managing the PremierAccess RADIUS Server Troubleshooting common problems -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. 229

242 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic 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 mode Mon 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 V 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 c e0 fa 7a 5a b2 7b 2c RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=5 Value=super RFC 2138 Attribute=2: (User-Password) Length=16 230

243 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation Value= (Hex dump of RADIUS-encrypted value) cf 97 4c ff 2c 66 d8 cc d6 83 3a 84 da 7a NAS-IP-Address = 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() a: 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=super SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=super SafeWordAuthenticate(): UserNamePassWord=super SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=super SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as:border SafeWordAuthenticate d: 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() a: authenrec.userid=super swec registered openconnection() a: Calling swecopen(): openconnection() b: returned from swecopen() Before call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=super 231

244 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText= After call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=super SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=1 SwecAuthenRec.actionDataLength=8 SwecAuthenRec.actionData=/bin/csh SwecAuthenRec.peerAddr= 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() 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 userparse() 06.00: Attribute: Service-Type = Framed userparse() 06.00: Attribute: Framed-Protocol = PPP userparse() 06.00: Attribute: Framed-IP-Address = userparse() 06.00: Attribute: Framed-IP-Netmask = FindParms() 09.00: Function Complete. Closing Users file. FindParms() 09.01: reply_pairs after Approval: Service-Type = Framed ApproveAccept() 03.00: user_reply after approval: Service-Type = Framed Sending Ack of id 240 to c0a8184f ( ) Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = Framed-IP-Netmask = Outgoing RADIUS packet: 232

245 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation 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 a 49 8e a0 da 0 48 a5 RFC 2138 Attribute=6: (Service-Type) Length=4 Value= RFC 2138 Attribute=7: (Framed-Protocol) Length=4 Value= RFC 2138 Attribute=8: (Framed-IP-Address) Length=4 Value=a 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 client radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: 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 a bf RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=9 Value=supertest RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) c b ef f2 a d b NAS-IP-Address = NAS-Port = 1 233

246 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation NAS-Port-Type = Async User-Name = supertest User-Password = \305Y\224\267a\222\023\357\362\244\211e\015\266\005C rad_authenticate() a: Username=supertest 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=supertest SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=supertest SafeWordAuthenticate(): UserNamePassWord=supertest SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=supertest SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as:5ph20p SafeWordAuthenticate d: Got RADIUS-encrypted password SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:5ph20p SafeWordAuthenticate() 03: UserName[]=supertest SafeWordAuthenticate() 04: RadiusPasswordOne[]= SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=5ph20p SafeWordAuthenticate() 08.00: No stateinforeceived SafeWordAuthenticate() 08.12: Calling SafeWord via swecauthen() SafeWordAuthenticate() a: authenrec.userid=supertest swec registered openconnection() a: Calling swecopen(): openconnection() b: returned from swecopen() Before call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=supertest SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr=

247 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation SwecAuthenRec.statusText= After call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=supertest SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=1 SwecAuthenRec.actionDataLength=8 SwecAuthenRec.actionData=/bin/csh SwecAuthenRec.peerAddr= 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() 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 userparse() 06.00: Attribute: Service-Type = Framed userparse() 06.00: Attribute: Framed-Protocol = PPP userparse() 06.00: Attribute: Framed-IP-Address = userparse() 06.00: Attribute: Framed-IP-Netmask = FindParms() 09.00: Function Complete. Closing Users file. FindParms() 09.01: reply_pairs after Approval: Service-Type = Framed ApproveAccept() 03.00: user_reply after approval: Service-Type = Framed Sending Ack of id 241 to c0a8184f ( ) Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = Framed-IP-Netmask =

248 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation RADIUS access-accept packet ID 241 is sent to the RADIUS client Outgoing RADIUS packet: Examining RFC 2138 Access-Accept Packet:Identifier=241. Packet length=44. Packet Authenticator=f6 e8 dd 8c 79 6f 5f 0 62 c 6a 8e c2 c0 5d 14 RFC 2138 Attribute=6: (Service-Type) Length=4 Value= RFC 2138 Attribute=7: (Framed-Protocol) Length=4 Value= RFC 2138 Attribute=8: (Framed-IP-Address) Length=4 Value=a RFC 2138 Attribute=9: (Framed-IP-Netmask) Length=4 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: RADIUS authentication request ID 242 is received from the RADIUS client radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=242. Packet length=67. Packet Authenticator=99 69 c6 9c 32 b9 cb ed f8 3a fe 99 2f 34 RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=9 Value=user_asyn RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) f3 de f ad c7 bb 2d f7 53 fe c1 NAS-IP-Address =

249 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation NAS-Port = 1 NAS-Port-Type = Async User-Name = user_asyn User-Password = \363\336\366cxe\255Vd\307\273- \367S\376\301 rad_authenticate() a: Username=user_asyn 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=user_asyn SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=user_asyn SafeWordAuthenticate(): UserNamePassWord=user_asyn SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=user_asyn SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as: SafeWordAuthenticate() 03: UserName[]=user_asyn SafeWordAuthenticate() 04: RadiusPasswordOne[]= SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]= SafeWordAuthenticate() 08.00: No stateinforeceived SafeWordAuthenticate() 08.12: Calling SafeWord via swecauthen() SafeWordAuthenticate() a: authenrec.userid=user_asyn swec registered openconnection() a: Calling swecopen(): openconnection() b: returned from swecopen() Before call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=user_asyn SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText= After call to swecauthen: SwecAuthenRec.waitTime=10 237

250 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation SwecAuthenRec.userId=user_asyn SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText=User aborted SWEC deregistered After returning from SafeWord swecauthen(): SafeWordAuthenticate() 09: SafeWord sent Challenge Sending Challenge of id 242 to c0a8184f ( ) Access-challenge request packet ID 242 is sent to the RADIUS client Outgoing RADIUS packet: Examining RFC 2138 Access-Challenge Packet:Identifier=242. Packet length=58. Packet Authenticator=9d 3d be b1 df a 90 d4 62 ce 2b RFC 2138 Attribute=18: (Reply-Message) Length=28 Value=Challenge: Response? RFC 2138 Attribute=24: (State) Length=6 Value= rad_authenticate(): SafeWordResult=2 rad_authenticate(): SafeWord sent access_challenge. Returning 238

251 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation The RADIUS client send a response to the challenge packet ID 243 radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=243. Packet length=75. Packet Authenticator=79 f e7 31 fe f5 e2 64 5f c2 d 28 RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=9 Value=user_asyn RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) 4d 4c fe a6 47 ab e6 8e d3 ea ae 41 2b 6 6 b2 RFC 2138 Attribute=24: (State) Length=6 Value= NAS-IP-Address = NAS-Port = 1 NAS-Port-Type = Async User-Name = user_asyn User-Password = ML\376\246G\253\346\216\323\352\256A+\006\006\262 State = " rad_authenticate() a: Username=user_asyn 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=user_asyn SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=user_asyn SafeWordAuthenticate(): UserNamePassWord=user_asyn SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=user_asyn 239

252 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation 240 SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as:19pc SafeWordAuthenticate d: Got RADIUS-encrypted password SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:19pc SafeWordAuthenticate() 03: UserName[]=user_asyn SafeWordAuthenticate() 04: RadiusPasswordOne[]= SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=19pc SafeWordAuthenticate() 04.1: Found State attrib SafeWordAuthenticate() 07: stateinforeceived SafeWordAuthenticate() 07.60: Calling SafeWord via swecauthen() swec registered openconnection() a: Calling swecopen(): openconnection() b: returned from swecopen() SafeWordAuthenticate() a: Before call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=user_asyn SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText= After call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=user_asyn SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=1 SwecAuthenRec.actionDataLength=8 SwecAuthenRec.actionData=/bin/csh SwecAuthenRec.peerAddr= SwecAuthenRec.statusText=User passed SWEC deregistered SafeWordAuthenticate() 07.70: returned from swecauthen() SafeWordAuthorize() 01.00: No 'group=' in user record rad_authenticate(): SafeWordResult=0 ApproveAccept() user_reply before approval: Service-Type = Framed FindParms() 02.10: Successfully opened RADIUS database file.

253 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation FindParms() 02.20: Found group name. FindParms() 02.30: Found group by virtue of DEFAULT match userparse() 06.00: Attribute: Service-Type = Framed userparse() 06.00: Attribute: Framed-Protocol = PPP userparse() 06.00: Attribute: Framed-IP-Address = userparse() 06.00: Attribute: Framed-IP-Netmask = FindParms() 09.00: Function Complete. Closing Users file. FindParms() 09.01: reply_pairs after Approval: Service-Type = Framed ApproveAccept() 03.00: user_reply after approval: Service-Type = Framed Sending Ack of id 243 to c0a8184f ( ) Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = Framed-IP-Netmask = RADIUS access-accept packet ID 243 is sent to the RADIUS client Outgoing RADIUS packet: Examining RFC 2138 Access-Accept Packet:Identifier=243. Packet length=44. Packet Authenticator=7a be d6 6b 2a e1 c2 d5 8b b RFC 2138 Attribute=6: (Service-Type) Length=4 Value= RFC 2138 Attribute=7: (Framed-Protocol) Length=4 Value= RFC 2138 Attribute=8: (Framed-IP-Address) Length=4 Value=a RFC 2138 Attribute=9: (Framed-IP-Netmask) Length=4 Value=ff ff ff 0 241

254 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation 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 client radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=244. Packet length=79. Packet Authenticator=6a b e4 74 d c 9c 8f 51 RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=9 Value=user_chap RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) 7 38 cf fe 9b c0 a de 37 7e 94 ed RFC 2138 Attribute=6: (Service-Type) Length=4 Value= RFC 2138 Attribute=7: (Framed-Protocol) Length=4 Value= NAS-IP-Address = NAS-Port = 1 NAS-Port-Type = Async User-Name = user_chap User-Password = \0078\317\2117\376\233\300\243yd\3367~\224\355 radrecv() a: Received User-Service-Type attribute value=0 Service-Type = Framed Framed-Protocol = PPP rad_authenticate() a: Username=user_chap 242

255 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=user_chap SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=user_chap SafeWordAuthenticate(): UserNamePassWord=user_chap SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=user_chap SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as:chap_password SafeWordAuthenticate d: Got RADIUS-encrypted password SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as:chap_password SafeWordAuthenticate() 03: UserName[]=user_chap SafeWordAuthenticate() 04: RadiusPasswordOne[]= SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]=chap_password SafeWordAuthenticate() 08.00: No stateinforeceived SafeWordAuthenticate() 08.12: Calling SafeWord via swecauthen() SafeWordAuthenticate() a: authenrec.userid=user_chap swec registered openconnection() a: Calling swecopen(): openconnection() b: returned from swecopen() Before call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=user_chap SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText= After call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=user_chap 243

256 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=1 SwecAuthenRec.actionDataLength=8 SwecAuthenRec.actionData=/bin/csh SwecAuthenRec.peerAddr= 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() 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 userparse() 06.00: Attribute: Service-Type = Framed userparse() 06.00: Attribute: Framed-Protocol = PPP userparse() 06.00: Attribute: Framed-IP-Address = userparse() 06.00: Attribute: Framed-IP-Netmask = FindParms() 09.00: Function Complete. Closing Users file. FindParms() 09.01: reply_pairs after Approval: Service-Type = Framed ApproveAccept() 03.00: user_reply after approval: Service-Type = Framed Sending Ack of id 244 to c0a8184f ( ) Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = Framed-IP-Netmask =

257 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces during correct operation RADIUS access-accept packet ID 244 is sent to the RADIUS client Outgoing RADIUS packet: Examining RFC 2138 Access-Accept Packet:Identifier=244. Packet length=44. Packet Authenticator=df fd 6c 4d 6f fc 85 d4 e9 34 ba a0 3c 9f 4b 6d RFC 2138 Attribute=6: (Service-Type) Length=4 Value= RFC 2138 Attribute=7: (Framed-Protocol) Length=4 Value= RFC 2138 Attribute=8: (Framed-IP-Address) Length=4 Value=a RFC 2138 Attribute=9: (Framed-IP-Netmask) Length=4 Value=ff ff ff 0 245

258 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic 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 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 SWRADSRV SafeWord EASSP Client V using TCPIP transport. RADIUS authentication request ID 247 is received from the RADIUS client radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=247. Packet length=63. Packet Authenticator=b1 8a b e 5c 57 e0 1c 3f fc ac f RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=5 Value=super RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) 246

259 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration 47 f6 72 8e 9e d 34 d f2 b9 f4 ea 52 c1 NAS-IP-Address = NAS-Port = 1 NAS-Port-Type = Async User-Name = super User-Password = G\366r\216\236\0154\323\0014\362\271\364\352R\301 rad_authenticate() a: 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=super SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=super SafeWordAuthenticate(): UserNamePassWord=super SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=super SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as:border SafeWordAuthenticate d: 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() a: authenrec.userid=super Error reading file: RegisterSwec FAILED. [Error reading file message means that the SafeWord RADIUS server is unable to process the configuration file radius.cfg] 247

260 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration 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 radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=246. Packet length=63. Packet Authenticator=e6 1e 91 3d 43 5c 34 a1 44 e3 86 b3 f e 2e 84 RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=5 Value=super RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) ce 9e a d3 1e db f5 b4 9c e4 e 58 ec b4 248

261 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration NAS-IP-Address = NAS-Port = 1 NAS-Port-Type = Async User-Name = super User-Password = \316\236BP\032\323\036\333\365\264\234\344\016X\354\264 rad_authenticate() a: 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 = userparse() 06.00: Attribute: Framed-IP-Netmask = rad_authenticate() b: UserName=super SafeWordAuthenticate(): Got PW_USER_NAME attribute SafeWordAuthenticate(): namepair->strvalue=super SafeWordAuthenticate(): UserNamePassWord=super SafeWordAuthenticate(): Processed UsernamePassWord SafeWordAuthenticate(): UserName[]=super SafeWordAuthenticate a: Got RADIUS-encrypted password SafeWordAuthenticate() 02a: Decoded RadiusPassword as: _ý " -_{Y SafeWordAuthenticate d: Got RADIUS-encrypted password SafeWordAuthenticate() 02b: Decoded RadiusPasswordTwo as: _ý " -_{Y SafeWordAuthenticate() 03: UserName[]=super SafeWordAuthenticate() 04: RadiusPasswordOne[]= SafeWordAuthenticate() 04.01: RadiusPasswordTwo[]= _ý " -_{Y SafeWordAuthenticate() 08.00: No stateinforeceived SafeWordAuthenticate() 08.12: Calling SafeWord via swecauthen() SafeWordAuthenticate() a: authenrec.userid=super swec registered openconnection() a: Calling swecopen(): openconnection() b: returned from swecopen() Before call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=super 249

262 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=0 SwecAuthenRec.actionDataLength=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText= After call to swecauthen: SwecAuthenRec.waitTime=10 SwecAuthenRec.userId=super SwecAuthenRec.passUserFlag=0 SwecAuthenRec.resultCode=3 SwecAuthenRec.actionDataLength=1 SwecAuthenRec.actionData=0 SwecAuthenRec.peerAddr= SwecAuthenRec.statusText=Failed authentication SWEC deregistered After returning from SafeWord swecauthen(): SafeWord 08.3: Failed SafeWord rad_authenticate(): SafeWordResult=1 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 c ca 41 be f c7 4 b9 de 92 Sending Reject of id 246 to c0a8184f 250

263 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration Dictionary file problems The following example shows sample output with dictionary file problems. Mon Jan 24 20:08:08 PST 2000 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 SWRADSRV SafeWord EASSP Client V using TCPIP transport. RADIUS authentication request ID 249 is received from the RADIUS client radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=249. Packet length=63. Packet Authenticator=cb e7 fa 12 aa 1b 16 e9 57 f5 c6 f3 a RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=5 Value=super RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) 7a 2a 6c 26 f8 f5 4d a1 b fd ed 89 b8 93 NAS-IP-Address = NAS-Port = 1 NAS-Port-Type = Async 251

264 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration radrecv() a: Received unknown attribute 1 radrecv() a: Received unknown attribute 2 rad_authenticate a: 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. 252

265 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration 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 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 SWRADSRV SafeWord EASSP Client V using TCPIP transport. RADIUS authentication request ID 254 is received from the RADIUS client radrecv: Packet from host c0a8184f, port=1645 Incoming RADIUS Packet: Examining RFC 2138 Access-Request Packet:Identifier=254. Packet length=63. Packet Authenticator=cd bd 1a 76 f0 b b a4 d7 43 7c 47 eb 61 RFC 2138 Attribute=4: (NAS-IP-Address) Length=4 Value=c0 a8 18 4f RFC 2138 Attribute=5: (NAS-Port) Length=4 Value= RFC 2138 Attribute=61: (NAS-Port-Type) Length=4 Value= RFC 2138 Attribute=1: (User-Name) Length=5 Value=super RFC 2138 Attribute=2: (User-Password) Length=16 Value= (Hex dump of RADIUS-encrypted value) b1 6 9e b4 e0 5d d7 b0 e2 64 a 2f bd 253

266 Chapter 9: Managing the PremierAccess RADIUS Server Diagnostic traces with incorrect configuration NAS-IP-Address = NAS-Port = 1 NAS-Port-Type = Async User-Name = super User-Password = \261\006\236\264\340]\327\260\342d\012/ Du&\275 rad_authenticate() a: Username=super 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 f5 eb d Sending Reject of id 254 to c0a8184f 254

267 Chapter 9: Managing the PremierAccess RADIUS Server References 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 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 255

268 Chapter 9: Managing the PremierAccess RADIUS Server References VENDORATTR 9 cisco-avpair 1 string # # Integer Translations # # User Types 256 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-

269 Chapter 9: Managing the PremierAccess RADIUS Server References 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 VALUE NAS-Port-Type ISDN_Async_V VALUE NAS-Port-Type Virtual 5 VALUE NAS-Port-Type PIAFS 6 VALUE NAS-Port-Type HDLC_Clear_Channel 7 257

270 Chapter 9: Managing the PremierAccess RADIUS Server References VALUE NAS-Port-Type X.25 8 VALUE NAS-Port-Type X 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 = , Framed-Routing = None, Framed-Compression = Van-Jacobsen-TCP-IP, Framed-Filter-Id = "std.ppp.in" Framed-MTU = 1500 # # Group of SLIP users # slip User-Service-Type = Framed-User, Framed-Protocol = SLIP, Framed-Netmask = , Framed-Routing = None, Framed-Compression = None, Framed-MTU = 1006 # # Group of cslip users # cslip User-Service-Type = Framed-User, Framed-Protocol = SLIP Framed-Netmask = , Framed-Routing = None, Framed-Compression = Van-Jacobsen-TCP-IP, Framed-MTU = 1006

271 Chapter 9: Managing the PremierAccess RADIUS Server References # # Example Group of Developers using Dialup connections, whose privileges are limited # by filters on the RADIUS client named "Developers" and "Dialin" # Develop User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Netmask = , Framed-Routing = None, Framed-Compression = Van-Jacobsen-TCP-IP, 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. 259

272 Chapter 9: Managing the PremierAccess RADIUS Server References # 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. # 260

273 Chapter 9: Managing the PremierAccess RADIUS Server References 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 last.samplecompany.com RADIUS 261

274 Chapter 9: Managing the PremierAccess RADIUS Server References 262

275 CHAPTER 10 Managing the RADIUS Accounting Server In this chapter... Understanding the RADIUS Accounting Server How the server works Configuring the server Starting the server

276 Chapter 10: Managing the RADIUS Accounting Server Understanding 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 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)). 264

277 Chapter 10: Managing the RADIUS Accounting Server Starting 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 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: NAS-IP-Address = NAS-Port = 11 NAS-Port-Type = Virtual User-Name = super Calling-Station-Id = Acct-Status-Type = Stop Acct-Authentic = RADIUS 265

278 Chapter 10: Managing the RADIUS Accounting Server Starting the server Service-Type = NAS-Prompt Acct-Session-Id = Acct-Session-Time = 3 Acct-Delay-Time = 0 Fri Jan 1 03:38: NAS-IP-Address = NAS-Port = 11 NAS-Port-Type = Virtual User-Name = super Calling-Station-Id = Acct-Status-Type = Stop Acct-Authentic = RADIUS Service-Type = NAS-Prompt Acct-Session-Id = Acct-Session-Time = 3 Acct-Delay-Time = 5 266

279 CHAPTER 11 Managing the RADIUS Server for Ascend In this chapter... PremierAccess interface to the Ascend RADIUS Server Prerequisites Troubleshooting References and additional resources

280 Chapter 11: Managing the RADIUS Server for Ascend PremierAccess 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 268

281 Chapter 11: Managing the RADIUS Server for Ascend References 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

282 Chapter 11: Managing the RADIUS Server for Ascend References and additional resources 270

283 CHAPTER 12 Setting Up Web-based Enrollment In this chapter... Understanding Web-based, user enrollment Customizing enrollment configurations Customizing enrollment forms Enrollment reservation overview Advanced Mode option features Other enrollment tasks User ChangePin feature

284 Chapter 12: Setting Up Web-based Enrollment Understanding 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. General tab settings To modify enrollment attributes, from the main console, click Configuration -> Enrollment. The Edit Configuration window appears with the General tab displayed. Figure 137: Edit Configuration window (General tab) 272

285 Chapter 12: Setting Up Web-based Enrollment Customizing 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 If you are deploying PremierAccess-generated user certificates, click the Certificate tab and continue with the next procedure. Figure 138: Edit enrollment configuration- Certificate tab 273

286 Chapter 12: Setting Up Web-based Enrollment Customizing enrollment configurations Certificate tab settings This tab contains the default values that will appear in PremierAccessgenerated 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. 274

287 Chapter 12: Setting Up Web-based Enrollment Customizing 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 275

288 Chapter 12: Setting Up Web-based Enrollment Customizing 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). 276

289 Chapter 12: Setting Up Web-based Enrollment Enrollment 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 subgroups. 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. 277

290 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 139 on page -278 shows a high-level overview of the process for creating a reservation with the enrollment reservation wizard. Figure 139: Enrollment reservation process using reservation wizard Select Enroll. Resv. Supply resv name Select admin group User enroll w / hdwr authent? Any/all No can be combined User enroll w /digital certif? Yes Yes Specify role(s)? Yes Specify role(s) No No User enroll w/fixed password Users select own names? Yes No Admin select existing users? Yes Generate pass phrases No Admin add/import new user(s) Summary screen of choices 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

291 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview 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 140: New User Reservation 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. 279

292 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 141: Authenticator 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 139. Digital Certificate Profile. If you have not created digital certificate profiles yet, refer to Digital certificate profiles on page 155 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 153. 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. 280

293 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 142: User Options 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 136). 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

294 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview 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 283. To specify existing usernames, proceed to Individual Pass Phrases, Existing Users on page 285. To specify new usernames, proceed to Individual Pass Phrase, New Users on page

295 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview 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 143: Individual Pass 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 b Specify the number of pass phrases to generate in the Number of Pass Phrases field. 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 window 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 Enrollment Pass Phrase pane. 283

296 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 144: Window with generated pass phrases Figure 145: Summary window 2 Once all needed pass phrases have been generated, click Next. A Summary window displays for this reservation. 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. 284

297 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview For an explanation of Advanced Mode, refer to the section called Advanced Mode option features on page 291. 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 297. 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 146: Individual Pass 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 147: User for Reservation: (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). 285

298 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 148: Individual Pass Phrase/Existing User window with selected users Figure 149: Individual Pass Phrase/Existing Users (with pass phrases) 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. 5 If no other choices are needed, click Next. A Summary window appears that reflects the choices you have made. 286

299 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 150: Summary screen, 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 291. To capture the enrollment URL, then see what your end users will see during Web-based enrollment, refer to Capturing the enrollment URL on page 297. 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 151: Individual Pass Phrase, New User window 287

300 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 152: Individual Pass Phrase, New User window (with names) 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 289. 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 153: Individual Pass Phrase/New User window (with pass phrases) 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. 3 Click Next. A Summary window appears listing the choices you have made for this reservation. 288

301 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 154: Summary window 4 (Optional) If something in the summary needs to be changed, click Back to return to the window requiring modification. 5 Click Finish to set the configurations you have just made. For an explanation of Advanced Mode, refer to the section called Advanced Mode option features on page 291. 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 297. 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 155: Browser window 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. 289

302 Chapter 12: Setting Up Web-based Enrollment Enrollment reservation overview Figure 156: Individual Pass Phrase/New User window Figure 157: Summary 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. 4 (Optional) If something in the summary needs to be changed, click Back to return to the window requiring modification. 5 Click Finish. For an explanation of Advanced Mode, refer to the section called Advanced Mode option features on page 291. 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

303 Chapter 12: Setting Up Web-based Enrollment Advanced 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 158: Create a new User Reservation - General tab General tab settings 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: 291

304 Chapter 12: Setting Up Web-based Enrollment Advanced Mode option features Figure 159: Create a new User Reservation - User Data tab 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. 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. 292

305 Chapter 12: Setting Up Web-based Enrollment Advanced Mode option features 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 160: Create a new 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. 293

306 Chapter 12: Setting Up Web-based Enrollment Advanced Mode option features Figure 161: User & Pass Phrase summary window 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. 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 289. 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. 294

307 Chapter 12: Setting Up Web-based Enrollment Advanced Mode option features Table 20: Name to enrollment pass phrase choice matrix With this Username choice... Users select own name Specify existing users Specify new users...and this Enrollment pass phrase choice... Shared pass phrase Individual pass phrase...you will follow-up with these actions Set max number of users for this reservation. Accept the default, or enter/generate a new 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. Shared pass phrase Individual 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). Shared pass phrase Individual 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. 3 Under the Personalization Data Attributes pane, select the attributes you 295

308 Chapter 12: Setting Up Web-based Enrollment Advanced Mode option features Figure 162: New Enrollment Reservation, History & Print tab 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. 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. 296

309 Chapter 12: Setting Up Web-based Enrollment Other 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 163: 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. 5 When you are finished, click OK. 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

310 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks Figure 164: Summary Print window To capture the URL for distribution by whatever means you have predetermined, do the following: 1 From the summary window, choose the option you wish to print, then click the Print button. 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 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 help- desk, 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. 298

311 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks 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 165: Enrollment Web 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 166: Enrollment Web page, Confirmation and Fixed Password test page This page indicates successful enrollment. 299

312 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks Figure 167: Authenticator Test successful page and Enrollment processing complete page 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. 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 275 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. 300

313 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks Figure 168: Token Authenticator Enrollment Web page and Enrollment Confirmation 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 reenters 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 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. 301

314 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks Figure 169: Token Authenticator Test page and 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 Click Next. The Test Authentication Successful page appears. 5 Click Next. 302

315 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks Figure 170: Enrollment Process Completion page The user is informed that they have successfully enrolled into PremierAccess. 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 171: New Digital Certificate 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. 303

316 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks Figure 172: Digital Certificate Successful Enrollment page and New Digital Certificate Test page The defaults provided on the Web form are configurable. 4 The user clicks Next. 304

317 Chapter 12: Setting Up Web-based Enrollment Other enrollment tasks 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 certificate. 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 173: Digital Certificate Test page and Successful Enrollment Completion 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. 305

318 Chapter 12: Setting Up Web-based Enrollment User 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 ( <machine_name.domain_name>/platform/toc.jsp), select Change your SoftPIN here. The Login page appears. 2 The user should click the Login button. 306

319 Chapter 12: Setting Up Web-based Enrollment User ChangePin feature Figure 174: Login page and 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. 307

320 Chapter 12: Setting Up Web-based Enrollment User ChangePin feature Figure 175: Change SoftPIN page and Successful SoftPIN Change 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. 308

321 Chapter 12: Setting Up Web-based Enrollment User ChangePin feature 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 176: Test SoftPIN page 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. 309