Exploring IBM Systems Director Security

Securing IBM Systems Director is a far-reaching subject with many nuances. In this article, I'll discuss the basic security aspects of the Systems Director management server, including how to control access to the web console and assign roles. I'll also discuss security between the management server and managed endpoints, including using certificates, using credentials, and auditing tasks. Finally, I'll discuss how to avoid a common security-related error when taking advantage of Systems Director's VMControl plug-in.

Controlling Access to the Web Console

A default installation of Systems Director configures two network ports for access to the web console: port 8421 for HTTP access and port 8422 for SSL access. Additional security aspects of web-console access include the inactivity timeout and concurrent access. Systems Director 6.2 defaults to a timeout value of 30 minutes; version 6.3 defaults to no timeout. The timeout value can be changed through the com.ibm.pvc.webcontainer.http.sessionGlobalTimeout value in the usmi_settings.properties file.

The default behavior for concurrent (or multisession) access is to not allow the same user to be logged on to the web console multiple times. To enable multisession support, change the following entry in the /opt/ibm/director/lwi/runtime/isc/consoleProperties.xml file:

Access to the web console is limited to members of the groups that have been authorized to use Systems Director. By default, Systems Director uses the user authentication mechanism of the underlying OS on which it’s installed. For example, if Systems Director is installed on an AIX or Linux system, it uses the user and group information defined on that system. Likewise, if Systems Director is installed on a Windows system, it uses the user and group information defined in that environment (typically Active Directory). Systems Director can also be configured to use LDAP for authentication.

When Systems Director is installed, four new user groups are created in the underlying OS. Each user group is defined by a default role:

• The smadmin group is given the SMAdministrator role.
• The smmgr group is given the SMManager role.
• The smmon group is given the SMMonitor role.
• The smuser group is given the SMUser role.

In addition to the four default groups created during installation, other OS groups can be authorized to access Systems Director. For example, if a group already exists for AIX administrators, you could authorize access for that group, defining the functions that the group members can execute and the managed resources they can use.

You can authorize additional groups through the Authorized Groups button on the Groups tab of the Users and Groups page of the Security task. Clicking this button starts a Systems Director wizard, which is shown in Figure 1.

Figure 1: Authorizing Additional Groups

The wizard displays a list of user groups, but it isn’t necessarily a complete list. So, if you don’t find the group you want to authorize in the displayed list, you can enter its name in the User groups field. Keep in mind that the group you specify must be a valid, already-defined group in the OS on which Systems Director is installed.

After a group has been authorized access to Systems Director, you need to assign it one or more roles, as Figure 2 shows. The role indicates the functions that group members will be able to perform and the managed resources they’ll be able to use.

Figure 2: Assigning Roles to a Group

Assigning Roles

Systems Director can provide systems management and administration capabilities to heterogeneous environments. It’s both possible and preferable to make Systems Director the management interface for an enterprise’s IBM i, AIX, Linux, and Windows environments running on both IBM Power Systems and Intel. In addition, Systems Director can be used to manage both mainframe environments and IBM BladeCenter environments.

Heterogeneous support makes it necessary to control the resources and functions that each user can access. For instance, the IBM i admin team should have access to the IBM i resources but shouldn’t be able to see or manage the other OS or hardware resources. Similarly, the functions that managers can execute should be a subset of the functions for which the systems admin team is responsible.

Systems Director uses roles to control the functions and resources to which users have access. It includes five predefined roles, and each role is granted specific capabilities:

• GroupRead. This role grants users the ability to view or open a group.
• SMAdministrator. This role is given to administrators. It gives them full authority over all tasks and commands, including those related to security administration, product installation, and configuration.
• SMManager. This role is given to managers. It lets them perform a subset of the tasks performed by administrators. Typically, the tasks are related to systems administration, system health management, and configuration.
• SMMonitor. Users who have this role can access those administrative functions that provide read-only access. It primarily lets them perform monitoring, notification, and status-checking tasks.
• SMUser. This role is given to authenticated users. It lets them perform basic operations, such as viewing resources and properties.

Suppose that a group is granted access to all managed resources with the GroupRead role and access to IBM i systems with the SM-Administrator role. This means that members of this group can view all the managed resources discovered by Systems Director and will have full authority over all tasks and commands in the discovered IBM i resources.

When Systems Director is installed, the user performing the installation (typically the root user) is added to the smadmin group. Initially, only this user has access to Systems Director. Providing access to additional users is easy; simply add their user IDs to a predefined group or to one of the groups authorized to access Systems Director.

The five predefined roles provide a fairly good separation of function, but there might be times when additional roles are required to meet the specific requirements of the enterprise. To create a role, select the Create option on the Roles page. After you provide a name for the role, assign permissions to it by navigating through the list of available permissions, selecting the desired permissions, and clicking Add, as shown in Figure 3.

Figure 3: Assigning Permissions to a Newly Created Role

The permissions assigned to a role can be quite granular. For example, if the group that will be assigned the new role needs to access only the system health information provided for AIX endpoints, you would select the Health permission under the AIX Management item.

Although I showed role and resource assignments only at the group level, Systems Director also supports assigning roles and managed resources to individual users. The Users tab of the Users and Groups page provides a list of users authorized to access Systems Director (i.e., users belonging to a Systems Director authorized group). From that list, you can select a user and assign roles to that person. The process for assigning roles and managed resources to a user is the same as that used for groups.

Using Certificates

Certificates are used to control the access that Systems Director has to the resources being managed. The level of functionality that Systems Director has for a given endpoint is directly related to the agents that are discovered on the endpoint and that are successfully accessed by the Systems Director management server. Thus, there are two functions—discovery and access—to address when using certificates with Systems Director.

The discovery process determines the network protocols on the managed endpoint that Systems Director can successfully contact (i.e., the network protocols that have an agent “listening” on the managed endpoint and that aren’t blocked by an intervening firewall between the management server and the managed endpoint). Which protocols the discovery function will check depends on the resource type selected during the discovery process and, optionally, the discovery profile used. Figure 4 shows an example of the discovery dialog box. Selecting All in the Select the resource type to discover drop-down list will allow Systems Director to query each system-management network port.

Figure 4: Configuring the System Discovery Process

I discuss the network port requirements for managing Power Systems and BladeCenter environments in my article “The Network Port Requirements for IBM Systems Director” (August 2012). You can also find more information about the necessary network ports in the IBM Systems Director 6.3.1 Information Center.

Although the certificates provided by the Platform Agent (i.e., the Common Information Model, or CIM, protocol) are maintained by Systems Director, the certificates provided by the Common Agent (i.e., the Common Agent Services, or CAS, protocol) are maintained by a separate component called the Agent Manager. Typically, Systems Director is configured to use the Agent Manager that’s installed on the same server as Systems Director. However, Systems Director also supports the ability to use a remote Agent Manager.

Systems Director is limited to using a single Agent Manager. You can specify the Agent Manager on the Agent Manager Configuration page (Figure 5), which you access under Settings in Systems Director. You can configure multiple Agent Managers, but only one can be active at any given time.

Figure 5: Configuring the Agent Manager

Because the certificates for the Common Agent are stored in the Agent Manager database, that database needs to be maintained (in addition to the Systems Director database). This affects the process you need to use when removing managed resources from Systems Director. If the managed resource had a CAS certificate in the Agent Manager database, that certificate needs to be removed as well. For more information about the Agent Manager database (including commands to run against it), check out my Power Implementers blog entry “Working with Agent Manager.”

As I mentioned previously, Systems Director communicates with managed resources through predefined communication protocols. The level of encryption supported depends on the communication protocol, as shown in Table 1.

Table 1: Level of Encryption Supported

To determine the protocols (and the ports used by those protocols) that Systems Director uses to manage a given endpoint, you can use the Configure Access page, which Figure 6 shows. You access this page by clicking the Configure Access option on the Security task.

Figure 6: Determining the Protocols Systems Director Uses to Manage a Given Endpoint

Note that Systems Director doesn’t include its own Secure Shell (SSH) server. Instead, it uses the SSH server of the OS that’s hosting Systems Director. Systems Director can also use third-party, SSH-compliant servers.

Using Credentials

Credentials provide a way to define a username and password pair for accessing remote functions against a managed endpoint. The credentials can be defined for authentication by the managed endpoint’s OS, LDAP, or AD. When certificates are part of the global Systems Director configuration, credentials are tied to a specific user. You can think of this as Systems Director’s version of single sign-on (SSO). In this way, different credentials can be defined for different users authorized to access Systems Director.

Systems Director uses credentials for managed resources’ inline functions, such as HMC Management for Hardware Management Consoles (HMCs), AIX Management for AIX endpoints, and IBM i Management for IBM i endpoints. It also uses credentials for remote access functions, such as Remote Command Line, Remote Control, and Serial Console.

Auditing Tasks

With Systems Director, you can audit many different types of tasks. Only security-related tasks are audited by default, but you can audit other types of tasks, including tasks related to VMControl configuration, network configuration, system configuration, and system triggers. You can add tasks to be audited on the Server Auditing page, which you access through the Security task.

Audit results are displayed in the Event Log page, which you access through the Server Auditing page. Figure 7 shows a sample event log.

Figure 7: Checking the Auditing Events in the Event Log

If you’re interested in a particular event, you can create an event filter for the event, then create an Event Automation Plan against the filter. That way, you can be notified every time the audit event is generated, or you can have a program automatically start in response to the event.

Avoiding a Common VMControl Error

When you use the capture functionality in the VMControl plug-in, you might run into a security-related error. VMControl relies on SSL authentication for captures when a Network Installation Manager (NIM) server is involved. If SSL isn’t enabled on the NIM master, the capture will fail because the capture uses the nimclient -c command to check for and copy (if present) the certificate from the NIM master. (The certificate is created by running nimconfig -c on the NIM master.)

Implementing a Robust But Secure Environment

I hope this look at Systems Director has provided some insights into how you can use its security functions and features to implement a robust management environment while enforcing access controls for the managed resources. If you have any questions or comments about Systems Director, contact me at askerwin@poweritpro.com.

Editor's Note: This article originally appeared in the September 2012 digital edition of POWER IT Pro.