Reference Guide

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.
UNIX security model
When the UNIX policy is selected, any attempt to change file level security from the SMB protocol, such as changes to access
control lists (ACLs), is ignored. UNIX access rights are referred to as the mode bits or NFSv4 ACL of a file system object. Mode
bits are represented by a bit string. Each bit represents an access mode or privilege that is granted to the user owning the file,
the group associated with the file system object, and all other users. UNIX mode bits are represented as three sets of
concatenated rwx (read, write, and execute) triplets for each category of users (user, group, or other). An ACL is a list of users
and groups of users by which access to, and denial of, services is controlled.
Windows security model
The Windows security model is based primarily on object rights, which involve the use of a security descriptor (SD) and its ACL.
When SMB policy is selected, changes to the mode bits from the NFS protocol are ignored.
Access to a file system object is based on whether permissions have been set to Allow or Deny through the use of a security
descriptor. The SD describes the owner of the object and group SIDs for the object along with its ACLs. An ACL is part of the
security descriptor for each object. Each ACL contains access control entries (ACEs). Each ACE in turn, contains a single SID
that identifies a user, group, or computer and a list of rights that are denied or allowed for that SID.
Authentication and access
19