CA3000 Plug-in Manual. Codebench, Inc 6820 Lyons Technology Circle Ste. 140 Coconut Creek, FL 33073

Transcription

1 CA3000 Plug-in Manual Codebench, Inc 6820 Lyons Technology Circle Ste. 140 Coconut Creek, FL Voice: Fax:

2 This page is intentionally left blank.

3 Contents Chapter 1 About This Manual...1 Who Should Use It...1 Typographical Conventions...1 Related Material...2 Trademarks and Copyrights...2 Chapter 2 System Specifications...3 Hardware Architecture...3 Software Architecture...3 Chapter 3 Site Preparation...5 Card Formats...5 PIV Card Format Options...6 GSA 75-bit Wiegand bit BCD bit...8 Personnel View...10 Enabling PIV View...10 Chapter 4 Configuring the PACS Plug-in...13 PACS Tab...13 Preparing to Register Cardholders...13 PACS Template File...14 Configuring the PACS Database Parameters...18 Chapter 5 Card to PACS Data Mapping...19 Overview...19 PIV Data Elements...19 PACS Data Elements...21 Appendix A...23 Reference Documents...23 Index...25 Rev i

4 CONTENTS This page is intentionally left blank. ii Rev

5 About This Manual This document is divided into the following chapters:..... Chapter 1, About this Manual. Chapter 2, System Specifications, details the hardware and software specifications for the CA3000 Plug-in. Chapter 3, Site Preparation, provides guidance for preparing your existing infrastructure for using PIVCheck software. Chapter 4, Configuring the PACS Service, describes in detail the steps required to install and license the CA3000 Plug-in. Chapter 5, Card to PACS Data Mapping, explains how XML Card to PACS Data Mapping can be customized. Appendix A, Document References, lists the document references in this manual. Who Should Use It This manual is intended for administrators who want to learn how to install and manage the CA3000 Plug-in. Typographical Conventions This document uses the following typographical conventions: Command and option names appear in bold type in definitions and examples. The names of directories, files, machines, partitions, and volumes also appear in bold. Variable information appears in italic type. This includes user-supplied information on command lines. Screen output and code samples appear in monospace type. In addition, the following symbols appear in command syntax definitions. Square brackets [ ] surround user-supplied optional items. Angle brackets < > surround user-supplied values that are required. The construct "C:\" represents a regular Windows command shell prompt. Dollar signs $ represent macro names. Pipe symbol separates mutually exclusive values for a command argument.! This symbol denotes important information or values. This symbol denotes important information or values which are dependant upon additional software or configuration. Not acknowledging this information properly may prevent the software from functioning properly. Rev

6 ABOUT THIS MANUAL Related Material This document should be used in conjunction with the following documentation: Blacklist Plug-ins Guide PACS Plug-in Template XML File Specification PACS Service Manual OMNICheck User Manual PIVCheck Desktop User Manual Trademarks and Copyrights CardAccess is a registered trademark of Napco Security Technologies, Inc. Continental Access is a trademark of Napco Security Technologies, Inc. CardAccess 3000 and CA3000 are copyrighted by Continental Access. Microsoft Windows 7, Microsoft Windows XP, Microsoft Windows CE, Microsoft Mobile, Microsoft.NET, and Microsoft Compact Framework are registered trademarks of Microsoft Corporation. TWIC is a trademark of the United States Transportation Security Administration (TSA). PIVCheck, OMNICheck and PKI at the Door are registered trademarks of Codebench, Inc. PIVCheck Mobile Edition, PIVCheck Desktop Edition, PIVCheck Plus Mobile Edition, PIVCheck Plus Desktop Edition, OMNICheck Plus Edition and PIVCheck Certificate Manager are trademarks of Codebench, Inc. All other trademarked or copyrighted names mentioned herein are the property of their respective owners. 2 Rev

7 System Specifications The CA3000 Plug-in can be installed on the same computer as the CA3000 PACS system, or on a separate computer if necessary. While the most common configuration is for all PIVCheck Desktop and PIVCheck Mobile clients at a site to communicate with a single CA3000 Plug-in, there may be rare cases where a large number of terminals could require multiple computers running the CA3000 Plug-in. This configuration requires additional setup and configuration time and should be done only with the assistance of factory engineers Hardware Architecture A typical hardware configuration is shown below. A smart card reader and fingerprint scanner are attached to a desktop PC, or integrated into a ruggedized PDA, known as a mobile biometric terminal. Regardless of whether PIVCheck is installed on a desktop or integrated into a mobile biometric terminal, the identity verification process is the same. Once a PIV card is inserted into the card reader, the PIVCheck operator collects cardholder data, validates the PIV card with the PKI or TWIC CCL plug-ins, and uploads the captured data to the CA3000 PACS. The physical topology of the PIVCheck system is shown in the next diagram. While the certificate authority, TWIC CCL server, and the local OCSP/SCVP responder are crucial to its functioning properly, they are not part of the PIVCheck product. Software Architecture The CA3000 Plug-in bundle consists of between two and four sub-components, depending on which options are enabled: PACS Server - a TCP-based service that receives data elements extracted from smart card credentials PACS Service Template Engine - a highly configurable component that transforms raw card data elements to a format usable by the CA3000 PACS PACS Plug-in - PACS-specific code that maps card data elements to the CA3000 PACS user and card fields Certificate Manager - an optional service task that periodically revalildates digital certificates associated with cards that have previously registered PACS Service Fixed Reader Service - an optional TCP-based service that provides database and PKI support to high-end FIPS 201 fixed readers Functionally, the PACS Plug-in can perform the following tasks on behalf of PIVCheck mobile and desktop clients: Insert a record into the CA3000 PACS cards table using the data extracted from the smart card Update an existing PIV card record with data extracted from the smart card In addition, the CA3000 Plug-in can: Determine whether a given PIV credential exists in the CA3000 PACS Explicitly suspend a PIV card in the CA3000 PACS when called upon to do so by the Certificate Manager Import credential data from the CA3000 PACS for use with OMNICheck Plus Mobile clients Rev

8 SYSTEM SPECIFICATIONS The functions supported by the CA3000 Plug-in include PACS registration, mapping data from PIV data fields to PACS cardholder fields, and associating PIV cards with PACS badges. In addition, the PKI data stored by the CA3000 Plug-in can be used by the Certificate Manager to periodically check for revoked credentials. Federal Bridge TWIC CCL (Canceled Card List) Internet LAN OMNICheck Plus with PACS Registration OCSP Responder SCVP Responder LDAP Directory Server (PIV, PIV-I, CAC, FRAC) PACS Server PIVCheck PACS Plug-in PIVCheck Certificate Manager PIVCheck Plus Desktop Edition 4 Rev

9 Site Preparation This diagram shows how PIVCheck interacts with a CA3000 PACS CA3000 PACS PIVCheck PACS Server Supported OS: Windows 7 Ultimate Windows 7 Professional Windows Vista Ultimate Windows Vista Business Windows Server 2008 Windows Server 2003 R2 Windows XP SP3 OMNICheck Plus with PACS Registration PIVCheck Plus Desktop Supported OS: Windows 7 Ultimate Windows 7 Professional Windows Vista Ultimate Windows Vista Business Windows Server 2008 Windows Server 2003 R2 Windows XP SP3 Card Formats Card Formats specify the arrangement of data that a reader connected to a controller expects to read from access cards presented. When a person presents an access card at a reader, the reader passes the information encoded in it to the controller. This information is generally a string of bits. Various portions of this string may have specific purposes, which the controller can check while determining if the cardholder should be granted or denied access. For the controller to interpret the numerical string, you must define a card format for CA3000 to download to the controller for use with that reader. There are several well-known PIV card formats. The most popular are: GSA 75-bit (agency code, system code, credential number, expiration date) GSA 48-bit (agency code, system code, credential number) 64-bit BCD (agency code, system code, credential number, credential series code, individual credential series) 200-bit raw (entire 50-byte FASC-N including sentinels, field separators, and LRC) Rev

10 SITE PREPARATION PIV Card Format Options The most common card format produced by PIV card readers is the GSA 75-bit Wiegand format. This format consists of an even parity bit, agency code (14-bits), system code (14 bits), credential number (20 bits), and expiration date (25 bits), and odd parity bit. While this is a very common format, it omits the credential series code (CS), and more importantly, the individual credential issue (ICI). When a person's card is reissued due to loss or theft, the first 15 digits remain the same, and the ICI is incremented by one. Since the GSA 75-bit format omits the ICI, if the lost or stolen card is swiped on a 75-bit Wiegand reader, neither the access panel or the PACS can distinguish between this lost or stolen credential and its replacement. This has obvious security ramifications. GSA 75-bit Wiegand This format consists of the Agency Code, System Code, Card Number, Expiration Date 6 Rev

11 SITE PREPARATION..... For the Name field enter 75-bit GSA. For the Badge Format Type, select PIV (MSB) from the dropdown. Enter a Bit/Char Length of 75. Fill in the PIV and All Types field with the information shown above. Element Bits Start End Even Parity Agency Code System Code Card Number Expiration Date (expressed as YYYYMMDD) Odd Parity Total bit BCD This format includes no parity bits and includes the first 16 significant digits of the FASC-N. Keep in mind that one digit is equal to four bits. Rev

12 SITE PREPARATION For the Name field enter 64-bit. Enter a Bit/Char Length of 64. For the Badge Format Type, select PIV (MSB) from the dropdown. Fill in the PIV and All Types field with the information shown above. Element Bits Digits Start End Agency Code System Code Card Number Credential Series Credential Issue Total bit This format consists of the entire 50-byte FASC-N including sentinels, field separators, and LRC. 8 Rev

13 SITE PREPARATION..... For the Name field enter 200-bit. Enter a Bit/Char Length of 40. For the Badge Format Type, select PIV200 from the dropdown. Fill in the FASC-N 200 and All Types fields with the information shown above. Element Digits Start Agency Code 4 1 System Code 4 6 Card Number 6 11 Credential Series 1 18 Credential Issue 1 20 Personnel Identifier Organizational Category 1 32 Organizational Identifier 4 33 Association Category 1 37 Total 32 Rev

14 SITE PREPARATION Personnel View Enabling PIV View If no PIV badge formats have been created, then PIV card elements will not be available when viewing a cardholder record. 10 Rev

15 SITE PREPARATION..... After you have created a PIV badge format, standard and PIV tabs become available when viewing a cardholder record. By default the details for a Personnel record are set to standard view. Standard view does not display PIV card elements such as agency code, credential series and badge credential. Rev

16 SITE PREPARATION Select the PIV tab shown in the screen capture below to display the PIV elements of a credential. 12 Rev

17 Configuring the PACS Plug-in PACS Tab Preparing to Register Cardholders The process for preparing the server so that it can register cardholder is as follows. 1 Select the PACS tab in the CA3000 Plug-in. 2 Select the correct PACS Template file. To register new cardholders, use template.xml 3 Press OK. 4 Choose Yes to restart the CA3000 Plug-in. 5 After the CA3000 Plug-in has restarted, select the Syncronize Data button from the client (PIVCheck Plus Desktop Edition or PIVCheck Plus Mobile Edition). This will pull down any new configured options from the CA3000 Plug-in server onto the client. 6 Once the Syncronize Data has been completed, you can proceed to validate cards. 7 After a card has been validated, the operator will be prompted whether or not to register the card with the PACS. 8 If the template.xml file was selected, the operator will simply be asked whether or not to register the card with the PACS. No other information will be required. Rev

18 CONFIGURING THE PACS PLUG-IN PACS Template File Select the PACS tab to configure your PACS template file and establish a connection to your PACS server. Make sure you have specified the right path for the template you wish to use in your application. Verify the value in the PACS Template file entry field in the PACS tab of the Server Configuration dialog:! Copies of the factory template files are stored in the templates/factory subdirectory as read only files. The template files in this subdirectory will be removed on uninstall and updated on upgrades, but the files in the /templates directory will not be modified. 14 Rev

19 CONFIGURING THE PACS PLUG-IN..... Registering New Cardholders The CA3000 Plug-in provides a template.xml file that contains XML-based instructions for mapping smart card data elements to CA3000 PACS cardholder fields. The template can be used as-is or can also be modified to suit the site's specific needs. User Fields The CA3000 Plug-in template.xml file provides user fields which demonstrate how non-smart card data in the form of user fields can be included in the data import. User fields define custom data fields that direct the PIVCheck Mobile and Desktop clients to prompt for immediately after a card and its cardholder have been validated. To enable any of the following available user fields, open the template.xml file using a text editor, then locate the appropriate code below that applies to the user field you want to enable and remove the comment tags. After making changes, make sure you save the file, then perform a synchronize data from you PIVCheck and/or OMNICheck clients. A reference copy of the template.xml file is installed in the templates/factory subdirectory. This copy is read-only. More information about creating and editing template files can be found in the PACS Plug-in Template XML File Specification manual located in the CA3000 Plug-in installation directory.! For complete details about customizing the PACS Plug-in for your site, please refer to the PIVCheck PACS Template XML File Specification which accompanies this software distribution. Rev

20 CONFIGURING THE PACS PLUG-IN Displaying a Dynamic List of Access Rights <!-- The following definition for access rights (using a datasource) will only work if you have run data import to populate the pivcheck access rights data table. This provides the user with a dynamic list of the available access rights in the system. Up to 6 access levels can be assigned per card --> <!-- <userfield id="accesslevel.1" description="select Access Level:"> <datasource source="accessrights"/> </userfield> <item> <card pattern="\w+" src="[accesslevel.1]">[accesslevel.1]</card> <pacs>badge.accesslevel.1</pacs> </item> --> Displaying a Hardcoded List of Access Rights <!-- Optionally, access levels can be hardcoded by specifying the access right ID to which the cardholder s card is assigned. Access levels go from 1 to 6 in which N is the access level number. --> <!-- <userfield id="accesslevel.n" description="select Access Level:"> <option value="">none</option> <option value="0">access Level 0</option> <option value="1">access Level 1</option> </userfield> <item> <card>[accesslevel.n]</card> <pacs>badge.accesslevel.n</pacs> </item> --> Setting a Single Hardcoded Access Right <!-- example: hardcoded accedss level ID of 1 - this must exist on the CA 3000 PACS to work. --> <!-- <item> <card>1</card> <pacs>badge.accesslevel.1</pacs> </item> --> 16 Rev

21 CONFIGURING THE PACS PLUG-IN..... Setting a Hardcoded Access Level Date <!-- Access levels can have assigned access level dates. This is optional. N can be from 1 to 6. The access level date N must match the access level N. Example date format: 5/30/ :00:00 AM The $now() macro can also be used to specify an access level date: $now() - today's date and time stamp. $now (+/-N[YMDhmsZ]) N represents the number of units Units are Y (years), M (months), D (days), h (hours), m (minutes), s (seconds) or Z days following next midnight. For instance, $now(+5y) returns the date five years from now. $now(+5z) returns the date 5 days from the next midnight. --> <!-- example: date one month from now --> <!-- <item> <card>$now(+1m)</card> <pacs>badge.accesslevel.date.1</pacs> </item> --> User Defined Fields <!-- User defined fields go from 1 to 48. User defined field values are strings for the most part with the exception of user field 5, 6, 7 and 8 which are to be float --> <!-- <item> <card></card> <pacs>badge.userfield.n</pacs> </item> --> Rev

22 CONFIGURING THE PACS PLUG-IN Configuring the PACS Database Parameters 1 Press the Configure the PACS system button to launch the CA3000 Plug-in Database Options. 2 In the Provider Name drop-down, choose SqlClient Data Provider. 3 For the Connection String field, enter: Server=<Server Name>\SQLEXPRESS;Database=ca27LiveDB<timestamp>;Trusted_Connection=True Server is the SQL Server and instance name for the CA 3000 database. Database is the CA3000 PACS database name (ie: ca27livedb<timestamp> where <timestamp> is the date and time in format MMddyyyy_hhmmsss 4 Click the Test button. This step is essential since the Test button verifies that the the PACS Service is able to connect to the CA3000 PACS database (ca27livedb<timestamp>) with the given connection string. If successful, a Connection OK message is displayed. If an error occurs, details will be displayed in red.! The Test button does not verify connectivity with the database if a different log-in account is used to run the PACS Service. In cases where the database server is on a different computer, or a different log-in account is being used to run the PACS Service, you should test connectivity using SQL Server Management Studio. 18 Rev

23 Card to PACS Data Mapping Overview During the PACS enrollment process, the credentials on a PIV card must be captured and mapped to the data fields managed by the CA3000 Plug-in. This is accomplished using a PACS template file, template.xml. This template file specifies the data elements captured from a PIV card and how they should map to the fixed fields of a temporary cardholder record that can be imported by the CA3000 PACS Automated Import Utility Customized user fields also can be defined to capture additional cardholder data on mobile biometric terminals or desktops. As an example, when a new PIV cardholder is enrolled in the CA3000 PACS, the credentials as well as his PACS badge number can be recorded within the CA3000 Plug-in credential database. This gives Certificate Manager the ability to terminate access to controlled areas by checking the stored credentials against a PKI and/or blacklist and then updating the PACS if a revoked credential is found. For complete details about customizing the CA3000 Plug-in for your site, please refer to the PIVCheck PACS Template XML File Specification which accompanies this software distribution. The next section describes the standard configuration.! Your template file should only be altered by your PIVCheck administrator. PIV Data Elements The following table lists all of the PIV data elements that are available for card to PACS data mapping. PIV Data Element CA3000 Field Description Card Holder Facial Image.Image for Visual Verification Card Holder Fingerprints.Fingerprint I Card Holder Fingerprints.Fingerprint II CHUID.Authentication Key Map Badge.Photo N/A N/A N/A Cardholder photograph. Mandatory biometric data. Max of 2000 bytes. Mandatory biometric data. Max of 2000 bytes. Specified as an optional field. If the Card Authentication Key is symmetric it specifies the cryptographic algorithm and key storage location. CHUID.Expiration Date Badge.ExpireDate The date the card expires. CHUID.FASC-N N/A Federal Agency Smart Credential Number. CHUID.GUID CHUID.Issuer Asymmetric Signature N/A N/A Global Unique Identification Number. It must be present and may include either an issuer assigned IPv6 address or be coded as all zeroes. If the FASC-N begins with 9999, then the GUID is split across CardInt1, CardInt2, and Credential.CardNumber. An optional field written by the FASC-N issuer. It permits validation of the CHUID data with no knowledge of the issuer signing secret. Max bytes Rev

24 CARD TO PACS DATA MAPPING $substring([chuid.fasc-n], 0, 4) $substring([chuid.fasc-n], 4, 4) $substring([chuid.fasc-n], 8, 6) $substring([chuid.fasc-n], 14, 1) $substring([chuid.fasc-n], 15, 1) $substring([chuid.fasc-n], 16, 10) $substring([chuid.fasc-n], 26, 1) $substring([chuid.fasc-n], 27, 4) $substring([chuid.fasc-n], 31, 1) Printed Information.Agency Card Serial Number Printed Information.Employee Affiliation line 1 Printed Information.Employee Affiliation line 2 Badge.AgencyCode Badge.Facility Badge.Number Badge.Series Badge.Issue Badge.PersonID Badge.OrgCat Badge.OrgID Badge.OrgAssoc N/A N/A N/A Agency Code. Identifies the government agency issuing the credential. System Code. Identifies the system the card is enrolled in and is unique for each site. Credential Number. Encoded by the issuing agency. For a given system no duplicate numbers are active. Credential Series. Field available to reflect major system changes. Individual Credential Issue. Initially encoded as 1, will be incremented if a card is replaced due to loss or damage. Person Identifier. Numeric Code used by the identity source to uniquely identify the token carrier. (e.g. DoD EDI PN ID) Organizational Category: 1 Federal Government Agency 2 State Government Agency 3 Commercial Enterprise 4 Foreign Government Organizational Identifier: 1 FIPS 95-2 Agency Code 2 State Code 3 Company Code 4 Numeric Country Code Person/Organization Association Category: 1 Employee 2 Civil 3 Executive Staff 4 Uniformed Service 5 Contractor 6 Organizational Affiliate 7 Organizational Beneficiary Agency Card Serial Number of max 10 digits. Examples of employee affiliation include CONTRACTOR, ACTIVE DUTY, and CIVILIAN. Same as Affiliation Line 1. Max 20 characters. 20 Rev

25 CARD TO PACS DATA MAPPING..... Printed Information.Expiration date Printed Information.Name Printed Information.Issuer Identification X.509 Certificate for Card Authentication.Certificate X.509 Certificate for Digital Signature.Certificate X.509 Certificate for Key Management.Certificate X.509 Certificate for PIV Authentication.Certificate N/A Badge.FirstName Badge.LastName Badge.MiddleInitial N/A N/A N/A N/A N/A The expiration date printed on the card. It should match the CHUID.Expiration Date. Cardholder s full name. The database fields are obtained from macros $firstname([printed Information.Name]), $lastname([printed Information.Name]), and $initials([printed Information.Name]). Max 15 bytes. This key and certificate, if the key is an asymmetric key, supports PIV card authentication for device to device authentication purposes. This key and certificate support the use of digital signatures for document signing. This key and certificate support the use of encryption for the purpose of confidentiality. Used to authenticate the card and cardholder using the Personal Identification Number (PIN). PACS Data Elements The following table lists al of the PACS data elements that can be set using the template file. PACS Plug-in Field Description Badge.Pin Default value is 0 Badge.Enabled Badge.ActiveDate Badge.UseCount Badge.CompanyID Default value is True The current date and time, use macro $now() The use limit for Badge. A use limit of 255 means the card has unlimited uses and is exempt from use limit restrictions. Use limits must be enabled for the site in order for this field to be available. Default value set to 255. Company name in which the badge holder works. This field accepts seventeen alphanumeric characters. Badge.UserField.N User fields where N can be 1 to 48 Badge.AccessLevel.N Badge.AccessTime Badge.APBSet Badge.Contact Badge.ContPhone Badge.DateOfBirth The PACS record ID of the access right to which the cardholder s card is assigned. N is a unique number, N can be 1 to 6. Number of seconds the a door is held unlocked after a successful badge read. The APB setting is a manual method of presetting the Anti Passback status for the cardholder. This field is meant for entering the name of the badge holder's Supervisor. The field accepts twenty one alphanumeric characters. These fields are provided for entering the badge holder's contact phone numbers and their extensions. The fields accept thirty alphanumeric characters each. Badge holder s date of birth Rev

26 CARD TO PACS DATA MAPPING Badge.Dept Badge.DurUse Badge.Embossed Badge.Escort Department name in which the badge holder works. This field accepts seventeen alphanumeric characters. Duration Use allows the setting of a time period duration, due to which, successive reads of the same badge will be blocked, until the timer expires. Serial number printed on the card. Used for notation only. When checked, two badge reads are required at the reader for the Escorted cardholder to gain access. The second badge read must be from a non-escorted type card. Badge.Gender The gender of the cardholder, male, female or unspecified (F, M or U) Badge.GroupNo Badge.InitLoad Badge.Vehicle Badge.License Badge.Location Badge.SSN Badge.Shunt Badge.Track This field is used for selecting a group for database partitioning. The default selection in this field will be None. Control is active when access panel is in interactive mode. Refer to CA 3000 for more information. Description of the badge holder's automobile. The field accepts a maximum of seventeen alphanumeric characters. License Plate number of badge holder's automobile. The field accepts a maximum of eleven alphanumeric characters. Location in which the badge holder works. This field accepts seventeen alphanumeric characters. Badge holder s social security number. The field accepts twelve numeric digits only. When enabled the badge holder's card is set up as a 'shunt card'. Refer to the CA 3000 Help documentation for more information on shunting. Used to track a badge holder s movements troughout a building. When the Tracked check box is enabled (checked) for a particular badge record, a different priority level is assigned to the badge. 22 Rev

27 Appendix A A Reference Documents Federal Information Processing Standard Publication (FIPS 201-1): Personal Identity Verification (PIV) of Federal Employees and Contractors, NIST, March, NIST PIV Program web site, 3 NIST Special Publication : Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology, February NIST Special Publication : Interfaces for Personal Identity Verification Part 1: End-Point PIV Card Application Namespace, Data Model, and Representation, February NIST Special Publication : Interfaces for Personal Identity Verification Part 2: End-Point PIV Card Application Card Command Interface, February NIST Draft Special Publication : Biometric Data Specification for Personal Identity Verification, January NIST Special Publication : Cryptographic Algorithms and Key Sizes for Personal identity Verification, February NIST Special Publication (SP ): Guidelines for the Accreditation of Personal Identity Verification (PIV) Card Issuers (PCI's), June NIST Draft Special Publication A-1 (SP A-1): PIV Card Application and Middleware Interface Test Guidelines (SP Compliance), March NIST Draft Special Publication B (SP B): PIV Data Model Test Guidelines, July NIST Draft Special Publication B-1 (SP B-1): DRAFT PIV Data Model Conformance Test Guidelines, September 11, NIST Draft Special Publication Rev 1 (SP Rev 1): Codes for Identification of Federal and Federally-Assisted Organizations, April NIST Special Publication : A Recommendation for the Use of PIV Credentials in Physical Access Control Systems (PACS), November TWIC Reader Hardware and Card Application Specification Version 1.1.1, May TWIC Technical Advisory TA-2008-TWIC001-V1.0, TWIC Reader Functionality Augmentation, September, TWIC Technical Advisory TA-2009-TWIC001-V1.0, Format for a TWIC Card with no Fingerprint Biometric Data, March, TWIC Technical Advisory TA-2009-TWIC002-V1.0 Additional Error Code Definitions for TWIC Cards, March, TWIC Technical Advisory TA-2011-TWIC001-V1.0 Name Change of HOTLIST to CANCELED CARD LIST, February, TWIC Technical Advisory TA-2011-TWIC002-V1.0 Release of new TWIC Card and Card Applications, July, Smart Card Alliance Publication Number: PAC-07002: Physical Access Control System Migration Options for Using FIPS Compliant Credentials, September Rev

28 APPENDIX A This page is intentionally left blank. 24 Rev

29 Index A About This Manual...1 C Card to PACS Data Mapping PACS Data Elements...21 PIV Data Elements...19 Configuring the PACS Service...13 PACS Tab...13 PACS Template File...14 Registering new cardholders...15 P PACS Database Parameters...18 R Reference Documents...23 Related Material...2 S Server Configuration PACS Tab...13 Site Preparation...5 System Specifications...3 Hardware Architecture...3 Software Architecture...3 T Trademarks and Copyrights...2 Typographical Conventions...1 Rev