This article explains Application Administration, one of those seldom-used functions of OS/400. You may not have been tempted to use it before now, but with the function added in V5R3, you may be persuaded to give it a try.

Application Administration

Application Administration (often called "App Admin") is a function of iSeries Navigator. It allows you to configure who can see certain functions or perform certain tasks. App Admin was created because there are times when you need to control access to something, but that something is a function or task and there is no object to restrict access to. For example, when you want to restrict access to a database file, you set *PUBLIC authority to *EXCLUDE, and no one can access the file. But if you want to control who can perform service traces, for example, there is no corresponding object to grant *EXCLUDE authority to. Therefore, App Admin was created to provide a facility for controlling functions.

To launch App Admin, click on the system name in iSeries Navigator and "Configure Application Administration" appears under the heading "Connection tasks" in the bottom right pane, as shown in Figure 1. Double-click on this, and you will see the screen in Figure 2.

Figure 1: Launch App Admin from here. (Click images to enlarge.)

Figure 2: Now, you're in iSeries Navigator's App Admin.

Application Administration functions fall into three categories as shown by the three tabs in Figure 2: iSeries Navigator, Client Applications, and Host Applications. The iSeries Navigator functions and Client Applications categories allow an administrator to control, respectively, the iSeries Navigator or the iSeries Access for Windows (Client Applications) functions that appear on a user's desktop. Because the checks for whether the functions are to appear on the desktop are made on the desktop itself (not by OS/400), you should not consider this to be a robust security implementation. Basically, it is "security by obscurity" because all you are doing is hiding the function from the user's view. If the user goes to another user's desktop where the function appears, there is nothing preventing the user from being able to run the function. But App Admin is usually worth configuring even though it is security by obscurity because 1) it simplifies users' desktops by removing function you don't want them using and 2) in some cases, such as end users who tend not to explore their computer systems, this strategy can be an effective first line of defense when trying to prevent users from running functions such as data transfer or ODBC. The third category, Host Applications, can be considered a robust security implementation because the checks for whether the user can use the function are performed by OS/400 and are not easily bypassed.

Under each tab is a list of the functions controlled by this category as well as three other columns: Default Access, All Object Access, and Customized Access. The way these columns are configured determines whether the user can use the corresponding function. Default Access is similar to the concept of *PUBLIC authority for an object except that the access control is not as granular. In the App Admin case, users are either allowed to use the function or not. If the Default Access box for a function is checked, all users are allowed to use that function. If it is not, users have to be given authority to use the function via Customized Access or by having *ALLOBJ special authority.

The All Object Access column allows you to determine whether having *ALLOBJ special authority inherently allows the user to be able to use that function. If the All Object Access box for a function is checked, any user who has *ALLOBJ special authority can use the function. If it is not checked, the user has to be given authority to use that function via Customized Access or by having the Default Access box checked.

Customized Access is very similar to giving a private authority (except, like the Default Access, it is not as granular.) You can either allow a user to access the function or prevent a user from accessing the function. The Customized Access column shows whether customized access exists for the function. No customized access exists unless there is an "X" in the column as shown in Figure 3.

Figure 3: If the Customized Access column is selected, access has been customized--in other words, given to or revoked from a particular user or group.

To customize access for a user or group of users, highlight the function and click on the Customize button in the lower right corner of the display. This display, shown in Figure 4, allows you to choose a user or group from the left scrolling pane and add the user or group to the list of users allowed to have access or to the list of users denied access.

Figure 4: Users or groups can be specifically allowed or denied access to use the function.

Centrally Managed Application Administration Settings

V5R2 added the capability to allow App Admin settings to be centrally managed and be part of a "policy template." You declare one iSeries system to be the Administration System and then define the "central settings." One aspect of these central settings lets you define the App Admin settings for each user. Once the central settings have been established and the client has been configured to go to the Administration System for these settings, the client will look to the Administration System to determine what functions the users' desktop should be populated with. You no longer have to go to each system and configure the App Admin functions. There are also other central settings beyond the App Admin settings you can configure the clients to use.

While centrally managing these functions is very powerful, some restrictions prohibit it from working for all shops. The first one is that the Administration System must be an iSeries running V5R2 and clients must have iSeries Access for Windows V5R2 to be centrally managed. Some of you will have to wait until your system or, more likely, all of your desktops are running V5R2. The second restriction is that there is no granularity between systems, so you will have to carefully choose which users' App Admin settings will be managed centrally. That is, the App Admin function settings will be the same no matter which system the user connects to. This will probably work well for your end users, but it is unlikely this will be acceptable for your programming staff. For example, they may be allowed more functionality on their development system than on the production systems. Finally, it can be a bit cumbersome to get all of the clients configured to "discover" the Administration System. For an excellent write-up on centrally managing App Admin, see chapter 3 in the Redbook V5R2 iSeries Access for Windows Hot Topics available from www.ibm.com/redbooks.

New Function in V5R3

V5R3 adds several new host functions, including my favorite: the ability for a non-*ALLOBJ user to be able to see the joblog of an *ALLOBJ user. OS/400 prevents viewing the joblog of an *ALLOBJ user if you're not an *ALLOBJ user, but Help Desk and on-call personnel often need this ability. I have had to write utilities for several clients to overcome this issue, so it's nice to see it added into the operating system.

Another new feature of V5R3 is the ability to manage these functions through the commands Display Function Usage (DSPFNCUSG), Change Function Usage (CHGFNCUSG), and Work with Function Usage (WRKFNCUSG). Prior to V5R3, you had to manage these functions through Application Administration. The only way you could print out a list of users allowed to use a particular function was to write to the AddFunctionUsage APIs. (This is what we did in my product, SkyView Risk Assessor for OS/400, which is available back to V4R4 in case you need this information and won't be upgrading to V5R3 anytime soon.)

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services, and security assessments, including the risk assessment product, SkyView Risk Assessor for OS/400. Carol has over 13 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. Look for Carol's second book, Experts' Guide to OS/400 and i5/OS Security, now available at http://www.pentontech.com/education.

Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..