Andere NAS-Infrastruktur-Serviceabhängigkeiten (KDC, LDAP und DNS)
Änderungen vorschlagen
PDFs
Bei der Verwendung von Google Cloud NetApp Volumes für NAS-Freigaben können externe Abhängigkeiten erforderlich sein, um ein ordnungsgemäßes Funktionieren sicherzustellen. Diese Abhängigkeiten spielen unter bestimmten Umständen eine Rolle. Die folgende Tabelle zeigt verschiedene Konfigurationsoptionen und ggf. erforderliche Abhängigkeiten.
| Konfiguration | Erforderliche Abhängigkeiten |
|---|---|
Nur NFSv3 |
Keine |
Nur NFSv3 Kerberos |
Windows Active Directory: * KDC * DNS * LDAP |
Nur NFSv4.1 |
Konfiguration der Client-ID-Zuordnung (/etc/idmap.conf) |
Nur Kerberos |
|
Nur SMB |
Active Directory: * KDC * DNS |
Multi-Protokoll-NAS (NFS und SMB) |
|
Kerberos Keytab-Rotation/Passwort-Reset für Computerkontoobjekte
Bei SMB-Computerkonten plant Google Cloud NetApp Volumes regelmäßige Passwortrücksetzungen für das SMB-Computerkonto. Diese Kennwortrücksetzung erfolgt mit Kerberos-Verschlüsselung und wird nach einem Zeitplan jeden vierten Sonntag zu einer zufälligen Zeit zwischen 23:00 und 1:00 UHR ausgeführt. Durch diese Passwortrücksetzungen werden die Kerberos-Schlüsselversionen geändert, die im NetApp-Volume-System von Google Cloud gespeicherten Keytabs gedreht und ein höheres Sicherheitsniveau für SMB-Server, die in Google Cloud NetApp Volumes ausgeführt werden, gewährleistet. Passwörter für Computerkonten sind randomisiert und Administratoren nicht bekannt.
Bei NFS-Kerberos-Computerkonten erfolgt ein Zurücksetzen des Passworts nur dann, wenn ein neuer Keytab mit dem KDC erstellt/ausgetauscht wird. In Google Cloud NetApp Volumes ist dies derzeit nicht möglich.
Netzwerkports zur Verwendung mit LDAP und Kerberos
Wenn Sie LDAP und Kerberos verwenden, sollten Sie die von diesen Diensten verwendeten Netzwerkports ermitteln. Eine vollständige Liste der von Google Cloud NetApp Volumes verwendeten Ports finden Sie im "Dokumentation zu Google Cloud NetApp Volumes zu Sicherheitsüberlegungen".
LDAP
Google Cloud NetApp Volumes fungiert als LDAP-Client und verwendet standardmäßige LDAP-Suchabfragen für Benutzer und Gruppen nach UNIX-Identitäten. LDAP ist erforderlich, wenn Sie Benutzer und Gruppen außerhalb der von Google Cloud NetApp Volumes bereitgestellten Standardbenutzer verwenden möchten. LDAP ist auch erforderlich, wenn Sie die Verwendung von NFS Kerberos mit Benutzerprinzipals (z. B. user1@domain.com) planen. Derzeit wird nur LDAP unterstützt, die Microsoft Active Directory verwenden.
Wenn Sie Active Directory als UNIX LDAP-Server verwenden möchten, müssen Sie die erforderlichen UNIX-Attribute für Benutzer und Gruppen ausfüllen, die Sie für UNIX-Identitäten verwenden möchten. Google Cloud NetApp Volumes verwendet eine LDAP-Standardschemavorlage, die Attribute basierend auf abfragt "RFC-2307-bis". Die folgende Tabelle zeigt die für Benutzer und Gruppen erforderlichen Mindestattribute für Active Directory und deren Verwendung für die einzelnen Attribute.
Weitere Informationen zum Festlegen von LDAP-Attributen in Active Directory finden Sie unter "Management des Dual-Protokoll-Zugriffs:"
| Attribut | Das macht es |
|---|---|
uid* |
Gibt den UNIX-Benutzernamen an |
UidNummer* |
Gibt die numerische ID des UNIX-Benutzers an |
GidNumber* |
Gibt die numerische ID der primären Gruppe des UNIX-Benutzers an |
ObjectClass* |
Gibt an, welcher Objekttyp verwendet wird; bei Google Cloud NetApp Volumes muss der „User“ in die Liste der Objektklassen aufgenommen werden (standardmäßig in den meisten Active Directory Implementierungen enthalten). |
Name |
Allgemeine Informationen zum Konto (echter Name, Telefonnummer usw.) |
UnixUserpasswort |
Kein Grund zur Festlegung; nicht in UNIX-Identitätssuchten für die NAS-Authentifizierung verwendet. Durch diese Einstellung wird der konfigurierte Wert unixUserPassword in Klartext gesetzt. |
UnixHomeDirectory |
Definiert den Pfad zu UNIX-Home-Verzeichnissen, wenn ein Benutzer sich von einem Linux-Client aus mit LDAP authentifiziert. Legen Sie diesen Wert fest, wenn Sie die Home-Directory-Funktion LDAP für UNIX verwenden möchten. |
LoginShell |
Definiert den Pfad zur Bash/Profile Shell für Linux-Clients, wenn ein Benutzer sich mit LDAP authentifiziert. |
*Bezeichnet Attribut ist für die ordnungsgemäße Funktion mit Google Cloud NetApp Volumes erforderlich. Die übrigen Attribute gelten nur für die Client-seitige Verwendung.
| Attribut | Das macht es |
|---|---|
kn* |
Gibt den Namen der UNIX-Gruppe an. Bei der Verwendung von Active Directory für LDAP wird dieser Wert bei der ersten Erstellung des Objekts festgelegt, kann aber später geändert werden. Dieser Name darf nicht mit anderen Objekten identisch sein. Zum Beispiel, wenn Ihr UNIX-Benutzer namens user1 gehört zu einer Gruppe namens user1 auf Ihrem Linux-Client, Windows erlaubt nicht zwei Objekte mit dem gleichen cn-Attribut. Um dies zu umgehen, benennen Sie den Windows-Benutzer in einen eindeutigen Namen (z. B. user1-UNIX) um; LDAP in Google Cloud NetApp Volumes verwendet das uid-Attribut für UNIX-Benutzernamen. |
GidNumber* |
Gibt die numerische ID der UNIX-Gruppe an. |
ObjectClass* |
Gibt an, welcher Objekttyp verwendet wird; Google Cloud NetApp Volumes erfordert, dass Gruppe in die Liste der Objektklassen aufgenommen wird (dieses Attribut ist standardmäßig in den meisten Active Directory-Implementierungen enthalten). |
MitgliedschaftenUid |
Gibt an, welche UNIX-Benutzer Mitglieder der UNIX-Gruppe sind. Bei Active Directory LDAP in den Google Cloud NetApp-Volumes ist dieses Feld nicht erforderlich. Das LDAP-Schema von Google Cloud NetApp Volumes verwendet das Feld „Mitglied“ für Gruppenmitgliedschaften. |
Mitglied* |
Erforderlich für Gruppenmitgliedschaften/sekundäre UNIX-Gruppen Dieses Feld wird ausgefüllt, indem Windows-Benutzer zu Windows-Gruppen hinzugefügt werden. Allerdings, wenn die Windows-Gruppen nicht über UNIX-Attribute gefüllt haben, sind sie nicht in der UNIX-Benutzer-Gruppenmitgliedliste enthalten. Alle Gruppen, die in NFS verfügbar sein müssen, müssen die in dieser Tabelle aufgeführten erforderlichen UNIX-Gruppenattribute ausfüllen. |
*Bezeichnet Attribut ist für die ordnungsgemäße Funktion mit Google Cloud NetApp Volumes erforderlich. Die übrigen Attribute gelten nur für die Client-seitige Verwendung.
LDAP-Bindeinformationen
Zur Abfrage von Benutzern in LDAP müssen Google Cloud NetApp Volumes die Verbindung (Anmeldung) zum LDAP-Service herstellen. Diese Anmeldung hat schreibgeschützte Berechtigungen und wird verwendet, um LDAP-UNIX-Attribute für Verzeichnissuchen abzufragen. Derzeit ist LDAP-Bindungen nur über die Verwendung eines SMB-Maschinenkontos möglich.
LDAP kann nur für Instanzen aktiviert NetApp Volumes-Performance und für NFSv3-, NFSv4.1- oder Dual-Protokoll-Volumes verwendet werden. Für eine erfolgreiche Implementierung des LDAP-fähigen Volumes muss in derselben Region wie das Google Cloud NetApp Volumes-Volume eine Active Directory-Verbindung hergestellt werden.
Wenn LDAP aktiviert ist, tritt in bestimmten Szenarien Folgendes auf.
-
Wenn für das Projekt Google Cloud NetApp Volumes nur NFSv3 oder NFSv4.1 verwendet wird, wird im Domänencontroller Active Directory ein neues Computerkonto erstellt, und der LDAP-Client in Google Cloud NetApp-Volumes bindet mithilfe der Anmeldeinformationen des Computerkontos an Active Directory. Für das NFS-Volume werden keine SMB-Shares erstellt und standardmäßige versteckte administrative Shares (siehe Abschnitt "„Standard versteckte Freigaben“") haben Freigabe-ACLs entfernt.
-
Wenn für das Projekt Google Cloud NetApp Volumes Dual-Protokoll-Volumes verwendet werden, wird nur das für den SMB-Zugriff erstellte EinzelMachine-Konto verwendet, um den LDAP-Client in Google Cloud NetApp Volumes an Active Directory zu binden. Es werden keine weiteren Computerkonten erstellt.
-
Wenn dedizierte SMB-Volumes separat erstellt werden (entweder vor oder nach Aktivierung von NFS-Volumes mit LDAP), wird das Computerkonto für LDAP-Bindungen mit dem SMB-Computerkonto gemeinsam genutzt.
-
Wenn NFS Kerberos ebenfalls aktiviert ist, werden zwei Computerkonten erstellt: Eins für SMB-Freigaben und/oder LDAP bindet und eins für die NFS-Kerberos-Authentifizierung.
LDAP-Abfragen
Obwohl LDAP-Bindungen verschlüsselt sind, werden LDAP-Abfragen über das Netzwerk im Klartext über den gemeinsamen LDAP-Port 389 übergeben. Dieser bekannte Port kann derzeit nicht in Google Cloud NetApp Volumes geändert werden. Infolgedessen kann ein Benutzer- und Gruppennamen, numerische IDs und Gruppenmitgliedschaften mit Zugriff auf Packet Sniffing im Netzwerk angezeigt werden.
Allerdings können Google Cloud VMs nicht schnuppern andere VM Unicast-Verkehr. Nur VMs, die aktiv am LDAP-Datenverkehr beteiligt sind (das heißt, binden zu können), können Datenverkehr vom LDAP-Server sehen. Weitere Informationen zum Paketschnüffeln in Google Cloud NetApp Volumes finden Sie im Abschnitt "„Packet Sniffing/Trace Betrachtungen.“"
Standard für die LDAP-Client-Konfiguration
Wenn LDAP in einer Instanz von Google Cloud NetApp Volumes aktiviert ist, wird standardmäßig eine LDAP-Client-Konfiguration mit bestimmten Konfigurationsdetails erstellt. In einigen Fällen gelten die Optionen entweder nicht für Google Cloud NetApp Volumes (nicht unterstützt) oder sind nicht konfigurierbar.
| LDAP-Client-Option | Das macht es | Standardwert | Können Sie Veränderungen vornehmen? |
|---|---|---|---|
LDAP-Serverliste |
Legt LDAP-Servernamen oder IP-Adressen für Abfragen fest. Dies wird nicht für Google Cloud NetApp Volumes verwendet. Stattdessen wird Active Directory Domain zum Definieren von LDAP-Servern verwendet. |
Nicht festgelegt |
Nein |
Active Directory-Domäne |
Legt die Active Directory-Domäne für LDAP-Abfragen fest. Google Cloud NetApp Volumes nutzt SRV-Datensätze für LDAP in DNS, um LDAP-Server in der Domäne zu finden. |
Legen Sie die Active Directory-Domäne fest, die in der Active Directory-Verbindung angegeben ist. |
Nein |
Bevorzugte Active Directory-Server |
Legt die bevorzugten Active Directory-Server fest, die für LDAP verwendet werden sollen. Nicht unterstützt von Google Cloud NetApp Volumes. Verwenden Sie stattdessen Active Directory-Sites, um die LDAP-Serverauswahl zu steuern. |
Nicht festgelegt. |
Nein |
Binden mit SMB Server Credentials |
Bindet an LDAP über das SMB-Maschinenkonto. Derzeit ist die einzige unterstützte LDAP-Bindungsmethode in Google Cloud NetApp Volumes. |
Richtig |
Nein |
Schemavorlage |
Die Schemavorlage, die für LDAP-Abfragen verwendet wird. |
MS-AD-BIS |
Nein |
LDAP-Serverport |
Die für LDAP-Abfragen verwendete Portnummer. Die Google Cloud NetApp Volumes verwenden derzeit nur den LDAP-Standardport 389. LDAPS/Port 636 wird derzeit nicht unterstützt. |
389 |
Nein |
Ist LDAPS aktiviert |
Steuert, ob LDAP over Secure Sockets Layer (SSL) für Abfragen und Bindungen verwendet wird. Derzeit nicht von Google Cloud NetApp Volumes unterstützt. |
Falsch |
Nein |
Zeitüberschreitung bei Abfrage (Sek.) |
Timeout für Abfragen. Wenn Abfragen länger als der angegebene Wert dauern, schlagen Abfragen fehl. |
3 |
Nein |
Minimale Stufe Der Bind-Authentifizierung |
Die minimal unterstützte Bindestufe. Da Google Cloud NetApp Volumes Computerkonten für LDAP-Bindungen verwendet und Active Directory keine anonymen Bindungen standardmäßig unterstützt, kommt diese Option aus Sicherheitsgründen nicht ins Spiel. |
Anonym |
Nein |
DN binden |
Der für Bindungen verwendete Benutzer/Distinguished Name (DN) wird verwendet, wenn einfache Bindung verwendet wird. Google Cloud NetApp Volumes verwendet Computerkonten für LDAP-Bindungen und unterstützt derzeit nicht die einfache Bind-Authentifizierung. |
Nicht festgelegt |
Nein |
Basis-DN |
Der Basis-DN, der für LDAP-Suchen verwendet wird. |
Die Windows-Domäne, die für die Active Directory-Verbindung im DN-Format verwendet wird (d. h. DC=Domain, DC=local). |
Nein |
Umfang der Basissuche |
Der Suchbereich für Basis-DN-Suchvorgänge. Werte können Basis, Onelevel oder Unterbaum umfassen. Google Cloud NetApp Volumes unterstützt nur Suchvorgänge in Unterbaumen. |
Unterbaum |
Nein |
Benutzer-DN |
Definiert den DN, in dem der Benutzer nach LDAP-Abfragen startet. Derzeit wird Google Cloud NetApp Volumes nicht unterstützt, daher beginnen alle Benutzersuchen bei der Basis-DN. |
Nicht festgelegt |
Nein |
Umfang der Benutzersuche |
Der Suchbereich für Benutzer-DN sucht. Werte können Basis, Onelevel oder Unterbaum umfassen. Google Cloud NetApp Volumes unterstützt nicht das Festlegen des Suchumfangs für Benutzer. |
Unterbaum |
Nein |
Gruppen-DN |
Definiert den DN, in dem die Gruppensuche nach LDAP-Abfragen beginnen soll. Derzeit werden Google Cloud NetApp Volumes nicht unterstützt, daher beginnen alle Gruppensuchen bei der Basis-DN. |
Nicht festgelegt |
Nein |
Bereich der Gruppensuche |
Der Suchbereich für Gruppen-DN sucht. Werte können Basis, Onelevel oder Unterbaum umfassen. Google Cloud NetApp Volumes unterstützt nicht das Festlegen des Gruppensuchbereichs. |
Unterbaum |
Nein |
Netzgruppe DN |
Definiert den DN, in dem Netzgruppe nach LDAP-Abfragen startet. Derzeit wird Google Cloud NetApp Volumes nicht unterstützt, daher beginnen alle Netzwerkgruppen-Suchen bei der Basis-DN. |
Nicht festgelegt |
Nein |
Suchumfang für Netzgruppe |
Der Suchbereich für Netzgruppe DN sucht. Werte können Basis, Onelevel oder Unterbaum umfassen. Google Cloud NetApp Volumes unterstützt nicht das Festlegen des Suchumfangs für Netzgruppen. |
Unterbaum |
Nein |
Verwenden Sie Start_tls über LDAP |
Nutzt Start TLS für zertifikatbasierte LDAP-Verbindungen über Port 389. Derzeit nicht von Google Cloud NetApp Volumes unterstützt. |
Falsch |
Nein |
Aktivieren Sie die Suche in netgroup-by-Host |
Ermöglicht die Suche in einer Netzwerkgruppe nach Hostnamen und nicht die Erweiterung von Netgroups, um alle Mitglieder aufzulisten. Derzeit nicht von Google Cloud NetApp Volumes unterstützt. |
Falsch |
Nein |
Netgroup-by-Host DN |
Definiert den DN, in dem netgroup-by-Host nach LDAP-Abfragen startet. Netgroup-by-Host wird derzeit nicht für Google Cloud NetApp Volumes unterstützt. |
Nicht festgelegt |
Nein |
Suchumfang für Netzgruppe nach Host |
Der Suchbereich für netgroup-by-Host DN sucht. Werte können Basis, Onelevel oder Unterbaum enthalten. Netgroup-by-Host wird derzeit nicht für Google Cloud NetApp Volumes unterstützt. |
Unterbaum |
Nein |
Sicherheit der Client-Session |
Definiert, in welchem Maß die Sitzungssicherheit von LDAP verwendet wird (Zeichen, Siegel oder keine). Die LDAP-Signatur wird von NetApp Volumes-Performance unterstützt, sofern von Active Directory angefordert. NetApp Volumes-SW unterstützt LDAP-Signing nicht. Für beide Servicetypen wird die Dichtung derzeit nicht unterstützt. |
Keine |
Nein |
LDAP-Verweisungsjagd |
Bei der Verwendung mehrerer LDAP-Server ermöglicht die Verweisungsjagd dem Client, auf andere LDAP-Server in der Liste zu verweisen, wenn ein Eintrag nicht im ersten Server gefunden wird. Dies wird derzeit von Google Cloud NetApp Volumes nicht unterstützt. |
Falsch |
Nein |
Filter für Gruppenmitgliedschaft |
Bietet einen benutzerdefinierten LDAP-Suchfilter, der verwendet werden kann, wenn eine Gruppenmitgliedschaft von einem LDAP-Server aus gesucht wird. Derzeit keine Unterstützung von Google Cloud NetApp Volumes |
Nicht festgelegt |
Nein |
LDAP für asymmetrische Namenszuweisung verwenden
Google Cloud NetApp Volumes ordnet Windows-Benutzern und UNIX-Benutzern standardmäßig identische Benutzernamen bidirektional und ohne spezielle Konfiguration zu. Solange Google Cloud NetApp Volumes einen gültigen UNIX-Benutzer finden können (mit LDAP), erfolgt eine 1:1-Namenszuordnung. Wenn z. B. Windows-Benutzer johnsmith verwendet wird, dann werden alle von erstellten Dateien/Ordner das korrekte Benutzereigentum anzeigen, und alle ACLs, die sich auf auswirken, unabhängig vom verwendeten NAS-Protokoll geehrt, wenn Google Cloud NetApp Volumes einen UNIX-Benutzer mit johnsmith dem Namen in LDAP johnsmith finden johnsmith. Dies wird als symmetrisches Namenszuordnungen bezeichnet.
Asymmetrisches Namenszuordnungen ist, wenn die Windows-Benutzer- und UNIX-Benutzeridentität nicht übereinstimmt. Wenn Windows-Benutzer beispielsweise johnsmith eine UNIX-Identität von `jsmith`haben, benötigt Google Cloud NetApp Volumes eine Möglichkeit, über die Variation informiert zu werden. Da Google Cloud NetApp Volumes derzeit die Erstellung statischer Namenszuordnungsregeln nicht unterstützt, muss LDAP verwendet werden, um die Identität der Benutzer sowohl für Windows- als auch für UNIX-Identitäten zu ermitteln. Dadurch wird sichergestellt, dass die richtigen Eigentümer von Dateien und Ordnern sowie die erwarteten Berechtigungen sind.
Google Cloud NetApp Volumes sind standardmäßig im ns-Switch der Instanz für die Namenszuordnungsdatenbank enthalten LDAP. Um also die Namenszuordnungsfunktion mithilfe von LDAP für asymmetrische Namen bereitzustellen, müssen Sie nur einige der Benutzer-/Gruppenattribute ändern, um den von Google Cloud NetApp Volumes gewünschten Inhalt wiederzugeben.
In der folgenden Tabelle wird gezeigt, welche Attribute für die asymmetrische Namenszuordnungsfunktion in LDAP ausgefüllt werden müssen. In den meisten Fällen ist Active Directory bereits dafür konfiguriert.
| Attribut von Google Cloud NetApp Volumes | Das macht es | Wert, der von Google Cloud NetApp Volumes für Namenszuordnung verwendet wird |
|---|---|---|
Windows auf UNIX objectClass |
Gibt den Typ des verwendeten Objekts an. (D. h. Benutzer, Gruppe, PosixAccount usw.) |
Muss Benutzer enthalten (kann mehrere andere Werte enthalten, falls gewünscht.) |
Attribut Windows zu UNIX |
Dies definiert den Windows-Benutzernamen bei der Erstellung. Google Cloud NetApp Volumes verwendet diese Funktion für Windows, um UNIX-Suchvorgänge durchzuführen. |
Hier ist keine Änderung erforderlich; sAMAccountName ist der gleiche wie der Windows-Anmeldename. |
UID |
Definiert den UNIX-Benutzernamen. |
Gewünschter UNIX-Benutzername. |
Google Cloud NetApp Volumes verwendet derzeit keine Domain-Präfixe in LDAP-Lookups, sodass LDAP-Umgebungen mit mehreren Domänen bei LDAP-Namemap-Lookups nicht ordnungsgemäß funktionieren.
Im folgenden Beispiel wird ein Benutzer mit dem Windows-Namen angezeigt asymmetric, Der UNIX-Name unix-user, Und das Verhalten folgt es beim Schreiben von Dateien sowohl aus SMB und NFS.
Die folgende Abbildung zeigt, wie LDAP-Attribute vom Windows-Server aussehen.
Von einem NFS-Client aus können Sie den UNIX-Namen, nicht jedoch den Windows-Namen abfragen:
# id unix-user uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup) # id asymmetric id: asymmetric: no such user
Wenn eine Datei aus NFS als geschrieben wird unix-user, Das folgende Ergebnis ist von dem NFS Client:
sh-4.2$ pwd /mnt/home/ntfssh-4.2$ touch unix-user-file sh-4.2$ ls -la | grep unix-user -rwx------ 1 unix-user sharedgroup 0 Feb 28 12:37 unix-user-nfs sh-4.2$ id uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup)
Von einem Windows-Client aus sehen Sie, dass der Eigentümer der Datei auf den richtigen Windows-Benutzer eingestellt ist:
PS C:\ > Get-Acl \\demo\home\ntfs\unix-user-nfs | select Owner Owner ----- NTAP\asymmetric
Umgekehrt werden Dateien vom Windows-Benutzer erstellt asymmetric Von einem SMB-Client wird der richtige UNIX-Eigentümer angezeigt, wie im folgenden Text dargestellt.
SMB:
PS Z:\ntfs> echo TEXT > asymmetric-user-smb.txt
NFS
sh-4.2$ ls -la | grep asymmetric-user-smb.txt -rwx------ 1 unix-user sharedgroup 14 Feb 28 12:43 asymmetric-user-smb.txt sh-4.2$ cat asymmetric-user-smb.txt TEXT
LDAP-Kanalbindung
Aufgrund einer Schwachstelle bei Windows Active Directory-Domänencontrollern "Microsoft Security Advisory ADV190023" Ändert die Art und Weise, wie DCs LDAP-Bindungen zulassen.
Die Auswirkungen für Google Cloud NetApp Volumes sind dieselben wie für jeden LDAP-Client. In Google Cloud NetApp Volumes wird derzeit keine Channel-Bindung unterstützt. Da Google Cloud NetApp Volumes standardmäßig über Verhandlung LDAP-Signaturen unterstützen, sollte die LDAP-Channel-Bindung kein Problem darstellen. Wenn Sie Probleme mit der Bindung an LDAP haben und die Kanalbindung aktiviert ist, befolgen Sie die Schritte zur Problembehebung in ADV190023, um zu gewährleisten, dass LDAP-Bindungen von Google Cloud NetApp Volumes erfolgreich durchgeführt werden.
DNS
Active Directory und Kerberos haben beide Abhängigkeiten von DNS für den Hostnamen zu IP/IP bis zur Auflösung des Hostnamens. DNS erfordert, dass Port 53 offen ist. Google Cloud NetApp Volumes ändert nichts an DNS-Einträgen und unterstützt derzeit auch nicht die Verwendung von in Netzwerkschnittstellen. "Dynamisches DNS"
Sie können Active Directory DNS so konfigurieren, dass Sie festlegen können, welche Server DNS-Einträge aktualisieren können. Weitere Informationen finden Sie unter "Sicheres Windows DNS".
Beachten Sie, dass Ressourcen innerhalb eines Google-Projekts standardmäßig mit Google Cloud DNS, die nicht mit Active Directory DNS verbunden ist. Clients, die Cloud NetApp verwenden, können die von Google Cloud DNS Volumes zurückgesendeten UNC-Pfade nicht auflösen. Windows-Clients, die mit der Active Directory-Domäne verbunden sind, sind für die Verwendung von Active Directory DNS konfiguriert und können solche UNC-Pfade auflösen.
Um einem Client zu Active Directory beizutreten, müssen Sie seine DNS-Konfiguration so konfigurieren, dass Active Directory DNS verwendet wird. Optional können Sie Cloud DNS konfigurieren, um Anfragen an Active Directory DNS weiterzuleiten. Siehe "Warum kann mein Client den SMB NetBIOS-Namen nicht lösen?"Finden Sie weitere Informationen.
|
Google Cloud NetApp Volumes unterstützt derzeit keine DNSSEC-Unterstützung, und DNS-Abfragen werden im Klartext ausgeführt. |
Prüfung von Dateizugriffen
Derzeit keine Unterstützung für Google Cloud NetApp Volumes
Virenschutz
Sie müssen in Google Cloud NetApp Volumes des Clients eine Virenprüfung auf einer NAS-Freigabe durchführen. Derzeit gibt es keine native Virenschutz-Integration in Google Cloud NetApp Volumes.