5 Ways to Control Access using Application Administration

By Carol Woodbury

Never heard of Application Administration? Don’t be surprised. Although it’s full of function, it’s one of little-known features of IBM i. Application Administration (or App Admin as it’s commonly called) has been around for a while but the additional features provided in the latest releases as well as recent Technology Releases makes this a feature worth exploring again.

Tip #1 explains how to configure Application Administration access controls. Tip #4 explains the most recently added features, including the ability to control network access (ftp, ODBC, etc) and Tip #5 explains how you can use App Admin with your own applications.

Application Administration

Application Administration is a function of i Navigator. It allows you to configure who can see certain functions or perform certain tasks. IBM created App Admin 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, right click on the system name in i Navigator and choose Application Administration. If you haven’t already signed on to the system, you’ll be presented with a sign on dialog.

Note: To configure most aspects of App Admin, you’ll need to sign on with a profile that has at least *SECADM special authority.

#1 – Controlling i Navigator

The first tab that’s presented(see below) when you launch App Admin allows you to control what parts of System i Navigators users see. For example, some organizations allow all users to manage their spool files (Printed Output) by using i Navigator but don’t want to allow users – especially end users - to see the rest of the functions provided by i Navigator.

Because all of the boxes under the “Default Access” column are checked, all users are allowed to see all parts of the i Navigator structure. In addition, because all boxes under the “All Object Access” column are checked, all users with *ALLOBJ special authority assigned to their profile are also allowed to see all parts of the structure.

If you only want users with *ALLOBJ to see all parts of iNavigator, leave the “All Object Access” column checked and uncheck the appropriate boxes under the “Default Access” column. With the configuration shown in the next figure, all users can see the Basic Operations of i Navigator but nothing else. *ALLOBJ users can see the entire structure.

Customizing the Access

This all-or-nothing approach may not work for your organization. You may have some users that don’t have *ALLOBJ that need to view and use some i Navigator functions – programmers and operators, for example. To setup this configuration, you’ll need to use the Customize feature. Click on one of the specific features. This will highlight the line and activate the Customize button in the lower right.

Clicking the Customize button produces the following dialog. Leaving the ‘Default Access’ box unchecked means that, by default, no users can see this feature. Then, you can open the Users and Groups select which individuals or groups are allowed to use the feature.

Note: You can do the reverse – allow all users and deny specific users or groups but that tends to be a maintenance nightmare. I prefer the ‘deny by default’ and allow only approved users or groups.

Click OK when you have the list of users or groups that are allowed to use this feature.

When you return to the main dialog you’ll see that there is an ‘X’ in the Customized column for this feature. To replicate this setting to other features, right click on the customized line and choose Copy Access Settings. Move your cursor to a single feature or to a feature heading, right click and choose Paste to copy the settings to that feature or to the whole category.

#2 – Controlling i Access

The Client Applications tab allows you to control what functions, such as data transfer, ODBC, etc a user can see. Now you shouldn’t be lulled into thinking that this is a robust security set-up. Using the configuration options provided by these two tabs is truly security by obscurity because these are checks that occur on the workstation – not IBM i itself, so they can be by-passed with enough ingenuity. But for some users, the “out of sight, out of mind” approach works for controlling their actions.

#3 - Host Applications

The Host Applications tab allows you to control various functions of i5/OS. Access is configured the same way as in the System i Navigator and Client Application tabs. One of popular features is the ability to allow users with *JOBCTL the ability to see the joblog of an *ALLOBJ user. One of the difficulties administrators often face when trying to reduce profiles having *ALLOBJ special authority is accommodating those users (typically programmers) who are on-call. The problem is that, users without *ALLOBJ cannot see the joblog of a job that is run with a profile that has *ALLOBJ. Normally, this is a good thing – most users shouldn’t be seeing what tasks an *ALLOBJ user performs. But when someone is on-call and trying to debug a problem, the first thing they want to look at is the joblog. Often the failing process may be a scheduled job that runs with a powerful (*ALLOBJ) profile. You can easily resolve this issue using App Admin. Checking the “Default Access” box means that any user with *JOBCTL can view the joblogs of an *ALLOBJ user. Unless you have *JOBCTL under tight control, this may allow more users access to the joblog of an *ALLOBJ user job than desired.

To limit who can have this capability, leave the “Default Access” box unchecked, click on (highlight) the entry and click on Customize. Add specific users or groups to the Access allowed section.

You may find some of the other Application Administration functions listed under the Host Applications tab useful as well. Functions such as BRMS administration and service trace functions are also controlled using Application Administration. But the newest additions to the App Admin Host Applications are the top of the next control point.

#4 Controlling Network Access

Controlling which users are allowed to perform ftp functions has been part of App Admin for many releases; however, recent Technology Releases have added the ability to control more network access. Now available in V7R1 and PTFed to V6R1 is the ability to control which users and groups can use DDM/DRDA as well as ODBC/JDBC (including ODBC/JDBC server requests and Run SQL Scripts, System i Navigator and Systems Director Navigator ODBC connections.) The control is strictly all-or-nothing. Either the user can use ODBC or they can’t.

Hint: TOOLBOX APPLICATION SERVER ACCESS is what you use to control ODBC.

For all of the network access controls in Application Administration (including FTP), changing the configuration will cause a ‘GR’ audit journal entry to be generated when a connection is attempted. If the connection is allowed, the user name will be listed along with the value *CHKUSAGE and what function was run. If the connection for the user is not allowed, the value will be *USAGEFAILURE and the function being attempted.

#5 Controlling Functions within your Own Applications

IBM is not the only one that can define functions to be controlled. You can use this same facility to control the use of functions within your own applications. Use the User Function Registration APIs to register (define), change and check access settings. IBM i will automatically generate the appropriate GR audit journal entries.

About the Author

Carol Woodbury is President and co-Founder of SkyView Partners, Inc, a firm specializing in security compliance software and services. Carol has over 20 years’ experience in the area of IBM i Security including 10 years as Chief Engineering Manager for iSeries Security at IBM in Rochester, MN.

Carol is an award-winning speaker and writer. Her latest book, IBM i Security Administration and Compliance is a now available.