Service tools user IDs

Service tools user IDs are user IDs that are required to access service functions through dedicated service tools (DST), system service tools (SST), iSeries™ Navigator (for logical partitions and disk unit management), and Operations Console. Service tools user IDs are created through DST or SST and are separate from user profiles.

IBM^® provides the following service tools user IDs:

QSECOFR
QSRV
22222222
11111111

The passwords for service tools user IDs QSECOFR, QSRV, and 22222222 are shipped as expired. All service tools passwords are shipped in uppercase.

Start of change You can create a maximum of 100 service tools user IDs (including the four IBM-supplied user IDs). Specific authorities are granted to the IBM-provided service tools user IDs. The IBM-supplied service tools user ID 11111111 is useful when upgrading Operations Console. End of change

Note: When IBM ships a server, there is a QSECOFR i5/OS™ user profile and a QSECOFR service tools user ID. These are not the same. They exist in different locations and are used to access different functions. Your QSECOFR service tools user ID can have a different password from your QSECOFR user profile. Service tools user IDs have different password policies than i5/OS user profiles.

Creating additional service tools user IDs allows a security administrator to manage and audit the use of service tools without giving out the passwords to the IBM-supplied service tools user IDs. You can create additional service tools user IDs using dedicated service tools (DST) or system service tools (SST).

Attention: If you lose or forget the passwords for all i5/OS security officer profiles and all security service tools user IDs, you might need to install and initialize your system from distribution media to recover them. For this reason, it is recommended that you create multiple profiles and user IDs. Contact your service provider for assistance.

Service tools user IDs can have expiration dates, which allow you to minimize your server's security risk. For example, you can create a service tools user ID that is expired for an employee. The first time the employee uses the ID, the employee must change the ID. You can disable the user ID if a user terminates employment with the company, minimizing a former employee's potential to maliciously access service tools.

Functional privileges for service tools user IDs

The ability for a service tools user ID to access individual service functions can be granted or revoked. This is called a functional privilege. You can set up functional privileges that control which service functions can be accessed by any service tools user ID. Here are some examples of how you might want to use functional privileges:

You can allow one user to take communications and Licensed Internal Code traces and give a different user the functional privilege to manage disk units.
You can create a service tools user ID with the same functional privileges as the IBM-supplied QSECOFR service tools user ID. You can then disable the IBM-supplied QSECOFR service tools user ID. This will prevent people from using the known QSECOFR user ID and help protect your server from security risks.

Functional privileges can be managed using DST or SST. A Start Service Tools privilege allows a service tools user ID to access DST, but be restricted from accessing SST.

Before a user is allowed to use or perform a service function, a functional privilege check is performed. If a user has insufficient privileges, access to the service function is denied. There is an audit log to monitor service function use by service tools users.

Like service tools user IDs, device IDs also have permissions that can be granted or revoked and can prevent functions from working. Device IDs can be accessed using SST.