Dateifreigabeprotokolle wie SMB (CIFS), NFSv3 mit erweiterten Gruppen und NFSv4, die Sicherheitsprinzipien verwenden, beruhen auf externen Verzeichnisdiensten, um Informationen zur Nutzeridentität bereitzustellen. NetApp Volumes verwendet Microsoft Active Directory für Verzeichnisdienste. Active Directory bietet Dienste wie LDAP-Server zum Auffinden von Objekten wie Nutzern, Gruppen und Computerkonten, DNS-Server zur Auflösung von Hostnamen und Kerberos-Server zur Authentifizierung.
Weitere Informationen finden Sie unter Best Practices für die Ausführung von Active Directory in Google Cloud.
Das verwaltete Microsoft Active Directory von Google Cloud wird von NetApp Volumes nicht unterstützt.
Anwendungsfälle
NetApp Volumes verwendet Active Directory für die Fälle in den folgenden Abschnitten.
SMB-Domaindienst
Active Directory ist der zentrale Domaindienst für SMB. SMB wird für die Authentifizierung und Identitätssuche für Nutzer und Gruppen verwendet. NetApp Volumes wird der Domain als Mitglied hinzugefügt und unterstützt SMB nicht im Arbeitsgruppenmodus.
Unterstützung für erweiterte NFSv3-Gruppen
Bei NFSv3 mit erweiterter Gruppenunterstützung stellt Active Directory den LDAP-Server bereit, der zum Abrufen von Objekten wie Nutzern, Gruppen oder Maschinenkonten erforderlich ist. Insbesondere ist für die Suche nach Nutzer- und Gruppen-IDs ein RFC2307bis-konformer LDAP-Server erforderlich. Die LDAP-Unterstützung wird bei der Erstellung von Speicherpools aktiviert.
Bei der Unterstützung erweiterter Gruppen werden alle Gruppen-IDs ignoriert, die vom NFS-Client in einem NFS-Aufruf gesendet werden. Stattdessen wird die Nutzer-ID der Anfrage verwendet und alle Gruppen-IDs für die angegebene Nutzer-ID werden vom LDAP-Server abgerufen, um Dateiberechtigungen zu prüfen.
Weitere Informationen finden Sie unter LDAP-POSIX-Attribute vom Typ RFC2307bis verwalten.
Zuordnung von NFSv4.x-Sicherheitsprinzipalen zu Nutzer- und Gruppen-IDs
Bei NFSv4.x werden Sicherheitsempfehlungen mithilfe von Active Directory Benutzer-IDs und Gruppen-IDs zugeordnet. NFSv4 verwendet ein prinzipalenbasiertes Authentifizierungsmodell. Bei der prinzipalen Authentifizierung werden Nutzer anhand von Sicherheitsprinzipalen identifiziert, die die Form user@dns_domain haben (siehe https://www.rfc-editor.org/rfc/rfc7530.html#section-19), anstatt anhand von Nutzer-IDs und Gruppen-IDs. Um Sicherheitsprinzipale beim Zugriff auf das Volume über ein NFSv4.x-Protokoll Nutzer-IDs und Gruppen-IDs zuzuordnen, benötigen NetApp-Volumes einen RFC2307bis-kompatiblen LDAP-Server. Der einzige unterstützte LDAP-Server ist Active Directory. Die LDAP-Unterstützung wird bei der Erstellung von Speicherpools aktiviert.
Wenn Sie Sicherheitsprinzipale verwenden möchten, müssen der NFS-Client und der NFS-Server eine Verbindung zurselben LDAP-Quelle herstellen und die Datei „idmapd.conf“ muss auf dem Client konfiguriert sein. Weitere Informationen zum Konfigurieren der Datei „idmapd.conf“ finden Sie unter Ubuntu-Manpage: idmapd.conf – Konfigurationsdatei für libnfsidmap.
Der Active Directory-Domainname wird für dns_domain verwendet. user ist der Name von Active Directory-Nutzern. Verwenden Sie diese Werte, wenn Sie Ihre LDAP POSIX-Attribute festlegen.
Wenn Sie NFSv4.1 ohne Einrichtung der ID-Zuordnung verwenden und nur Nutzer- und Gruppen-IDs wie bei NFSv3 verwenden möchten, können Sie numerische IDs verwenden, um Sicherheitsprinzipale zu ignorieren. NetApp Volumes unterstützt numerische IDs und aktuelle NFS-Clients verwenden standardmäßig numerische IDs, wenn die ID-Zuordnung nicht konfiguriert ist.
NFSv4.x mit Kerberos
Wenn Sie Kerberos verwenden, müssen Sie Active Directory als LDAP-Server für die Suche nach Sicherheitsempfehlungen verwenden. Kerberos-Principals werden als Sicherheits-IDs verwendet. Active Directory wird auch als Kerberos Key Distribution Center (KDC) verwendet. Dazu müssen Sie dem Pool eine Active Directory-Richtlinie mit Kerberos-Einstellungen zuweisen und die LDAP-Unterstützung beim Erstellen des Speicherpools aktivieren.
Weitere Informationen finden Sie unter Speicherpool erstellen.
Active Directory LDAP-Zugriff
Für NFS-Anwendungsfälle wird Active Directory als LDAP-Server verwendet. NetApp Volumes erwartet Identitätsdaten mit einem RFC2307bis-Schema. Dieses Schema ist bereits in Active Directory verfügbar. Sie müssen jedoch die erforderlichen Attribute für Ihre Nutzer und Gruppen angeben.
NetApp Volumes verwendet die angegebenen Anmeldedaten aus der Active Directory-Richtlinie, um eine LDAP-Bindung mit LDAP-Signatur vorzunehmen.
Wenn der Nutzer oder die Gruppe nicht gefunden werden kann, wird der Zugriff verweigert.
Attribut-Caching
NetApp Volumes speichert die Ergebnisse von LDAP-Abfragen im Cache. In der folgenden Tabelle werden die Einstellungen für die Gültigkeitsdauer (TTL) für den LDAP-Cache beschrieben. Wenn der Cache aufgrund von Fehlkonfigurationen ungültige Daten enthält, die Sie beheben möchten, müssen Sie warten, bis der Cache aktualisiert wurde, bevor Ihre Änderungen in Active Directory erkannt werden. Andernfalls verwendet der NFS-Server weiterhin die alten Daten, um den Zugriff zu überprüfen. Dies führt wahrscheinlich zu Meldungen, dass die Berechtigung auf dem Client verweigert wurde. Nach Ablauf der TTL werden Einträge veraltet, damit veraltete Einträge nicht in der Datenbank verbleiben. Nicht gefundene Suchanfragen werden für eine TTL von einer Minute aufbewahrt, um Leistungsprobleme zu vermeiden.
| Cache | Standardzeitlimit |
|---|---|
| Liste der Gruppenmitgliedschaften | 24-Stunden-TTL |
| Unix-Gruppen (GID) | 24-Stunden-TTL, 1-Minuten-negative TTL |
| Unix-Nutzer (UID) | 24-Stunden-TTL, 1-Minuten-negative TTL |
Active Directory-Domaincontroller-Topologien
Sobald Sie eine Verbindung zu Active Directory-Domaincontrollern hergestellt haben, können Sie die folgenden Dateifreigabeprotokolle verwenden:
- KMU
- NFSv3 mit erweiterten Gruppen
- NFSv4
In den folgenden Abschnitten werden verschiedene mögliche Topologien veranschaulicht. Die Diagramme zeigen nur den Domaincontroller, der von NetApp Volumes verwendet wird. Andere Domaincontroller für dieselbe Domain werden nur bei Bedarf angezeigt.
Microsoft empfiehlt, aus Gründen der Redundanz und Verfügbarkeit mindestens zwei Domaincontroller (DCs) bereitzustellen.
Active Directory-Domaincontroller in derselben Region wie NetApp Volumes-Volumes
Das folgende Diagramm zeigt den einfachsten Bereitstellungsmodus: einen Domaincontroller in derselben Region wie die NetApp-Volumes.
Active Directory-Domaincontroller in mehreren Regionen mit AD-Websites
Wenn Sie NetApp Volumes-Volumes in mehreren Regionen verwenden, empfehlen wir, in jeder Region mindestens einen Domaincontroller zu platzieren. Der Dienst versucht zwar, den besten DC automatisch auszuwählen, es wird jedoch empfohlen, die Auswahl des DC mithilfe von AD-Websites zu verwalten.
Active Directory-Domaincontroller in einem lokalen Netzwerk
Die Verwendung eines lokalen Domaincontrollers über ein VPN wird unterstützt, kann sich aber negativ auf die Authentifizierung von Endnutzern und die Leistung des Dateizugriffs auswirken. Fügen Sie Ihrem Netzwerkpfad keine zusätzlichen VPC-Peering-Hops hinzu.
Hinweise zu lokalen Rechenzentren
Für Verbindungen zu lokalen Rechenzentren werden TCP und IP verwendet. Diese Verbindungen schlagen aufgrund der folgenden Einschränkungen häufig fehl:
VPC-Peering: NetApp-Volumes können nur auf DCs zugreifen, die sich im VPC des Speicherpools befinden oder über ein VPN damit verbunden sind. NetApp-Volumes können keine DCs in anderen VPCs erreichen, einschließlich derjenigen, die mit der VPC verbunden sind, die mit dem Speicherpool verbunden ist.
Firewalls: Sie müssen NetApp Volumes erlauben, Ihre DCs zu kontaktieren. Weitere Informationen finden Sie unter „Firewallregeln für den Active Directory-Zugriff“.
Active Directory-Domaincontroller in einem anderen VPC-Netzwerk
Sie können den Domaincontroller nicht in einem anderen VPC platzieren, da das VPC-Peering von Google Cloud kein transitives Routing zulässt. Alternativ können Sie NetApp-Volumes an ein freigegebenes VPC-Netzwerk anhängen, in dem die Active Directory-Domaincontroller gehostet werden. Wenn Sie NetApp-Volumes mit einem freigegebenen VPC-Netzwerk verknüpfen, entspricht dieses Szenario architektonisch einem der Szenarien in den vorherigen Abschnitten.
DC-Auswahl mithilfe von AD-Websites verwalten
Um die tatsächlichen Standorte von Rechenzentren, Büros und die Netzwerktopologie so genau wie möglich darzustellen, platzieren Sie Domaincontroller in derselben Region wie Ihre Volumes und definieren Sie einen Active Directory-Standort für diese Region.
Wenn NetApp Volumes mit Ihrer Domain verbunden ist, verwendet der Dienst die DNS-basierte Suche, um die richtigen Domaincontroller für die Kommunikation zu finden. Anhand der Ergebnisse der Suche verwaltet der Dienst eine Liste gültiger DCs, zu denen eine Verbindung hergestellt werden kann, und verwendet den mit der niedrigsten Latenz.
Wenn Sie in den Active Directory-Einstellungen von NetApp-Volumes einen Standort angeben, können Sie die Liste der DCs auf die in der AD-Website angegebenen beschränken.
Wenn die automatische DC-Auswahl fehlschlägt, kann die Verwendung von AD-Websites helfen, das Problem zu beheben:
Stellen Sie mindestens einen Domaincontroller in der NetApp Volumes-Region bereit und verbinden Sie ihn mit Ihrem vorhandenen Active Directory.
Erstellen Sie eine Active Directory-Website für Ihre Google Cloud-Region und platzieren Sie die entsprechenden Domaincontroller auf dieser Website.
Verwenden Sie die Active Directory-Website, wenn Sie Active Directory-Verbindungen einrichten.
Informationen zum manuellen Überprüfen der Liste der potenziellen Domaincontroller, die der Dienst verwenden kann, finden Sie unter „Active Directory-Domaincontroller identifizieren, die von NetApp-Volumes verwendet werden“.
Weitere Informationen finden Sie unter „Active Directory: Designüberlegungen und Best Practices“.