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

Understanding Common AntiVirus Agent (CAVA), Why is antivirus important?

Get Dell PowerStore 1000T PDF manuals and user guides View all Dell PowerStore 1000T manuals
Add to My Manuals
Save this manual to your list of manuals

Page 24 highlights

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. Windows credential for NFS requests The Windows credential is only built or retrieved when a user through an NFS request attempts to access a file system that has a Windows access policy. The UID is extracted from the NFS request. There is a global Windows credential cache to help avoid building the credential on each NFS request with an associated retention time. If the Windows credential is found in this cache, no other action is required. If the Windows credential is not found, the UDS or local file is queried to find the name for the UID. The name is then used (optionally, through ntxmap) to find a Windows user, and the credential is retrieved from the Windows DC or LGDB. If the mapping is not found, the Windows credential of the default Windows user is used instead, or the access is denied. Understanding Common AntiVirus Agent (CAVA) Common AntiVirus Agent (CAVA) provides an antivirus solution to clients using a NAS server. It uses an industry-standard SMB protocol in a Microsoft Windows Server environment. CAVA uses third-party antivirus software to identify and eliminate known viruses before they infect files on the storage system. Why is antivirus important? The storage system is resistant to the invasion of viruses because of its architecture. The NAS server runs data access in real-time using an embedded operating system. Third parties are unable to run programs containing viruses on this operating system. Although the operating system software is resistant to viruses, Windows clients that access the storage system require virus protection. Virus protection on clients reduces the chance that they will store an infected file on the server, and protects them if they open an infected file. This antivirus solution consists of a combination of the operating system software, CAVA agent, and a third-party antivirus engine. The CAVA software and a third-party antivirus engine must be installed on a Windows Server in the domain. For additional information about CAVA, which is part of Common Event Enabler (CEE), refer to Using the Common Event Enabler on Windows Platforms on www.dell.com/powerstoredocs. 24 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
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.
Windows credential for NFS requests
The Windows credential is only built or retrieved when a user through an NFS request attempts to access a file system that has a
Windows access policy. The UID is extracted from the NFS request. There is a global Windows credential cache to help avoid building the
credential on each NFS request with an associated retention time. If the Windows credential is found in this cache, no other action is
required. If the Windows credential is not found, the UDS or local file is queried to find the name for the UID. The name is then used
(optionally, through ntxmap) to find a Windows user, and the credential is retrieved from the Windows DC or LGDB. If the mapping is not
found, the Windows credential of the default Windows user is used instead, or the access is denied.
Understanding Common AntiVirus Agent (CAVA)
Common AntiVirus Agent (CAVA) provides an antivirus solution to clients using a NAS server. It uses an industry-standard SMB protocol
in a Microsoft Windows Server environment. CAVA uses third-party antivirus software to identify and eliminate known viruses before they
infect files on the storage system.
Why is antivirus important?
The storage system is resistant to the invasion of viruses because of its architecture. The NAS server runs data access in real-time using
an embedded operating system. Third parties are unable to run programs containing viruses on this operating system. Although the
operating system software is resistant to viruses, Windows clients that access the storage system require virus protection. Virus
protection on clients reduces the chance that they will store an infected file on the server, and protects them if they open an infected file.
This antivirus solution consists of a combination of the operating system software, CAVA agent, and a third-party antivirus engine. The
CAVA software and a third-party antivirus engine must be installed on a Windows Server in the domain.
For additional information about CAVA, which is part of Common Event Enabler (CEE), refer to
Using the Common Event Enabler on
Windows Platforms
on
www.dell.com/powerstoredocs
.
24
Authentication and access