Security in Unicenter NetMaster

Products

• CMDB for z/OS
• NetSpy Network Performance
• NetMaster Network Automation
• SOLVE
• NetMaster Network Management for SNA
• NetMaster Network Management for TCP/IP
• NetMaster File Transfer Management
• SOLVE:Operations Automation
• SOLVE:Access Session Management
• SOLVE:FTS

Issue/Introduction

Security in Unicenter NetMaster

Environment

Release:
Component: NFT

Resolution

The Unicenter NetMaster product range supports multiple users. It allows very close control over the facilities that each user is allowed to access. This control is managed via the NetMaster User Access Management System (known as UAMS).

This security facility can operate in one of 3 modes:

1. Stand-alone. In this mode, NetMaster uses a VSAM dataset, known as the UAMS dataset, to hold all user-related information, including passwords.
   
   
2. Partial Security Exit. In this mode, the UAMS dataset is still used. It contains user-related information. However, an exit is used to interface to an external security system (that is, RACF, ACFII, or Top-Secret), for user and password validation.
   
   
3. Full Security Exit. In this mode, no UAMS dataset is used. The security exit provides all information about users, including what NetMaster facilities can be used, and so on.

What are the pros and cons of each mode?

1. (Pro) The stand-alone mode allows quick installation and initial testing of the product(s). No external involvement is required.
   
   (Con) Stand-alone mode is just that. No synchronisation of userids or passwords with any external security system.
   
   
2. (Pro) The partial security exit approach synchronises the userid and password information with the external security system. This allows the security managers to oversee NetMaster access.
   
   (Con) A partial security exit must be used. One may need to be written, although source samples and 2 out-of-the-box exits are supplied with the product.
   
   
3. (Pro) A Full security exit allows all NetMaster user security and profile information to be managed by the external security system. There is no UAMS dataset.
   
   (Con) A Full security exit is complicated. It must perform a significant amount of additional processing. Most external security systems are not set up to store the extra information that NetMaster requires. Various workarounds are possible, but none are simple.

The recommended security approach for NetMaster products is the partial security exit, in conjunction with a UAMS dataset. Specifically, we recommend use of the NMSAF security exit solution.

NOTE: You can share the UAMS dataset across NetMaster regions. This includes across LPARs. NetMaster will preserve dataset integrity during updates.

The security exit interface in NetMaster is fully documented. In addition, the product comes with sample exits (in source form) that can be used as a starting point for writing your own exit.

While this is fine for those installations that have the time and expertise to write and maintain an exit, what about other installations that just want to use the product, but with an external security system?

To this end, we supply 2 supported exits that can be used with NetMaster:

• 'PARTSAF', an exit that implements basic SAF security. This supported exit has basically the same functionality as the supplied SAF sample exit. Being a SAF-based exit, it will work with the 3 main security systems (CA's ACF2 & Top-Secret, and IBM's RACF).
  
  
• 'NMSAF', an exit that provides a comprehensive security solution. Also SAF-based, it too can work with all the main security systems. As described below, this exit has significant capabilities, and can be used to replace most in house-written security exits.

You can control the type of security that a NetMaster region will use with the SEC JCL parameter, which is typically specified in the RUNSYSIN PDS member in the execution JCL for the NetMaster region. The following values can be specified:

SEC=NO	No security exit. UAMS-based security only.
SEC=PARTSAF	Use the supplied basic SAF security exit.
SEC=NMSAF	Use the supplied advanced SAF security exit.
SEC= lmname	Use an installation-supplied security exit where the name of the load module is lmname. (Refer to the documentation for details on how the exit informs Unicenter NetMaster that it is a partial or full exit).

 

The NMSAF Security Exit Solution

As mentioned above, we recommend use of the NMSAF partial security exit.

Use of this exit means that the UAMS dataset is still required. However, we believe that the split between what is stored in the UAMS dataset and what is maintained in the external security system is a sensible one.

The design philosophy of the NMSAF security solution is based on:

• An understanding that most installations have a centralised security administration function.
  
  
• The approach that many sites took when implementing a full security exit.
  
  
• The use of NetMaster Modelling and Group Userids.
  
  
• A tradeoff between the need to have and administer the UAMS dataset versus the inflexibility and maintenance problems associated with a full security exit.

The main reason why it was decided to not to implement the NMSAF solution using the full security exit approach was because the external security systems are not set up to easily (if at all) store additional user data. Not everything that Unicenter NetMaster needs to know about a user maps to simple access levels. As an example, one field in the UAMS database record for a user is the initial OCS command, which is a character string that is treated as a command when the OCS facility is started. There are many other examples.

The NMSAF solution utilizes the external security system and the NetMaster UAMS database in the following ways:

1. At system initialisation, the NMSAF exit reads a configuration file and builds a list of resource names. Each resource name is associated with a model userid name. (A Model userid is a UAMS record)
   
   
2. When a user logs on the NetMaster, and the userid has not been seen before (That is, there is no UAMS record), the user is tested against the list of resource names. The first resource that the user has (at least read) access to is used to determine the name of the model userid record that this user will be modelled on.
   
   
3. A new userid record is created in the UAMS dataset using this chosen model. The user is then allowed to log on, and will be presented with a screen where some other details can be provided.

To make administration easier, we recommend the use of, and distribute the system with a set of model userid records that in turn are members of a group. In NetMaster, a userid record that is a member of a group takes all the important information from the group record ad logon time. The basic userid record only has personal information (and the group name). Thus, it is very simple to alter the privileges etc. for all members of a group my merely altering the group definition.

Of course, password maintenance, and so on is completely managed by the external security system. (You can allow a Unicenter NetMaster user to change their external security system password via a NetMaster panel, or you can prevent this, requiring them to change the password through some other means).

If a user is not defined on the external security system or is suspended or revoked, they will not be able to log on to the Unicenter NetMaster region.

At this time, the only ongoing UAMS maintenance that is required is the occasional cleanup of old userids (that is, users that have been deleted from the external security system).

If you need to change the authority of a user, you can simply delete the UAMS record. The next time they log on, the latest resource access levels will be used to choose a new model (and thus group) for the user.

Of course, for users with special privileges, you can use the standard UAMS definition facilities to add the appropriate profiles. The external security system is still used to maintain the password (and prevent login if the user is suspended or revoked).

Some Useful NMSAF tailoring Parameters

As mentioned above, the NMSAF solution uses a configuration file. This allows you to alter processing to suit your installation's requirements.

These parameters are fully documented in the manual (see the reference at the end of this article). However, some of the useful parameters are mentioned here:

1. SYSCHECK { NO | YES } Controls whether system userids (the background users that a Unicenter NetMaster region uses for internal processing) will be validated with the external security system. The default is YES. Note, however, that event if the external security system inhibits the logon (for example, user not known), NetMaster still allows the logon (otherwise the system would not start).
   
   
2. APPCCHECK { NO | YES } Controls whether APPC logon requests will be validated by the external security system. Previously, it was recommended that this parameter be set to YES, especially since the NetMaster Web Center used APPC logon requests for web sessions. However this caused problems with APPC sessions between NetMaster regions by background (system) users. See below for more information.
   
   
3. MODELGROUP { resourcename | * modeluserid } These statements define the list of resource names to check the (new, to NetMaster) user against, and the associated model userid. To avoid having to permit everyone to NetMaster (for example, when everyone in an installation is allowed to use SOLVE:Access), you can define a final entry in the list with an asterisk (*) instead of the resource name. If no previous resources could be accessed, if this list entry is reached, the user is automatically allowed to logon using the associated model userid definition (which, along with its group definition, should have minimal privileges).

Security and the Unicenter NetMaster WEB Interface

We have changed the Unicenter NetMaster WEB interface (WebCenter) security interface. Now, external security systems (including NMSAF) have the option of being told that a logon request is from a web interface user rather than APPC. To enable this:

1. Ensure that the JCL parameter XOPT=SXWEBU is specified in the NetMaster startup JCL (or RUNSYSIN file)
   
   
2. Ensure that the security exit can handle a LOGON request with a subcode of 36 and a VALIDATE request with a subcode of 16. (NMSAF can handle these). Note that the current security exit interface documentation does not cover these codes.

Summary

Security is a very important part of any installation. Unicenter NetMaster provides a sophisticated and comprehensive security regime. The NMSAF solution is one way to easily exploit these facilities.

 

Additional Information

Manual Reference

The NMSAF security solution is fully described in the Unicenter NetMaster, NetSpy, and SOLVE Security Guide. Chapter 2 describes the solution, and Appendix A covers the parameter file that is used to control processing.

This same manual covers many other aspects of security, including details on how to write your own security exit.