An authentication credential is the combination of a user ID and a password. Almost every activity in the satellite environment requires authentication, from the first connection to the satellite control database for a test synchronization, to the execution of a script. Authentication credentials reside both at the DB2 control server (in the satellite control database), and at every satellite in the environment. The master copy is at the DB2 control server. Every satellite maintains a shadow copy of the authentication credentials. Because all passwords in the satellite environment are encrypted, the authentication information on the satellites cannot be updated independently of the synchronization process with the DB2 control server. The encryption prevents unauthorized access to a password for a user ID, and allows you to maintain tight control over the security of the environment.
The DB2 control server maintains the master copy of all the authentication credentials that are required in the satellite environment. Because all authentication credentials are at the DB2 control server, you can manage all your authentication credentials from a central location.
When you create an authentication credential, you give it a name and provide a user ID and password. The password is encrypted when it is stored in the satellite control database. When you create a target, you provide the name of the authentication credential. The user ID and password of this authentication credential is used to authenticate the user with the target.
You must create an authentication credential for every DB2 instance or DB2 database that will be the target of script execution. Because all the satellites in a group execute the same scripts against the same targets, you only need to create one set of authentication credentials for the group. Because operating system scripts run locally on the satellite under the authority of the system administrator, you do not need to create an authentication credential for them.
Because you will know which targets the satellites in a group will need to authenticate with before you set up a model office or perform a deployment, you may find it more convenient to create the authentication credentials and targets before creating any batches. You can set up and maintain the authentication credentials by using the Create Authentication and Edit Authentication windows. You can set up and maintain targets by using the Create Target and Edit Target windows. These windows are available from the Satellite Administration Center.
| Note: | The online help for the Create Authentication and Edit Authentication windows states that the maximum length for a password is 256 characters. This length is not correct. The maximum supported length for a password is 31 characters. |
For information about how authentication credentials are used to authenticate the execution of a script in a batch step, see Components of a Batch Step. For information on how to update the passwords at the DB2 control server, see Managing Password Changes.
All user IDs and passwords that are used in the satellite environment for synchronization are stored in the instance_directory\security\satadmin.aut file on each satellite. The entries in this file mirror the authentication credentials at the DB2 control server. The satellite synchronization process maintains the satadmin.aut file by downloading the encrypted passwords from the satellite control database, and storing the encrypted passwords in the file. The use of encryption prevents direct access to all passwords that are used in the satellite environment.
Only satellites that are both recorded in the satellite control database and enabled to execute group batches can use the synchronization process to access and download the authentication credentials.
During a synchronization session, two types of security checks occur. First, the satellite must authenticate with the DB2 control server to download the batch steps that it will execute. Second, when each script is executed, if its target is an instance or a database, authentication occurs before the script can be executed. If the target of the script is the local operating system, the script executes locally on the satellite under the authority of the system administrator. For additional information, see Authentication with Target Servers for Script Execution.
The satadmin.aut file is created either during installation, or at the first test synchronization. During the installation process, you can supply a user ID and password that will be used to connect to the satellite control database on the DB2 control server. If you supply this information during installation, the authentication file is created and the user ID and password stored in it. If you do not provide the user ID and password during installation, you will be prompted for them the first time you run the db2sync -t command to perform a synchronization test. At this time the file will be created and the authentication credentials stored in it. For more information about the db2sync command, see db2sync - Start DB2 Synchronizer.
The first time that the satellite synchronizes, it downloads the authentication credentials for all the targets against which it must authenticate, and stores this information in its authentication file. All the passwords in the file will be encrypted. On subsequent synchronizations, changes to the authentication credentials are also downloaded so that the authentication credentials on the satellite are always current. For additional information, see Managing Password Changes.
When a satellite executes a script against a target that is a DB2 instance or a DB2 database, the user ID associated with the authentication credentials must be authenticated before the script can be executed. Authentication credentials, the combination of a user ID and password, are required to authenticate on each attach to a DB2 instance, or connect to a DB2 database. When the satellite executes the batch step, its authentication file is accessed to retrieve the user ID and password for the target, which is then used on the attach or connect to authenticate the satellite.
In addition to scripts, if you are using DB2 data replication, the Apply program also requires authentication credentials for each database that it must connect to when it replicates data. On a satellite, the Apply program checks for authentication credentials as follows:
| Note: | Because the replication password file does not encrypt passwords, it is recommended that you define all authentication credentials required for DB2 data replication by using the Satellite Administration Center. |
Because of standard security procedures, situations will occur in which the password must be changed for one or more of the target DB2 servers against which satellites authenticate. When this occurs, however, the satellites may experience authentication errors when they attempt to attach or connect to the target DB2 server. To avoid this problem, the satellite maintains both the current and the previous password for all of the DB2 databases or servers against which that satellite must authenticate. The fact that the satellite maintains both passwords enables you to make a transition from the existing password on a DB2 server to the new password.
To change the password associated with the user ID that one or more groups use to synchronize with the DB2 control server:
When you change the password used to access the DB2 control server, the Password changed column of the satellite details view in the Satellite Administration Center changes to Yes for all the satellites in the group. The Yes value indicates that the password required to access the DB2 control server is changed.
When a satellite next synchronizes, it will recognize that the password is changed, and download the changed password. As soon as the satellite obtains the new password, the Password changed column of the satellite details view in the Satellite Administration Center changes to No to indicate that the satellite has the new password.
The next time that the satellite synchronizes, it will use the new password to connect to the DB2 control server. Because the password is not yet changed at the DB2 control server, authentication will fail. When the authentication fails, the satellite will attempt to connect again, this time using the old password. This time, the authentication will succeed.
To change the password at a target DB2 server:
When the satellite next synchronizes, any new passwords are downloaded and stored, in encrypted format, in the satadmin.aut file on the satellite. The satellite will use the new password when it attempts to connect to the target DB2 server. If the password is not yet changed at the target server, authentication will fail. The satellite automatically recovers from this error by attempting to connect or attach again, this time using the old password. Authentication should succeed.
An authentication error can occur if a synchronization session is stopped or terminates before the satellite has executed all the scripts for that session. When an interrupted synchronization session is restarted, the satellite will execute the remaining scripts for the session before connecting to the DB2 control server to report the results of the session. The error occurs if any scripts that remain to be executed access a target DB2 server whose password changed between the time that the synchronization session was stopped and restarted. Because the satellite does not download updated passwords until it connects to the DB2 control server, the satellite will not have the correct password for the DB2 target that has undergone a password change. You can recover from this situation by refreshing the authentication credentials on the satellite. For more information, see Re-Creating or Updating the satadmin.aut File.
[ Top of Page ]