EMC Celerra Network Server · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103...

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-91031-508-435-1000www.EMC.com

EMC® Celerra® Network ServerRelease 6.0

Celerra Security Configuration GuideP/N 300-009-990

REV A01

Celerra Security Configuration Guide2 of 102 Release 6.0

3 of 102Release 6.0Celerra Security Configuration Guide

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Cautions and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5User interface choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Related information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Planning considerations for user identification and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Planning considerations for using an external LDAP-based directory server for user identification and authentication . . . . . . .22Planning considerations for role-based user access . . . . . . . . . . . .25Planning considerations for password security . . . . . . . . . . . . . . . .29Planning considerations for Public Key Infrastructure. . . . . . . . . . .30

Configuring the use of an external LDAP-based directory server for user identification and authentication . . . . . . . . . . . . . . . . . . . . . . . . .34Configuring password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Define password policy interactively . . . . . . . . . . . . . . . . . . . . . . . .37Define specific password policy definitions . . . . . . . . . . . . . . . . . . .38Set password expiration period . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Configuring session timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Change the session timeout value . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Customizing a login banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Creating a message of the day (MOTD) . . . . . . . . . . . . . . . . . . . . . . . . . . .42Protecting session tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Configuring network encryption and authentication using the SSL protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Using HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Using SSL with LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Change the default SSL protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Change the default SSL cipher suite . . . . . . . . . . . . . . . . . . . . . . . . .45Postrequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Configuring PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Creating the certificate provided by the persona . . . . . . . . . . . . . . .47Obtaining CA certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Using the Control Station as the CA. . . . . . . . . . . . . . . . . . . . . . . . . .47Generate a key set and certificate request. . . . . . . . . . . . . . . . . . . . .48Send the certificate request to the CA . . . . . . . . . . . . . . . . . . . . . . . .51Import a CA-signed certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52List the available CA certificates . . . . . . . . . . . . . . . . . . . . . . . . . . .54Acquire a CA certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Import a CA certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Generate a new Control Station CA certificate . . . . . . . . . . . . . . . . .57Display the certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Distribute the Control Station CA certificate . . . . . . . . . . . . . . . . . . .60

Managing PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Display key set and certificate properties . . . . . . . . . . . . . . . . . . . .61Check for expired key sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Clear key sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

Celerra Security Configuration GuideRelease 6.0 4 of 102 Celerra Security Configuration GuideRelease 6.0 4 of 102

Display CA certificate properties . . . . . . . . . . . . . . . . . . . . . . . . . . .63Check for expired CA certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Delete CA certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65Where to get help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65EMC E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . . .65Troubleshooting the Control Station connection to a LDAP-based directory server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65Troubleshooting local user accounts . . . . . . . . . . . . . . . . . . . . . . . . .66Troubleshooting domain-mapped user accounts . . . . . . . . . . . . . . .68Troubleshooting certificate imports . . . . . . . . . . . . . . . . . . . . . . . . . .68Error messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Training and Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . .70

Appendix A: CLI role-based access setup . . . . . . . . . . . . . . . . . . . . . . . .71Appendix B: Supported SSL cipher suites . . . . . . . . . . . . . . . . . . . . . . . .81Appendix C: Understanding your LDAP-based directory server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Active Directory Users & Computers . . . . . . . . . . . . . . . . . . . . . . . . .83Ldap Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99


IntroductionThe EMC® Celerra® Network Server implements a variety of security features to control user and network access, monitor system access and use, and support the transmission of encrypted data. These security features are implemented on the Control Station and Data Movers. This document explains why, when, and how to use these security features. A basic understanding of these features is important to understanding Celerra security. "Concepts" on page 10 provides more details. This document is part of the Celerra Network Server documentation set and is intended for administrators responsible for the overall configuration and operation of the Celerra.

System requirementsTable 1 on page 5 describes the Celerra Network Server software, hardware, network, and storage configurations.

Cautions and warnings If any of this information is unclear, contact your EMC Customer Support Representative for assistance.If you do not change the default passwords during installation, you should change them as soon as possible.

User interface choicesThe Celerra Network Server offers flexibility in managing networked storage that is based on your support environment and interface preferences. This document describes how to configure security features by using the command line interface (CLI). You can also perform many of these tasks by using the EMC Unisphere™ software.The Unisphere online help contains additional information about managing your Celerra.The Celerra Network Server Release Notes contain additional, late-breaking information about Celerra management applications.

Table 1 Security system requirements

Software Celerra Network Server version 6.0

Hardware No specific hardware requirements

Network No specific network requirements

Storage No specific storage requirements


TerminologyThe Celerra Glossary provides a complete list of Celerra terminology.access control entry (ACE): In a Microsoft Windows environment, an element of an access control list (ACL). This element defines access rights to a file for a user or group.access control list (ACL): A list of access control entries (ACEs) that provide information about the users and groups allowed access to an object. access policy: The policy that defines what access control methods (NFS permissions and/or Windows ACLs) are enforced when a user accesses a file on a Celerra system in an environment configured to provide multiprotocol access to some file systems. The access policy is set with the server_mount command and also determines what actions a user can perform against a file or directory. authentication: The process for verifying the identity of a user trying to access a resource or object, such as a file or a directory. Certificate Authority (CA): A trusted third party that digitally signs public key certificates.Certificate Authority Certificate: A digitally signed association between an identity (a Certificate Authority) and a public key to be used by the host to verify digital signatures on Public Key Certificates.command line interface (CLI): An interface for entering commands through the Control Station to perform tasks that include the management and configuration of the database and Data Movers and the monitoring of statistics for the Celerra cabinet components. Common Internet File System (CIFS): A file-sharing protocol based on the Microsoft Server Message Block (SMB). It allows users to share file systems over the Internet and intranets. Control Station: A hardware and software component of the Celerra Network Server that manages the system and provides an administrative user interface to Celerra components. Data Mover: A Celerra Network Server cabinet component running its own operating system that retrieves files from a storage device and makes them available to a network client.digital certificate: An electronic ID issued by a certificate authority that establishes a user’s credentials. It contains the user’s identity (a hostname), a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting messages and digital signatures), and a digital signature from the certificate-issuing authority so that a recipient can verify that the certificate is valid. directory server: A server that stores and organizes information about a computer network's users and network resources, and that allows network administrators to manage users' access to the resources. X.500 is the best-known open directory service. Proprietary directory services include Microsoft’s Active Directory. Hypertext Transfer Protocol (HTTP): The communications protocol used to connect to servers on the World Wide Web. Hypertext Transfer Protocol Secure (HTTPS): HTTP over SSL. All network traffic between the client and server system is encrypted. In addition, there is the option to

../../mergedprojects/Glossary/index.htm


verify server and client identities. Typically server identities are verified and client identities are not.Kerberos: An authentication, data integrity, and data privacy encryption mechanism used to encode authentication information. Kerberos coexists with NTLM (Netlogon services) and, using secret-key cryptography, provides authentication for client/server applications.LDAP-based directory: A directory server that provides access by LDAP. Examples of LDAP-based directory servers include OpenLDAP or iPlanet (also known as Sun Java System Directory Server and Sun ONE Directory Server). Lightweight Directory Access Protocol (LDAP): An industry-standard information access protocol that runs directly over TCP/IP. It is the primary access protocol for Active Directory and LDAP-based directory servers. LDAP Version 3 is defined by a set of Proposed Standard documents in Internet Engineering Task Force (IETF) RFC 2251. Network File System (NFS): A distributed file system providing transparent access to remote file systems. NFS allows all network systems to share a single copy of a directory. OpenLDAP: The open source implementation of an LDAP-based directory service.persona: A means of providing an identity for a Data Mover as either a server or a client through a private key and associated public key certificate. Each persona can maintain up to two sets of keys (current and next), to allow for the generation of new keys and certificates prior to the expiration of the current certificate. Public Key Infrastructure (PKI): A means of managing private keys and associated public key certificates for use in Public Key Cryptography.Simple Network Management Protocol (SNMP): Method used to communicate management information between the network management stations and the agents in the network elements.Secure Socket Layer (SSL): A security protocol that provides encryption and authentication. It encrypts data and provides message and server authentication. It also supports client authentication if required by the server.Transport Layer Security (TLS): The successor protocol to SSL for general communication authentication and encryption over TCP/IP networks. TLS version 1 is nearly identical with SSL version 3.X.509: A widely used standard for defining digital certificates. XML API: An interface for remotely managing and monitoring a Celerra Network Server. The interface uses XML formatted messages, and is programming language neutral.


Related information Specific information related to the features and functionality described in this document is included in:◆ Celerra Network Server Command Reference Manual

◆ Online Celerra man pages

◆ Celerra Network Server Parameters Guide

◆ Celerra Glossary

◆ Installing Celerra Management Applications

◆ Configuring and Managing CIFS on Celerra

◆ Configuring NFS on Celerra

◆ Managing Celerra for a Multiprotocol Environment

◆ Configuring Celerra Naming Services

◆ Using Celerra FileMover

◆ Configuring Celerra Events and Notifications

◆ Auditing in the Celerra Control Station Technical Note

◆ Celerra Network Server on the Enterprise Network Technical Note

For general information on LDAP, refer to:◆ RFC 2307, An Approach for Using LDAP as a Network Information Service

For specific information on Active Directory’s LDAP and SSL configuration, refer to:◆ Microsoft Knowledge Base article How to enable LDAP over SSL with a third-

party certification authority (ID 321051)

For specific information on OpenLDAP and SSL configuration, refer to the OpenLDAP website (www.openldap.org). If you are using a different non-Active Directory LDAP-based directory server, refer to that vendor’s documentation for information on LDAP and SSL configuration.

EMC Celerra documentation on PowerlinkThe complete set of EMC Celerra customer publications is available on the EMC Powerlink® website. To search for technical documentation, go to http://Powerlink.EMC.com. After logging in to Powerlink, click Support, and locate the link for the specific product technical documentation required.

Celerra Support DemosCelerra Support Demos are available on Powerlink. Use these instructional videos to learn how to perform a variety of Celerra configuration and management tasks. After logging in to Powerlink, click Support. Then click the link for the specific product required. Click Tools. Locate the link for the video you require.

http://powerlink.emc.com../CommandReference/index.htm../Parameters/index.htm../InstallationManagement/index.htm../ConfWindows/index.htm../CgNFS/index.htm../ConfWinMulti/index.htm../FileMover/index.htm../EventsandNotifications/index.htm


Celerra wizardsCelerra wizards can be used to perform set up and configuration tasks. Using Wizards to Configure Celerra provides you with an overview of the steps required to configure a Celerra Network Server using the Set Up Celerra wizard.


Concepts Strong system security features are increasingly necessary to comply with new regulations and ensure greater protection against system attacks. Celerra implements a variety of features on both the Control Station and Data Movers to secure its infrastructure, control access, and protect data.On the Control Station: ◆ To secure its infrastructure, Celerra provides a variety of features that can be

used to tighten the operation of the Control Station. Table 2 on page 11 describes these features.

◆ To protect system resources against unauthorized access, Celerra supports strict user identification and authentication, role-based access, and customer-defined password policies. Table 3 on page 13 describes these features.

◆ To support the transmission of encrypted data, Celerra supports the SSL security protocol. Table 4 on page 15 describes this feature.

On Data Movers: ◆ To secure its infrastructure, Celerra provides a variety of features that can be

used to tighten the operation of the Data Movers. Table 5 on page 16 describes these features.

◆ To protect the transmission of encrypted data, Celerra supports the SSL security protocol and public key certificate management for certain protocols. Table 6 on page 19 describes these features.

Although many of these features require explicit configuration and management, others have been introduced as basic changes to software operation. For example, beginning with Celerra version 5.6, the following changes have been implemented:◆ Security between a user and the Unisphere software and between two Control

Stations has been enhanced by changing the checksum used to sign the session token (cookie) from MD5 to SHA1. SHA1 produces a 160-bit hash value unlike MD5, which produces only a 128-bit hash value.

◆ Unnecessary services and dynamic ports have been removed from the Control Station's Linux operating system.

Note: Many of the Celerra’s security features are described elsewhere in the documentation library, as noted in the overview tables. Therefore, this document includes detailed configuration procedures for only a subset of the available security features.


Table 2 Overview of Control Station features to secure infrastructure (page 1 of 2)

Feature What it does Restrictions More information

Session timeout Celerra enforces a session timeout for administrative sessions accessed from both Control Station shells and Unisphere. Sessions time out after a specified period of inactivity.

Session timeout is enabled by default. You must be root to modify Control Station properties.

To manage shell session timeout, use the command /nas/sbin/ nas_config -sessiontimeout. "Configuring session timeout" on page 39 describes how to configure this feature. To manage Unisphere session timeout, select Settings (UI Sessions tasks) > Manage Idle Timeout. You can find a description of this feature in Unisphere online help.

Login banner and message of the day (MOTD)

A login banner and message of the day (MOTD) provide a way for an administrator to communicate with Celerra users. The same login banner is seen from the command line interface and Unisphere. The MOTD is seen only from the command line interface.

You must be root to modify Control Station properties.

To configure the banner through Unisphere, select System (System tasks) > Manage Control Stations. You can find a description of this feature in Unisphere online help.To configure the banner and MOTD through the CLI, use a text editor to edit the /etc/issue or /etc/motd files. "Customizing a login banner" on page 41 and "Creating a message of the day (MOTD)" on page 42 describe how to configure these features.

Network services management

In Unisphere, you can list the current state of some network services (and associated communications ports and protocols) on the Control Station. You can enable, disable, and monitor these services. To improve Celerra security, you should restrict access to the Celerra by disabling network services that are not used in your environment.


To manage network services through Unisphere, select System > Network > Network Services. You can find a description of this feature in Unisphere online help.

Session tokens (cookies) Celerra uses SHA1 to generate checksums to protect the session tokens (cookies) used to identify users after they log in. To enhance security, you can change the default SHA1 secret value used to generate the checksums.

When you change this value, existing session tokens (cookies) are no longer valid and current users of Unisphere will have to log in again. You must be root to modify Control Station properties.

To manage session tokens (cookies), edit the file /nas/http/conf/secret.txt. "Protecting session tokens" on page 43 describes how to configure this feature.


Auditing Celerra provides configuration files and commands to capture management activities initiated from the Control Station, specifically access to key system files and end-user data.


The Technical Note Auditing in the Celerra Control Station, available on EMC Powerlink, provides specific information about how to implement auditing.

Table 2 Overview of Control Station features to secure infrastructure (page 2 of 2)



Table 3 Overview of Control Station features to control access (page 1 of 2)


User identification and authentication

Unique user accounts allow for more secure management of the Celerra. User accounts can be either a local user account or a local user account mapped from a LDAP or storage domain user account. LDAP domain-mapped user accounts require that Celerra has access to a LDAP-based directory server. This may mean configuring access to an Active Directory or a non- Active Directory server such as OpenLDAP or iPlanet. Storage domain-mapped user accounts require that the Celerra is joined to the storage domain of its associated EMC CLARiiON®.

Users can be managed only through Unisphere. The Linux commands available from the CLI (useradd, userdel, usermod, groupadd, groupmod, and groupdel) do not support Celerra role-based user access and should no longer be used to manage user and group accounts.You must be root or a user who has root or security operator privileges to create a new user account.

"Planning considerations for user identification and authentication" on page 20 describes the concepts behind this feature. To create and manage users with Unisphere, select Settings > User Management. You can find a description of this feature in Unisphere online help. "Planning considerations for using an external LDAP-based directory server for user identification and authentication" on page 22 describes how Celerra interacts with an LDAP-based directory server and "Configuring the use of an external LDAP-based directory server for user identification and authentication" on page 34 describes how to configure this feature.

Role-based user access This feature enables you to assign users privileges that are appropriate to their responsibilities. Consequently, it simplifies the Unisphere and CLI interfaces for users by limiting the operations they can perform while protecting the system and customer data from operations by those who should not perform them.A role defines the privileges (read, modify, or full control) you can perform on a particular Celerra object. Celerra offers both predefined and custom roles.

You must be root or a user who has root or security operator privileges to assign roles.

"Planning considerations for role-based user access" on page 25 describes the concepts behind this feature. To create and manage role-based user access with Unisphere, select Settings > User Management. You can find a description of this feature in Unisphere online help.


Password quality policy Strong passwords are an important element of a security strategy. Celerra enforces several requirements to guarantee a password quality policy.

This feature defines password complexity requirements for all local users. This feature does not apply to domain-mapped users, whose passwords are governed by the policies within the domain.You must be root to define the password quality policy.

"Planning considerations for password security" on page 29 describes the elements of a password quality policy. To define password quality policy, use the command /nas/sbin/ nas_config -password. "Configuring password policy" on page 37 describes how to configure this feature.

Table 3 Overview of Control Station features to control access (page 2 of 2)



Table 4 Overview of Control Station features to protect data


SSL (X.509) certificates for Unisphere

Unisphere uses SSL encryption and authentication to protect the connection between the user’s web browser and Celerra’s Apache web server. Digital certificates, whose authenticity is verified by a CA, are used by SSL to identify and authenticate the server. Starting with 5.6, the Celerra software automatically generates the CA certificate and a new Apache certificate signed by that CA certificate at system installation or software upgrade if these certificates do not already exist.

In the case of Unisphere, the Control Station serves as a limited purpose CA, signing the certificate provided by the Apache web server.If you change Celerra's hostname, you have to regenerate the Control Station’s CA and Apache certificates. When you generate a new CA certificate, a matching Apache certificate is also generated.If you only change Celerra's domain name or IP address, you can just regenerate the Apache web server’s certificate.Once you regenerate the certificates, any browsers or systems using the previous certificates need to install the new certificates.You must be root to modify Control Station properties.

Installing Celerra Management Applications describes how to configure this feature. The Celerra white paper Using Unisphere in Your Web Browsing Environment: Browser and Security Settings to Improve Your Experience, available on EMC Powerlink, provides information about how and why to install the certificates.

Network encryption and authentication using LDAP over SSL

Celerra supports SSL encryption and authentication on the LDAP connection between the Control Station and an LDAP-based directory server.

"Planning considerations for using an external LDAP-based directory server for user identification and authentication" on page 22 describes how Celerra interacts with an LDAP-based directory server, and "Configuring the use of an external LDAP-based directory server for user identification and authentication" on page 34 describes how to configure this feature.


Table 5 Overview of Data Mover features to secure infrastructure (page 1 of 3)


Network services management

In Unisphere, you can list the current state of some network services (and associated communications ports and protocols) on the Data Movers. You can enable, disable, and monitor these services. To improve Celerra security, you should restrict access to the Celerra by disabling network services that are not used in your environment, for example, FTP.

Some services that are running on the Data Movers require a reboot for changes to take effect.

To manage network services through Unisphere, select System > Network > Network Services. You can find a description of this feature in Unisphere online help.

CIFS Kerberos authentication

Since Kerberos is now the recommended authentication method in Windows environments, you may want to disable NTLM authentication. (By default, Celerra allows both Kerberos and NTLM authentication.)To set CIFS server authentication mode to Kerberos only, use the command server_cifs -add compname=, domain=, authentication=kerberos.

The server_cifs man page describes how to configure this setting. Configuring and Managing CIFS on Celerra describes authentication.

NFS security settings Although generally regarded as a vulnerable file-sharing protocol, you can make NFS more secure by using the following configuration settings: • Defining read-only access

for some (or all) hosts• Limiting root access to

specific systems or subnets• Hiding export and mount

information if a client does not have mount permissions for the file system corresponding to that entry

In addition, if strong authentication is required, you can configure Secure NFS, which uses Kerberos.

All NFS exports are displayed by default. To hide NFS exports, you must change the value of the forceFullShowmount parameter.

Configuring NFS on Celerra describes how to configure these settings.


Access policies Celerra’s set of customizable access modes allow you to choose the best possible interaction between NFS and CIFS access for your environment.You can select how security attributes are maintained and the type of interaction between NFS and CIFS users including: • Separate• CIFS dominant• NFS dominant• Equal • Mixed (used to achieve a

high level of synchronization between the two protocols)

The mixed access policy is required when using NFSv4.

Managing Celerra for a Multiprotocol Environment describes how to configure this feature.

Windows-style (NT) credentials for UNIX users

Celerra allows you to create a common Windows-style (NT) credential. Users therefore have the same credentials regardless of their file access protocol, providing more consistent access control.

Managing Celerra for a Multiprotocol Environment describes how to configure this feature.

SNMP management The SNMP community string provides the basis for security in SNMP. The default community name is the well-known name public. This name should be changed to prevent unwanted access to Celerra. Use the server_snmp -community command to assign a new value to a server SNMP agent’s community for a Data Mover.

SNMP is used for communication between the Control Station and Data Mover, so disabling it can interfere with some functions. For example, the server_netstat command will not work.

Configuring Celerra Events and Notifications describes how to configure this feature.




IP packet reflect IP packet reflect provides your network with an additional security level. Because reply packets always go out the same interface as the request packets, request packets cannot be used to indirectly flood other LANs. In cases where two network devices exist, one connected to the Internet and the other connected to the intranet, replies to Internet requests do not appear on the intranet. Also, the internal networks used by Celerra are not affected by any packet from external networks.

Configuring and Managing Celerra Networking describes how to configure this feature.




Table 6 Overview of Data Mover features to protect data


Network encryption and authentication through SSL

Celerra supports SSL encryption and authentication for both LDAP and HTTP connections between Data Movers and various external services.

SSL on Data Mover connec-tions can be configured and managed only through the CLI.

"Configuring network encryption and authentication using the SSL protocol" on page 44 describes how to configure parameters associated with this feature. Configuring Celerra Naming Ser-vices and Using Celerra FileM-over describe how to configure and manage SSL for these fea-tures.

Public key certificates The PKI framework provides the software management and database systems to support the use of digital certificates for Data Mover LDAP and HTTP connections on which SSL is enabled.

The Celerra PKI framework supports only X.509 public key certificates.

"Planning considerations for Public Key Infrastructure" on page 30 describes the concepts behind this feature. "Configuring PKI" on page 47 and "Managing PKI" on page 61 describe how to configure and manage this feature by using the CLI. To configure and manage PKI through Unisphere, select Settings > Public Key Certificates. You can find a description of this feature in Unisphere online help.


Planning considerations for user identification and authentication Creating unique users, each with privileges appropriate to their responsibilities, simplifies Celerra management by limiting the operations that users can perform as well as by protecting system and customer data from operations by users who should not perform them. The administrators feature enables you to define:◆ Users who need to view, configure, or manage Celerra file server operation

◆ Groups by which to organize users

◆ Roles to associate with groups

◆ Privilege levels that define the roles for accessing and controlling all Celerra objects

For simplified management, the user management feature also provides the ability to use an external LDAP directory server as a centralized repository of user accounts.In addition, user accounts created to manage storage are mapped to Celerra user accounts so that storage domain global users can be given privileges to access and control Celerra objects. The association of specific privileges with users, also referred to as roles, is supported for users who access the Celerra through the CLI, Unisphere, and the XML API.

Note: This feature is different from the existing Control Station access control support managed by using the nas_acl command.

Default usersCelerra provides two default user accounts: root and nasadmin. You can create additional users, each with privileges appropriate to their responsibilities. The root user can access and control every object and action in Celerra. The nasadmin user has the same access and control as root with certain exceptions. Table 8 on page 26 lists the Unisphere features root and nasadmin can access and control. Table 14 on page 78 lists the CLI commands that only root or nasadmin or, in some cases, an user account associated with the root and nasadmin roles can execute. "Planning considerations for role-based user access" on page 25 provides more information on how root and nasadmin are affected by role-based access.

Note: The privileges assigned to root and nasadmin cannot be modified and these accounts cannot be disabled or deleted.

Creating new users

You can also create additional user accounts, each with privileges appropriate to their responsibilities. Create new user accounts by using Settings > User


Management > Users > Create. Unisphere online help provides a detailed explanation of this procedure.

Note: Beginning with version 5.6, you should no longer create user accounts through the CLI. The Linux commands previously used in the CLI to manage user and group accounts (useradd, userdel, usermod, groupadd, groupmod, and groupdel) do not support Celerra role-based access and will no longer set up entries recognized by the Celerra software.

To create a new user account, you must be root or a user who has root or security_operator privileges. "Planning considerations for role-based user access" on page 25 describes how privileges are assigned and used. User accounts can be a local user account, a LDAP domain user account mapped from a LDAP domain account (described in "LDAP domain-mapped user accounts" on page 21), or a storage domain global user account mapped from a storage domain account (described in "Storage domain global user accounts" on page 21).

Note: When logging in to Unisphere with a local user account, select Scope and change the value to Local to indicate you are using a local user account that will be authenticated by and used to manage the Celerra system only.

LDAP domain-mapped user accounts

A LDAP domain-mapped user account uses the username and password specified on the LDAP domain server. This type of user account is always authenticated on the LDAP domain server. If the LDAP domain server is not available, the user is not able to log in. Mapping users to local user accounts provides the mechanism for verifying that a user who is authenticated by an external LDAP directory server is authorized to access the Celerra, and that the user has the necessary local credentials, including a UID, to perform tasks. Celerra provides the ability to automatically create local user accounts for LDAP domain users. When enabled, a local user account is established for any LDAP domain-mapped user who can successfully authenticate with the LDAP domain server and who belongs to at least one group mapped to the Celerra system. The LDAP domain user account's local account name will be the same name as the domain username along with the appended domain name (for example, joe.corp). If that name already exists locally, a number will be appended to the username (for example, joe1.corp). The appended number is the next unused number in sequence.

Note: When logging in to Unisphere with a LDAP domain user account, select Use LDAP to indicate the user account will be authenticated by the LDAP domain server. Select local scope to manage the Celerra system only. Select global scope to manage all systems within the storage domain.

Storage domain global user accounts

In addition to local user accounts and user accounts mapped from a LDAP domain account, a user account can be a local user account mapped from a storage domain global user account. Beginning with version 6.0, when a Celerra is joined to the storage domain of its associated CLARiiON, the existing storage domain global user account is imported into the Celerra user account database so that the global


user account can also be used to manage the Celerra system. A storage domain-mapped user account uses the username and password specified in the storage domain. This type of user account is always authenticated in the storage domain. By default, Unisphere expects that a storage domain user account be used to log in. Logging in using a global user account allows you to manage both Celerra and CLARiiON systems. However, since Celerra initially gives a storage domain-mapped user the operator role (read-only privileges), you must change the role with which it is associated to give it administrator privileges.

Note: Alternatively, you can manage both Celerra and CLARiiON systems by logging in using a LDAP domain user account that is recognized by both systems.

You define roles by using Settings > User Management > Roles > Create. Unisphere online help provides a detailed explanation of this procedure. Specifying user access to the Celerra

Users can access the Celerra system through the Control Station shell command line interface (CLI), Unisphere, or XML API.

Note: The XML API allows you to create your own GUI or other types of management interface. Like Unisphere and certain CLI commands, the XML API uses the Celerra software interface between the web user interface presentation layer and the core Control Station code, referred to as the appliance layer or APL. Consequently, access to the Celerra through the XML API must be specifically enabled.

When you create a new user, you must specify the type of access that user has to the Celerra. By default, a new user has no access. When a local user account is created automatically for a domain-mapped user that new user is given access to Unisphere and the XML API by default.

Planning considerations for using an external LDAP-based directory server for user identification and authenticationA user account can be identified and authenticated by an external directory server when the user logs in to the Celerra Control Station. The external directory server provides a centralized repository of user accounts, simplifying management. The external directory server can be an LDAP-based Active Directory or non-Active Directory server:◆ Active Directory is an LDAP-based directory service used in Windows that

provides management of user and group accounts, security, and distributed resources.

◆ OpenLDAP and iPlanet (also known as Sun Java System Directory Server and Sun ONE Directory Server) are distributed LDAP-based directory servers that provide a central repository for storing and managing identity profiles, access privileges, and application and network resource information.

Understanding the directory server An LDAP-based directory server organizes information in a hierarchical directory structure unique to a particular organization’s needs. Each object stored in the directory is represented by a directory entry. An entry is formed by one or more


attributes. Entries are stored in a hierarchical form in the directory tree. Each entry is uniquely defined by its distinguished name (DN) which enumerates the position of this entry in the tree. For example, the distinguished name for the admin group is "cn=admin,ou=group,dc=mycompany,dc=com". Using LDAP, one may query an entry and request all the entries and their attributes below the requested entry.An example of an LDAP-based directory structure is as follows:

dc= indicates domain components and ou= indicates organizational units consisting of people, groups, hosts, and netgroups. Typically, the cn attribute is used to indicate the name by which a particular entry is commonly known. The directory structure can be changed. You inform the Data Mover about your organization’s directory structure by uploading a custom client configuration profile or configuration file. For example, your organization’s user information might be stored in a container called users rather than people, and hosts in a container called computers rather than hosts. You can also define several containers for the same object class.

Configuring access To configure the Control Station’s LDAP-based client, you must have the following information:◆ domain name — Indicates the root of the LDAP directory tree, that is, where in

the LDAP directory tree to begin a search for information. Also known as the base distinguished name.

For example, the base distinguished name for the example LDAP-based directory structure is dc=mycompany,dc=com. Active Directory assumes that the attribute type is dc so the base distinguished name can be expressed as simply mycompany.com.

Note: Celerra supports only a single LDAP domain. It does not support trees or forests. Consequently, references to other domains are not followed.

◆ bind distinguished name — Indicates the identity used to bind to the LDAP service, that is, the user or account permitted to search the LDAP directory within the defined search base.

Typically, Active Directory assumes a bind distinguished name format of cn=,cn=users,dc=,dc=.

Note: The Active Directory administrator can create users in other locations within Active Directory, in which case the bind distinguished name path may be different.

dc=mycompany,dc=com

ou=hostsou=people ou=group ou=netgroup


An OpenLDAP directory server accepts different bind distinguished name formats such as cn=,uid=,ou=people,dc=,dc= or uid=,dc=users,dc=,dc=.

◆ user search path and name attribute — Indicate the directory branch Celerra will search for an instance of the name attribute whose value is the user’s account name.

Typically, Active Directory assumes a user search path and name attribute of cn=,cn=users,dc=,dc=.

Note: The Active Directory administrator can create users in other locations within Active Directory, in which case the user search path may be different.

An OpenLDAP directory server accepts different bind distinguished name formats such as uid=,ou=people,dc=,dc= or uid=,dc=users,dc=,dc=.

◆ group search path, name attribute, group class and member — Indicate the directory branch Celerra will search for an instance of the attribute whose value is the user’s group name. The group may be further specified by identifying the class in which the group is stored and the attribute of that class.

Active Directory assumes a group search path and name attribute of cn=,cn=users,dc=,dc=. In Active Directory, groups and users are stored in the same hierarchy. The group class is called group and the default attribute value is member.

Note: The Active Directory administrator can create groups in other locations within Active Directory, in which case the group search path may be different.

In other directory servers, the class may be posixGroup, groupOfNames, or groupOfUniqueNames. If the group class value is groupOfUniqueNames, the default attribute value is uniqueMember. If the group class value is groupOfNames, the default attribute value is member. If the group class value is posixGroup, the default attribute value is memberUid.

Connecting to the directory server using SSLTo protect LDAP traffic and improve client and server application security, the LDAP-based directory server can support and, in some cases, require the use of SSL. SSL provides encryption and authentication capabilities. It encrypts data over the network and provides message and server authentication. It also supports client authentication if required by the server. SSL uses digital certificates, whose authenticity is verified by a CA. The LDAP client, using the underlying SSL client, authenticates the certificate received from the LDAP-based directory server. The CA certificate (for the CA that signed the directory server's certificate) must have been imported into the Control Station for the certificate verification to succeed. In addition, the subject from the server's certificate must contain the hostname or IP address of the server, otherwise the certificate verification fails.


Note: The Control Station LDAP-based client implementation does not support SSL-based client authentication.

"Configuring the use of an external LDAP-based directory server for user identification and authentication" on page 34 describes how to configure this feature.

Planning considerations for role-based user accessA user account is always associated with a primary group and each group is assigned a role. A role defines the privileges (that is, the operations) the user can perform on a particular Celerra object. Beginning in version 5.6, you must have the appropriate privileges to access and control Celerra objects.

Groups and roles A user account is always associated with a primary group. It can also be associated with other groups to a maximum of 17. Like user accounts, groups can be either a local group or a local group mapped to a domain group. Celerra offers both predefined and custom groups. Predefined groups cannot be modified or deleted. Each group is assigned a role. A group can be assigned only one role at a time, although a role can be associated with many groups. If a group is not assigned a role, the group is given the default role of operator, which has read privileges only. Table 7 on page 25 lists the predefined groups and their associated roles.

Table 7 Predefined groups and their associated roles (page 1 of 2)

Group name Associated role

backup backup_operator

fullnas nasadmin

nasadmin operator

network network_admin

opadmin operator

root root

security security_operator

storage storage_admin

imported_administrator imported_administrator

imported_manager imported_manager

imported_monitor imported_monitor


Note: Groups and roles with the prefix imported are mapped from storage domain groups and roles. User accounts created to manage storage are mapped to Celerra user accounts, groups, and roles so that storage users can be given privileges to access and control Celerra objects.

A user can have multiple roles by belonging to multiple groups. In this case, a union of these roles determines what operations the user can perform.You can create new groups by using Settings > User Management > Groups > Create.

Roles and privilegesA role defines the privileges (operations) a user can perform on a particular Celerra object. There are three levels of privileges: ◆ Read — Allows a user to view objects. By default, all users have read privileges

on all objects.

◆ Modify — Allows a user to make changes to an object.

◆ Full control — Allows a user to create and delete objects and make significant changes. By default, all users have full control of the task object.

Celerra offers both predefined and custom roles. Predefined roles (also identified as system roles) cannot be modified. Custom roles (also identified as user roles) are roles defined by administrators.The predefined roles (and the Unisphere sections and CLI commands over which those roles have full control privileges) are listed in Table 8 on page 26.

imported_replication imported_replication

imported_security_admin imported_security_admin

Table 8 Unisphere and CLI full control privileges given to predefined roles (page 1 of 3)

Predefined roles Unisphere sections over which role has full control Associated CLI commands

root All Unisphere sections

Note: To have full control over Control Station properties and Connect Home, you must be logged in as the root user. A user assigned root privileges does not have full control over these objects.

All commands

Table 7 Predefined groups and their associated roles (page 2 of 2)

Group name Associated role


nasadmin All Unisphere sections except:System (System tasks) > Manage Control StationsSystem (System tasks) > Setup Celerra Wizard > Control Station setupSystem (Service tasks) > Manage Connect HomeSettings > User Management (users, groups, & roles)Settings > User Management (UI Sessions tasks) > Manage Idle Timeout

All commands with some exceptions. See Table 14 on page 78 for a list.

security operator Settings > User ManagementSettings > Public Key Certificates

nas_licenseserver_certificateserver_kerberosserver_security

backup operator Replicas > CheckpointsStorage > Virtual Tape

fs_ckptnas_ckpt_scheduleserver_mount server_mountpointserver_umountserver_vtlu

filemover_application Storage > File Systems cel_fsfs_dhsmfs_groupfs_timefindernas_fsnas_fsckserver_httpserver_mpfsstat

network admin System > Network > InterfacesSystem > Network > DevicesSystem > Network > DNSSystem > Network > RoutesSystem > Network (Network tasks) > Manage NIS Settings

server_arpserver_dnsserver_ftpserver_ifconfigserver_ldapserver_nisserver_ripserver_routeserver_snmpserver_snmpdserver_sysconfig




The ability to select a predefined role or define a custom role that gives a user the necessary privileges to execute a command is not available for all CLI commands. The specific command actions available when Modify or Full Control privileges are selected are listed in "Appendix A: CLI role-based access setup" on page 71. Commands not included in this list can only be performed by the default user accounts root and nasadmin or, in some cases, by a user account associated with the root and nasadmin roles. You define roles using by Settings > User Management > Roles > Create.

Default user privilegesThe user account root has its primary group membership in the root group that is associated with the root role. The user account nasadmin has its primary group membership in the nasadmin group, which is associated with the operator role for read-only access. In addition, it is a member of the fullnas group, which is associated with the nasadmin role for modify and full-control access to almost all Celerra objects.By default, a new user is assigned to the nasadmin group, which means the user has only read privileges.

storage admin Storage > File SystemsStorage > Data MigrationStorage > Storage PoolsStorage > Volumes

cel_fsfs_dhsmfs_groupfs_rdffs_timefindernas_disknas_fsnas_fscknas_poolnas_quotasnas_slicenas_storagenas_volumeserver_cdmsserver_devconfigserver_httpserver_mountserver_mountpointserver_mpfsstatserver_umount

operator n/a Display-type options for all commands (such as, -info, -list, -status, -verify)

sd_name n/a n/a




Note: In the role-based user access feature, the nasadmin group is associated with the more restrictive operator role. The broader privileges previously associated with the default nasadmin user account are now accessed through membership in the fullnas group. When upgrading to version 5.6, all users previously associated with the nasadmin group are automatically assigned membership in the fullnas group so they retain modify and full-control access to most Celerra objects.

What happens once roles are assignedA user must have the appropriate privileges to access and control Celerra objects. Using Unisphere

If a user uses Unisphere to access the Celerra system and that user is not authorized to perform a certain function that function is dimmed and unavailable. This can occur in menus, buttons, and fields.Using the CLI

If a user uses the CLI to access the Celerra system and that user is not authorized to perform a certain function, the Celerra software returns an error message. This error message indicates that the user does not have permission to perform this operation and that the role database has to be modified in order for the user to get permission.

Planning considerations for password securityStrong passwords are an important element of a security strategy.

Password quality policyTo ensure that sufficiently strong passwords are chosen by all local users, you can define a password quality policy that enforces a certain complexity for user-defined passwords. This feature does not apply to domain-mapped users, whose passwords are governed by the policies within the domain. The default Celerra password policy includes the following requirements: ◆ A minimum password length of 8 characters

◆ A maximum of 3 attempts to define a new password of acceptable value before the command fails

◆ A minimum of 3 characters that were not in the previous password

◆ A minimum of one numeral in the new password

Note: There is currently no requirement to use special characters (such as !, @, #, $, %, &, ^, and *) or lowercase and uppercase characters in the password.

Celerra also supports a default password expiration period of 120 days. "Configuring password policy" on page 37 describes how to configure this feature.

Note: Changes made to the password quality policy apply only to password defined after the policy is revised.


Changing default passwordsCelerra provides two default user accounts: root and nasadmin. Both accounts are assigned the password nasadmin by default. The Celerra software installation procedure allows you to enter a different password, but a new password is not required.

!CAUTION!If you do not change the default passwords during installation, you should change them as soon as possible.

You choose and change passwords through the User Properties dialog box in Unisphere. Unisphere online help provides a detailed explanation of this procedure.

Note: You can access the User Properties page from Settings > User Management > Users or from the User Name field on Control Station Properties.

Root and users with security operator privileges are not required to choose passwords that conform to password policy. Furthermore, when creating a new user account, root and users with security operator privileges can assign any password to that user. However, if the user subsequently changes the password, this password is subject to the current password policy. Once the password policy is set, you will receive an error indicating the password is bad if you attempt to define a password that does not meet the specified requirements.

Planning considerations for Public Key InfrastructureCelerra’s Public Key Infrastructure (PKI) provides the software management and database systems to support the use of digital certificates for Data Mover LDAP and HTTP connections on which SSL is enabled. Certificates, whose authenticity is verified by a Certificate Authority (CA), are used by SSL to identify one or both ends of a connection, providing stronger security between clients and servers.

Note: Celerra’s PKI framework supports the X.509 certificate standard. Certificates are encoded using Distinguished Encoding Rules (DER) and may be further encoded in Privacy Enhanced Mail (PEM) format for ease of distribution through email systems.

PersonasPersonas are used to provide an identity for a Data Mover when it is acting as a server or a client. When negotiating a secure connection with a client (such as the external policy and migration software used with FileMover), the persona provides a private key and certificate to the Data Mover (which is acting as a server). This certificate provides the means by which the client can identify and authenticate the server. When negotiating a secure connection with a server (such as an external LDAP-based directory server) that is configured to require client authentication, the persona provides the private key and certificate to the Data Mover (which is acting as a client). The certificate provides the means by which the server can identify and authenticate the client.


By default, each Data Mover is configured with a single persona named default. To create the certificate that the persona provides to the Data Mover, you first generate the persona’s public/private key set. You must then request a signed certificate from a CA. Certificate requests are generated in Privacy Enhanced Mail (PEM) format only.

Note: Currently, each Data Mover is allowed only one persona. Celerra does not support a mechanism to create additional personas.

If you are using the Celerra’s Control Station as the CA, the Control Station automatically receives the certificate request, generates and signs the certificate, and returns the certificate to the Data Mover. The Control Station can sign certificates for all the Data Movers in the cabinet. It cannot be used to sign certificates for any external hosts. "Using the Control Station as the CA" on page 47 describes the tasks for using a Control Station CA. If you are using an external CA, you must send the certificate request manually. The request to sign the public key is generated with the public/private key set. Display the persona’s properties to verify its content. Obtain a copy of the certificate request and then send the request to the CA through that company’s website or email. When the CA returns a signed certificate, you must import it to the Data Mover. To import the signed certificate, you can either provide a path and import a file, or cut and paste the associated text. A file can be in either Distinguished Encoding Rules (DER) or PEM format. You can cut and paste text only in PEM format. Each persona can be associated with up to two sets of keys and certificates (current and next), to allow generating new keys and certificates before the expiration of the current certificate. When the next certificate (which is already valid) is imported, it and its associated key set immediately become the current key set and certificate.Because the next certificate is typically generated when it is needed, you typically do not see a next certificate associated with a persona. However, a next certificate may be waiting if there is a time difference between the Data Mover and the CA (or the Control Station if it is serving as the CA). For example, a CA might prepare a certificate in advance by assigning it a future start date. Merging companies could set up such a certificate to have it in place for the official merge date.The next certificate becomes the current certificate (and the current key and certificate are deleted) when the certificate becomes valid (per Data Mover time), and one of the following happens: ◆ The persona is queried (by either the CLI or Unisphere).

◆ The persona's key and certificate are requested by a Data Mover function (such as SSL).

After a certificate expires, any attempt to use the certificate results in a failure, typically a loss of connection or a failure to reconnect. When a new certificate is available, PKI deletes the old certificate and provides the new certificate when requested. However, if you did not obtain a new certificate before the current certificate expires, the certificate request will fail. PKI will not provide an expired certificate for a persona.


There is no automated way to check for expired public key certificates. You must check for expired certificates manually by listing the personas and examining the expiration dates of the associated certificates. You can then take action based on your organization’s business practices."Creating the certificate provided by the persona" on page 47 outlines the procedure for creating the key set and certificate that are provided by the persona to the Data Movers when the Celerra is configured as a server or client.

Certificate Authority (CA) certificatesWhen a Celerra-based client application requires a network connection with a server (such as FileMover’s connection with its secondary storage), the server provides a certificate as part of the negotiation for a secure connection. Celerra confirms the server’s identity by validating the certificate. It does this by verifying the server certificate’s signature with the public key from the CA certificate. Obtaining the required CA certificates is a manual task. Typically, before actual operation, you must identify the appropriate CA. Then you must check the list of CA certificates that are available on the Celerra. If a new CA certificate is required and an external CA is being used, you can obtain the CA certificate from the company’s website or from the person responsible for security. If the CA is local (enterprise-level or inhouse), obtain the CA certificate from the person who manages the CA. To make the CA certificate known to the Celerra, you must import it. You can provide a path and import a file, or cut and paste the text. A file can be in either DER or PEM format. You can cut and paste text only in PEM format. "Obtaining CA certificates" on page 47 outlines the procedure for obtaining the certificate that is used to confirm the identity of a server.

Using the Control Station as the CAThe Celerra software automatically generates a key set and certificate for the Control Station when the system is installed or upgraded. The Control Station uses this key set and certificate to sign certificate requests from Data Movers. However, before the Control Station can successfully operate as a CA and be recognized by a Data Mover as such, you must complete several configuration tasks:◆ Distribute the Control Station CA certificate to network clients. In order for a

network client to validate a certificate sent by a Data Mover that has been signed by the Control Station, the client needs the public key from the CA certificate to verify the Data Mover certificate’s signature.

◆ Import the CA certificate (with the CA certificates from external CAs).

A copy of the Control Station certificate can be obtained only by using the CLI command nas_ca_certificate, as described in "Using the Control Station as the CA" on page 47.If the Control Station key set and certificate are compromised, you can regenerate them. This task can be accomplished only through the CLI command nas_ca_certificate. After regenerating the Control Station key set and certificate, you have to regenerate a new key set and certificate request, and then import the signed certificate for any personas whose certificates are signed by the Control Station.


Note: The Control Station continues to generate a separate key set for the SSL-based connection between Celerra’s Apache web server (on behalf of Unisphere) and a user’s web browser. However, the Control Station now uses the CA key set to sign the Apache web server’s certificate, meaning the certificate is no longer self-signed. Installing Celerra Management Applications describes how to manage certificates for Unisphere.


Configuring the use of an external LDAP-based directory server for user identification and authenticationThe use of an external LDAP-based directory server provides a centralized repository of user accounts, simplifying management. "Planning considerations for using an external LDAP-based directory server for user identification and authentication" on page 22 provides a general description. Prior to user login, you must perform a number of preliminary configuration tasks.

Step Action

1. Determine what LDAP-based directory server the Celerra will communicate with.

Note: Typically, the enterprise in which the Celerra is being used already uses an LDAP-based directory server to store user credentials. In this case, consult with the Active Directory or other LDAP-based directory server administrator to obtain connection information. Otherwise, you will need to study the available Active Directory or other LDAP-based directory server and discover the necessary connection information. There are several tools available to manage LDAP-based directory services. "Appendix C: Understanding your LDAP-based directory server configuration" on page 83 provides information on these tools.

2. Obtain the following information:a. The base distinguished name of the root of the LDAP directory tree, that is, where in the

LDAP directory tree Celerra would begin a search for information. The base DN can be expressed as a fully qualified domain name or in X.509 format using the attribute dc=. For example, if the fully qualified domain name is mycompany.com, the base DN is expressed as dc=mycompany,dc=com.

b. LDAP-based directory server’s IP address or hostname.c. IP address or hostname of a backup LDAP-based directory server.


3. Request that the directory server administrator add an user or account name identifying the Celerra in the LDAP-based server’s directory structure. Or, if you have permission to create user and group accounts on the Active Directory or another LDAP-based directory server, add this user or account name yourself. This account should be a restricted user account (such as a Domain Guest account) with read/search privileges for the directory.

Note: There are several tools available to manage LDAP-based directory services. "Appendix C: Understanding your LDAP-based directory server configuration" on page 83 provides information on these tools.

This entry identifies the Celerra as the user or account that will bind to the directory service, that is, the user or account permitted to search the LDAP directory within the defined search base. This entry is also known as the bind distinguished name. For example, when using an Active Directory, the bind distinguished name might be defined as cn=,cn=users,dc=,dc= and, when using an OpenLDAP directory server, uid=,dc=users,dc=,dc= or cn=,uid=,ou=people,dc=,dc=.

4. Verify that the administrative users (and their associated groups) that will be logging in to the Control Station are defined in the LDAP-based directory server and determine the paths Celerra will search for an instance of the name attribute whose value is the user or group name. If the user and group accounts do not already exist, request that the directory server administrator add them. Or, if you have permission to create user and group accounts on the Active Directory or another LDAP-based directory server, add these accounts yourself.

Note: There are several tools available to manage LDAP-based directory services. "Appendix C: Understanding your LDAP-based directory server configuration" on page 83 provides information on these tools.

For example, if users and groups are stored in an organizational unit with the common name users, the search path will be cn=users,dc=,dc=.

5. If the LDAP connection uses SSL, obtain the public certificate from the CA that signs the LDAP-based directory server's SSL server certificate. Celerra uses this CA certificate to verify the certificate received from the LDAP server. The certificate must be in a Base64 encoded format.If the LDAP-based directory server uses an external CA, obtain the CA certificate from the CA company’s website. If the LDAP-based directory server uses an inhouse CA or if certificates are self-signed, obtain the CA certificate from the LDAP-based directory server administrator. If you are not enabling SSL, a CA certificate is not required.

Step Action


6. With the information you have discovered, log in to Unisphere and use Settings > User Management (User Management tasks) > Manage LDAP Domain to configure the Control Station so it can access the LDAP-based directory server.

Note: If you select the Enable automatic domain user mapping field on the Manage LDAP Domain dialog box, Celerra automatically creates a local user account mapped to the domain user. Alternatively, you can create a user mapped to a domain user and associate it with a domain-mapped group.

Unisphere online help provides a description of these tasks.

Step Action


Configuring password policyThis feature enables the Celerra root administrator to define password complexity requirements for all local users. "Planning considerations for password security" on page 29 provides a general description.

Note: This feature does not apply to domain-mapped users, whose passwords are governed by the policies within the domain.

Note: You must be root to execute the /nas/sbin/nas_config command.

Define password policy interactively

Action

To initiate a script that prompts for password policy definitions, use this command syntax: # /nas/sbin/nas_config -password

Output

Minimum length for a new password (Between 6 and 15): [8] Number of attempts to allow before failing: [3] Number of new characters (not in the old password): [3] Number of digits that must be in the new password: [1] Number of special characters that must be in a new password: [0] Number of lower case characters that must be in password: [0] Number of upper case characters that must be in password: [0]

Notes

The current value defined for each field is displayed in brackets. The original default values for each field are:• Length: minimum 8 characters, range 6-15• Attempts: maximum of 3 attempts• New characters: minimum of 3 characters• Digits: minimum of 1 digit• Special, lowercase, and uppercase characters: 0 To change the value for each field, type a new value when prompted.


Define specific password policy definitions

Set password expiration periodThe /etc/login.defs file contains the parameter used to set password expiration.

Action

To set specific password policy definitions, use this command syntax: # /nas/sbin/nas_config -password [-min ] [-retries ] [-newchars ] [-digits ] [-spechars ] [-lcase ] [-ucase ]

where = minimum length of the new password. The default length is 8 characters. The length has to be a value between 6 and 15 characters. = number of attempts a user can make to define an acceptable new password before the command fails. The default value is 3 attempts. = minimum number of characters that must be in the new password that were not included in the old password. The default value is 3 characters. = minimum number of digits that must be included in the new password. The default value is 1 digit. = minimum number of special characters (such as !, @, #, $, %, &, ^, and *) that must be included in the new password. The default value is 0. = minimum number of lowercase characters that must be included in the new password. The default value is 0. = minimum number of uppercase characters that must be included in the new password. The default value is 0.Example:To set the minimum length of a new password to 10 characters, type:# /nas/sbin/nas_config -password -min 10

Output

#

Step Action

1. Log in to the CLI with your username and password. You must have root privileges to access the /etc/login.def file.

2. Change the value of the pass_max_days parameter in the /etc/login.def file by using vi or another text editor.

Note: The default expiration period is 120 days.


Configuring session timeoutCelerra enforces a session timeout for both Unisphere sessions and Control Station shell sessions: ◆ To manage Unisphere session timeout, select Settings (UI Sessions tasks) >

Manage Idle Timeout. You can find more detailed information in Unisphere online help.

◆ You can change the default value of the Control Station session timeout by using the command /nas/sbin/nas_config -sessiontimeout.

Note: You must be root to execute the /nas/sbin/nas_config command.

PrerequisitesThe Control Station supports three shells:◆ bash

◆ ksh

◆ tcsh

Each shell supports a session timeout feature. The Control Station session timeout option sets the session timeout value across the system, automatically updating the appropriate values in /etc/environment for the bash and ksh shells, and the autologout variable in /etc/csh.cshrc for the tcsh shell. After the value is set, newly created shells are affected (but not any currently running shells).

Note: You can change the session timeout value for individual users by setting the relevant variable in the user’s shell configuration file (for example, ~/.bashrc). Values are not restricted if you edit the configuration file directly.

Change the session timeout valueThe default session timeout value for Control Station shell sessions is 60 minutes. Inactivity or idle time is defined as the time since a primary shell prompt was displayed and no input has been received. Therefore waiting at a prompt within a command for some indeterminate amount of time is not affected by the session timeout value.


Disable session timeout

Action

To change the session timeout value, use this command syntax:# /nas/sbin/nas_config -sessiontimeout

where: = number of minutes for session timeout (in the range 5 through 240)Example:To change the session timeout value to 200 minutes, type:# /nas/sbin/nas_config -sessiontimeout 200

Output

#

Action

To disable session timeout, use this command syntax: # /nas/sbin/nas_config -sessiontimeout 0

or# /nas/sbin/nas_config -sessiontimeout off

Output

#


Customizing a login bannerThe /etc/issue file contains a login banner message or system identification, which appears before the login prompt. A login banner can be used for any informational purpose, but is most often used to warn users about unauthorized or improper use of the system.

Note: You can also customize the login banner by using System (System tasks) > Control Station Properties. You must have root privileges to access the Login Banner field.

Step Action

1. Log in to the CLI with your username and password. You must have root privileges to access the /etc/issue file.

2. Edit the /etc/issue file by using vi or another text editor. EMC suggests you add an extra carriage return at the end of the banner message.Use spaces, tabs, and carriage returns to format the message. In general, you should limit the size of the message to no more than a single screen.

Note: Because the login banner appears with the login prompt, do not include any sensitive information in the banner message.

3. Log in to the CLI or Unisphere to view the login banner and verify your changes.


Creating a message of the day (MOTD) The message of the day file, /etc/motd, is displayed after a user successfully logs in. It can be used for any informational purpose, but it is particularly useful for sending messages that affect all users. The message might contain information about a server upgrade or an alert about an impending system shutdown. By default, this file is empty.

Step Action

1. Log in to the CLI with your username and password. You must have root privileges to access the /etc/motd file.

2. Edit the /etc/motd file by using vi or another text editor. EMC suggests you add an extra carriage return at the end of the banner message.Use spaces, tabs, and carriage returns to format the message. In general, you should limit the size of the message to no more than a single screen.

3. Log in to the CLI to display the MOTD and verify your changes.


Protecting session tokensThe connection between a user and Unisphere and between two Celerra systems uses SHA1 to generate checksums to protect the session tokens (cookies) that identify users after they log in. The SHA1 secret value used to generate the checksums is set at random during installation. However, to enhance security, you can change the default SHA1 secret value.

Step Action

1. Log in to the CLI with your username and password. You must have root privileges to access the /nas/http/conf/secret.txt file.

2. Edit the /nas/http/conf/secret.txt file by using vi or another text editor. Replace the default phrase with a new value and save the file.When you change this value, existing session tokens are no longer valid and current users of Unisphere will have to log in again.


Configuring network encryption and authentication using the SSL protocolSecure Socket Layer (SSL) is a session level protocol used to encrypt network transmissions on the Internet. It encrypts data and provides message and server authentication. It also supports client authentication if required by the server. SSL is independent of higher level protocols so it can encapsulate any of the application level protocols such as HTTP and LDAP: ◆ Hypertext Transfer Protocol (HTTP) is a fast, stateless, and object-oriented

protocol used on the web. It enables web clients and servers to negotiate and interact. Unfortunately it has minimal security features. HTTPS (Secure) is a variant of HTTP used by a server that is SSL-enabled.

◆ Lightweight Directory Access Protocol (LDAP) is an industry-standard access protocol that runs directly over TCP/IP. It is the primary access protocol for Active Directory and other directory servers such as the Sun Java System Directory Server (iPlanet) and OpenLDAP.

Celerra supports SSL for Data Mover HTTP and LDAP connections.

Using HTTPSYou enable SSL on Data Mover HTTP connections through the server_http command. Currently, Celerra’s FileMover feature uses HTTPS and SSL’s encryption and authentication features. Using Celerra FileMover describes how to configure SSL with HTTP for use by FileMover. The keys and certificates used with SSL are managed by using PKI. PKI is available through the CLI and Unisphere. "Planning considerations for Public Key Infrastructure" on page 30 provides an overview of the PKI feature. "Configuring PKI" on page 47 and "Managing PKI" on page 61 describe how to configure and manage PKI through the CLI.

Using SSL with LDAPYou enable SSL on Data Mover LDAP connections through the server_ldap command. Currently, Celerra’s naming service support for OpenLDAP, iPlanet, and Active Directory uses LDAP and SSL’s encryption and authentication features. Configuring Celerra Naming Services describes how to configure SSL with LDAP for use by the OpenLDAP and iPlanet LDAP-based directory servers. The keys and certificates used with SSL are managed through PKI. PKI is available through the CLI and Unisphere. "Planning considerations for Public Key Infrastructure" on page 30 provides an overview of the PKI feature. "Configuring PKI" on page 47 and "Managing PKI" on page 61 describe how to configure and manage PKI through the CLI.

Change the default SSL protocolCelerra supports the following SSL protocol versions:◆ SSLv3

◆ TLSv1


Change the default SSL cipher suiteA cipher suite defines a set of technologies to secure your SSL communications: ◆ Key exchange algorithm (how the secret key used to encrypt the data is

communicated from the client to the server). Examples: RSA key or Diffie-Hellman (DH)

◆ Authentication method (how hosts can authenticate the identity of remote hosts). Examples: RSA certificate, DSS certificate, or no authentication

◆ Encryption cipher (how to encrypt data). Examples: AES (256 or 128 bits), RC4 (128 bits or 56 bits), 3DES (168 bits), DES (56 or 40 bits), or null encryption

◆ Hash algorithm (ensuring data by providing a way to determine if data has been modified). Examples: SHA-1 or MD5

The supported cipher suites combine all these items. "Appendix B: Supported SSL cipher suites" on page 81 lists the SSL cipher suites supported by Celerra.

Action

To change the default SSL protocol, use this command syntax:$ server_param -facility ssl -modify protocol -value

where: = name of the Data Mover = 0 (both SSLv3 and TLSv1), 1 (only SSLv3), or 2 (only TLSv1)

Note: The default value is 0.

Parameter and facility names are case-sensitive.Examples:To change the default SSL protocol to SSLv3 only, type:$ server_param server_2 -facility ssl -modify protocol -value 1

To change the default SSL protocol to TLSv1 only, type:$ server_param server_2 -facility ssl -modify protocol -value 2

Output

server_2 : done


PostrequisitesAfter changing SSL parameter values, you must reboot the Data Mover for a SSL protocol and cipher suite change to take effect.

Action

To change the default SSL cipher suite, use this command syntax:$ server_param -facility ssl -modify cipher -value

where: = name of the Data Mover. = string that specifies the new cipher value. If the value includes any special characters (such as a semi-colon, space character, or exclamation), it must be enclosed in quotation marks.

Note: The default cipher suite value is ALL:!ADH:!SSLv2:@STRENGTH, which means that Celerra supports all ciphers except the SSLv2, Anonymous Diffie-Hellman, and NULL ciphers, sorted by their “strength”, that is, the size of the encryption key.

Parameter and facility names are case-sensitive.Example:To change the default SSL cipher suite to a strong cipher (mainly AES128 and AES256) to be used by each new SSL connection, type:$ server_param server_2 -facility ssl -modify cipher -value ‘HIGH:@STRENGTH’

Output

server_2 : done


Configuring PKI"Planning considerations for Public Key Infrastructure" on page 30 provides a general description of this feature.

Creating the certificate provided by the personaThe procedure for creating the certificate provided by the persona to the Data Mover varies slightly depending on whether the Certificate Authority (CA) that signs the certificate is an external CA or the Celerra’s Control Station: 1. "Generate a key set and certificate request" on page 48

2. "Send the certificate request to the CA" on page 51 (not required if using the Control Station)

3. "Import a CA-signed certificate" on page 52 (not required if using the Control Station)

Obtaining CA certificates The procedure for obtaining the CA certificates used to confirm the identity of a server includ

EMC Celerra Network Server · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103...

Documents

Transcript of EMC Celerra Network Server · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103...