Dell PowerStore 1000T EMC PowerStore Security Configuration Guide - Page 18
Security on file system objects, File protocol relationships, Building a credential
View all Dell PowerStore 1000T manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 18 highlights
File protocol relationships With Kerberos the following is required: • DNS - You must use DNS name in place of IP addresses. • NTP - PowerStore must have a configured NTP server. NOTE: Kerberos relies on the correct time synchronization between the KDC, servers, and client on the network. • UDS - To build credentials. • Hostname - Kerberos works with names and not IP addresses. NFS secure uses one or two service principal names (SPNs) depending on the value of the hostname. If the hostname is in FQDN format host.domain: • The short SPN: nfs/host@REALM • The long SPN: nfs/host.domainFQDN@REALM If the hostname is not in FQDN format, only the short SPN will be used. Similar to SMB, where an SMB server can be joined to a domain, an NFS server can be joined to a realm (the Kerberos equivalent term for domain). There are two options for this: • Use the configured Windows domain if any • Entirely configure a UNIX KDC based Kerberos realm If the administrator selects to use the configured Windows domain, there is nothing else to do. Every SPN used by the NFS service is automatically added/removed into the KDC when joining/unjoining the SMB server. Note that the SMB server cannot be destroyed if NFS secure is configured to use the SMB configuration. If the administrator selects to use a UNIX based Kerberos realm, more configuration is needed: • Realm name: The name of the Kerberos realm, which generally contains all upper-case letters. • Entirely configure a UNIX KDC based Kerberos realm. To ensure that a client mounts an NFS export with a specific security, a security parameter, sec, is provided that indicates which minimal security is allowed. There are 4 kinds of security: • AUTH_SYS: Standard legacy security which does not use Kerberos. The server trust the credential provided by the client • KRB5: Authentication using Kerberos v5 • KRB5i: Kerberos authentication plus integrity (signing) • KRB5p: Kerberos authentication plus integrity plus privacy (encryption) If a NFS client tries to mount an export with a security that is lower than the configured minimal security, the access will be denied. For example, if minimal access is KRB5i, any mount using AUTH_SYS or KRB5 will be rejected. Building a credential When a user connects to the system, it presents only its principal, user@REALM, which is extracted from the Kerberos ticket. Unlike AUTH_SYS security, the credential is not included in the NFS request. From the principal, the user part (before the @) is extracted and used to lookup the UDS for the corresponding uid. From that uid, the credential is built by the system using the active UDS, similar to when the Extended NFS credential is enabled (with the exception that, without Kerberos, the uid is provided directly by the request). If the principal is not mapped in the UDS, the configured default UNIX user credential is used instead. If the default UNIX user is not set, the credential used will be nobody. Security on file system objects In a multiprotocol environment, security policy is set at the file system level, and is independent for each file system. Each file system uses its access policy to determine how to reconcile the differences between NFS and SMB access control semantics. Selecting an access policy determines which mechanism is used to enforce file security on the particular file system. NOTE: If the older SMB1 protocol needs to be supported in your environment, it can be enabled by using the svc_nas_cifssupport service command. For more information about this service command, see the PowerStore Service Scripts Guide. 18 Authentication and access