Preventing Startup Program from Running

In the QCTL controlling subsystem, there is an auto job entry called QSTRUPJD. It runs as soon as the QCTL is started. In the QSTRUPJD job description, a request data CALL QSYS/QWDAJPGM retrieves system value QSTRUPPGM. The program that is specified in the system value will run. If system value QSTRUPPGM is set to *NONE, there is no startup program to call.

To change the system value, on the operating system command line type the following:

CHGSYSVAL SYSVAL(QSTRUPPGM) VALUE(*NONE)

Press the Enter key.

The help text on the operating system for the system value includes the following:

A change to this system value takes effect the next time the system is IPLed. The shipped value is QSYS/QSTRUP.

Starting of TCP/IP Interface Fails with Message TCP1B01

When using the STRTCPIFC command, or when trying to start a TCP/IP interface from the NETSTAT or CFGTCP menus, the start attempt times out with error message TCP1B01. The message reads:

Message ID . . . . . . . . . : TCP1B01

Message file . . . . . . . . : QTCPMSG

Library . . . . . . . . . : QSYS

Message . . . . : Unable to determine if &1 interface started.

Cause . . . . . : The QTCPIP job in the QSYSWRK subsystem is not active, or the default wait time for your job was exceeded while waiting for the interface to start.

Recovery . . . : Use the Work with Active Jobs (WRKACTJOB) CL command to list the active jobs in the QSYSWRK subsystem. If the QTCPIP job is not active, issue the End TCP/IP (ENDTCP) CL command followed by the Start TCP/IP (STRTCP) CL command. After STRTCP completes processing, issue the Start TCP/IP Interface (STRTCPIFC) CL command again. If the QTCPIP job in the QSYSWRK subsystem is active, continue to look in the QTCPIP job log to determine if the &1 interface was started. To avoid this problem when using STRTCPIFC, wait for system activity to decrease, or increase the default wait time for your job using the Change Job (CHGJOB) CL command.

Despite the recovery action listed, the problem can actually be due to authority issues. When using the WRKJOB command on the QTCPIP job (WRKJOB QTCPIP), it is possible to see no active QTCPIP jobs. Working with the most recent job in OUTQ status, and reviewing the joblog, it is very likely that message CPFA09C is posted in the joblog. Typically this message refers to an object named QLGPGCMA.LOCALE. However, the message can vary. It is very possible that the object is an Integrated File System object and is potentially the root directory ('/'). Verify the root directory's authority by using the command WRKLNK OBJ('/') or verify the authority to the object identified in the error message. Use Option 9 to view the authority, and ensure *PUBLIC is not set to *EXCLUDE.

Displaying Previous Sign-On Information

When the QDSPSGNINF is set to one, the Previous Signon Date and Time is displayed correctly when using Client Access connectivity. The last date/time of signon for the user profile is updated when the security API is called to verify a positive indicator and also updates the user profile. If the password is good for the ID provided, the API returns a positive indicator and also updates the user profile. There is no implication that this sign-on was for an interactive job.

The Signon Server for Client Access (for APPC and Sockets) calls the security API. Other products (such as an OEM emulator) may not call the security API, for example, Telnet from the DOS prompt. In addition, the PCOMM product (not the emulator shipped with Client Access) goes straight to the Telnet server and will not go through the Client Access Signon Server.

The Client Access Signon Server is used for a specific reason. If the Client Access user is running Data Transfer or RMTCMD, security must verify a user ID and password, and that would be a previous signon. The term signon means the last time a user ID and password were verified but not necessarily when a an interactive job was started. Client Access has a suite of functions that do not use a interactive job. In that case, the Client Access Signon Server is used to verify that the user ID and password are correct. Therefore, the date and time stamps for the user profile reflects the previous time that the user ID and password were checked rather than only the last time that an interactive job was started. This is working as designed and is not a defect.

As long as the same user ID and password are used for the Client Access sign-on and again later at the time the interactive job is started, you will see where the date and time stamps are correct for the previous sign-on. We understand that, in some cases, this information may not mean much. But, the last time that the password was verified and the user attempted any type of signon is always the date listed. This occurs when starting Client Access for the first time or when closing a Client Access connection and the user is prompted for the AS/400 sign-on information.

Group Profile Names Cannot Be Used for Authentication

User names that are group profiles cannot be used as the Security Server ID when security is enabled with the LocalOS user registry. Nor can group profiles be used to authenticate to IBM® WebSphere® Application Server when attempting to access any protected WebSphere resource. Use the DSPUSRPRF command to determine if a user profile is used as a group profile. Each such user profile is assigned a unique group ID number.

Securing a Library from Some Users but Allowing *PUBLIC Access

There are times when you want a person or group to have less access than *PUBLIC has. To be the most secure possible, you can even make the entire system excluded from the user except what you want that user to be able to see.

For the person or group, do the following:


1 To exclude a person from all libraries on the system and, therefore, all objects in libraries on the system, run the following command:
GRTOBJAUT OBJ(QSYS/*ALL) OBJTYPE(*LIB) USER(xxxx) AUT(*EXCLUDE)
2 Run the following command:
DSPSYSVAL QSYSLIBL
Document every library in the system library list.

3 For each library in the system library list, run the following command:
RVKOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(*ALL)
This allows the user to access the libraries in the system library list. Without this, the user cannot sign on.

4 Do the same thing for each library in the user library list (which is listed in their job description). Then, repeat Step 3 for each library added to the user's library list.

5 For each additional library you want the excluded user to be able to use objects in that library, do one of the following:
To give the user the same authority that public does, run the following command:
RVKOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(*ALL)
To give the user specific authority to the library, run the following command:
GRTOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(xxxx)

To give the user specific authority to the library, run the following command:

GRTOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(xxxx)

If a user is *EXCLUDE from a library, that user is excluded from all objects in the library. However, if the user can *USE the library, the user can do more than merely *USE the objects within. The authority goes down to the specific object authorities. Therefore, the user might be able to change or even delete objects within the library.


The user must always have access to the following:

o The libraries in their library list.

o Most objects available to *PUBLIC in QSYS.

o The device that they're signing in from, with at least *CHANGE authority.

o Their own user profile, with at least Operator and Management data authorities, and all data authorities.

Without these, the user is not able to sign on.

What happens if the QSECOFR user profile gets deleted?

If the QSECOFR user profile gets deleted from the system, the best way to ensure it is properly re-created is to restore it from your latest full system backup tapes or security backups (created with the SAVSECDTA command).

This ensures that all authorities are returned. (Others who might have security authorities might not have the complete range of special authorities and, therefore, cannot authorize other users to these.) If full system or security backups are not available, the default values for QSECOFR can be restored from PID tapes or CD-ROM.

Internal security object not available – Message Identifier Message CPF2247 RC6

When a message CPF2247 RC6 is posted, there is no explanation on what a RC6 means. Below is the text that will be seen:

Message ID . . . . . . . . . : CPF2247
Message file . . . . . . . . : QCPFMSG
Library . . . . . . . . . : QSYS
Message . . . . : Internal security object not available. Reason code &1.
Cause . . . . . : An internal security object is not available for one of the following reasons:

1-Object is locked by another process.
2-User profile does not have enough auxiliary storage.
3-Interactive profile is damaged.
4-Damaged object detected, it is not an interactive profile.
5-Unable to access temporary interactive profile.

A RC6 indicates that the Password for user &1 not available. This will occur as a result of system value QRETSVRSEC being set to 0 when the profile was created and the password has not been changed since the system value was changed to 1. The fix is to change the password for the profile on each of the nodes.

Checking System Authority

When a user attempts to perform an operation on an object, the system verifies that the user has authority for the operation. The system first checks authority to the object library. If the authority to the library is adequate, the system checks authority to the object itself. In the case of database files, authority checking is done at the time the file is opened, not when each individual operation to the file is performed.

During the authority-checking process, when any authority is found (even if it is not adequate for the requested operation) authority checking stops and access is granted or denied. Adopted authority function is the exception to this rule. Adopted authority can override any specific (and inadequate) authority found. See the topic Objects That Adopt the Owner's Authority in the Security Reference manual for more information about adopted authority.

The system verifies a user's authority to an object in the following order:

1. User's *ALLOBJ special authority

2. User's specific authority to the object

3. User's authority on the authorization list securing the object

4. Group's *ALLOBJ special authority

5. Group's authority to the object -- see Note below.

6. Group's authority on the authorization list securing the object

7. Public authority specified for the object or for the authorization list securing the object

8. Program owner's authority, if adopted authority is used

Note: Authority from one or more of the user's groups may be accumulated to find sufficient authority for the object being accessed.

Determining What Objects Were Deleted with User Profile Deletion

If an administrator deletes a profile and also accidentally deletes the owned objects, it is possible to track what objects may have been deleted if security auditing is already being used at that time with QAUDLVL set with type *DELETE.

In the following example, user SMOHAMED deletes user profile COCO04 with the following command:

DLTUSRPRF USRPRF(COCO04) OWNOBJOPT(*DLT)

At the time it was deleted, the user profile owned a number of objects including job queues COCO401 through COCO405.

Using security auditing, it is possible to create an output file containing the deletes using the following commands:

Step 1: Create a file based on the correct field description file for DO journal entries:

CRTDUPOBJ OBJ(QASYDOJ4) FROMLIB(QSYS) OBJTYPE(*FILE) NEWOBJ(COCODELETE)

Step 2: Create an output file from the appropriate journal entries. In this example, I also narrowed down the search with specifics for date and time.

DSPJRN JRN(QAUDJRN) FROMTIME(083106 0730) ENTTYP(DO) OUTPUT(*OUTFILE) +

OUTFILFMT(*TYPE4) OUTFILE(COCODELETE)

Step 3: Look at the resulting file with the following command:

WRKF FILE(COCODELETE)

The following is shown:

 

 

 

 

 

 

 

 

 

Press F20 one time to get to the following screen.

 

 

 

 

 

 

 

 

As you can see, it does not reference the owner of the deleted objects (COCO04) in each entry. However, in the three tests I made, the owned objects were listed immediately above the deletion of the profile. Therefore, the entries are not a definitive answer but at least give a list of everything the administrator deleted immediately before the actual deletion of the profile. Unless the administrator deleted objects right before going on to delete the profile, the list should be fairly accurate.

SRC A9002000 on an HMC-Managed System after Installing from a SAVSYS

A restore was completed from a V5R1 system to a new Model 570 at V5R3 following the procedure for a slip migrate release. At the point where the users were ready to do a B-IPL, they could not access the system console, which was a HMC console. They received an SRCA9002000, which indicates the system console cannot be found. A manual B-IPL works fine through DST and locates the console.

The problem was with the old controller type that was brought over with the restore from the V5R1 system. WRKCTLD showed controllers, but these were brought over from a V5R1 configuration. They did not work because the controllers used for an HMC console are of a different type. There was a 2746 Twinax CTLD varied on with no device under it. They had 5 CTL0x twinax controllers.

To resolve the problem, vary off all old CTLDs from the V5R1 system and turn on QAUTOCFG. After the normal IPL starts, it will autoconfigure a CTLD for the HMC console that is the correct type, and the console will have a sign on screen.

HMC 5250 Console Disconnects After a Period of Inactivity

Problem

After upgrading to HMC V4R2.1_0902, the HMC 5250 console can disconnect from a partition after 2 hours of inactivity. If the partition is running IBM® i5/OS™ with MF33488 or later, the console returns to the DST sign on screen. The user will see the 'resume' screen after logging back in. For earlier levels of i5/OS, the console session is lost. If the user attempts to reconnect, the console will hang with the message "0043 Connected - waiting for screen data".

Recovery

For i5/OS levels before MF33488, the only recovery is to IPL the partition.

To prevent the console hang problem from recurring until an e-fix is available, connect with a shared console or apply MF33488 or later to each i5/OS partition. Both methods allow console recovery without requiring an IPL of the partition.

HMC Console Error: "0099 Unknown Error Occurred - Contact Service"

If one HMC has an active 5250 console connection to a partition, an attempt to open another 5250 Console connection to the same partition from a redundant HMC will fail. The error message differs depending on the version of the HMC.

Version 4 Release 2.0 and earlier of the HMC returns the error: 00FF Unknown Error Occurred - Contact Service.

Version 4 Release 2.1 and later of the HMC returns the error: 0008 Session already in use.

In the case of networks with redundant HMCs, only one of the HMCs can have an active console connection. Console sharing (two or more consoles sharing the same session) is only available using the remote 5250 console function through one direct connected HMC.

To resolve the problem, first locate all redundant HMCs. On each redundant HMC, end any active local 5250 console session and any remote 5250 console session connected through that HMC.

Digital Certificate Manager

This document provides steps for configuring Digital Certificate Manager (DCM) on the IBM System i system.

Step 1: To start the HTTP ADMIN instance (if it is not already active), do the following:

1 To determine if the ADMIN instance is active, run the following command:

WRKACTJOB SBS(QHTTPSVR) JOB(ADMIN)

2 If there are no active ADMIN jobs, run the following command:

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

3 Run the WRKACTJOB SBS(QHTTPSVR) JOB(ADMIN) command again, and press F5 (Refresh) until at least 3 ADMIN jobs are in *SIGW status.

http://ipaddressorhostname:2001/

Step 2: To sign into Digital Certificate Manager, do the following:

1 Using a browser, access the following Web site:

Where is the IP address or host name of the System i™ system.

2 You are prompted to type a profile and password. Use a system administrator level profile.

3 The browser will display the i5/OS TASKS or iSeries TASKS page. Click the link for Digital Certificate Manager.

Step 3: To create a *SYSTEM store, do the following:

1 On the left panel, click Select a Certificate Store. If there is an option for *SYSTEM, you already have a *SYSTEM store.

2 If there is no option for *SYSTEM, on the left panel, click Create New Certificate Store. Click the bullet next to *SYSTEM, and then click Continue.

3 Click the bullet next to No - Do not created a certificate in the certificate store, and then click Continue.

4 Type a password for the *SYSTEM store (must be letters and numbers only with no punctuation nor spaces), and click Continue.

5 Click OK.

6 Click Cancel.

Step 4: To create a Local Certificate Authority, do the following:

1 On the left panel, click Select a Certificate Store. If there is an option for Local Certificate Authority (CA), you already have a Local CA.

2 If there is no option for Local Certificate Authority (CA), on the left panel, click Create a Certificate Authority (CA).

3 Type a password (letters and numbers only).

4 Provide a unique Certificate Authority (CA) name; for example, the name of your company, the name of your System i™ system, and Local CA MyCompany i5 Local CA.

5 Complete the remaining fields as appropriate. Specifying the maximum value for the Validity Period is recommended (unless your Security Administrator requires further limitations). Then, click Continue.

6 The option to install the certificate will be available later. Click Continue.

7 Setting the Validity Period for Server Certificates to the maximum value is recommended (unless your Security Administrator requires further limitations). Then, click Continue.

8 At this time, you do not need to have any applications trust this CA. Continue clicking Continue until you are asked if you want to create the default signing store. At that point, click Cancel.

Step 5: To create a Local Server Certificate, do the following:

1 Click the button: Select a Certificate Store.

2 Click the bullet next to *SYSTEM, and click Continue.

3 Enter the password to the store, and click Continue.

4 On the left panel, click the triangle next to FastPath to expand the section.

5 Under FastPath, click Work with server and client certificates.

6 Click the button: Create.

7 Click the bullet next to Local Certificate Authority (CA), then click Continue.

8 Fill in the fields on the form. For the Certificate Label, use a unique name. For example: MyCompany i5 Local Server Cert. For the common name, use the same value as the label. However, if this certificate will be used for HTTP, use the host identifier that you will be using in the URL. For example: www.i5.mycompany.com. (It is not necessary to complete any of the fields under Subject Alternative Name.) Click Continue.

9 You do not need to assign the certificate to any applications at the moment. Click Continue. Click Ok.

Step 6: To assign the Server Certificate to your applications, do the following:

1 Assuming that you are still signed into the *SYSTEM store, on the left panel under FastPath, click Work with server and client certificates.

2 If there are multiple certificates, click the bullet next to the one you want to work with.

3 Click Assign to Applications.

4 Check the box next to the application(s) you want to use the certificate, and click Continue. Click OK.

5 For server applications, end and start the server application for the newly assigned certificate to be in use. For client applications, sign on to a new character-based user interface (if necessary, sign off and on again) to pick up the changes in DCM.

6 The ADMIN instance is required only for configuration purposes and can now be ended. Run the following command:

ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

Collecting System Dump

To collect a PHYP platform dump or System Dump, use Option 42 from the control panel. The system must be in manual mode.

Note: This will take down all partitions on the system.

If the system does not have a control panel, this Dump can be initiated from Advanced System Management.

Leave the default settings as shown, and click on Save settings and initiate dump:

 

 

 

 

 

 

 

 

 

System Values - Printing

Use the Work with System Value (WRKSYSVAL) command to get a printout of the system values. From an IBM OS/400 or IBM i5/OS command line, type the following:

WRKSYSVAL

Press F4 (to prompt), and specify *PRINT for the OUTPUT parameter. This creates a spooled file that can be printed.

Displaying the Main Storage Size

To display the main storage size, use the Work with Shared Pool (WRKSHRPOOL) command. The main storage size is displayed at the top of the screen.

Getting a Listing of All User Profiles Including a Text Description

To generate a listing of all user profiles, on the operating system command line type the following:


DSPOBJD OBJ(*all) OBJTYPE(*usrprf) OUTPUT(*print)
Press the Enter key.

System Name Changing Process

Use the Change Network Attributes (CHGNETA) command to change the system name.

CHGNETA SYSNAME(new system name)

LCLCPNAME(Local control point) (May need to be changed also)

LCLLOCNAME(Default local location) (May need to be changed also)

Note: This command requires *ALLOBJ authority.

The name can contain up to 8 alphanumeric characters. The name entered becomes the current system name at the next IPL.

It is important to remember that the Local Control Point Name (LCLCPNAME) and Default Local Location Name (LCLLOCNAME) are used rather than the SYSNAME when setting up SNA communications with APPN. Take this into consideration when changing the SYSNAME because the LCLCPNAME and LCLLOCNAME may also require changes.

Making Only One Batch Job Run at a Time

The number of batch jobs running can be controlled at the job queue level, the subsystem level, or the pool level. Do one of the following: o For the job queue level, set the MAXACT parameter on the Change Job Queue Entry (CHGJOBQE) command.


o For the subsystem level, set the MAXJOBS parameter on the Change Subsystem Description (CHGSBSD) command.

o For the pool level, the manner of changing the maximum number of jobs is a function of whether a private pool is being used or a shared pool. Which pool a particular job runs in is a function of how it is routed; thus, it is a function of the routing data specified when the job is submitted and the routing entries in the subsystem description for the subsystem that is servicing the job queue that the batch job is submitted to. If the pool is a private pool defined to and used only by that subsystem, the activity level is specified for the pool when the subsystem description is created or by using the CHGSBSD command to change the activity level. If the pool is a shared pool, the activity level of the pool is changed by use of the CHGSHRPOOL command or the WRKSHRPOOL command.

Creating Subsystem

A subsystem can be created using one of the following methods. You can copy an existing subsystem description and change it, or you can create a new description. Use one of the following methods.

Copy an existing subsystem description and customize to your needs:

1 Create a duplicate object, CRTDUPOBJ, of an existing subsystem description. (The WRKOBJ or WRKOBJPDM commands can also be used.)
2 Change the copy of the subsystem description. The most common changes to make are to remove the existing job queue entries from the duplicate object so that it will not try to allocate the same job queues as the original subsystem. Use the Remove Job Queue Entry (RMVJOBQE) command for that. Then, create one or more new job queues for the new subsystem using the Create Job Queue (CRTJOBQ) command and attach them to the new subsystem via the Add Job Queue Entry (ADDJOBQE) command.

Create an entirely new subsystem description:

1 Create a subsystem description (CRTSBSD).
2 Create a job description (CRTJOBD).
3 Add work entries to the subsystem description.
o ADDWSE (Add Workstation Entry)
o ADDJOBQE (Add Job Queue Entry)
o ADDJOBQE (Add Job Queue Entry)
o ADDCMNE (Add Communications Entry)
o ADDAJE (Add Autostart Job Entry)
o ADDPJE (Add Prestart Job Entry)
4 Create a class (CRTCLS).
5 Add routing entries to the subsystem description (ADDRTGE).