Silent installation suppresses the adapter installation wizard and the Launcher User Interfaces (UIs). It does not display any information or require interaction.
You can use the –silent option to install or uninstall the adapter in silent mode.
Note:
v The plug-in installs run time files from Microsoft. The installer for these run times shows some user interfaces and you cannot suppress these user interfaces.
v If you install the plug-in in silent mode, the uninstaller runs in silent mode irrespective of whether you are using –silent option or not.
Installing the plug-in by using the silent mode
Installing the plug-in with default options
To install the adapter with the –silent option:
1. Navigate to the location where you have stored the SetupPwdSync.exe.
2. Run the following command from command prompt:
SetupPwdSync.exe -i silent -DLICENSE_ACCEPTED=TRUE The adapter is installed in the adapter installation directory,
C:\Tivoli\PasswordSynch. A log file, pwd_out.txt, is created and the plug-in is installed with the default value, %SYSTEM_DRIVE_ROOT%:\Tivoli\
passwordsynch.
After you install the plug-in, you must:
1. Run the pfconfig.exe (For 32-bit version of the plug-in) and pfconfig64.exe(For 64-bit version of the plug-in) from the bin directory and configure the plug-in.
2. Install the CA certificates. For information about CA certificates installation, see “Installing CA certificates” on page 15.
3. Restart the workstation.
Installing the plug-in with command line options
You can specify the listed installation options from the command prompt when you install the plug-in by using the silent mode. For example, if you want to override the default installation directory path then, run the following command:
SetupPwdSynch.exe -i silent -DLICENSE_ACCEPTED=TRUE -DUSER_INSTALL_DIR=
"D:\Tivoli\MyFolder"
Note:
v The -D option is followed by a variable and a value pair without any space after the -D option.
v You must wrap arguments with quotation marks when the arguments contain spaces.
© Copyright IBM Corp. 2009 17
Table 8. Installation options
Option Value
-DUSER_INSTALL_DIR=Value Value overrides the default installation directory path. For example, D:\Tivoli\MyFolder.
-DLICENSE_ACCEPTED=Value Accept the IBM license for plug-in, the value must be TRUE.
When you do not specify this option, the default value is FALSE.
-DUSER_CERT_FILE=Value The name of the CA certificate file for your IBM Tivoli Identity Manager server. For example,
My_CertfileName.cer.
-DPATH_OF_CERT_FILE=Value The full path of the CA certificate file (excluding the file name) for your IBM Tivoli Identity Manager server. For example, C:\CA_My_Folder.
After you install the plug-in, you must:
1. Run the pfconfig.exe (For 32-bit version of the plug-in) and pfconfig64.exe(For 64-bit version of the plug-in) from the bin directory and configure the plug-in.
2. Restart the workstation.
Installing the plug-in by using the response file Generating the response file
You can use response file to provide inputs during silent installation. Response file can be generated by running the
following command. This runs the installer in interactive mode and install the plug-in.
SetupPwdSync.exe –r "Full path of response file"
For example:
SetupPwdSync.exe –r "c:\temp\PwdSynResponse.txt"
Note: If you are running this command to only generate the response file, you must uninstall the plug-in by using the uninstaller.
Creating the response file manually
You can also manually create the response file with the following content:
#Start of Response file
#Choose Install Folder
#---USER_INSTALL_DIR=Value
#Has the license been accepted
#---LICENSE_ACCEPTED=TRUE
#Select CA Certificate file.
#---USER_CERT_FILE=Value
PATH_OF_CERT_FILE=Value
#End of Response file
After you create the response file you can use it as:
SetupPwdSynch.exe –i silent -f "Full path of response file"
After you install the Windows Tivoli Password Synchronization plug-in, you must:
1. Run the pfconfig.exe (For 32-bit version of the plug-in) and pfconfig64.exe (For 64-bit version of the plug-in) from the bin directory and configure the plug-in.
2. Reboot the workstation.
Uninstalling the plug-in by using the silent mode
Run the following command from command line to uninstall the Windows Tivoli Password Synchronization plug-in by using the –i silent option. Specify the full path when you are not running the command from Uninstall_Tivoli Windows Password Synch Plugin directory in the installation directory of the plug-in.
"Uninstall Tivoli Windows Password Synch Plugin.exe" -i silent
For example, "C:\Tivoli\PasswordSynch\Uninstall_Tivoli Windows Password Synch Plugin\Uninstall Tivoli Windows Password Synch Plugin.exe" -i silent. Note: Restart the workstation to completely remove plug-in.
Chapter 4. Installing and uninstalling the plug-in by using the silent mode 19
Chapter 5. Configuring SSL authentication for the plug-in
In order to establish a secure connection between a IBM Tivoli Identity Manager adapter and the Tivoli Identity Manager server, you must configure the adapter and the server to use the Secure Sockets Layer (SSL) authentication. By configuring the adapter for SSL, you ensure that the Tivoli Identity Manager server verifies the identity of the adapter before a secure connection is established.
The Password Synchronization plug-in uses http with SSL to establish secure communications.
Note: In a production environment, you need to enable SSL security. For testing purposes you might want to disable SSL. However, if an external application that communicates with the adapter (such as Tivoli Identity Manager server) is set to use server authentication, you must enable SSL on the adapter to verify the certificate that the application presents.
You can configure SSL authentication for connections that originate from the Tivoli Identity Manager server or from the adapter. Typically, the Tivoli Identity Manager server initiates a connection to the adapter in order to set or retrieve the value of a managed attribute on the adapter. However, depending on the security
requirements of your environment, you might need to configure SSL authentication for connections that originate from the adapter. For example, if the adapter uses events to notify the Tivoli Identity Manager server of changes to attributes on the adapter, you can configure SSL authentication for Web connections that originate from the adapter to the Web server that is used by the Tivoli Identity Manager server.
This chapter presents an overview of SSL authentication and digital certificates.
Overview of SSL and digital certificates
When you deploy IBM Tivoli Identity Manager into an enterprise network, you must secure communication between the Tivoli Identity Manager server and the software products and components with which the server communicates. The industry-standard SSL protocol, which uses signed digital certificates from a certificate authority (ca) for authentication, is used to secure communication in a IBM Tivoli Identity Manager deployment. Additionally, SSL provides encryption of the data exchanged between the applications. Encryption makes data transmitted over the network intelligible only to the intended recipient.
Signed digital certificates enable two applications connecting in a network to authenticate each other's identity. An application acting as an SSL server presents its credentials in a signed digital certificate to verify to an SSL client that it is the entity it claims to be. An application acting as an SSL server can also be configured to require the application acting as an SSL client to present its credentials in a certificate, thereby completing a two-way exchange of certificates. Signed
certificates are issued by a third-party certificate authority for a fee. Some utilities, such as those provided by OpenSSL, can also issue signed certificates.
A certificate-authority certificate (ca certificate) must be installed to verify the origin of a signed digital certificate. When an application receives another
application's signed certificate, it uses a ca certificate to verify the originator of the
© Copyright IBM Corp. 2009 21
certificate. A certificate authority can be well-known and widely used by other organizations, or it can be local to a specific region or company. Many applications, such as Web browsers, are configured with the ca certificates of well known
certificate authorities to eliminate or reduce the task of distributing ca certificates throughout the security zones in a network.
Private keys, public keys, and digital certificates
Keys, digital certificates, and trusted certificate authorities are used to establish and verify the identities of applications.
SSL uses public key encryption technology for authentication. In public key encryption, a public key and a private key are generated for an application. Data encrypted with the public key can only be decrypted using the corresponding private key. Similarly, the data encrypted with the private key can only be decrypted using the corresponding public key. The private key is
password-protected in a key database file so that only the owner can access the private key to decrypt messages that are encrypted using the corresponding public key.
A signed digital certificate is an industry-standard method of verifying the authenticity of an entity, such as a server, client, or application. In order to ensure maximum security, a certificate is issued by a third-party certificate authority (ca).
A certificate contains the following information to verify the identity of an entity:
Organizational information
This section of the certificate contains information that uniquely identifies the owner of the certificate, such as organizational name and address. You supply this information when you generate a certificate using a certificate management utility.
Public key
The receiver of the certificate uses the public key to decipher encrypted text sent by the certificate owner to verify its identity. A public key has a corresponding private key that encrypts the text.
Certificate authority's distinguished name
The issuer of the certificate identifies itself with this information.
Digital signature
The issuer of the certificate signs it with a digital signature to verify its authenticity. This signature is compared to the signature on the
corresponding ca certificate to verify that the certificate originated from a trusted certificate authority.
Web browsers, servers, and other SSL-enabled applications generally accept as genuine any digital certificate that is signed by a trusted Certificate Authority and is otherwise valid. For example, a digital certificate can be invalidated because it has expired or the ca certificate used to verify it has expired, or because the distinguished name in the digital certificate of the server does not match the distinguished name specified by the client.
Self-signed certificates
You can use self-signed certificates to test an SSL configuration before you create and install a signed certificate issued by a certificate authority. A self-signed certificate contains a public key, information about the owner of the certificate, and the owner's signature. It has an associated private key, but it does not verify the origin of the certificate through a third-party certificate authority. Once you
generate a self-signed certificate on an SSL server application, you must extract it and add it to the certificate registry of the SSL client application.
This procedure is the equivalent of installing a ca certificate that corresponds to a server certificate. However, you do not include the private key in the file when you extract a self-signed certificate to use as the equivalent of a ca certificate.
Use a key management utility to generate a self-signed certificate and private key, extract a self-signed certificate, and add a self-signed certificate.
Where and how you choose to use self-signed certificates depends on your security requirements. In order to achieve the highest level of authentication between critical software components, do not use self-signed certificates, or use them selectively. For example, you can choose to authenticate applications that protect server data with signed digital certificates, and use self-signed certificates to authenticate Web browsers or IBM Tivoli Identity Manager adapters.
If you are using self-signed certificates, in the following procedures you can substitute a self-signed certificate for a certificate and ca certificate pair.
Certificate and key formats
Certificates and keys are stored in files with the following formats:
.pem format
A privacy-enhanced mail (.pem ) format file begins and ends with the following lines:
---BEGIN ---END
CERTIFICATE---A .pem file format supports multiple digital certificates, including a certificate chain. If your organization uses certificate chaining, use this format to create ca certificates.
.arm format
An .arm file contains a base-64 encoded ASCII representation of a certificate, including its public key, but not its private key. An .arm file format is generated and used by the IBM Key Management utility.
.der format
A .der file contains binary data. A .der file can only be used for a single certificate, unlike a .pem file, which can contain multiple certificates.
.pfx format (PKCS12)
A PKCS12 file is a portable file that contains a certificate and a
corresponding private key. This format is useful for converting from one type of SSL implementation to a different implementation.
Configuring certificates when the plug-in operates as an SSL client
In this configuration, the plug-in operates as an SSL client. For example, the plug-in initiates the connection and the Web server responds by presenting its certificate to the plug-in.
Figure 1 on page 24 illustrates how a IBM Tivoli Identity Manager plug-in operates as an SSL sever and an SSL client. When communicating with the Tivoli Identity Manager server, the plug-in sends its certificate for authentication. When
communicating with the Web server, the plug-in receives the certificate of the Web
Chapter 5. Configuring SSL authentication for the plug-in 23
server.
If the Web Server is configured for two-way SSL authentication, it verifies the identity of the plug-in, which sends its signed certificate to the Web server (not shown in the illustration). In order to enable two-way SSL authentication between the plug-in and Web server, use the following procedure:
1. Configure the Web server to use client authentication.
2. Follow the procedure for creating and installing a signed certificate on the Web server.
3. Install the ca certificate on the plug-in.
4. Add the ca certificate corresponding to the signed certificate of the plug-in to the Web server.
For more information on configuring certificates when the plug-in initiates a connection to the Web server (used by the Tivoli Identity Manager Server) to send a notification, see the Tivoli Identity Manager Information Center.
Tivoli Identity Manager Adapter
Tivoli Identity Manager Server
CA Certificate A Certificate A
CA Certificate C
Certificate C Web server
A B
C
Hello
Certificate A
Hello
Certificate C
Figure 1. IBM Tivoli Identity Manager plug-in operating as an SSL server and an SSL client