Dell PowerStore 1000T EMC PowerStore Security Configuration Guide - Page 18

Security on file system objects, File protocol relationships, Building a credential

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

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41

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