First, let's make sure we all understand what IASPs are. I don't claim to know every gory technical detail of IASPs, but here are the basics. As Figure 1 shows, IASPs contain databases, and those databases can be accessed through system interfaces when the IASP is "online." An IASP can be online with only one system at a time. IASPs may be one of the technologies you use as a contingency plan for disaster recovery. The idea is that you place your application libraries and directories in an IASP. Then, in the event of a failure, you attach the IASP DASD to another system, and you're up and running again. For example, in Figure 1, IASP001 is currently online with the ROCH system, but in the event that ROCH experienced a failure, IASP001 would be brought online to the SEATTLE system.
Figure 1: A configuration using IASPs
Some Information, Based on Figure 1
- You can have more than one IASP attached to a system, but an IASP can only be attached to one system at a time.
- You can have the same library in two different IASPs that are attached to the same system because they have no "knowledge" of each other.
- You cannot have the same library name in the system base and any attached IASPs. If you try to create one in the system base and it exists in the IASP, the creation will be blocked.
- If an IASP has an object with the same name as an object in the system base, the IASP will not come online.
- The special value for the system base is *SYSBAS.
Accessing Objects in IASPs
In V5R2, one of a job description's attributes is which IASPs the job is able to access (assuming, of course, that they are online at the time). Think of this as a "library list" of IASPs for the job. Then, when you specify *ALL for the library name on a command (e.g., WRKF *ALL/CAROL_FILE), all libraries in both the system and that IASP are searched for the file (CAROL_FILE).
Security commands, such as Grant Object Authority (GRTOBJAUT) have added an IASP parameter. Thus, you can manage authority to objects in any IASP that is currently online, even though it might not be in your job's IASP list. Other security "management" commands like PRTPVTAUT or WRKOBJOWN looks at all objects on both the system as well as any IASP that is currently online.
User Profiles
To make sure security is constant and consistent when an IASP is moved from one system to another, a user profile "extension" exists on the IASP for every user who 1) owns an object, 2) is the primary group of an object, or 3) has a private authority to one of the objects on the IASP. This "extension" is not a real user profile object, and you cannot create one of these extensions yourself. They are internal objects that reside only on the IASP. When an IASP is brought online, these extensions are "matched up" with the corresponding user profile on the system itself.
If no matching user profile object exists when the IASP is brought online, the system will create a user profile object with the following attributes:
- PASSWORD(*NONE)
- STATUS(*DISABLED)
- SPCAUT(*NONE)
- UID--will attempt to use the UID from the profile extension
- GID--will attempt to use the GID from the profile extension
The Importance of UIDs and GIDs
Part of how the user extensions on the IASP and the user profiles on the system are "matched up" depends on the UID, or User Identifier. The UID is a numerical identifier for a user. The GID is a numerical identifier for a group profile. It is essential that the UIDs and GIDs of the user profiles on the system and the corresponding UIDs and GIDs in the user extensions are the same. In fact, when the IASP comes on line, the system ensures that they match. The UID of the user profile extension will be changed to match the UID of the corresponding user profile on the system. If you connect this IASP to three different systems and user CJW owns objects on the IASP and has a different UID on each system, the UIDs in the profile extension will be changed each time the IASP is brought online. Unnecessary processing (churning) will occur each time the IASP is brought online unless you take the time to ensure all UIDs are the same for each user across all systems connecting to the IASP.
Making the UIDs and GIDs the Same on All Systems
iSeries Navigator (aka Management Central, formerly known as Operations Navigator) provides a tool to help you get all of the UIDs to match across your network. While slightly easier since V5R1, it is still a tedious process, but it's one that you will probably want to perform to allow the IASP to come online more quickly. Here are the steps:
1. From iSeries Navigator, select the systems to edit the user on.
2. Select Users and Groups>Edit Users.
3. Enter the profile to edit, and then select Capabilities>Unique Identifier from the category list.
4. Either double-click "UID number" or select the Properties button.
5. From the Properties dialog, select "Find a unique number across all selected systems."
6. Click "OK" to edit the user.
You might want to consider creating user profiles through Management Central to take advantage of synchronizing UIDs across the network at user profile creation time.
Primary Group
If you use primary group authority, you will want to make sure this authority is consistent across all systems as well. Say that an object in IASP001 has been given primary group authority. The primary group is CAROL. Making CAROL the primary group of an object means that CAROL is actually a group profile. For example, a file in IASP001 currently connected to SYSTEM_1 has primary group CAROL. That means there's a group profile on SYSTEM_A by the name of CAROL. The IASP is moved from SYSTEM_A to SYSTEM_B. Profile CAROL exists on SYSTEM_B, but its GID is *NONE. That means that CAROL on SYSTEM_B is not a group profile. Therefore, it cannot be given primary group authority. (The only profiles that can be granted primary group authority are group profiles.) When IASP001 comes online, all objects that have CAROL as its primary group will now have their primary group authority set to *NONE. In this case, it is essential that all the group profiles have the same GID to avoid excess processing when an IASP comes online.
It's Ba-ack! Deleting User Profiles
When you delete a profile, it will be re-created when an IASP comes online if that profile meets one of three conditions: It owns objects on the IASP, it is a primary group for an object on the IASP, or it has a private authority to one of the objects on the IASP. Therefore, a little more thought will have to go into deleting user profiles. For example, you will probably want to delete profiles only when the shared IASP is online to ensure all of its authorities are properly cleaned up.
Objects Secured with an Authorization List
Only the name of the authorization list--not the authorization list itself or the authorities users have to the authorization list--is kept with the object on the IASP. If an authorization list does not exist when the IASP is brought online, the authorization list will be created on the system and its *PUBLIC authority will be set to *EXCLUDE.
Efficiently Bringing the IASP Online (from a Security Perspective)
Security-related objects--that is, user profiles and authorization lists--on all systems sharing the IASP should be mirror images of one another. That means the following:
- Users owning objects on, users that are a primary group of, or users that have a private authority to objects on the IASP must exist on all systems that share the IASP.
- UIDs and GIDs of user profiles must match on all systems that share the IASP, at least for those profiles that have a profile extension and for the group profiles that are the primary group for an object.
- Authorization lists that secure objects on the IASP must exist on all systems.
As I stated earlier, if the above is not true, then the system will spend time making sure it is true.
Maximum Storage
When a user owns an object on an IASP, the maximum storage parameter in the user profile takes on a new meaning. The maximum storage parameter indicates how much storage is allowed on both the system and each IASP. In other words, if a user's maximum storage parameter is 40 KB, the user can have 40 KB of owned objects that are resident to the system and 40 KB of owned objects on each IASP that is online.
Audit Records Updated for IASPs
Audit entries that are sent for actions performed against library-based objects in an IASP have added a field for the IASP. This is so that the audit entry can uniquely identify which object was acted upon. Because a file of the same name can exist on two different IASPs, the IASP must be part of the audit entry; otherwise, you would not be able to determine on which IASP the object being acted upon resides.
Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online