User authentication and roles e-Learning course

If you manage a small system, you might only need one user: the Superuser. The Superuser is created when the system is created, cannot be deleted, and has full authority over system functions. A password is required to access the system and perform specific service actions. The rest of this e-Learning topic is applicable to administrators who manage a large number of users who require different levels of access. If you are managing a large system, you will most likely need more than one user. The content of this e-Learning module applies to both small and large systems.

To organize a large number of system users, the security administrators can create user groups. The user group determines the user role, which defines the level of access to different system functions.

There are five default user groups and roles available in cases where you need more than the Superuser. When you add a new user to a group the user is associated with the corresponding role. The Monitor role only provides access to viewing actions. These users cannot perform actions that change the state of the system. The Copy Operator can view actions, and can also perform management tasks for all existing Copy Services relationships. The Service role can view actions, and can perform service-related tasks, including disk discovery and viewing the progress of actions on the system. The Administrator role can access all functions and commands, except those commands related to managing users, user groups, and authentication. The Security Administrator can access all functions and commands.

While user roles specify the system tasks that a user can perform, authentication controls how users access the system. There are two types of authentication. Remote authentication uses credentials held on a remote server. Users who authenticate in this way are known as remote users. Local authentication uses credentials held on the system. Users who authenticate this way are known as local users.

Local users must be associated with one, and only one, of the user groups that were previously mentioned. If a local user wants to access the management GUI or CLI, he or she must have a password. For access to the CLI, an ssh key, or both.

Remote user authentication can be configured in one of two ways. The product can communicate directly with supported LDAP servers, including IBM Tivoli(R) Directory Server and Microsoft(R) Active Directory, to obtain user information. This is known as native LDAP. The alternative is to use an enterprise-wide directory service, such as IBM Tivoli Integrated Portal, to communicate user information between the product and one or more LDAP servers. The second approach provides centralized management, which enables a remote user to sign on once to a SAN management application, and then access the management GUI and other applications without needing to sign on again. With either method, remote authentication defines users, groups, and the mapping of users to groups. The product then maps these user groups to user roles.

If you have implemented native LDAP, a remote user can access the GUI or CLI using a user name and password, just as a local user does. If you have implemented centralized management, a remote user must be created and, if CLI access is required, then a user password and SSH key must be stored on the system. But, if a remote user wants to only access the management GUI, no credentials are needed on the system. Note that if you have remote users, you will want to set the date and time on the system using the same Network Time Protocol, or NTP server, as the authentication service. This ensures correct assignments for user roles.

Now that you understand some authentication concepts, here is an example of how to configure authentication for a local user. Kevin is a local user who requires access and you want to set up a user name and password for him.

You create a local user by going to the Users panel. Select New User. Enter a user name for Kevin and select Local for the authentication mode. Select the Monitor user group for Kevin and create his password. He is now added to the list of users.

For some systems, authentication is configured automatically for a remote user. If Maria is a remote user who needs GUI and CLI access, and you are using LDAP to manage remote authentication, you have the option of setting up an SSH key for her.

To manually configure the remote authentication service, go to the Directory Services panel. Click Configure Remote Authentication. You select IBM Tivoli Integrated Portal, and enter the user name, password, and web address for the remote authentication service.

Next, identify the user groups that can access the product as defined by the remote authentication service. Then, create new groups on the system, with the same names.

In this example, you discover that Maria is assigned to the Monitors user group on the remote authentication service. So you create a Monitors user group on the system with the Monitor role assigned to it. Ensure that the remote setting is enabled for this group.

Now that you have configured remote authentication, you need to generate an SSH key pair, and then create a user.

To generate an SSH key pair, install the PuTTY SSH client software program on your workstation. You also need to install PuTTY on any other workstation that will access the CLI, although this task could be performed at a later time.

Open the PuTTY key generator, select SSH-2 RSA as the type of key to generate, and click Generate. Move your cursor around the blank area of the Key section to generate the random characters that create a unique key. Information about the new key is then displayed. Save the public key and the private key. In this example, Maria will be using the CLI from her workstation, so she will need to save the private key on that workstation.

Next, go to the Users panel. Select New User. Enter a user name for Maria and select Remote for the authentication mode. Because Maria is not a local user, you do not specify her user group as this is defined by the remote service. Enter her password, which needs be the same as the password required by the remote authentication service. Select the public SSH key you just generated. Click Create and Maria should then be able to access the system.

Now that you understand how to authenticate and create local and remote users, you will learn how to manage established users and user groups. To view all authorized cluster users, go to the Users panel. Here you can see the assigned user group, whether the user has a configured password, and whether the user has an associated SSH key. In this panel, you can also select to modify or delete a user.

Select a user group to view the members of each group, including the names of individual users. From here you can remove an SSH key from a specific user, or delete the user.

In this e-Learning module, you learned that you can control access to system functions using the five default user groups and corresponding roles. You also learned the differences between local and remote users and how to configure authentication for each. Finally, you learned how to use the management GUI to manage authentication and users.

To learn more, see the software installation and configuration topics in this information center.