Reference Guide

● A UNIX user must be mapped to a Windows user in order to build the Windows credential when the user is accessing a file
system that has a Windows access policy.
Two properties are associated to the NAS server with regards to unmapped users:
● The default UNIX user.
● The default Windows user.
When an unmapped Windows user attempts to connect to a multiprotocol file system and the default UNIX user account is
configured for the NAS server, the user identifier (UID) and primary group identifier (GID) of the default UNIX user are used in
the Windows credential. Similarly, when an unmapped UNIX user attempts to connect to a multiprotocol file system and the
default Windows user account is configured for the NAS server, the Windows credential of the default Windows user is used.
NOTE: If the default UNIX user is not set in the UNIX Directory Services (UDS), SMB access is denied for unmapped users.
If the default Windows user is not found in the Windows DC or the LGDB, NFS access on a file system that has a Windows
access policy is denied for unmapped users.
NOTE: The default UNIX user can be a valid existing UNIX account name or follow the new format
@uid=xxxx,gid=yyyy@, where xxxx and yyyy are the decimal numerical values of the UID and the primary GID,
respectively, and can be configured on the system through PowerStore Manager.
UNIX credential for NFS requests
To handle NFS requests for an NFS only or multi-protocol file system with a UNIX or native access policy, a UNIX credential
must be used. The UNIX credential is always embedded in each request; however, the credential is limited to 16 extra groups.
The NFS server extendedUnixCredEnabled property provides the ability to build a credential with more than 16 groups. If
this property is set, the active UDS is queried with the UID to get the primary GID and all the group GIDs to which it belongs. If
the UID is not found in the UDS, the UNIX credential embedded in the request is used.
NOTE: For NFS secure access, the credential is always built using the UDS.
UNIX credential for SMB requests
To handle SMB requests for a multi-protocol file system with a UNIX access policy, a Windows credential must first be built for
the SMB user at the session setup time. The SID of the Windows user is used to find the name from the AD. That name is then
used (optionally through ntxmap) to find a Unix UID and GID from the UDS or local file (passwd file). The owner UID of the user
is included in the Windows credential. When accessing a file system with a UNIX access policy, the UID of the user is used to
query the UDS to build the UNIX credential, similar to building an extended credential for NFS. The UID is required for quota
management.
Windows credential for SMB requests
To handle SMB requests for an SMB only or a multi-protocol file system with a Windows or native access policy, a Windows
credential must be used. The Windows credential for SMB needs to be built only once at the session setup request time when
the user connects.
When using Kerberos authentication, the credential of the user is included in the Kerberos ticket of the session setup request,
unlike when using NT LAN Manager (NTLM). Other information is queried from the Windows DC or the LGDB. For Kerberos the
list of extra group SIDs is taken from the Kerberos ticket and the list of extra local group SIDs. The list of privileges are taken
from the LGDB. For NTLM the list of extra group SIDs is taken from the Windows DC and the list of extra local group SIDs. The
list of privileges are taken from the LGDB.
Additionally, the corresponding UID and primary GID are also retrieved from the user mapping component. Since the primary
group SID is not used for access checking, the UNIX primary GID is used instead.
NOTE:
NTLM is an older suite of proprietary security protocols that provides authentication, integrity, and confidentiality to
users. Kerberos is an open standard protocol that provides faster authentication through the use of a ticketing system.
Kerberos adds greater security than NTLM to systems on a network.
24 Authentication and access