iSeries Navigator has become a truly remarkable tool for managing your iSeries systems. From basic features, like viewing messages, to advanced features, like graphically working with disk units or databases or managing health across systems, iSeries Navigator's range of function is quite broad.

However, that in itself is a bit unsettling for many administrators. They love using the functions, but they get concerned when they are told to give someone else access to iSeries Navigator. Early on, it wasn't such a big deal to install iSeries Navigator on a new operator's desktop because there weren't a whole lot of destructive actions they could do. But since V5R1, the range of functions (potentially destructive functions) is broad and easy to get to. You may have heard the tale:

In the beginning was the Navigator, and it was good. But simple. The Administrator found it wonderfully easy to use but treated it as only a toy because of the few functions available. The Administrator said, "This is cute, but I need more. I must have more functionality," and it was delivered. But, alas, the Administrator was still not pleased. He demanded even more from the Navigator. So the Navigator produced functions beyond his wildest dreams. The Administrator was full of glee. He could graph, view, drag, drop, sort, search, export, send, and configure with grace and elegance. After experiencing all the joys that the Navigator could offer, the Administrator said with a slight trace of fear, "OK. Pretty cool. So how do I turn all that off and secure it so nobody else can use it?"

The good news is that we at IBM have always honored standard security practices. And we've added access control that lets you be quite flexible on which functions different users can use.

Honoring Standard Security Practices

The relationship between iSeries Navigator and OS/400 (or i5/OS) has never changed. iSeries Navigator is a portal, or view, into the iSeries system. When you start iSeries Navigator, you add a connection to an iSeries system and then sign on using your user profile and password. That user profile and password is then used throughout the life of your iSeries Navigator session to view data and run actions. iSeries Navigator will do nothing on your system unless the profile you used has the authority to do it. iSeries Navigator honors all i5/OS security settings and will not override those settings for any reason.

Ah, but here's the catch. Not all administrators have fully secured their iSeries systems properly. In the past, when we used the green and black command line user interface, activating Limited Capabilities was enough to feel secure because it remove the command line, so only those tasks that appeared on the menu were accessible. Now, however, with TCP/IP servers running, things get a lot more complex. There are 148 ways to connect to the iSeries (OK, I might be exaggerating, but just a bit), and each one may use different commands, APIs, ports, servers, or protocols to get to the objects residing on the iSeries...and it would be darn tough to fill all those holes properly.

Where am I headed? Object level security. That's really the best way to make sure your iSeries is secure.

For example, if I want to edit a file located in the /root file system, I can open iSeries Navigator, sign on, select the file, edit it, and save it directly back. You, the trusty administrator, can uninstall the File Systems component on my iSeries Navigator, but I would just find another PC or reinstall it with the CD I got from the Internet. You can then use Application Administration (more on that later) to remove the File Systems folder from my view, but then I can open Data Transfer and edit the data from there. You can use Application Administration to remove access to use Data Transfer, but then I can open a DOS prompt and FTP into the system and edit the file. You can remove my access to the FTP server, but then I can use ODBC to get the data. You can remove my access to that, but then I can open Microsoft Excel and use its OLE interfaces to access the data. Finally, you can edit the permissions on that IFS folder or object in the folder, and I will not be able to edit the file.

Get the picture? If your iSeries system is going to live in this modern connected world, you need object level security.

Application Administration Overview

Now that I've lectured you on object level security, it is still important that you use Application Administration to control system access. Why? Here are some examples of problems you can solve using Application Administration (shown in Figure 1):

• An administrator needs access to view active jobs and server jobs, but you don't want him to have access to memory pools.
• You are trouble-shooting and need a quick way to revoke everyone's access to the File Systems folder, even if they have All Object Access.
• Users' PCs have been pre-loaded with the systems they're allowed to connect to, and you don't want them to add more connections.

Figure 1: Use Application Administration to help manage security issues. (Click images to enlarge.)

So how does it work? That depends on whether you select Local Settings or Central Settings. Local Settings, available on all supported releases, resides locally on each iSeries system and locally control access to iSeries Navigator function. When iSeries Navigator connects to the system, it asks what items have been denied using Application Administration. It then hides the appropriate folders from the users' view. Central Settings, available since V5R2, (Figure 2), resides on a centrally located system that centrally manages client applications and behaviors. When the user starts a PC, iSeries Access for Windows connects to the administration system and asks it what central settings have been customized for this user. As you can see from the figure, you can customize at a deep level of detail, including how to download data from a server or what emulation options the user can use. The list is quite lengthy and has similar behaviors to Microsoft Windows policies, but Navigator's are easier to set up and are centrally located so that you only have to specify them once for all PCs.

Figure 2: With Central Settings, you can manage client applications and behaviors from a centrally located system.

For both, the general behavior is the same: You select a function you want to control access to and then select Default Access, which grants or denies access to this function for any user who does not have All Object Access. But you could select All Object Access, which will grant or deny access to this function even if you have All Object Access (this is a big deal for some customers who need to give their users All Object access for various applications but don't want them to access certain iSeries Navigator function). You could also select the Customize button, which opens a dialog where you can customize the access control for that particular function. In that dialog, you can select sets of users or user groups and explicitly grant or deny them access. These customized access settings override any Default Access or All Object Access setting in case you want to remove access for all users except Joe, Sally, and Frank. In that example, you would de-select Default Access and All Object Access and then click the Customize button to add their user profiles. The other way works fine too in those cases where everyone can have access except certain profiles.

Also, with Local Settings, you can control access to much more than just iSeries Navigator. For example, you can control access to other client applications, many host applications, and TCP/IP servers. The general behavior is the same for all these areas, and once you start using it, you will soon discover how easily you can control access to your iSeries function.

Other Security Points to Consider

While we're on the topic of access and security, there are few things about iSeries Navigator that you should know so that you can make informed decisions regarding what users can view and access.

Viewing Unauthorized Objects: In a few places in iSeries Navigator, users can view objects they are not authorized to, even though they are not viewable if you're using a command line. However, because we honor i5/OS security, users can't taken action on these objects. Work Management will show jobs. Basic Operations will show printers, printer output, and messages on message queues users are not authorized to.

Inventory: iSeries Navigator can collect inventory of hardware, software, fixes, users and groups, and system values from across systems and store it on the central system. This is great, but be aware that the collected data is viewable by anyone who has access to the inventory folders. This means that if I don't have permission to view users on System1 (neither from the command line nor from iSeries Navigator), and I don't even have a profile on System2, I can still sign on to System 3, which is my central system, navigate down to the Management Central endpoints for Systems 1 and 2 and view all the inventory and property information that was collected. I could see hardware device names, products installed on those other systems, system value settings, user profile names and levels of authority, and what fixes (or PTFs) are installed on those systems (password information isn't collected and isn't viewable). While I would not be able to change any setting or delete any objects from System 1 or 2, this information could be used to attempt to compromise your systems, so it's important to use Application Administration to deny access to those folders.

Monitors: Job, file, and message monitors can run OS/400 commands if a threshold is exceeded. I could create a monitor that calls a program when a threshold is exceeded. This is a very nice way to automate actions on your iSeries. However, these monitors can be shared, and that means that if I share the monitor and you start the monitor, then when the threshold is exceeded, that program that you don't even have access to is run. The program will run under my profile because I created the monitor, but by sharing it, I have given others the ability to start the monitor. The good thing is that we do not allow a shared monitor to be edited by anyone other than the owner (we call that "controlled sharing"). This ensures that if I create a monitor and specify a program to run, nobody else can alter which program is run or what thresholds cause it to run.

Actions in Definitions: Command definitions, package definitions, user definitions, and product definitions can all be shared. In the case of definitions, the sharing level is "Full," so anyone can edit, activate, or delete a definition. These definitions also have a post action that can be run (except for the command definition, where the command to run is the primary action). This is very handy for running post actions to further automate your IT shop. Because the definitions launch a separate task to do the function that the definition is defined to do (send a file, create a user, send and install a product), the task runs under the user who activated the definition, not the owner. Suppose I have access to a program, but you don't. If I create a definition and then run a post action, it will work. But it will not work if you run it because i5/OS security has determined that you do not have access to that program.

Note that, if you have sharing set, other users with lesser authority can view command and program syntax that normally they would not be able to see. This is not a huge deal, but you should be aware of it.

By default, it would be hard for you to see what other users are creating as definitions and what tasks are being created, because you only see shared definitions and tasks in your view. However, there is a way to view tasks and definitions for all users, regardless of their sharing value. To see all definitions regardless of who owns them and regardless of sharing value, go into Application Administration, select Host Applications, open Management Central, and then customize Management Central Administration Access. Any profile added here will see all definitions and tasks and system groups, no matter who owns them or what their sharing value is. You can then see what post actions are being used and notify owners if you want them to make changes.

New V5R3 iSeries Navigator Tasks for Web Access Control

In V5R3, we introduced iSeries Navigator tasks that you can run from a Web browser. This opens a whole new set of possibilities for better systems management, but it also opens a whole new set of access control to think about. As before, all i5/OS security is honored in these Web tasks. No one can modify a database item or work management job from the Web unless they're authorized to. Also, if you have removed access to the Work Management folder in iSeries Navigator, you have removed access from a Web browser as well. One new thing to consider is that through Application Administration you can control who can access the iSeries through these Web tasks. See Figure 3.

Figure 3: Control who can access the iSeries.
With iSeries Navigator tasks on the Web, you can open a browser and point to Server 1 to manage Server 1, or you can open a browser and point to Server 1 but actually manage Server 2. This is all customizable in the URL, and there's no way to control what people type into the Web address area, so we had to let you specify whether a user is allowed to point the browser to Server 1. If so, you can also specify whether that user is allowed to manage that server from the browser.

For example, if you (the administrator) want only one Web application server running in your environment that performs iSeries Navigator tasks on the Web, you could set up System 1 to be that server. Then, all other servers would have "Use of iSeries Navigator Web interface" turned off for both Default Access and All Object Access. Then, based on who you want to manage which servers through System 1, you would open Application Administration on each of the other servers and select "Manage server through Web interface." Of course, with any Web application, you need to consider whether you need to use an SSL connection or not. For more details on configuring SSL for use with the iSeries Navigator tasks on the Web, see the iSeries Information Center and search on "iSeries Navigator security."

Feeling Secure

I hope this gives you a taste of the issues with securing iSeries Navigator, securing your iSeries data, controlling access to the various tasks involved, and securing iSeries Navigator tasks for the web.

Greg Hintermeister is an eServer user interface designer at IBM Rochester and has worked extensively with iSeries Navigator, iSeries Navigator for Wireless, and several Web applications. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Greg Hintermeister works at IBM as a user experience designer and is an IBM master inventor. He has extensive experience designing user interaction for IBM Systems Director, IBM Virtualization Manager, System i Navigator, mobile applications, and numerous Web applications. Greg is a regular speaker at user groups and technical conferences. You can email him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility