Secure EVS considerations

When using secure EVSs, keep the following points in mind:

• Security context defaults. Unless an individual security context is specified for an EVS (making it a secure EVS), the EVS security context defaults to the global security context.
• Inherited global settings. NDMP user name and password settings are not EVS-specific; the same NDMP user name and password settings apply to all EVSs and secure EVSs in a server/cluster.
• Secure EVS-specific security settings. After an EVS has a defined individual security context, it becomes a secure EVS, and each secure EVS is considered to be separate from all other EVSs and secure EVSs in the server or cluster.

  A secure EVS is always treated as an individual unit, whether it uses the same security context settings as another secure EVS or uses different security context settings. As a result, different secure EVSs cannot share anything, including an individual EVS name space.

• Secure EVS migration. When a secure EVS migrates to a different cluster, it retains all specified security settings in its individual security context. If, however, a secure EVS is configured to use default settings from the global context, then the secure EVS uses the settings in the global context of the cluster to which it migrates.
• Moving file systems between secure EVSs. A system administrator with sufficient privileges can move a file system from one secure EVS to another, but a warning is issued if the security contexts of the source and destination secure EVSs are different.
• External name server access. Each secure EVS can be configured to connect to several external name servers, and each secure EVS can connect to different name servers.
• Secure EVSs and name spaces. Links from the cluster’s CNS tree to a secure EVS are supported, according to the following rules:
  • Accessing the CNS. Only a secure EVS that uses the global security context can access links in the CNS.
  • CNS links to a file system hosted by a secure EVS with an individual security context are not allowed. In the CNS, you cannot add a link to a file system hosted by a secure EVS. Similarly, you cannot configure an individual security context for an EVS (turning an EVS into a secure EVS) if there are CNS links to one or more file systems in that EVS.
  • Name space usage and the secure EVS. If you want to use a name space with a secure EVS that does not use the global configuration settings, you must configure an EVS name space for that secure EVS. An EVS name space is required because file systems hosted by the secure EVS cannot be linked to from the CNS, and file systems hosted by the EVS cannot access links in the CNS.

    If you want to use a name space with a secure EVS that does use the global configuration settings, you may configure an EVS name space for that secure EVS, but it is not required. If the secure EVS uses the global security settings, the file systems hosted by the EVS can access links in the CNS.

  • Links to a secure EVS individual name space. In a secure EVS with an individual name space, you can add links between file systems hosted by the same secure EVS.
• Configuring a group of EVSs with the same settings. To create a group of secure EVSs that use the same individual security context settings (that are different from the global settings), you must configure each secure EVS in the group separately.
• Reconfiguring a secure EVS security context to use the global context. If a secure EVS is reconfigured to use the global security context (reverting it to an EVS), and the secure EVS was using a different NT domain than the cluster, CIFS names and CIFS share names become invalid. This occurs because CIFS names (and CIFS share names) are associated with a specific NT domain, and the NT domain name changes.

  If the global security context and the secure EVS and the NT domain are different, after you remove the secure EVS’ individual security context (making it an EVS again), you must delete all CIFS names for the EVS and all CIFS shares for the file systems in the EVS. Then, you must recreate the EVS CIFS names and the CIFS shares for the file systems in the EVS.

Parent Topic

• Server and Cluster Administration Guide

  This guide provides information about administering servers, clusters, and server farms. Includes information about licensing, name spaces, upgrading firmware, monitoring servers and clusters, the backing up and restoring configurations.

Child Topics

• About security contexts
• Security context contents

About security contexts

Because EVSs and secure EVSs inherit many of their settings from the cluster’s global context, when configuring name services, you must specify if you want to change the global context or the individual context.

For example, on the NIS/LDAP Configuration page or the EVS Details page, the current security context displayed as follows.

The EVS security context can be any of the following:

• Global Configuration, which indicates that the current security context is the global context.
• Inherits Global Configuration, which indicates that the EVS is a regular EVS (not a secure EVS), and it uses the security context settings defined in the global security context.
• Individual Configuration, which indicates that the current security context is an individual context that has individually specified settings.

On the Name Services and NIS/LDAP Configuration pages, click change to switch the current context between an individual context for a particular secure EVS and the global context.

If you make changes that affect:

• The global context, those changes apply to all EVSs that have security context settings set to Inherits Global Configuration.
• An individual context, those changes apply only to the currently selected EVS.

On the EVS Details page, click change to switch the context used by the EVS:

• If an individual context is being used, you can change the EVS to use the global context, removing the individual security context and changing the secure EVS into a regular EVS.
• If the global context is being used, you can change the EVS to use an individual context (creating a secure EVS).

Parent Topic

• Secure EVS considerations