Chapter 8   Configuration Recovery


The objectives of this chapter are to cover:

• Dynamic Configuration Export and Import

• Configuration Security

• What data needs to be backed up

• What data is frequently written

• What configuration data needs to be backed up

• What happens when certificates expire?

• How to do Disaster Recovery?

Dynamic Configuration Export

---

To export dynamic configuration items for backup use the Config | Export setting in the iTTM admin screens.

This will return a file for download. Some browsers may display this file rather than saving - in this case use View Source to generate a text document containing the exported configuration and save to the desired location.

Configuration Security

---

Since the administration screens are accessible remotely, it is essential to protect the system from a malicious users attempting to change the iTTM config, rendering it open to attack. The administration screens are protected from unauthorised use but it might still be possible for a malicious user to trick an authorised administrator into importing a modified config file. To protect against this kind of attack, the configuration is exported with a signature. Only configuration signed by the designated key will be reimported (using Config | Import).

By default, the IPSC key will be used to sign configuration. If you wish to change the signing key or signing algorithm you will need the following Configuration Parameters found in /opt/ittm/myhost/tbase.properties for XMLConfig Import/Export

[DynamicConfigImportExport]

SigningAlgorithm - Default: SHA1withRSA

- algorithm with which to generate signature on exported config

SigningAlias - Default: CFGSC

- alias with which to mark token key store entry for signing exported config

To change the signing key, a token key store certificate / key entry should be generated and marked with the SigningAlias (the previous alias should be removed). This does not need to be issued by a Certificate Authority.

Dynamic Configuration Import

---

This is done in the same way that you import any file with the restriction that you can only import what you have exported from that specific instance of iTTM

Data Model

---

This section is intended to illustrate the Data Model so that the user can make their own decision about how they wish to procede with archiving and backup.

Figure 8-1    Oracle Data tables

Figure 8-2    Oracle OCSP tables

Figure 8-3    Comms

Figure 8-4    Audits

Figure 8-5    Users

Figure 8-6    Roles

Figure 8-7    Identrus

Figure 8-8    Errors

Database Table Definitions

This section classifies all of the tables in an iTTM/iTPS/BIAB/Tooled Up installation.

Table Name	Description
archive_table	No Longer Used
attribute_key_attrs	No Longer Used
attribute_name_attrs	No Longer Used
auditdata	Log of all audit events
audit_parameters	Log of all event specific parameters for each audit event
audit_services	Private Internal Data
audit_text	Mapping of audit strings to locale specific strings
authorisation	Private Internal Data
bill_data	An entry for each Identrus Message is made here, it maps the message signer information to a raw log entry.
certificateauthentication	Private Internal Data
cert_data	All unique certificates from Identrus CertBundles are logged here.
cert_table	No Longer Used
config	Private Internal Data
default_locale	Private Internal Data
environments	Private Internal Data
error	Log of all errors
error_codes	Mapping of error codes to locale specific strings and error severity
error_map_locales	Private Internal Data
error_parameters	Log of all error specific parameters for each error entry
error_support	Log of supporting error data for error entries - java stacktraces
identrus_data	For each Identrus message in the raw log table an entry exists here with key Identrus message fields extracted into the table entry
init_table	Private Internal Data
key_table	No Longer Used
ocsp_data	Every OCSP request/response that goes to the local OCSP responder - OR request/response from a remote OCSP responder in fallback mode.
ocsp_requests	Used by the OCSP responder in iTTM to log all requests received.
ocsp_responses	Used by the OCSP responder in the iTTM to log all responses sent out.
raw_data	All messages arriving at iTTMare logged in this tamper evident table
revocation_attrs	No Longer Used
revocation_serial_num	No Longer Used
revocation_table	No Longer Used
roles	Private Internal Data
role_description	Private Internal Data
salt_table	No Longer Used
smime_transport	All smime messages have their security information logged
smtp_connection	All connections to the SMTP proxy are logged
smtp_message	All smtp messages received by the SMTP proxy are logged
ssl_connection	No Longer Used
ttm_organisation	Private Internal Data
ttm_role	Private Internal Data
ttm_user	Private Internal Data
ttm_user_role	Private Internal Data
usernamepasswordauth	Private Internal Data

• All tables marked as 'Private Internal Data' are controlled by the specified product and the sructures of these tables are subject to change in future revisions.

• All tables marked as 'No Longer Used' are tables that existed in an earlier version of the product that are deprecated in the current version. Because of upgrade paths these tables are not dropped by their respective products, the DBA is at liberty to drop these tables once the contained data is no longer needed.

Auditdata

Contains internal audit information & indicates what the TC processed.

Figure 8-9    TTM table Auditdata

Column Name	Type	Size	NULL	Key Information	Description
auditid	NUMBER			Primary Key	Unique Identifier. Monotonic sequence number.
messageid	VARCHAR2	240			Not Used
machineid	VARCHAR2	50	Not Null		IP address of machine that logged audit event
timestamp	DATE		Not Null		The timestamp of when event was logged.
audittype	VARCHAR2	200	Not Null	FK-> audit_text.audit_text_id	The class of audit that this event is
message	VARCHAR2	1000	Not Null	FK - audit_text.audit_text_id	The audit message reference

Auditparameters

Log of all event specific parameters for each audit event.

Figure 8-10    iTTM table Auditparameters

Column Name	Type	Size	NULL	Key Information	Description
auditid	NUMBER			FK	The audit id in auditdata that this parameter relates to.
parameter	VARCHAR2	2000			The value of the parameter
parameter_no	NUMBER				The "tag" number when this parameter value is inserted into the audit_text

audit_text

Maps audit strings to locale specific strings

Figure 8-11    iTTM table audit_text

Column Name	Type	Size	NULL	Key Information	Description
audit_text_id	VARCHAR2	1000	Not Null	PK	Unique Id
text	VARCHAR2	1000			The text of the audit message or type in a locale specific form
locale	VARCHAR2	10	Not Null		The locale of the text

bill_data

Billing records are a sub-set of the information within the raw message log that provides sufficient information to determine who made each transaction. These tables are designed for used by third party tools that generate the actual Bill for the customer. The definitions for the bill table columns are as follows:

Figure 8-12    iTTM table bill_data

Column Name	Type	Size	NULL	Key Information	Description
subjectdn	VARCHAR2	500	Not Null		This will be the originator distinguished name extracted from the mandatory Identrus level 1 message signature. This will determine who should be billed.
issuerdn	VARCHAR2	500	Not Null		This will be the issuer distinguished name extracted from the mandatory Identrus level 1 message signature. This is to enable the identification of the exact key used to sign this message - in conjunction with the serial number field below.
serialnumber	VARCHAR2	100	Not Null		This will be the originator certificate serial number that may be used to identify the exact key used to sign the message - in conjunction with the issuer distinguished name.
rawrecordid	VARCHAR2	240	Not Null		This will be the RawRecordId of the associated raw log table record.

cert_data

In order to reduce the volume of data logged with each Identrus message the certificates contained with the message header are stripped out and stored in a certificate table. If the iPlanet Trustbase Transaction Manager has already logged a particular certificate in the table it will not be logged again. The information stored within the table is:

Figure 8-13    iTTM table cert_data

Column Name	Type	Size	NULL	Key Information	Description
issuerdn	VARCHAR2	500	Not Null	PK	The issuer distinguished name of the certificate, RFC 2253 format string.
serialnumber	VARCHAR2	100	Not Null	PK	The serial number of the certificate
subjectdn	VARCHAR2	500	Not Null		The subject distinguished name from the certifcate, in RFC2253 format
certdata	LONG		Not Null		The Base64 certificate data.

Error

The actual error log table is described below, this table is not normally viewed by the administrator directly, instead there is an Oracle view called errorview that provides a resolved view of the errors that have been logged.

Figure 8-14    iTTM table error

Column Name	Type	Size	NULL	Key Information	Description
errorid	NUMBER		Not Null	PK	This is a unique id for the error log entry; it is generated from a monotonic sequence that means that this field may be used to accurately order error messages in the order that they were logged
errorcode	VARCHAR2	7		FK - error_codes.errorcode	This is the errorcode of the error being logged, see the error_codes table description.
timestamp	DATE				This is an ORACLE DateTime field that identifies when the error was logged.
machineid	VARCHAR2	50			This is a string representing the IP address of the iPlanet Trustbase Transaction Manager that logged the error - this may be different in a multi-node IAS installation.
contextid	VARCHAR2	200			This context id field is for future expansion.

error_codes

The iPlanet Trustbase Transaction Manager error logging mechanism requires that every different occurrence of an error be given a code which is unique throughout iPlanet Trustbase Transaction Manager.

Figure 8-15    iTTM table error_codes

Column Name	Type	Size	NULL	Key Information	Description
errorcode	VARCHAR2	7	Not Null	PK	This is the unique errorcode string that identifies the error; this must be 7 characters exactly. The normal for an error code is XXXnnnn. Where XXX is a three-letter code for the service or subsystem and nnnn is a unique number. e.g. IPH0009 is an error in the Identrus Protocol Handler.
classname	VARCHAR2	500			The class from which this error is logged. This places a constraint that each error code may only be used from one place.
severity	NUMBER				This is the severity level of the error, described previously. Constants for each of the error severities can be located in the uk.co.jcp.tbaseimpl.log.error.ErrorLog class.
message	VARCHAR2	2000	Not Null		This is the localised version of the error message that will appear in the error log. Parameters may be used in this message as described by the standard Java class java.text.MessageFormat. The values to be placed in these parameters are passed in an array of strings that one of the ErrorObject constructors allows.
locale	VARCHAR2	10	Not Null

error_parameters

This is a cross referencing table used for querying errors. parameters are used to expand text according to the error text.

Figure 8-16    iTTM table error_parameters

Column Name	Type	Size	NULL	Key Information	Description
errorid	NUMBER			FK - error.errorid	Error Number
parameter	VARCHAR2	200			Parameter description
parameter_no	NUMBER				Parameter number

error_support

When an error is logged it is often accompanied by some free form string data which helps to store the context in which the error occurred to aid diagnosis. The most common example of such data is exception stack traces.

Figure 8-17    iTTM table error_support

Column Name	Type	Size	NULL	Key Information	Description
errorid	NUMBER			FK - error.errorid	This links this entry to an entry in the Error table
datatype	VARCHAR2	200	Not Null		This datatype is an arbitrary string identifier that categorises the data in the data field. The only value for this field defined by iPlanet Trustbase Transaction Manager is "STACKTRACE" which identifies the contents of the data field to be a Java Exception Stack Trace.
data	LONG				Free form string data

identrus_data

The Identrus data table records identrus specific message data, which can be related to the raw log records in the raw_data table, using the rawrecordid foreign key.

Figure 8-18    iTTM table identrus_data

Column Name	Type	Size	NULL	Key Information	Description
rawrecordid	VARCHAR2	240	Not Null	FW - rawdata.recordmarker	the id of the associated raw log record
msggrpid	VARCHAR2	120	Not Null		the Identrus MsgGrpId from the NIB of the message
msgid	VARCHAR2	120	NotNull
doctype	VARCHAR2	120	Not Null		the DOCTYPE of the message.e.g.CSCRequest, PingRequest etc..
connectionid	VARCHAR2	100	NotNull		No Longer Used
protocoltype	VARCHAR2	10	Not Null		The protocol over which the messge arrived e.g. HTTP or SMTP
input	NUMBER		Not Null		1 indicates message was inbound to the TC. 0 indicates that the message was outbound from the TC.

ocsp_data

This data records all the ocsp transactions -- responses and requests that are carried out between the local ocsp responder and iTTM.

Figure 8-19    iTTM table ocsp_data

Column Name	Type	Size	NULL	Key Information	Description
ocspid	NUMBER		Not Null	PK	A unique identifier for the record
type	VARCHAR2	2000	Not Null		OCSPREQUEST or OCSPRESPONSE
message	VARCHAR2	2000	Not Null		A text summary of the contents of the request or response
machine	VARCHAR2	2000	Not Null		The URL to which the request was submitted to or the response was received from
timestamp	NUMBER		Not Null		The date and time that the entry was made
data	LONG		Not Null		Base64 encoding of the request or response

ocsp_requests

Records messages sent from iTTM to the OCSP Responder.

Figure 8-20    iTTM table ocsp_requests

Column Name	Type	Size	NULL	Key Information	Description
id	VARCHAR2	127	Not NULL	PK	Unique Identifier
requestor_name	VARCHAR2	500	Not Null		The DN of the person requesting the OCSP
signed	NUMBER				Whetehr it was signed (0 or 1)
version	NUMBER				Version number of OCSP
request	LONG RAW				DER of the request
timestamp	DATE		Not Null		Time of the request

ocsp_responses

Records messages received from the OCSP responder to iTTM

Figure 8-21    iTTM table ocsp_responses

Column Name	Type	Size	NULL	Key Information	Description
id	VARCHAR2	127	Not Null	PK	Unique Identifier connected between request and response
status	NUMBER				Overall status of the response (See RFC2560)
response	LONG RAW				DER of the response
timestamp	DATE		Not Null		Time of the response

raw_data

The raw log inserts a row into a relational database table for each log operation. The structure of the database table is described here. All raw log tables have the same structure, although each raw log uses a different table, whose name is determined when the raw log is created with the AddLoggerWizard. The raw logging facility records raw incoming and outbound message data.

Figure 8-22    iTTM table raw_data

Column Name	Type	Size	NULL	Key info	Description
sessionid	NUMBER		Not Null		The id of the raw log session that wrote record
logconnectionid	NUMBER		Not Null		The id of the connection within the session
recordid	NUMBER		Not Null		The id of the record within the connection
msggrpid	VARCHAR2	120			Message Group Id
msgid	VARCHAR2	120			Message Id
doctype	VARCHAR2	120			doctype of message
recordmarker	VARCHAR2	240	Not Null	PK	A unique monotonically increasing identifier
connectionid	VARCHAR2	100
protocoltype	VARCHAR2	10
input	NUMBER
timestamp	NUMBER		Not Null		An integer which represents the UNIX time at which the record was logged.
rawdata	LONG		Not Null		The Identrus Message XML, without the CertBundle fields. The certificates from the bundle are logged separately in the "cert_data_table"
digestofrecord	RAW	2000			A SHA-1 digest of this record.
signeddigestofcalculation	RAW	2000			An RSA signature of this record and data from the previous record.

smime_transport

Logs incoming SMIME connections

Figure 8-23    iTTM table smime_transport

Column Name	Type	Size	NULL	Key Information	Description
connection_id	VARCHAR2	100	Not Null		Provides a link back to the smtp_message table
peer_issuer_dn	VARCHAR2	2000			The issuer_dn of the certificate that was used to verify the message
peer_cert_serial_number	VARCHAR2	100			The serial number of the certificate used to verify the message.
message_protection	VARCHAR2	100			The type of protection used to secure the message
time_stamp_type	VARCHAR2	10			The type of timestamp LOCAL or NETWORK
time_stamp	DATE		Not Null		The time at which the entry was made

smtp_connection

The ssl_connection and smtp_message tables both have connection_id fields that are passed to the iPlanet Trustbase Transaction Manager running in the application server. This connection_id is stored within the Identrus Log table allowing queries that link the originator information with the actual requests made.

Figure 8-24    iTTM table smtp_connection

Column Name	Type	Size	NULL	Key Information	Description
stream_id	VARCHAR2	100	Not Null		Identifier for the connection
peer_ip_addr	VARCHAR2	20	Not Null		IP address of the peer
timestamptype	VARCHAR2	10			Whether the time of the connection was local or remote
timestamp	DATE		Not Null		The time the connection was made

smtp_message

Logs incoming SMTP mail messages.

Figure 8-25    iTTM table smtp_message

Column Name	Type	Size	NULL	Key Information	Description
stream_id	VARCHAR2	100	Not Null		A unique id for the smime_transport
connection_id	VARCHAR2	100	Not Null		A unique id for the smtp connection
recipients	VARCHAR2	1000	Not Null		The recipients of this message
sender	VARCHAR2	100	Not Null		The sender of this message
timestamptype	VARCHAR2	10			The type of timestamp LOCAL or NETWORK
message_valid	NUMBER		Not Null		Is the message valid? 1 indicates it is valid
message_invalid_reason	VARCHAR2	1000			The reason for the invalidity of the message
timestamp	DATE		Not Null		The date and time at which the entry was made

What configuration data needs to be backed up?

---

Configuration information is split into two sections: static information (changing which requires a restart of Trustbase) and dynamic information (at present this consists of the Audit Logging and Error Logging settings).

Static configuration can easily be backed up by copying the

1. /opt/ittm/myhost/*.properties files

2. /opt/ittm/store certificate database

to a storage directory. Typically this would involve

mkdir /opt/temp

cd /opt/ittm/store

cp -r * /opt/temp

3. As mentioned in an earlier section, to export dynamic configuration items for backup use the Config | Export

setting in the iTTM admin screens.

This will return a file for download. Some browsers may display this file rather than saving - in this case use View Source to generate a text document containing the exported configuration and save to the desired location.

4. For a list of sql tables see for instance

   /opt/ittm/current/config/sql

   su oracle

   sqlplus tbase/tbase

   select TABLE_NAME from USER_TABLES;

   exit;

5. We now list the important sql tables
   1.       Identrus Local OCSP Log

      OCSP_DATA

1.       Identrus Message log

IDENTRUS_DATA

1.       Trustbase Raw log (linked to Identrus_data)

   RAW_DATA

   INIT_DATA

2.       Trustbase OCSP Responder (optional)

   OCSP_REQUESTS

   OCSP_RESPONSES

3.    Trustbase Configuration Table

   CONFIG

4.       Trustbase Authorisation Table

   AUTHORISATION

   ROLES

   ROLE_DESCRIPTION

5.       Trustbase Errror codes

   ERROR

   ERROR_CODES

   ERROR_PARAMETERS

6.       Trustbase Certificate Store

   CERT_DATA

7.       Trustbase Auditing Subsystem

   AUDITDATA

8.       Trustbase Auditing Subsystem

   AUDITPARAMETERS

   AUDIT_SERVICES

   AUDIT_TEXT

Take a snapshot backup of the environment.

su - oracle

exp

Export: Release 8.1.7.0.0 - Production on Wed Feb 27 10:30:38 2002

(c) Copyright 2000 Oracle Corporation. All rights reserved.

Log as a super user with DBA privilage and export the iTTM user. Refer to the Oracle documentation http://technet.oracle.com for the Export tool user guide.

6. To backup the LDAP directory used by iAS you can replicate the server, see for instance

   http://docs.sun.com/source/816-5770-10/adconfig.htm#13057

7. iWS copy the installation directory i.e. /opt/iws6

8. The HSM security world i.e. /opt/nfast/kmdata

9. iTTM software components are of course available on the CD-ROM supplied with this document.

What happens when certificates expire?

---

It is possible to have two sets of certificates running simultaneously. When certificates are nearing their expiry date the following procedure needs to be adopted.

There are two cases:

1. CA certificate expiry
   1. New CA cert issued to same key

   Add the new CA certificate as a TrustedCertificateEntry using the TokenKeyTool

   1. New CA cert issued to new CA key

   All certificates issued by the expired certificate in a Trust Domain must be reissued with the CA certificate, and imported to the KeyEntry using TokenKeyTools importkeychain command.

2. Subject Certificate expiry
   1. New Certificate to be issued to same key

      Use TokenKeyTool to generate a Certificate request for the KeyEntry associated with the expired certificate and import the resulting certificate to the KeyEntry.

   2. New cert to be issued to new key

      Generate new key (with same subject name as old key, if desired) using TokenKeyTool. Generate a Certificate request, and import the resulting certificate to the KeyEntry. More pertinent aliases from the old to the new KeyEntry using TokenKeyTool

How to do Disaster Recovery?

---

In the event of hardware or disk failure it will be necessary to perform a disaster recovery. By ensuring the following contents are intact through restoration from backup, a iPlanet Trustbase Transaction Manager can continue its operation.

• nCipher Users only. nCipher "Security World" needs to be restored according to the KeySafe User Guide using the Administrator Card Set and the nCipher backup data.

• Reinstall iWS 6.0 SP2, iAS 6.0 SP3, database and iTTM 3.0.1

• Reinstate /opt/ittm/myhost

• Import saved Configuration via
  
  

• Reinstate database from the backup of tables created under the user specified in the SQL script in your Installation Guide. If necessary consult your Database Administrator.

  
  

  ---

  Note	Refer to the installation worksheet for information about the setup of iPlanet Trustbase Transaction Manager's application server and database.

  ---