Reference Guide

Windows-Zugangsdaten für SMB-Anforderungen

Zur Verarbeitung von SMB-Anforderungen für ein Nur-SMB- oder Multiprotokolldateisystem mit einer Windows- oder nativen Zugriffs-

Policy müssen Windows-Anmeldedaten verwendet werden. Die Windows-Anmeldedaten für SMB müssen nur einmal zum Zeitpunkt der

Anforderung einer Sitzungseinrichtung erstellt werden, wenn sich der Benutzer verbindet.

Wenn Kerberos-Authentifizierung verwendet wird, sind die Anmeldedaten des Benutzers im Kerberos-Ticket der Anforderung zur

Sitzungseinrichtung enthalten, anders als bei der Verwendung von NTLM (NT LAN Manager). Weitere Informationen werden vom

Windows-DC oder der LGDB abgefragt. Für Kerberos wird die Liste der Extragruppen-SIDs dem Kerberos-Ticket und der Liste der lokalen

Extragruppen-SIDs entnommen. Die Liste der Rechte werden der LGDB entnommen. Für NTLM wird die Liste der Extragruppen-SIDs dem

Windows-DC und der Liste der lokalen Extragruppen-SIDs entnommen. Die Liste der Rechte werden der LGDB entnommen.

Darüber hinaus wird die entsprechende UID und primäre GID auch von der Benutzerzuordnungskomponente abgerufen. Da die

Primärgruppen-SID für die Zugriffsprüfung nicht verwendet wird, wird stattdessen die primäre UNIX-GID verwendet.

ANMERKUNG: NTLM ist eine ältere Suite proprietärer Sicherheitsprotokolle, die Authentifizierung, Integrität und Vertraulichkeit für

Benutzer bereitstellt. Kerberos ist ein offenes Standardprotokoll, das schnellere Authentifizierung durch den Einsatz eines Ticketing-

Systems bietet. Kerberos verleiht Systemen in einem Netzwerk mehr Sicherheit als NTLM.

Windows-Anmeldedaten für NFS-Anforderungen

Die Windows-Anmeldedaten werden nur erstellt oder abgerufen, wenn ein Benutzer über eine NFS-Anforderung versucht, auf ein

Dateisystem zuzugreifen, das über eine Windows-Zugriffs-Policy verfügt. Die UID wird aus der NFS-Anforderung extrahiert. Es gibt einen

globalen Cache für Windows-Anmeldedaten. Damit wird vermieden, dass die Anmeldedaten bei jeder NFS-Anforderung mit einer

zugehörigen Aufbewahrungszeit erstellt werden müssen. Wenn die Windows-Anmeldedaten in diesem Cache gefunden werden, ist keine

weitere Aktion erforderlich. Wenn die Windows-Anmeldedaten nicht gefunden werden, wird der UDS oder die lokale Datei abgefragt, um

den Namen für die UID zu finden. Der Name wird dann verwendet (optional, durch ntxmap), um einen Windows-Benutzer zu finden, und

die Anmeldedaten werden vom Windows-DC oder LGDB abgerufen. Wenn die Zuordnung nicht gefunden wird, werden stattdessen die

Windows-Anmeldedaten des standardmäßigen Windows-Benutzers verwendet oder der Zugriff wird verweigert.

Überblick über Common Antivirus Agent (CAVA)

Common AntiVirus Agent (CAVA) bietet eine Virenschutzlösung für Clients, die einen NAS-Server verwenden. Sie nutzt ein

Branchenstandard-SMB-Protokoll in einer Microsoft Windows Server-Umgebung. CAVA nutzt Virenschutzsoftware von Drittanbietern,

um bekannte Viren zu identifizieren und zu eliminieren, bevor sie Dateien im Speichersystem infizieren können.

Warum ist Virenschutz wichtig?

Das Speichersystem ist aufgrund seiner Architektur gegen das Eindringen von Viren resistent. Der NAS-Server führt mithilfe eines

eingebetteten Betriebssystems den Datenzugriff in Echtzeit aus. Drittanbieter können auf diesem Betriebssystem keine Programme

ausführen, die Viren enthalten. Obwohl die Betriebssystemsoftware gegen Viren geschützt ist, muss auf Windows-Clients, die auf das

Speichersystem zugreifen, ebenfalls ein Virenschutz installiert sein. Der Virenschutz auf Clients reduziert das Risiko, dass sie eine infizierte

Datei auf dem Server speichern, und schützt sie, wenn sie eine infizierte Datei öffnen. Diese Virenschutzlösung besteht aus einer

Kombination aus Betriebssystemsoftware, einem CAVA-Agenten und einer Antivirus-Engine eines Drittanbieters. Die CAVA-Software und

eine Drittanbieter-Virenschutz-Engine muss auf einem Windows-Server in der Domain installiert sein.

Weitere Informationen zu CAVA, das ein Teil von Common Event Enabler (CEE) ist, finden Sie unter Using the Common Event Enabler on

Windows Platforms auf www.dell.com/powerstoredocs.

Codesignierung

PowerStore wurde entwickelt, um Softwareupgrades für neue Versionen und Patch-Versionen zu akzeptieren. Ein Master-GNU-Privacy-

Guard-Schlüssel (GPG) signiert alle PowerStore-Softwarepakete und Dell EMC steuert diesen GPG-Schlüssel. Der PowerStore-

Softwareupgradeprozess überprüft die Signatur des Softwarepakets und lehnt ungültige Signaturen ab, die auf eine mögliche Manipulation

oder Beschädigung hindeuten könnten. Der Überprüfungsschritt ist in den Upgradeprozess integriert und die Signatur des Softwarepakets

wird in der Phase vor der Installation automatisch überprüft.

Authentifizierung und Zugriff