How To Manage A Network On A Linux Computer (Vnx) On A Windows 7 Computer (Windows) On An Ipod Or Ipod (Windows 7) On Your Ipod Computer (For Windows) On The Network (For Linux)

Transcription

1 EMC VNX Series Configuring VNX Naming Services P/N REV A01 EMC Corporation Corporate Headquarters: Hopkinton, MA

2 2 of 80

3 Contents Introduction System requirements Restrictions User interface choices Terminology Related information Concepts Local files NIS DNS LDAP-based directory services Active Directory WINS nsswitch.conf file Protocol user authentication Configuring local files Prerequisites Configure local files on a Data Mover Configuring NIS Prerequisites Configure a Data Mover as an NIS client Configuring DNS Prerequisites Configure a Data Mover as a DNS client Configuring a Data Mover as an LDAP-based directory service client.25 Prerequisites Configure an LDAP-based directory client by using a domain name Configure an LDAP-based directory client by using a base distinguished name Configuring additional LDAP-based directory options Specify the use of simple (password) authentication Specify the use of Kerberos authentication Enable SSL for LDAP-based directories Specify the SSL persona Specify the SSL cipher suite Specify an iplanet client configuration profile Copy the ldap.conf file Specify an NIS domain Configuring the nsswitch.conf file Prerequisites Edit the nsswitch.conf file Managing local files Managing NIS Display the NIS configuration Verify the status of the NIS configuration Delete the NIS configuration Managing DNS Verify the DNS configuration of 80

4 Delete the DNS configuration Set or change the DNS server protocol Clear the DNS cache Disable access to the DNS server Enable access to the DNS server Managing an LDAP-based directory Verify the status of the LDAP-based directory service Delete the LDAP-based directory configuration Display information about the LDAP-based directory configuration Temporarily disable the LDAP-based directory service Enable the LDAP-based directory service Disable SSL for LDAP-based directories Looking up information in the LDAP-based directory server Troubleshooting Where to get help E-Lab Interoperability Navigator Check network connectivity by using server_ping Access naming services from the Control Station Check communication with DNS Check LDAP-based directory operation Verify the download of the iplanet client profile Edit OpenLDAP schema for Linux Using group membership with distinguished name syntax CIFS user mapping in a multiprotocol environment Error messages LDAP error messages Training and Professional Services Appendix A: iplanet client profile attributes Appendix B: OpenLDAP configuration file Appendix C: IdMU configuration file template Appendix D: SFU 3.5 configuration file template Appendix E: Examples of configuring a Data Mover as an LDAP-based directory service client Connecting to iplanet using anonymous authentication Connecting to OpenLDAP using simple password authentication 71 Connecting to Active Directory with SFU using simple password authentication Connecting to Active Directory with IdMU using Kerberos authentication Connecting to Active Directory with IdMU using SSL authentication Index of 80

5 Introduction This document provides information about naming services, which provide a Data Mover with a mechanism for looking up user and system information, including usernames, passwords, home directories, groups, hostnames, IP addresses, and netgroup definitions. Configuring each Data Mover with access to one or more naming services is a basic task that you must perform to ensure correct operation of EMC VNX. The Control Station is configured to use naming services, specifically DNS, during system initialization. Configuring and Managing VNX Networking and the Unisphere Control Stations online help topic provide more information. User mapping, the mapping of the security identifiers (SIDs) used by Windows users to the UNIX-style user identifiers (UIDs) and group identifiers (GIDs) used by VNX, can be provided by several of the naming services described in this document, specifically local files, NIS, LDAP-based directory servers including Active Directory with SFU/IdMU, and Active Directory using VNX CIFS Microsoft Management Console snap-ins. Configuring VNX User Mapping describes how VNX uses these methods to map users. This document is part of the VNX documentation set and is intended for the system administrators responsible for configuring and maintaining file storage and network retrieval infrastructure. System requirements Table 1 on page 5 describes the VNX software, hardware, network, and storage configurations. Table 1 Naming services system requirements Software VNX version 7.0. Hardware Network Storage No specific hardware requirements. To use NIS, DNS, LDAP-based directories, or WINS with VNX, there must be at least one NIS, DNS, LDAP-based directory, or WINS server, respectively, on the network accessible to the file server. No specific storage requirements. 5 of 80

6 Restrictions These restrictions apply: NIS+, which uses a different protocol than standard NIS, is not supported on the VNX. LDAP over SSL does not support start_tls mode, which starts a TLS connection on an existing non-ssl LDAP connection (for example, over port 389). User interface choices VNX offers flexibility in managing networked storage based on your support environment and interface preferences. This document describes how to configure naming services by using the command line interface (CLI). You can also perform many of these tasks by using one of the VNX management applications: EMC Unisphere software Microsoft Management Console (MMC) snap-ins Active Directory Users and Computers (ADUC) extensions The Unisphere online help contains additional information about managing your VNX. The VNX Release Notes contain additional, late-breaking information about VNX management applications. Using Unisphere to configure naming services Unisphere can be used to configure a Data Mover to use the naming services listed in Table 2 on page 6. Table 2 Naming services configured using Unisphere Naming service NIS DNS Unisphere procedure To configure the Data Mover as an NIS client, select System > Network (Network tasks) > Manage NIS Settings. To configure the Data Mover as a DNS client, select System > Network > DNS or select Sharing > CIFS > DNS. Note: You cannot use Unisphere to change the DNS server protocol or clear the DNS cache. WINS To configure the Data Mover as a WINS client, select Sharing > CIFS (CIFS tasks) > Configure CIFS. You cannot use Unisphere to manage local files, including the nsswitch.conf file, or configure a Data Mover as an LDAP-based directory client. Unisphere online help provides more information about configuring naming services. 6 of 80

7 Note: You can also use the Unisphere configuration wizards to set up the use of NIS, DNS, and WINS. Terminology The VNX Glossary provides a complete list of VNX terminology. Active Directory: Advanced directory service included with Windows operating systems. It stores information about objects on a network and makes this information available to users and network administrators through a protocol such as LDAP. Certificate Authority (CA): Trusted third party that creates and digitally signs public key certificates. Certificate Authority Certificate: 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. Common Internet File System (CIFS): File-sharing protocol based on the Microsoft Server Message Block (SMB). It allows users to share file systems over the Internet and intranets. directory server: 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. domain: Logical grouping of Microsoft Windows servers and other computers that share common security and user account information. All resources such as computers and users are domain members and have an account in the domain that uniquely identifies them. The domain administrator creates one user account for each user in the domain, and the users log in to the domain once. Users do not log in to each individual server. Domain Name System (DNS): Name resolution software that allows users to locate computers on a UNIX network or TCP/IP network by domain name. The DNS server maintains a database of domain names, hostnames and their corresponding IP addresses, and services provided by these hosts. File Transfer Protocol (FTP): High-level protocol for transferring files from one machine to another. Implemented as an application-level program (based on the OSI model), FTP uses Telnet and TCP protocols. Identity Management for UNIX (IdMU): Microsoft software that provides a UNIX environment on Windows, specifically UNIX identity and security services. Kerberos: 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. Kerberos Key Distribution Center (KDC): Stores and retrieves information about security principles in the Active Directory database. Each domain controller in Windows 2000 or later is a Kerberos KDC that acts as a trusted intermediary between a client and a server. 7 of 80

8 LDAP-based directory: Directory servers that support LDAP, including Active Directory with IdMU or SFU, OpenLDAP, or iplanet (also known as Sun Java System Directory Server and Sun ONE Directory Server). Lightweight Directory Access Protocol (LDAP): 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 Microsoft Windows Services for UNIX (SFU): Microsoft software that provides a UNIX environment on Windows. netgroup: Group of computers on a network administered using a single name. Netgroups can be defined using a local text file that provides the list of hosts in a netgroup or using NIS or an LDAP-based directory server. Network File System (NFS): Distributed file system that provides transparent access to remote file systems. NFS allows all network systems to share a single copy of a directory. Network Information Service (NIS): Distributed data lookup service that shares user and system information across a network, including usernames, passwords, home directories, groups, hostnames, IP addresses, and netgroup definitions. OpenLDAP: Open source implementation of an LDAP-based directory service. persona: 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): Means of managing private keys and associated public key certificates for use in Public Key Cryptography. It is a framework which allows the creation of a certificate which is used by SSL. Secure Sockets Layer (SSL): 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. SFU, see Microsoft Windows Services for UNIX. Sun Java System Directory Server: (Also known as Sun ONE Directory Server and iplanet.) A distributed directory service accessible using LDAP. Transport Layer Security (TLS): Successor protocol to SSL for general communication authentication and encryption over TCP/IP networks. TLS version 1 is nearly identical with SSL version 3. Windows domain: Microsoft Windows domain controlled and managed by a Microsoft Windows Server using the Active Directory to manage all system resources and using the DNS for name resolution. Windows Internet Naming Service (WINS): Microsoft name resolution system that determines the IP address associated with a particular network node. WINS provides the mapping between the machine name and the Internet address, allowing Microsoft networking to function over TCP/IP networks. 8 of 80

9 Windows NT domain: Microsoft Windows domain controlled and managed by a Microsoft Windows NT server using a SAM database to manage user and group accounts and a NetBIOS namespace. In a Windows NT domain, there is one primary domain controller (PDC) with a read/write copy of the SAM, and possibly several backup domain controllers (BDCs) with read-only copies of the SAM. Related information Specific information related to the features and functionality described in this document is included in: VNX Command Reference Manual Online VNX for file man pages VNX Parameters Guide VNX Glossary Configuring and Managing VNX Networking Configuring VNX User Mapping VNX Security Configuration Guide Managing VNXfor a Multiprotocol Environment Configuring and Managing CIFS on VNX RFCs: RFC 2307, An Approach for Using LDAP as a Network Information Service RFC draft (Joslin), A Configuration Profile Schema for LDAP-based Agents EMC VNX documentation on the EMC Online Support website The complete set of EMC VNX series customer publications is available on the EMC Online Support website. To search for technical documentation, go to After logging in to the website, click the VNX Support by product page to locate information for the specific feature required. VNX for File wizards Unisphere software provides wizards for performing setup and configuration tasks. The Unisphere online help provides more details on the wizards. 9 of 80

10 Concepts Each Data Mover on a VNX for File system needs a mechanism for looking up user and system information, including usernames, passwords, home directories, groups, hostnames, IP addresses, and netgroup definitions. The Data Mover obtains this information by making queries to naming services. Naming services are used by several of the protocols supported by VNX for File. You can configure one or more of the following naming services for each Data Mover in your system: Local files (passwd, group, hosts, and netgroup) Network Information Service (NIS) Domain Name System (DNS) Active Directory with Microsoft Windows Services for UNIX (SFU) or Identity Management for UNIX (IdMU) OpenLDAP Sun Java System Directory Server (iplanet) Note: The Sun Java System Directory Server was formerly known as Sun ONE Directory Server and iplanet. Because this product continues to be known as iplanet by many users, the name iplanet is used in this discussion. Active Directory (using VNX CIFS Microsoft Management Console [MMC] snapins) Windows Internet Naming Service (WINS) When naming services are required, the Data Mover first checks its local cache. It then queries all the configured naming services in a predetermined order until the requested entity is found or until all naming services are queried. The search order is determined by the name service switch (nsswitch), which is configured by using the nsswitch.conf file. Local files Local files are text files that reside on a Data Mover. Depending on the type of information these files contain, they are identified as passwd, group, hosts, or netgroup files: The passwd file contains the users who can access the Data Mover. The group file defines the groups to which users belong. The hosts file contains a list of IP addresses with their corresponding hostnames. Note: When deploying CIFS in a Windows environment, DNS is required. 10 of 80

11 The netgroup file contains a list of network group names with the list of hostnames for hosts belonging to the group. In addition to mapping hosts to network groups, it also maps users to network groups. Local files are the most efficient way of looking up entities because they do not require getting information from another server on the network. However, when you use local files, you must manually update entity information on each Data Mover as the entities on your network change. Local files are not provided on a Data Mover by default. To use local files, you must create and copy these files to the Data Mover. To update the information in an existing file, you must retrieve the file from the Data Mover, modify it, and then copy it back to the Data Mover. These tasks can only be accomplished by using the CLI. "Configuring local files" on page 20 describes how to configure a Data Mover to use local files for naming services. NIS NIS is a distributed data lookup service that shares user and system information across a network, including usernames, passwords, home directories, groups, hostnames, IP addresses, and netgroup definitions. Unlike local files that must be maintained on each Data Mover individually, NIS allows you to organize information in a domain structure stored in a central repository and maintained on dedicated NIS servers. When configured, NIS domain information is available on the network. To configure a Data Mover as a client of an NIS server, you must know the NIS domain name and the IP addresses for the NIS servers. If possible, configure multiple NIS servers; the Data Mover tries the alternate servers if the first one is unavailable. You can configure up to 10 NIS servers in a single NIS domain on a Data Mover. Note: If you are accessing NIS servers that support both IPv4 and IPv6, you should configure at least one interface for each address type on each Data Mover in that domain. Note: A Data Mover supports only one NIS domain. Each time you configure an NIS domain and specify the servers, it overwrites the previous configuration. "Configuring NIS" on page 23 describes how to configure a Data Mover to use NIS for naming services. DNS DNS is a name resolution system that allows users to locate computers and services on a UNIX or TCP/IP network by name. The DNS server maintains a database of domain names, hostnames and their corresponding IP addresses, and services provided by these hosts. To configure a Data Mover as a client of a DNS server, you must know the DNS domain name and the IP addresses for the DNS servers. If possible, configure multiple DNS servers; the Data Mover tries the alternate servers if the first one is unavailable. You can configure up to three DNS servers in a single DNS domain on 11 of 80

12 a Data Mover. Furthermore, you can configure multiple DNS domains for the same Data Mover, each with its own set of DNS servers. Note: DNS is required for Windows 2000 and later domains. The DNS server should support dynamic updates (DDNS). If DDNS is unsupported, you must manually update the DNS server. Also, if you are accessing DNS servers that support both IPv4 and IPv6, you should configure at least one interface for each address type on all CIFS servers on each Data Mover in that domain. Configuring and Managing CIFS on VNX provides more information on DNS and Windows domains. "Configuring DNS" on page 24 describes how to configure a Data Mover to use DNS for naming services. LDAP-based directory services VNX for File supports three LDAP-based directory services: Active Directory with Microsoft Windows Services for UNIX (SFU) or Identity Management for UNIX (IdMU) OpenLDAP iplanet Active Directory with SFU or IdMU, OpenLDAP, and iplanet (also known as Sun Java System Directory Server and Sun ONE Directory Server), hereafter collectively referred to as LDAP-based directories, are distributed directory servers that provide a central repository for storing and managing identity profiles, access privileges, and application and network resource information. In a VNX environment, LDAP-based directories may be used to provide user account information, group information, hosts, and netgroups. While LDAP-based directories provide a repository for the same information as that stored by NIS, unlike NIS where you have to edit database tables and explicitly propagate updated information, LDAP-based directories provide centralized management in real time. To configure a Data Mover as a client of an LDAP-based directory server, you must know the LDAP-based directory domain name or base distinguished name and the IP addresses for the configuration or service servers. If possible, configure multiple LDAP-based directory servers; the Data Mover tries the additional servers if the first one is unavailable. A Data Mover supports only one LDAP-based directory domain. Note: EMC recommends continuing to use DNS to get information about hostnames and their IP addresses. "Configuring a Data Mover as an LDAP-based directory service client" on page 25 describes how to configure a Data Mover to use an LDAP-based directory server for naming services. If you are using OpenLDAP and plan to export NFS file systems, "Edit OpenLDAP schema for Linux" on page 59 provides additional information. LDAP-based directory structure An LDAP-based directory server organizes information in a hierarchical directory structure unique to a particular organization s needs. Each object stored in the 12 of 80

13 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=mycompany,dc=com ou=people ou=group ou=hosts ou=netgroup 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. The containers that make up the LDAP-based directory structure use the following object types: iplanet/openldap Containers iplanet/openldap Object Class IdMU Containers IdMU Object Class ou=people posixaccount cn=users User ou=group posixgroup cn=group Group ou=hosts iphost cn=computers Computer ou=netgroup nisnetgroup cn=netgroup nisnetgroup Directory server differences The primary difference between LDAP-based directory servers is how the directory services are configured. You configure and manage them by using the server_ldap command: iplanet makes use of an optional, downloadable client configuration profile containing additional configuration attributes beyond those supplied during the basic configuration. "Appendix A: iplanet client profile attributes" on page 64 provides a description of the LDAP configuration attributes. 13 of 80

14 When provided, this attribute supersedes server_ldap configuration settings, when connecting to the iplanet service. Specifying a valid client configuration profile immediately impacts the iplanet service; that is, the client configuration profile is retrieved and read. Active Directory with SFU or IdMU and OpenLDAP use a file-based configuration located in the Data Mover s /.etc directory: For OpenLDAP, you can copy the ASCII configuration file, ldap.conf, from any available UNIX/Linux client. The Data Mover ignores the keywords that it does not support. This is the quickest way to set up file-based configuration. The PADL Software website provides additional information. "Appendix B: OpenLDAP configuration file" on page 67 provides an example of the relevant LDAP configuration attributes. For Active Directory with SFU or IdMU, VNX for File provides two different configuration file templates, ldap.conf.idmu_template_v1 and ldap.conf.sfu35_template_v1. These templates provide the relevant LDAP configuration attributes for each schema (the SFU 3.5 LDAP schema requires more remapping directives than the IdMU LDAP schema). Rename the selected template file to ldap.conf. "Appendix C: IdMU configuration file template" on page 68 and "Appendix D: SFU 3.5 configuration file template" on page 69 provide examples of these template files. The IdMU template file provides the correct LDAP settings if the directory server was not configured with a special container for netgroups. Typically, the NIS Data Migration Wizard that is part of the IdMU software creates a default container for netgroups. Netgroups are not supported by the SFU 3.5 schema. If the LDAP-based directory service was previously configured with an ldap.conf file, substituting a different ldap.conf file does not immediately impact the service. If the service is restarted, the ldap.conf file is read and any applicable settings are applied. If the service is not restarted, the configuration is automatically refreshed every 20 minutes, and the ldap.conf file is read at that point. Similarly, if the LDAP-based directory service is configured by using an ldap.conf file, removing the file does not immediately impact the service, unless the service is restarted, or the configuration is refreshed (every 20 minutes). If the LDAP-based directory service was not previously configured with an ldap.conf file, adding an ldap.conf file requires that you clear the previous configuration and reconfigure the Data Mover in order for the new ldap.conf file to be read and applied. ldap.conf file The ldap.conf file contains the following fields: nss_base_passwd nss_base_group nss_base_hosts nss_base_netgroup (OpenLDAP and IdMU only) nss_map_objectclass 14 of 80

15 nss_map_attribute The first four fields define the containers for users, groups, hosts, and netgroups. Containers are identified by their distinguished name. nss_base_passwd ou=users,dc=mycompany,dc=com nss_base_hosts ou=computers,dc=mycompany,dc=com Containers can point to any directory in the tree. It is also possible to define several containers for the same object class. For example, if your organization s users are divided into several groups such as sales, engineering, and manufacturing, you can define three user containers. nss_base_passwd ou=sales,dc=mycompany,dc=com nss_base_passwd ou=engineering,dc=mycompany,dc=com nss_base_passwd ou=manufacturing,dc=mycompany,dc=com The default search scope is one (that is, a single level). EMC recommends using the default value as this type of search optimizes a lookup request. nss_base_passwd ou=sales,dc=mycompany,dc=com?one You can change the search scope using the following syntax: nss_base_xxx base?scope?filter scope is {base,one,sub} VNX for File does not support the filter field A scope value of sub (for example, nss_base_passwd ou=sales,dc=mycompany,dc=com?sub) results in a search of the entire sub tree for posixaccount objects with the requested uid or username. This type of search can be lengthy when tens of thousands of objects have to be scanned. The field nss_map_objectclass <rfc 2307 class> <class used in the ldap tree> tells the Data Mover to query the customer-specific class instead of the default class defined by RFC The following definition is required for IdMU. nss_map_objectclass posixaccount User The field nss_map_attribute <rfc 2307 attribute> <attribute used in the ldap object> tells the Data Mover to query the customer-specific attribute instead of the default attribute defined by RFC nss_map_attribute homedirectory unixhomedirectory Configuration sequence If you specify a client configuration profile when you start an LDAP-based directory service, the Data Mover tries to download the profile. If the profile downloads, iplanet directory services run. If the specified profile does not exist, the configuration fails. If no configuration profile is specified, the Data Mover checks for the /.etc/ldap.conf file. If it exists, it is used to complete the setup. If neither a client configuration profile is specified nor a configuration file exists, the directory service runs by using default parameters. When using SSL, SSL configuration settings specified in the client configuration profile and in the file-based configuration override SSL settings configured with the server_ldap command. 15 of 80

16 Authentication methods The Data Mover s directory client supports several different authentication methods. The options you choose when configuring LDAP determine which authentication method is used: Anonymous Simple (password) Kerberos SSL: Anonymous Simple (password) SSL-based client authentication (if the LDAP-based directory server is configured to require client certificates) Note: Active Directory with SFU or IdMU requires an authentication method that uses a password, Kerberos, or SSL. Anonymous authentication is not allowed. Anonymous authentication Anonymous authentication means no authentication occurs and the Data Mover uses an anonymous login to access the LDAP-based directory server. Note: Anonymous authentication is only available when using OpenLDAP or iplanet. Simple authentication Simple or proxy authentication means the Data Mover must provide a bind distinguished name and password to access the LDAP-based directory server. The bind DN is the distinguished name of the identity used to bind to the service. Usually, the identity used to bind to the service is the domain manager. Typically, Active Directory assumes a bind distinguished name format of cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>. However, the Active Directory administrator can create users in other locations within Active Directory, in which case the bind distinguished name path may be different. An OpenLDAP directory server accepts different bind distinguished name formats. Typically, the domain manager is a user located in the default container for users: cn=administrator,ou=people,dc=<domain component>,dc=<domain component>. Kerberos authentication Kerberos authentication means the Data Mover, configured as a CIFS server, uses a KDC to confirm the Data Mover s identity when accessing the Active Directory. After you join a CIFS server to a domain, Kerberos generates a set of encryption and decryption keys that it shares with the domain controller. When the KDC receives an authentication request from a CIFS server, it performs authentication by decrypting the preauthentication data sent by the Data Mover with the decryption keys. If the decryption succeeds and the preauthentication data is accurate, the CIFS server is authenticated. After a CIFS server is authenticated, the KDC 16 of 80

17 generates an initial ticket called the Ticket-granting Ticket (TGT). The TGT is a special ticket that enables the CIFS server to request services to the KDC. Note: If a Data Mover is using Kerberos authentication, the VNX for File administrator must not delete the associated CIFS server while it is being used for LDAP service. SSL authentication SSL authentication means the Data Mover directory client, using the underlying SSL client, verifies 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 Data Mover for the certificate verification to succeed. If SSL-based client authentication is required by the LDAP-based directory server, a private key and a valid certificate must be associated with the specified persona in the Data Mover to authenticate the client. The Data Mover certificate subject must match the distinguished name for an existing user (account) at the directory server for authentication to succeed. (Some directory servers support mapping between the expected client certificate subject and the desired user account.) When negotiating a secure connection with an LDAP-based directory server that requires SSL-based client authentication, the persona provides the private key and certificate to the Data Mover (client). The certificate provides a means for the server to identify and authenticate the client. Because there may be multiple services, each with its own key and certificate, and possibly one or more client connections running on a single Data Mover, the Data Mover application must indicate the persona to use to identify the private key and associated public key certificate. The VNX Security Configuration Guide provides information about SSL and PKI. Authentication configuration rules The following rules determine which authentication method is used: If you do not specify the bind DN option or enable SSL, the anonymous bind is used. If you specify the bind DN and password options, but do not enable SSL, a password-based bind is used. If you specify the bind DN and password options and enable SSL, a passwordbased bind is used, whether or not the sslpersona is configured. If you do not specify the bind DN option and do not configure the sslpersona, but enable SSL, an anonymous bind is used after the SSL connection is established. If you do not specify the bind DN option, but configure the sslpersona and enable SSL, an anonymous bind without SSL is used, unless the LDAP-based directory server is configured to require client certificates. Note: When the sslpersona is configured (whether it is used or not), there must be a key and valid public key certificate associated with the specified persona or the SSL connection attempt fails. You must specify the sslpersona whenever the LDAP-based directory server is configured to require the client certificate, or the SSL connection fails because it is rejected by the LDAP-based directory server. 17 of 80

18 Cipher suites A cipher suite defines a set of technologies to secure your LDAP 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 ensure that the identity of remote hosts is correct). 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 (assuring data cannot be altered by unauthorized parties). Examples: SHA-1 or MD5 The supported cipher suites combine all of these items. The VNX Security Configuration Guide provides a list of cipher suites supported by VNX for File. "Configuring additional LDAP-based directory options" on page 28 provides information on how to configure a Data Mover to use secure LDAP-based directory communications. Active Directory Before the introduction of Microsoft software that provides a UNIX environment on Windows (Active Directory with SFU or IdMU), Active Directory was primarily used in Windows 2000 and Windows Server 2003 environments to provide authentication and authorization for Windows users. However, if the Active Directory schema was extended with an EMC proprietary schema to include UNIX attributes for Windows users and groups, you could configure a Data Mover to query the Active Directory to determine if a user and the group of which the user is a member has UNIX attributes assigned. If so, information stored in these attributes could be used for file access authorization. To configure a Data Mover to query the Active Directory for UNIX attributes, you must install the UNIX user management component of the VNX CIFS management MMC snap-ins. You must also set the cifs useadmap parameter. Installing VNX Management Applications, Configuring VNX User Mapping, and the VNX UNIX User Management and VNX UNIX Attribute Migration online help systems provide more information. Note: EMC recommends that you use Active Directory with SFU or IdMU instead of Active Directory with VNX CIFS MMC snap-ins. "LDAP-based directory services" on page 12 provides more information on using Active Directory with SFU or IdMU. WINS WINS is a Microsoft NetBIOS-based name resolution system that determines the IP address associated with a particular network node. WINS is typically used only in Windows NT environments. Starting with Windows 2000, WINS is superseded by DNS. 18 of 80

19 To configure a Data Mover as a WINS client, you must define one or more WINS servers that all CIFS servers on a Data Mover can access. Configuring and Managing CIFS on VNX provides more information on configuring WINS for CIFS servers in Windows NT environments. nsswitch.conf file The nsswitch.conf file determines which naming services are queried for each entity type and the order in which the naming services are checked. The nsswitch.conf file is a text file that can be edited to arrange the search order that best fits your environment. A template for the file, nsswitch.conf.tmpl, is provided in the Control Station s /nas/sys directory. If you do not provide a nsswitch.conf file, the Data Mover queries naming services for each entity in the following order: For passwd, group, and netgroup entities, the Data Mover queries its local files first, followed by NIS. For hosts entities, the Data Mover queries its local files first, followed by NIS, and then DNS. If an entity is not defined in the nsswitch.conf file, the Data Mover uses the default search. The LDAP-based directory server is only queried if it is added to the nsswitch.conf file as a naming service. For example, to configure the Data Mover to query users from the /.etc/passwd file first, and, if it is not found, to then query the LDAP server, specify passwd: files ldap. If no nsswitch.conf file is provided, the Data Mover uses the default search order that does not include the LDAP-based directory server. "Configuring the nsswitch.conf file" on page 38 provides more information about the nsswitch.conf file. Protocol user authentication Certain protocols, such as FTP, can use LDAP-based directories, NIS, or local files to authenticate user account information for distributed applications. For example, each time you log in to VNX for File's FTP server, FTP binds to the directory server, which then validates the presented credentials and allows you to authenticate with the server you are accessing. VNX for File authenticates the FTP user by reading the hashed password from a directory, hashing the password supplied by the FTP user, and comparing the two. Passwords are hashed using the UNIX CRYPT, MD5, or MD5_CRYPT encryption algorithms. Note: MD5_CRYPT may be required when the directory server is an Active Directory. "Specify the use of simple (password) authentication" on page 28 describes how the LDAP-based directory must be configured if it is used to provide user password authentication for a Data Mover s FTP or PC-NFS services. The FTP man page and FTP on VNX provide information about FTP. 19 of 80

20 Configuring local files To configure the use of local files by a Data Mover, you must either: Create the appropriate text file on the Control Station, and then copy it to the Data Mover or Retrieve the existing file from the Data Mover, modify it, and then copy it back to the Data Mover "Local files" on page 10 provides information about local files. Prerequisites To create a new local file for a Data Mover, you can copy a passwd, group, hosts, or netgroup file from another UNIX or Linux system to use as a template. When creating or editing local files, these rules apply: All entries (Windows names, usernames, domain names, global group names) must be typed in lowercase ASCII only. Any spaces in Windows domain or group names should be replaced with =20 to become legal in a UNIX-style file. Any non-ascii character (such as vowels with French accents) must be replaced by =xx or ==xxyy, where xx and xxyy are the hexadecimal codes in UTF-8 of the character. If using UNIX user authentication, run the server_user command to generate an encrypted password in the password field, but do not include the domain as part of the username. The passwd, group, hosts, and netgroup files are standard UNIX-based files. You can view the standard description of these files and their format by using the man command. Create or edit a passwd file Each line of the passwd file defines a user and has the format: username:password:uid:gid:gcos username is the user's login name. When querying for Windows users, by default, the system checks for CIFS usernames in the form username.domain (domain being the Windows domain name). Setting the cifs resolver parameter to 1 enables the system to retrieve user and group entries without domain extensions. Configuring VNX User Mapping provides more information. password is an empty field. The encrypted password for the user is in the corresponding entry in the shadow file. uid is the user's unique numerical ID for the system. gid is the unique numerical ID of the group to which the user belongs. 20 of 80

21 Note: You can use the server_user <movername> -add command to create a new user account on the Data Mover. This command must be executed from the /nas/sbin directory; you must be root user to execute it. Create or edit a group file The group file defines the groups to which users belong. Each line of the group file defines a group and has the format: groupname:gid:user_list groupname is the name of the group. When querying for Windows groups, by default, the system checks for CIFS group names in the form groupname.domain (domain being the Windows domain name). Setting the cifs resolver parameter to 1 enables the system to retrieve user and group entries without domain extensions. Configuring VNX User Mapping provides more information. gid is the numerical group ID. user_list is all the group member usernames, separated by commas. Create or edit a hosts file Each line of the hosts file defines a host and has the format: IP_address hostname aliases IP_address is the host s IP address. hostname is the official name of the host. aliases provides for name changes, alternate spellings, shorter hostnames, or generic hostnames (for example, localhost). Fields are separated by any number of blanks or tab characters or both. Create or edit a netgroup file Each line of the netgroup file defines a group and has the format: groupname member1 member2... Each member is either the name of another group or indicates specific hosts, users, and domains, referred to as a triple, as follows: (hostname,username,domainname) Any of the triple s three fields can be blank, meaning all the values in that field are included. A dash (-) in any of the fields means there are no valid values. For example, the following line defines a group called ouruniverse that consists of all hosts and users in the NIS domain ourdomain. ouruniverse (,,ourdomain) The following lines define a group called ourhosts that includes all of the hosts but none of the users in the domain, and a group called ourusers that includes all users but no hosts. 21 of 80

22 ourhosts (,-,ourdomain) ourusers (-,,ourdomain) The following line defines a group called ouruniverse that consists of two hosts hostatlanta and hostboston. ouruniverse (hostatlanta,,),(hostboston,,) Note: IP addresses are not allowed. A netgroup file can include as many lines as required; however, each line must be less than 1 KB in length. If necessary, a line can be continued on another line by using the backslash (\) as a continuation character. A triple, however, cannot be split across two lines. Note: If you use a backslash (\) as a continuation character, it must be the last character on the line. It cannot be followed by spaces. Configure local files on a Data Mover Step 1. Copy the local file (passwd, group, hosts, or netgroup) from the Data Mover to the Control Station by using this command syntax: $ server_file <movername> -get <src_file> <dst_file> <movername> = name of the Data Mover <src_file> = source file on the Data Mover <dst_file> = destination file on the Control Station 2. By using a text editor, edit the file on the Control Station to add, delete, or modify entries. 3. Copy the file from the Control Station back to the Data Mover by using this command syntax: $ server_file <movername> -put <src_file> <dst_file> <movername> = name of the Data Mover <src_file> = source file on the Control Station <dst_file> = destination file on the Data Mover 22 of 80

23 Configuring NIS To configure a Data Mover as an NIS client, you must provide the NIS domain name and one or more NIS servers that host the domain. A Data Mover can support only one NIS domain. "NIS" on page 11 provides information about NIS. Prerequisites If possible, define multiple NIS servers; the Data Mover tries the alternate servers if the first one is unavailable. You can configure up to 10 NIS servers for a single NIS domain on a Data Mover. Each time you run the server_nis command to configure an NIS domain and specify the servers, it overwrites the previous configuration. The server_nis command also starts the NIS service on the Data Mover, if NIS is not running. After the NIS service is configured, it is enabled by default; that is, it automatically restarts after a Data Mover reboot. Configure a Data Mover as an NIS client To configure a Data Mover as an NIS client, use this command syntax: $ server_nis <movername> <domainname> {<ip_addr>,...} <movername> = name of the Data Mover <domainname> = name of the NIS domain <ip_addr> = address of an NIS server for the specified domain Example: To configure the use of two NIS servers on server_2 for the NIS domain nsg by using NIS servers found at IP addresses and , type: $ server_nis server_2 nsg , Output server_2 : done 23 of 80

24 Configuring DNS To configure a Data Mover as a DNS client, you must provide a DNS domain name and one or more DNS servers that host the domain. "DNS" on page 11 provides information about DNS. Prerequisites If possible, define multiple DNS servers; the Data Mover tries the alternate servers if the first one is unavailable. You can configure up to three DNS servers for a single DNS domain on a Data Mover. Furthermore, you can configure multiple DNS domains for the same Data Mover, each with its own set of DNS servers. To configure multiple DNS domains for the same Data Mover, rerun the server_dns command for the same Data Mover but indicate a different DNS domain name and IP address. The server_dns command also starts the DNS service on the Data Mover, if DNS is not running. After the DNS service is configured, it is enabled by default; that is, it automatically restarts after a Data Mover reboot. Configure a Data Mover as a DNS client To configure a Data Mover as a DNS client, use this command syntax: $ server_dns <movername> <domainname> {<ip_addr>,...} <movername> = name of the Data Mover <domainname> = name of the DNS domain (cannot exceed 155 characters) <ip_addr> = address of a DNS server for the specified domain Example: To configure server_2 to use the DNS domain nasdocs.emc.com on the DNS server found at IP address , type: $ server_dns server_2 nasdocs.emc.com Output server_2 : done 24 of 80