Best Practices Guidelines

Transcription

1 Best Practices Guidelines Copyright 2005 CRYPTOCard Corporation All Rights Reserved

2 Table of Contents Copyright... 3 Trademarks... 3 Publication History... 3 Who Should Read This Manual?... 3 Additional Information, Assistance, or Comments... 4 Text Conventions... 4 Windows/Mac/Linux Conventions SYSTEM INSTALLATION... 6 Windows installation WORKING WITH CRYPTO-SERVER LOG FILES... 7 CRYPTO-Protocol service/daemon-governed logs... 7 CRYPTO-Log service/daemon-governed logs... 8 CRYPTO-Server (Jboss) service/daemon-governed logs USING LOG FILES FOR TROUBLESHOOTING Interpreting log messages SYSTEM IMPLEMENTATION Hardware Tokens (RB-1 and KT-1) Software Tokens (ST-1, SC-1, and UB-1) Adjusting the system for a first-time deployment Instructing users about token use CONFIGURING NAS ENTRIES ESTABLISHING COMMUNICATION WITH THE CRYPTO-CONSOLE CRYPTO-LOGON FOR MICROSOFT WINDOWS DATABASE REPLICATION USING AN EXTERNAL MYSQL DATABASE SYSTEM MAINTENANCE MySQL database backup and maintenance for CRYPTO-Server systems configured for replication CRYPTO-Server 6.3 Best Practices Guide 2

3 Copyright Copyright 2005, CRYPTOCard Corp. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without the written permission of CRYPTOCard Corp. Trademarks CRYPTOCard, CRYPTO-Server, CRYPTO-Web, CRYPTO-Kit, CRYPTO-Logon, CRYPTO-VPN, are either registered trademarks or trademarks of CRYPTOCard Corp. Microsoft Windows and Windows XP/2000/2003/NT are registered trademarks of Microsoft Corporation. SecurID is a registered trademark of RSA Security. All other trademarks, trade names, service marks, service names, product names, and images mentioned and/or used herein belong to their respective owners. Publication History Date October 17, 2005 October 27, 2005 November 8, 2005 Changes Initial release Added System Maintenance section Added replication for an external MySQL database Who Should Read This Manual? This guide provides guidelines for deploying, managing, and maintaining a CRYPTO-Server 6.3 system. It includes background information about the product components and configuration instructions for setting up the software. This manual is intended for Security Officers and System Administrators. It assumes the reader has a good knowledge of the CRYPTO-Server product suite, as well as client-server computing terminology and processes, and the various operating systems on which CRYPTO-Server, authentication agents, plug-ins, and authenticators are installed. CRYPTOCard publishes updates and addenda to this and other CRYPTOCard documents at Please check often to stay current with new and important information about our products and services. These additional documents are located in the Support and Documentation area of our website. CRYPTO-Server 6.3 Best Practices Guide 3

4 Additional Information, Assistance, or Comments CRYPTOCard s technical support specialists can provide assistance when planning and implementing CRYPTOCard in your network. In addition to aiding in the selection of the appropriate authentication products, CRYPTOCard can suggest deployment procedures that provide a smooth, simple transition from existing access control systems and a satisfying experience for network users. We can also help you leverage your existing network equipment and systems to maximize your return on investment. This complimentary support service is available from your first evaluation system download. CRYPTOCard works closely with channel partners to offer worldwide Technical Support services. If you purchased this product through a CRYPTOCard channel partner, please contact your reseller directly for support needs. To contact CRYPTOCard directly: International Voice: North America Toll Free: support@cryptocard.com For information about obtaining a support contract, see our Support Web page at Text Conventions The following text conventions are used in this document: Courier text: denotes something you see on-screen (e.g. a dialog window title or field, a configurable Key, an exact filename) or something you enter verbatim on-screen (e.g. a command). <Italicized, bracketed text>: denotes a variable that requires an appropriate value to be entered. For example, if you see <IP_address>, you might enter Bold text: denotes a path. If the path uses a pipe ( ) character (e.g. A B C D), the path does not lead to a folder or file, but rather represents GUI/application menu options. If the path uses the forward slash (/) character, the path leads to a folder or file. CRYPTO-Server 6.3 Best Practices Guide 4

5 Windows/Mac/Linux Conventions The CRYPTO-Server 6.3 solution operates in a similar fashion when installed on a Windows, Mac, or Linux platform. All material in this document should be assumed to apply to all platforms unless otherwise noted. Please note the following conventions: Right/control-click: control-click in Mac is equivalent to right-click in Windows/Linux. \ vs. /: in this document, Windows file/folder/directory paths are written with \, while Mac and Linux file/folder/directory paths are written with /. Daemons vs. services: these terms are used interchangeably. The following table provides some examples of the most important: Service/daemon Name Platform CRYPTO-Server (Jboss) CRYPTO-Log CRYPTO-Protocol MySQL ccjbossd Jboss CRYPTO-Server (JBoss 3.2x) cclogd CCLogServ CRYPTO-Log Server ccptcld CCProtoServ CRYPTO-Protocol Server ccmysqld MySQL Linux Mac Windows Linux Mac Windows Linux Mac Windows Linux Mac/Windows CRYPTO-Server 6.3 Best Practices Guide 5

6 1 System Installation If you are installing the CRYPTO-Server and/or CRYPTO-Console, be sure you thoroughly read all the system requirements and installation-related material in the CRYPTO-Server Administrator s Manual prior to beginning. Similarly, installation guidelines for other CRYPTOCard solution components should be reviewed before beginning an installation. All documentation is available from Windows installation If you are installing CRYPTOCard software on a system that has Terminal Services installed, you must use the Add/Remove Programs utility to install the software. There is nothing that prevents the CRYPTO-Server software from being installed on a Microsoft Windows Active Directory domain controller. However, this configuration is not supported because in certain instances, port conflicts between the CRYPTO-Server and some Active Directory services can arise. For example, when the system is rebooted, a port required by CRYPTO-Server might be taken by an Active Directory service, or vice versa. If you are installing on a platform running Windows 2003 with SP1, the Data Execution Prevention utility that is installed with SP1 can interfere with.exe packages. This security feature can be overridden on a file-by-file basis. For example, if you wish to install the CRYPTO-Console 6.3.exe file: 1. Right-click on My Computer and select Properties. 2. Select the Advanced tab. 3. Click the Settings button in the Performance section. 4. Select the Data Execution Prevention tab. 5. Add the CRYPTO-Console 6.3.exe file to the list of exceptions. Click the Apply and OK buttons. 6. Execute the file. CRYPTO-Server 6.3 Best Practices Guide 6

7 2 Working with CRYPTO-Server log files Log files can be useful tools when monitoring or troubleshooting a system. There are three primary CRYPTO-Server services/daemons that generate log files: the CRYPTO-Protocol daemon, CRYPTO-Log daemon, and CRYPTO-Server (Jboss) daemon. CRYPTO-Protocol service/daemon-governed logs When the CRYPTO-Protocol service/daemon is started, it creates a number of log files, the most important of which are: CAPManager.dbg (logs the various protocols startup/failure events) CAPProtocol.dbg (logs any CAP activity; this log is therefore especially useful when seeking information about CRYPTO-Logon, PAM modules, etc.) HTTPProtocol.dbg (logs any HTTP activity; this log is therefore especially useful when seeking information about CRYPTO-Web) HTTPSProtocol.dbg (logs any HTTPS activity; this log is therefore especially useful when seeking information about CRYPTO-Web) RADIUSProtocol.dbg (logs any RADIUS activity) The content of all of these logs is organized in a similar way. They all contain startup information first (e.g. trusted IP ranges, the CRYPTO-Server that is being connected to, the port that is being bound to). An example of this portion of the RADIUSProtocol.log is shown below; the others may look somewhat different: The next information displayed is a dump of the packet that is arriving and the attributes of the packet: CRYPTO-Server 6.3 Best Practices Guide 7

8 Then the log displays what was done with the packet (e.g. the handoff between the Protocol Server module and the Authentication module within the CRYPTO-Server): At this point, the log displays the action related to the packet (i.e. accept or reject), a dump of the packet that is sent back, and its attributes: Each of the CRYPTO-Protocol Server protocols (RADIUS, HTTP, CAP, etc.) can be individually configured to generate reports in the desired format. Each of the CRYPTO-Protocol daemon-governed log files can also be modified so that they will roll over to another file. A backup of the MySQL database should be made prior to performing the changes. For example, to configure the RADIUS logs to roll over, make the following changes: 1. From the CRYPTO-Console, select Server System Configuration and the RadiusProtocol Entity. 2. Select the log4j.appender.rad_dbg Key and change the Value from: org.apache.log4j.fileappender to org.apache.log4j.dailyrollingfileappender 3. Right/control-click on RADIUSProtocol and select New Key-Value. 4. Set the Key to log4j.appender.rad_dbg.datepattern. 5. Set the Value to. yyyy-mm-dd. 6. Apply and OK the change. CRYPTO-Log service/daemon-governed logs When the CRYPTO-Log service/daemon is started, it creates the cryptocard.log file. This log file records system validation information. In other words, information related to the daily system maintenance processes (CRYPTO-Server scheduled tasks) that are automatically performed (e.g. RSA token expiration check, check for LDAP user listing CRYPTO-Server 6.3 Best Practices Guide 8

9 status changes, etc.). This log file also records authentication request information related to server-side settings (e.g. PIN changes, token behavior thresholds configured in the CRYPTO-Server, etc.). In general, the cryptocard.log file provides useful server-side information that can be used to supplement the information contained in the logs generated by the CRYPTO-Protocol service/daemon. CRYPTO-Server (Jboss) service/daemon-governed logs When the CRYPTO-Server (Jboss) service/daemon is started, it creates the server.log file. This log file records information related to anything the CRYPTO-Server connects to (e.g. the database and/or an LDAP directory server). By default, the server.log file is located in: \Cryptocard\Crypto-Server\JBoss-3.2\server\cryptocard\log (Windows), Applications/CRYPTO-Server/jboss-3.2/server/cryptocard/log (Mac), or /usr/local/cryptocard/cryptoserver/jboss-3.2/server/cryptocard/log (Linux). By default, the server.log file is overwritten each day, rather than appended to. To change this so that log information is appended: 1. On the primary and secondary CRYPTO-Servers, locate the log4j.xml file. The default location is: \Cryptocard\Crypto-Server\JBoss-3.2\server\cryptocard\ conf (Windows), Applications/CRYPTO-Server/jboss-3.2/server/cryptocard/ conf (Mac), or /usr/local/cryptocard/cryptoserver/jboss-3.2/server/ cryptocard/conf (Linux). Open the log4j.xml file with a text-editing tool and change: <log4j:configuration xmlns:log4j=" debug="false"> <!-- ================================= --> <!-- Preserve messages in a local file --> <!-- ================================= --> to: <!-- A time/date based rolling appender --> <appender name="file" class="org.jboss.logging.appender.dailyrollingfileappender"> <errorhandler class="org.jboss.logging.util.onlyonceerrorhandler"/> <param name="file" value="${jboss.server.home.dir}/log/server.log"/> <param name="append" value="false"/> <param name="threshold" value="info"/> <log4j:configuration xmlns:log4j=" debug="false"> <!-- ================================= --> <!-- Preserve messages in a local file --> <!-- ================================= --> CRYPTO-Server 6.3 Best Practices Guide 9

10 <!-- A time/date based rolling appender --> <appender name="file" class="org.jboss.logging.appender.dailyrollingfileappender"> <errorhandler class="org.jboss.logging.util.onlyonceerrorhandler"/> <param name="file" value="${jboss.server.home.dir}/log/server.log"/> <param name="append" value="true"/> <param name="threshold" value="info"/> 2. Restart the CRYPTO-Server (Jboss), CRYPTO-Log, and CRYPTO-Protocol services/daemons. CRYPTO-Server 6.3 Best Practices Guide 10

11 3 Using log files for troubleshooting Prior to forwarding log file content to CRYPTOCard Support when seeking assistance, ensure that Log4J logging is set to the DEBUG level for each of the protocols being used: 1. From the CRYPTO-Console, select Server System Configuration and the appropriate protocol Entity (e.g. RadiusProtocol). 2. Ensure the DebugLog.Enabled Key is set to True. 3. The log4j.category.com.cryptocard.cryptoadmin.capserver.<protocol>.configure.<type> Keys set the level of logging detail for the specified protocol. The <TYPE> can be ACC (accounting logs), DBG (authentication logs), and LOG (Syslogs). Set the Value of these Keys to DEBUG (the most detailed), for each of the three log types. For example, if the protocol used is RADIUS, the Value for these Keys should be DEBUG, RAD_ACC; DEBUG, RAD_DBG; and DEBUG, RAD_LOG. This sets the level of detail in the RADIUS accounting, authentication, and Syslog logs to DEBUG (the most detailed). By default, the logging level is set to INFO, which provides less detail than DEBUG. This is because the log files tend to grow rapidly when set to the DEBUG level of detail. 4. Stop the CRYPTO-Protocol and CRYPTO-Log services/daemons. 5. Restart the CRYPTO-Protocol and CRYPTO-Log services/daemons to activate the changes. If you encounter a problem, it is often a good idea to stop the current logging processes, save the existing logs, and restart the logging processes to generate smaller, more focused logs: 1. Stop the relevant services/daemons (i.e. the CRYPTO-Protocol and CRYPTO-Log daemons; possibly the CRYPTO-Server (Jboss) daemon). 2. Rename the existing logs to preserve them (e.g. by adding a.old suffix). 3. Restart the daemons to recreate the logs. 4. Repeat the action that is generating the problem. In this way, the logs will be smaller in size and will be easier to analyze vis-à-vis the specific problem scenario. At the same time, the previous logs are preserved in case they are required. Interpreting log messages The following log file excerpts represent some of the more common messages that might be seen: 1. From the cryptocard.log file: [PtclServer Authenticato SessionBean joeblow:cryptocard ] Exceeded maximum consecutive failures. Token has been locked. The CRYPTO-Server has a setting called MaxConsecutiveFailures. By default, the CRYPTO-Server 6.3 Best Practices Guide 11

12 maximum consecutive authentication failure limit is set to 10. Once this threshold is reached, the user s token becomes locked. Unlocking a token requires CRYPTOCard Operator intervention. 2. From the cryptocard.log file: PIN validation failed....resulting from INFO Operational /09/12 00:48:39:571 [ ] CCInvalidDataException: PIN length '44' is greater than maximum PIN length '8'. This error is generated when an imported RSA token is used for the first time with a CRYPTO-Server system configured to use MSCHAP. First-time use of an RSA token can only be performed via PAP. 3. From the cryptocard.log file: INFO Audit /09/12 00:00:58:878 [PtclServer Authenticato SessionBean joeblow:cryptocard ] CCAuthBadPINException: Invalid authentication PIN. When a user sends in a one-time password, the CRYPTO-Server breaks it into two pieces. It first verifies the PIN portion and then the one-time passcode. This message indicates the PIN provided to the CRYPTO-Server was incorrect. 4. From the cryptocard.log file: PIN validation failed....resulting from INFO Operational /09/12 00:19:23:843 [ ] CCInvalidDataException: PIN length '2' is less than minimum PIN length '3'. The CRYPTO-Server has a minimum and maximum PIN length restriction that can be set at the token or token template level. The minimum PIN length value is 3 and the maximum is From the RADIUSProtocol.dbg file: MSCHAP, PAP, CRYPTO-Server NAS entries and CHALLENGE messages. When a PAP authentication request is sent to the CRYPTO-Server, the RADIUS attributes in the packet will look something like this: User-Name (1), Length: 11, Data: [joeblow], 0x736E676D User-Password (2), Length: 18, Data: 0x3B658E56AD6FA859A823821B03926AAB Service-Type (6), Length: 6, Data: [# 8 (Authenticate Only)], 0x NAS-Identifier (32), Length: 21, Data: [vpnupdate.cryptocard.com], 0x76706E E C652E636F6D NAS-IP-Address (4), Length: 6, Data: [# ] / [IP ], 0x11FE0D36 CRYPTO-Server 6.3 Best Practices Guide 12

13 When an MSCHAP authentication request is sent to the CRYPTO-Server, the RADIUS attributes in the packet will look something like this: User-Name (1), Length: 11, Data: [joeblow], 0x736E676D Vendor-Specific ID: Microsoft (311), VSA Count: 1 MS-CHAP-Challenge (11), Length: 18, Data: 0x53F073988FA8A5DFCDD27FA8BF33FBC4 Vendor-Specific ID: Microsoft (311), VSA Count: 1 MS-CHAP2-Response (25), Length: 52, Data: 0xB229818DA82076FDDD1F715D9DAACDA71BDD B12E3FA20AADA450D83EBA8F 85289B71C712DA214D5F6CD5 Service-Type (6), Length: 6, Data: [# 2 (Framed)], 0x Framed-Protocol (7), Length: 6, Data: [# 1 (PPP)], 0x The CRYPTO-Server provides a challenge for an authentication request if the password field in an application was left blank by the user or if the RADIUS password attribute sent by the VPN server does not exist for the authentication type expected by the CRYPTO-Server. The CRYPTO-Server needs a unique authentication type specified for each NAS device (i.e. PAPCHAP or MSCHAP). For example, if VPN Server A sends an MSCHAP authentication request to the CRYPTO- Server, the RADIUS password attribute looks like this: Vendor-Specific ID: Microsoft (311), VSA Count: 1 MS-CHAP-Challenge (11), Length: 18, Data: 0x53F073988FA8A5DFCDD27FA8BF33FBC4 Vendor-Specific ID: Microsoft (311), VSA Count: 1 MS-CHAP2-Response (25), Length: 52, Data: 0xB229818DA82076FDDD1F715D9DAACDA71BDD B12E3FA20AADA450D83EBA8F 85289B71C712DA214D5F6CD5 If the CRYPTO-Server NAS entry is configured to expect a PAP request from VPN Server A, it is looking for this type of RADIUS Password Attribute from VPN Server A: User-Password (2), Length: 18, Data: 0x3B658E56AD6FA859A823821B03926AAB Since the CRYPTO-Server cannot find User-Password and was not configured to expect MS- CHAP-Challenge and MS-CHAP2-Response, it assumes the user has requested a challenge. Since RSA tokens do not support Challenge-response operation, we cannot find a challenge so we display Challenge: CRYPTO-Server 6.3 Best Practices Guide 13

14 4 System Implementation In order to achieve a smooth transition to two-factor authentication within your organization, it is important to provide users with clear instructions regarding the use of tokens and first-time logon. Tokens should not be distributed to users until the users have received instructions for their use. Tokens can be assigned to a user when the user is created, or subsequently. There should always be at least two users with Operator privileges in every system. The following general procedures should be followed when issuing tokens to users: Hardware Tokens (RB-1 and KT-1) 1. Ensure the user exists in CRYPTO-Server. 2. Ensure the token exists in the CRYPTO-Server token inventory and is in the Unassigned state. 3. Edit the token characteristics, if required, using the Edit Token function. Initialize the token, if required. Hardware tokens can be received from CRYPTOCard in pre-programmed (i.e. preinitialized) or unprogrammed format, depending on your stated preference. If you opt to receive pre-programmed tokens, each token is individually packaged in a small box that has the initial PIN printed on it. Simply register the tokens using the UID and assign the tokens to the users. If you opt to receive unprogrammed tokens, you must use a token initializer to initialize each token. You may wish to use a Token Template during the initialization to speed the process. 5. Assign the token to the user, from the token inventory. 6. Activate the token. As an Operator, you can activate a token by changing its state to Active via the CRYPTO-Console GUI. However, in order to expedite the process, you may wish to enable end users to activate their tokens using the CRYPTO-Deploy utility. CRYPTO-Deploy is a facility of CRYPTO-Server that enables end users to activate hardware tokens via the Web. Upon receipt of his hardware token, the user self enrols by navigating to: address>:8080/caserver/activation.request. The user requires the following information: Username address Serial number of token CRYPTO-Server 6.3 Best Practices Guide 14

15 PIN Earliest activation date, if token has a Start/Expiry date CRYPTO-Server IP address One of the fields that must be populated on the CRYPTO-Deploy dialog window is Response. This is the password displayed by the token. Users should be informed that if a Server-side PINs is used, the Response field is a combination of the PIN and the one-time token passcode (the PIN is prepended to the passcode displayed by the token). Upon successfully entering the required information in the CRYPTO-Deploy dialog window, the token is assigned to the user and activated. The token will now be displayed in the Token List of the user. The user can use the token for authentication, unless it has a Start/Expiry date where the start date has not yet arrived. Software Tokens (ST-1, SC-1, and UB-1) 1. Ensure the user exists in CRYPTO-Server. 2. Ensure the token exists in the CRYPTO-Server token inventory and is in the Unassigned state. Tokens are placed into inventory when the UID is used to register them. 3. Edit the token characteristics, if required, using the Edit Token function. 4. Ensure that the EUS (end-user service) software is installed on the user s workstation/device that will be used in conjunction with the token. There are three methods to do this. The first is to manually install the EUS on each end-user machine. The second is to use a third-party tool (e.g. Microsoft SMS) to push the EUS software onto the user s desktop. This is typically the most practical way to distribute the EUS - the package is approximately 30 MB in size and therefore is not suitable for most systems. The third method is to create a baseline workstation image that includes the EUS software, and apply this to the end-user machines. Typically, this is only practical if other software upgrades are required at the same time. 5. Assigning a software token to a user, from inventory, is essentially the same as initializing it. There are three methods to this. The first is to install the token locally. To do this, insert the USB token or smart card reader and smart card into the CRYPTO-Console workstation and install the token. This method generates a report indicating the Initial PIN required to activate the token. The smart card or USB dongle token can then be removed from the CRYPTO- Console workstation and activated by the user on a computer with a pre-installed EUS. This method would only be used with an ST-1 token if the token were intended for use with the CRYPTO-Console machine (i.e. an Operator token). CRYPTO-Server 6.3 Best Practices Guide 15

16 The second method is to generate an initialization file that can be transferred to the user s machine. This method generates a report indicating the Initial PIN required by the user to activate the token and the location of the initialization file to be installed on the EUS of the user s computer. The third method is to the initial PIN and token initialization file to the end user. The s contain user instructions for token activation and enrolment that can be modified as required. This method generates a report confirming the separate sending of PIN and token initialization files, including instructions for activation, to the user. The initialized token appears in the Token List and is marked as Active. If desired, a token template can be assigned during initialization to speed the process. Adjusting the system for a first-time deployment Adequately preparing users and giving them clear and complete instructions for token usage can minimize problems due to unfamiliarity with a new system. Problems can also be minimized by temporarily adjusting CRYPTO-Server operational settings to allow for user error. These parameters can be adjusted by selecting Server System Configuration and the appropriate protocol Entity and Key. For example, the Token Entity s MaxForward Key specifies the maximum number of times to "look ahead" when attempting to match a user token response with the expected response. By default, this is set to 10, but it could be increased to 20, to minimize the instances of out-of-sync tokens that arise due to user inexperience. Similarly, the MaxConsecutiveFailures Key specifies the maximum number of consecutive token response failures before a token becomes locked. Unlocking a token requires CRYPTOCard Operator intervention. By default, the maximum consecutive authentication failure limit is set to 10. The Value of this Key can also be increased temporarily. Instructing users about token use There are numerous token configuration parameters that can potentially impact a user s experience with his token. It is important to make users aware of the tokens operational parameters in order to avoid problem scenarios. For example, a user s Initial PIN value is permanent if Fixed PIN is selected, but this value must be changed on first use of the token (and whenever desired, subsequently) if User-changeable PIN is selected. It is important to apprise users of the settings that affect permitted user-changeable PINs. PIN values selected by users must be within the limits set under the Min PIN Length, Characters allowed, Try Attempts, and Allow Trivial PINs configuration parameters. This is especially important because PIN-change failure messages do not attribute the failure to specific parameter contraindications. Therefore, users can CRYPTO-Server 6.3 Best Practices Guide 16

17 repeatedly attempt to select a PIN that is not permitted if they do not know the PIN change requirements. Users should also be made aware that their Initial PIN could be longer than the Min PIN Length setting that governs their PIN changes. CRYPTO-Server 6.3 Best Practices Guide 17

18 5 Configuring NAS entries When you are adding NAS entries in your system (e.g. under the RADIUSProtocol Entity), NAS.1 should never be edited. NAS.1 is always the loopback device, which enables the CRYPTO-Server to communicate with itself. NAS.2 is a bucket for all NAS clients in the system. By default, the IP address range for NAS.2 encompasses the entire subnet that CRYPTO-Server belongs to. If required, this IP address range can be edited (narrowed) so as to include only the existing NAS clients that CRYPTO-Server will accept authentication requests from, rather than the entire subnet. This address range can be further narrowed to include only a specific NAS client if you wish to add new NAS.x entries for individual NAS clients. For example, you may wish to vary the <Shared Secret> used by each NAS client. Similarly, you may wish to use different <Authentication Protocols> (i.e. MSCHAPv2 and PAP) for different NAS clients. In these cases, you will need to add new NAS entries for the relevant protocols. When adding NAS entries, you must ensure that none of the IP address ranges overlap. CRYPTO-Server 6.3 Best Practices Guide 18

19 6 Establishing communication with the CRYPTO-Console If there is a firewall between the remote CRYPTO-Console workstation and the CRYPTO- Server, you must establish a VPN connection between the two endpoints in order to enable communication. Regardless of whether a firewall is present, both the remote CRYPTO-Console workstation and the CRYPTO-Server must be able to perform a forward and reverse lookup on each other. This can be configured via the host file of each system. For example, on the remote CRYPTO-Console system, you would add the IP address, fully qualified name, and hostname of the CRYPTO-Server machine (and vice versa). Failure to configure the systems for forward and reverse lookup will generate Connection Null error messages. CRYPTO-Server 6.3 Best Practices Guide 19

20 7 CRYPTO-Logon for Microsoft Windows The domain Administrator account should not be issued a CRYPTOCard token of any type and/or be enabled to use CRYPTO-Logon for Windows. CRYPTO-Logon replaces a user s static Microsoft password with one-time passwords and this can result in the Administrator becoming locked out of the domain. Admin users can be issued tokens and use CRYPTO-Logon as long as they are not required to connect to services or applications that are incompatible with CRYPTO-Logon. CRYPTO-Server 6.3 Best Practices Guide 20

21 8 Database replication using an external MySQL database In the CRYPTO-Server 6.3 Administrator s Manual, the Secondary (Replica) Server & Failover Configuration chapter describes how to implement database replication for systems that utilize CRYPTO-Server s internal, native MySQL database. There is also a document available at that describes how to implement database replication in systems that use an external MS SQL database. This section describes how to implement database replication when an existing (i.e. nonnative, external) MySQL database is used. 1. On the primary server, create another Operator (other than the 'admin' operator) who can log in to the server. To verify that your replica (secondary) UID/license has been registered on the primary server, connect to the CRYPTO-Console on the primary server and select Server Licenses. There should be at least two licenses present, with one of them having a MaxTokens value of Perform a database backup of the primary CRYPTO-Server database, as per the instructions in the MySQL Database Backup and Restore chapter in the CRYPTO-Server 6.3 Administrator s Manual. Ensure you name the backup file CRYPTOAdmin6.sql. Depending on the operating system, the default name of the database will be CRYPTOAdmin6 or cryptoadmin6. To avoid case-sensitivity problems, ensure you are consistent in your naming; this procedure uses the CRYPTOAdmin6 spelling. 3. Ensure that you have a functional external MySQL database that can be used for the secondary server database. This cannot be the same system that is used for the primary CRYPTO-Server, as only one instance of the CRYPTOAdmin6 database can be present in the same MySQL server. This MySQL database should be the same version/build of MySQL that is currently used for the primary CRYPTO-Server. 4. Install the CRYPTO-Server software (both the CRYPTO-Server, and CRYPTO-Console) on the secondary system. During the server installation, select your remote/external MySQL database system. Select the option for LDAP support if the primary server is using LDAP as the user database. When the installation on the secondary system is complete, do not log in with the CRYPTO-Console or register the system. 5. On the secondary server, restore the backup of the MySQL database that you created from step 2. Create the database as CRYPTOAdmin6. Once the database has been restored on the MySQL server used by the secondary, start only the MySQL service/daemon. 6. To enable two-way (bi-directional) replication between the MySQL databases, you must issue commands on both systems to grant permissions for the databases to connect and replicate, and must also place some entries in the my.cnf file. Details on this CRYPTO-Server 6.3 Best Practices Guide 21

22 configuration can be found at: Specifically, the command for MySQL versions and higher is: mysql> GRANT REPLICATION SLAVE ON *.* TO IDENTIFIED BY <slavepass>; where: <repl> is the username (root by default) <%.mydomain.com> is the fully qualified domain name of the MySQL server <slavepass> is the password assigned to the user (root by default) 7. Restart the MySQL service/daemon on both MySQL servers. Check the <servername>.err log (by default, located in the C:\CRYPTOCard\CRYPTO-Server\ mysql\data\ (Windows), /Applications/CRYPTO-Server/mysql/data (Mac), or /usr/local/cryptocard/cryptoserver/mysql/data/ (Linux) directory) on both MySQL servers for the status of the replication. If replication between both MySQL servers appears to be working, then continue. 8. Copy the ptclconfig.zip that is included with the CRYPTO-Server distribution to the secondary CRYPTO-Server. Extract the package to the C:\CRYPTOCard\CRYPTO- Server (Windows), /Applications/CRYPTO-Server (Mac), or /usr/local/cryptocard/cryptoserver (Linux) directory. This will create a PtclConfig directory; open a terminal and navigate to the new /PtclConfig directory. Execute the command:./ptclserverconfig <IPAddress_Secondary_CRYPTOServer> The tool will create.replica Entities for each protocol (i.e. CapProtocol.replica, HttpProtocol.replica, HttpsProtocol.replica, Ptclserver.replica, and RadiusProtocol.replica). 9. From the CRYPTO-Console, select Server System Configuration, and for each protocol s.replica Entity, ensure the Primary.EJB.Url and Primary.JMS.Url Keys are configured with the fully qualified domain name of your secondary CRYPTO-Server (i.e On the secondary server, go to \CRYPTOCard\CRYPTO-Server (Windows), /Applications/CRYPTO-Server (Mac), or /etc/cryptocard (Linux) and edit the capserver.properties file. Locate the server.identification = PtclServer string and replace it with server.identification = PtclServer.replica. Modify the Primary.EJB.Url and Primary.JMS.Url Key Values to reflect the fully qualified name of the secondary CRYPTO-Server. 11. To configure each CRYPTO-Server to be able to use either MySQL database (so that if one MySQL database fails, the CRYPTO-Server can fail over to the other MySQL database), edit the cryptocard-ds.xml file. By default, this file is found in the CRYPTOCard\CRYPTO-Server\jboss-3.2\server\cryptocard\deploy (Windows), CRYPTO-Server 6.3 Best Practices Guide 22

23 /Applications/CRYPTO-Server/jboss-3.2/server/cryptocard/deploy (Mac), or /usr/local/cryptocard/crypto-server/jboss-3.2/server/cryptocard/deploy (Linux) directory. Make a backup of this file before editing it. Then add the database details for the alternate MySQL server, below the existing MySQL server details: <datasources> <local-tx-datasource> <jndi-name>cryptocard/1</jndi-name> <connection-url>jdbc:mysql://<ipaddress_of_mysql_server>,<ipaddress_of_ second_mysql_server>:3306/cryptoadmin6</connection-url> <driver-class>com.mysql.jdbc.driver</driver-class> <user-name>root</user-name> <password></password> <connection-property name ="autoreconnect">true</connection-property> <connection-property name ="failoverreadonly">false</connection-property> </local-tx-datasource> </datasources> This needs to be done on both CRYPTO-Servers. 12. Set the permissions on the MySQL servers so that the CRYPTO-Servers can connect to them. On the MySQL database being used by the primary server, you must grant permissions for the secondary CRYPTO-Server system so that it is allowed to connect to that MySQL server in the event of a database failover. Then grant permissions on the MySQL database being used by the secondary CRYPTO-Server so the primary CRYPTO- Server can connect to it. CRYPTO-Server 6.3 Best Practices Guide 23

24 9 System Maintenance MySQL database backup and maintenance for CRYPTO-Server systems configured for replication Regular CRYPTO-Server database backup should be performed on the secondary CRYPTO- Server, using the mysqldump command. During this process, the secondary CRYPTO-Server cannot receive authentication requests as the database backup requires that each table be locked for the duration of the dump. The primary CRYPTO-Server will queue all transactions until the dump has completed. The CRYPTO-Server logs all authentication attempts into its database. This information can be used to generate token usage reports via the Token Usage Reporter within the CRYPTO- Console. If these data are not purged on a regular basis, database backups will take considerably longer to perform. It is highly recommended that weekly or monthly token usage reports be created then the data are purged. For more information about the Token Usage Reporter tool, please refer to the Logging and Reporting chapter in the CRYPTO- Server Administrator Manual. The following procedure is similar to the database backup procedure for a non-replicating (i.e. single) CRYPTO-Server system that is described in the MySQL Database Backup and Restore chapter in the CRYPTO-Server Administrator s Manual. 1. On the primary CRYPTO-Server, navigate to the \CRYPTOCard\CRYPTO-Server\ log (Windows), /Applications/CRYPTO-Server/ log (Mac), or /usr/local/cryptocard/crypto-server/log (Linux) directory. In the RADIUSProtocol.dbg or CAPProtocol.dbg file, verify that authentication requests are being sent to the primary CRYPTO-Server (see section 2 Working with CRYPTO- Server log files). 2. On the primary CRYPTO-Server, open the CRYPTO-Console and connect to the CRYPTO-Server. Select Tools Token Usage Reporter. Enter the report selection criteria, a filename, and the location of the report. Use * as a wildcard. A full report should be generated on a weekly or monthly basis. Once the report is complete, select Purge. 3. On the secondary CRYPTO-Server, stop the CRYPTO-Protocol, CRYPTO-Log, and CRYPTO-Server services/daemons. Do not stop the MySQL service/daemon. 4. Navigate to the CRYPTOCard\CRYPTO-Server\mysql\bin (Windows DOS prompt), /Applications/CRYPTO-Server/mysql/bin (Mac terminal), or /usr/local/cryptocard/cryptoserver/mysql/bin (Linux console) directory and type the command: mysqldump -u root -qv CRYPTOAdmin6 > cryptoadmin6.sql (Windows) mysqldump -u root -h CRYPTOAdmin6 > cryptoadmin6.sql (Mac) mysqldump -u root p -qv CRYPTOAdmin6 > cryptoadmin6.sql (Linux) 5. Copy the cryptoadmin6.sql database backup to a safe location (backup tapes, etc). CRYPTO-Server 6.3 Best Practices Guide 24

25 6. Start the CRYPTO-Server, CRYPTO-Protocol, and CRYPTO-Log services/daemons. CRYPTO-Server 6.3 Best Practices Guide 25