Chapter 3: Authentication

The joke goes that the only secure computer is the one without users. This section outlines the principles for securing the system, even with users! These principles include a good user schema based on the principles of Least Privilege, Separation of Duties and Individual Accountability.

User Administration

This chapter discusses administering userids and aliases on an HP NonStop server.

Userids

Users are defined by assigning a unique user name and number to each user:

<GroupName>.<MemberName>

<GroupNumber>,<MemberNumber>

The Group Name or Number identifies the user's administrative group. The Member Name or Number identifies the user within the group . The combination must be unique for a single system and unique over the network of systems if the user will have access to multiple nodes.

Groups

On the HP NonStop server, there are two types of user groups:

Administrative

File-sharing

Administrative Groups

Administrative Groups exist primarily for user management but can also be used for file-sharing in Safeguard software . Administrative Groups are used in both the Guardian and Safeguard environments.

Administrative Group Names are made up of 1 to 8 alphanumeric characters . The first character must be a letter. Groups with numbers ranging from 0 to 255 may be used as Administrative Groups.

Administrative Groups can be thought of as Job Function Groups because they are the primary unit that categorizes a given user's job function. Users with similar job descriptions and tasks require the same access to system resources. They should be given userids in the same Administrative Group.

File-sharing Groups

File-Sharing Groups can only be created in Safeguard software. They are used to grant access to disk files and other objects on the system. They are used primarily in the OSS environment and will be discussed in detail in the OSS Chapters.

Groups numbered above 255 exist solely for file-sharing purposes.

Members

Member Names are made up of 1 to 8 alphanumeric characters. The first character must be a letter. Member Numbers must be between 0 and 255.

A secure system requires a well organized and well thought out userid schema. Users must be given userids in appropriate administrative groups and uniquely identified to the system.

In general, userids can be broken down into two categories:

Personal IDs

Privileged IDs

Privileged IDs fall into 3 categories:

IDs with inherent Guardian privileges

Application Owner IDs

Job-Function IDs

Privileged IDs will be discussed later in this section.

Aliases

Aliases are only available in Safeguard environments.

An alias is an alternate user name that can be used to log on to the system. Each alias has its own Alias Authentication Record and set of user attributes. Users may be assigned one or more aliases.

Alias names can contain between 1 and 32 alphanumeric characters. Some special characters such as dots ( . ), hyphens ( - ) and underscores ( _ ) can also be included in alias names.

Unlike userids, which TACL automatically upshifts, aliases are case sensitive .

AP-ADVICE-ALIAS-01 Use good naming conventions when creating aliases. If a two or three character job-function descriptor is used at the beginning of each alias name, researching alias configuration and audit activity is easier.

AP-ADVICE-ALIAS-02 Don't create alias names that look like Guardian userids. It makes it difficult to read audit and other user- related reports . In general, don't make aliases all upper case and don't include dots (.).

For example, use oper-joe or operjoe instead of OPER.JOE.

Each alias has a specific underlying userid, for example oper-joe is mapped to 210,5. Each underlying userid can have multiple aliases mapped to it.

RISK Aliases cannot be included in Safeguard Protection Records. An alias's access to system resources is based solely on that of the underlying userid.

RISK An alias gains all of its underlying userid's privileges.

RISK Safeguard software provides limited auditing of alias activity.

Aliases to privileged userids such as SUPER.SUPER or the application owner IDs should be used only as a last resort. The most secure way to grant the necessary access to users who must 'act' as a privileged userid in order to perform their job function is with a third party access control product which can make access to resources much more granular and provide comprehensive auditing.

3P-ADVICE-ALIAS-01 If aliases are required, use third party products to both limit their privileges and provide more extensive auditing.

Single SignOn

Single-SignOn provides an employee with a single userid that is valid on multiple platforms. In this instance, the userid on the NonStop server would need to match some corporate standard, such as an employee number.

Because such userids are unlikely to fit the NonStop server's userid naming conventions, the only way to implement Single-SignOn is with aliases. Such aliases can be only be implemented securely if:

Each alias has a unique underlying userid.

The underlying userids are assigned to appropriate administrative groups based on the job function.

The underlying userids are not Privileged IDs such as SUPER.SUPER or an Application Owner.

If the alias will be the primary ID, the underlying userid can be frozen.

Safeguard rules are used to grant the underlying userids appropriate access.

Such aliases can be implemented securely by creating an individual userid, in the appropriate administrative group, for each user. The alias is then created for this individual userid. The underlying userid can then be frozen to prevent anyone logging onto it, and the alias used as the primary ID. This way, the user's privileges can be restricted, based on the underlying userid, which can be used in Safeguard Protection Records.