Skip to main content
NetApp public and hybrid cloud solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

PME

Contributeurs kevin-hoke
PDF

"PME"est un protocole de partage de fichiers réseau développé par Microsoft qui fournit une authentification centralisée des utilisateurs/groupes, des autorisations, un verrouillage et un partage de fichiers à plusieurs clients SMB sur un réseau Ethernet. Les fichiers et dossiers sont présentés aux clients via des partages, qui peuvent être configurés avec une variété de propriétés de partage et offrent un contrôle d'accès via des autorisations au niveau du partage. SMB peut être présenté à n’importe quel client offrant un support pour le protocole, y compris les clients Windows, Apple et Linux.

Google Cloud NetApp Volumes prend en charge les versions SMB 2.1 et 3.x du protocole.

Contrôle d'accès/partages SMB

  • Lorsqu'un nom d'utilisateur Windows demande l'accès au volume Google Cloud NetApp Volumes , Google Cloud NetApp Volumes recherche un nom d'utilisateur UNIX à l'aide des méthodes configurées par les administrateurs Google Cloud NetApp Volumes .

  • Si un fournisseur d'identité UNIX externe (LDAP) est configuré et que les noms d'utilisateur Windows/UNIX sont identiques, les noms d'utilisateur Windows seront mappés 1:1 aux noms d'utilisateur UNIX sans aucune configuration supplémentaire nécessaire. Lorsque LDAP est activé, Active Directory est utilisé pour héberger ces attributs UNIX pour les objets utilisateur et groupe.

  • Si les noms Windows et les noms UNIX ne correspondent pas de manière identique, LDAP doit être configuré pour permettre à Google Cloud NetApp Volumes d'utiliser la configuration de mappage de noms LDAP (voir la section"Utilisation de LDAP pour le mappage de noms asymétriques" ).

  • Si LDAP n'est pas utilisé, les utilisateurs Windows SMB sont mappés à un utilisateur UNIX local par défaut nommé pcuser dans Google Cloud NetApp Volumes. Cela signifie que les fichiers écrits dans Windows par les utilisateurs correspondent au pcuser afficher la propriété UNIX comme pcuser dans les environnements NAS multiprotocoles. pcuser voici effectivement le nobody utilisateur dans les environnements Linux (UID 65534).

Dans les déploiements avec SMB uniquement, le pcuser le mappage se produit toujours, mais cela n'aura pas d'importance, car la propriété des utilisateurs et des groupes Windows est correctement affichée et l'accès NFS au volume SMB uniquement n'est pas autorisé. De plus, les volumes SMB uniquement ne prennent pas en charge la conversion en volumes NFS ou à double protocole après leur création.

Windows utilise Kerberos pour l’authentification du nom d’utilisateur avec les contrôleurs de domaine Active Directory, ce qui nécessite un échange de nom d’utilisateur/mot de passe avec les contrôleurs de domaine AD, qui est externe à l’instance Google Cloud NetApp Volumes . L'authentification Kerberos est utilisée lorsque le \\SERVERNAME Le chemin UNC est utilisé par les clients SMB et ce qui suit est vrai :

  • Une entrée DNS A/AAAA existe pour SERVERNAME

  • Un SPN valide pour l'accès SMB/CIFS existe pour SERVERNAME

Lorsqu'un volume SMB Google Cloud NetApp Volumes est créé, le nom du compte machine est créé comme défini dans la section"Comment Google Cloud NetApp Volumes s’affiche dans Active Directory." Ce nom de compte machine devient également le chemin d'accès au partage SMB, car Google Cloud NetApp Volumes exploite Dynamic DNS (DDNS) pour créer les entrées A/AAAA et PTR nécessaires dans DNS et les entrées SPN nécessaires sur le principal du compte machine.

Remarque Pour que les entrées PTR soient créées, la zone de recherche inversée pour l'adresse IP de l'instance Google Cloud NetApp Volumes doit exister sur le serveur DNS.

Par exemple, ce volume Google Cloud NetApp Volumes utilise le chemin de partage UNC suivant : \\cvs-east- 433d.cvsdemo.local .

Dans Active Directory, voici les entrées SPN générées par Google Cloud NetApp Volumes:

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Voici le résultat de la recherche DNS directe/inverse :

PS C:\> nslookup NetApp Volumes-EAST-433D
Server:  activedirectory. region. lab. internal
Address:  10. xx.0. xx
Name:    NetApp Volumes-EAST-433D.cvsdemo.local
Address:  10. xxx.0. x
PS C:\> nslookup 10. xxx.0. x
Server:  activedirectory.region.lab.internal
Address:  10.xx.0.xx
Name:    NetApp Volumes-EAST-433D.CVSDEMO.LOCAL
Address:  10. xxx.0. x

En option, un contrôle d'accès plus strict peut être appliqué en activant/exigeant le chiffrement SMB pour les partages SMB dans Google Cloud NetApp Volumes. Si le chiffrement SMB n’est pas pris en charge par l’un des points de terminaison, l’accès n’est pas autorisé.

Utilisation des alias de noms SMB

Dans certains cas, il peut s'agir d'un problème de sécurité pour les utilisateurs finaux de connaître le nom du compte machine utilisé pour Google Cloud NetApp Volumes. Dans d’autres cas, vous souhaiterez peut-être simplement fournir un chemin d’accès plus simple à vos utilisateurs finaux. Dans ces cas, vous pouvez créer des alias SMB.

Si vous souhaitez créer des alias pour le chemin de partage SMB, vous pouvez exploiter ce que l’on appelle un enregistrement CNAME dans DNS. Par exemple, si vous souhaitez utiliser le nom \\CIFS pour accéder aux actions au lieu de \\cvs-east- 433d.cvsdemo.local , mais vous souhaitez toujours utiliser l'authentification Kerberos, un CNAME dans DNS qui pointe vers l'enregistrement A/AAAA existant et un SPN supplémentaire ajouté au compte de machine existant fournit l'accès Kerberos.

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Voici le résultat de la recherche DNS directe après l'ajout d'un CNAME :

PS C:\> nslookup cifs
Server:  ok-activedirectory.us-east4-a.c.cv-solution-architect-lab.internal
Address:  10. xx.0. xx
Name:    NetApp Volumes-EAST-433D.cvsdemo.local
Address:  10. xxx.0. x
Aliases:  cifs.cvsdemo.local

Voici la requête SPN résultante après l'ajout de nouveaux SPN :

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Dans une capture de paquet, nous pouvons voir la demande de configuration de session à l'aide du SPN lié au CNAME.

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Dialectes d'authentification SMB

Google Cloud NetApp Volumes prend en charge les éléments suivants "dialectes" pour l'authentification SMB :

  • LM

  • NTLM

  • NTLMv2

  • Kerberos

L'authentification Kerberos pour l'accès au partage SMB est le niveau d'authentification le plus sécurisé que vous puissiez utiliser. Avec le cryptage AES et SMB activé, le niveau de sécurité est encore augmenté.

Google Cloud NetApp Volumes prend également en charge la compatibilité descendante pour l’authentification LM et NTLM. Lorsque Kerberos est mal configuré (par exemple lors de la création d'alias SMB), l'accès au partage revient à des méthodes d'authentification plus faibles (telles que NTLMv2). Étant donné que ces mécanismes sont moins sécurisés, ils sont désactivés dans certains environnements Active Directory. Si les méthodes d’authentification plus faibles sont désactivées et que Kerberos n’est pas configuré correctement, l’accès au partage échoue car il n’existe aucune méthode d’authentification valide vers laquelle se rabattre.

Pour plus d'informations sur la configuration/l'affichage de vos niveaux d'authentification pris en charge dans Active Directory, consultez "Sécurité du réseau : niveau d'authentification du gestionnaire LAN" .

Modèles d'autorisation

Autorisations NTFS/Fichiers

Les autorisations NTFS sont les autorisations appliquées aux fichiers et dossiers dans les systèmes de fichiers adhérant à la logique NTFS. Vous pouvez appliquer des autorisations NTFS dans Basic ou Advanced et peut être réglé sur Allow ou Deny pour le contrôle d'accès.

Les autorisations de base incluent les éléments suivants :

  • Contrôle total

  • Modifier

  • Lire et exécuter

  • Lire

  • Écrire

Lorsque vous définissez des autorisations pour un utilisateur ou un groupe, appelé ACE, elles résident dans une ACL. Les autorisations NTFS utilisent les mêmes bases de lecture/écriture/exécution que les bits du mode UNIX, mais elles peuvent également s'étendre à des contrôles d'accès plus granulaires et étendus (également appelés autorisations spéciales), tels que la prise de possession, la création de dossiers/l'ajout de données, l'écriture d'attributs, etc.

Les bits du mode UNIX standard ne fournissent pas le même niveau de granularité que les autorisations NTFS (comme la possibilité de définir des autorisations pour des objets utilisateur et groupe individuels dans une ACL ou de définir des attributs étendus). Cependant, les ACL NFSv4.1 fournissent les mêmes fonctionnalités que les ACL NTFS.

Les autorisations NTFS sont plus spécifiques que les autorisations de partage et peuvent être utilisées conjointement avec les autorisations de partage. Avec les structures d'autorisation NTFS, la plus restrictive s'applique. Ainsi, les refus explicites à un utilisateur ou à un groupe remplacent même le contrôle total lors de la définition des droits d'accès.

Les autorisations NTFS sont contrôlées à partir des clients Windows SMB.

Autorisations de partage

Les autorisations de partage sont plus générales que les autorisations NTFS (lecture/modification/contrôle total uniquement) et contrôlent l'entrée initiale dans un partage SMB, de la même manière que fonctionnent les règles de stratégie d'exportation NFS.

Bien que les règles de stratégie d'exportation NFS contrôlent l'accès via des informations basées sur l'hôte telles que les adresses IP ou les noms d'hôte, les autorisations de partage SMB peuvent contrôler l'accès à l'aide des ACE d'utilisateur et de groupe dans une liste de contrôle d'accès de partage. Vous pouvez définir des listes de contrôle d'accès de partage à partir du client Windows ou de l'interface utilisateur de gestion de Google Cloud NetApp Volumes .

Par défaut, les listes de contrôle d'accès de partage et les listes de contrôle d'accès de volume initiales incluent Tout le monde avec un contrôle total. Les ACL des fichiers doivent être modifiées, mais les autorisations de partage sont remplacées par les autorisations de fichier sur les objets du partage.

Par exemple, si un utilisateur est uniquement autorisé à accéder en lecture à l'ACL du fichier de volume Google Cloud NetApp Volumes , l'accès à la création de fichiers et de dossiers lui est refusé, même si l'ACL de partage est définie sur Tout le monde avec un contrôle total, comme illustré dans la figure suivante.

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Pour de meilleurs résultats en matière de sécurité, procédez comme suit :

  • Supprimez tout le monde des listes de contrôle d'accès aux fichiers et aux partages et définissez plutôt l'accès au partage pour les utilisateurs ou les groupes.

  • Utilisez des groupes pour le contrôle d'accès au lieu d'utilisateurs individuels pour faciliter la gestion et accélérer la suppression/l'ajout d'utilisateurs afin de partager les ACL via la gestion de groupe.

  • Autorisez un accès de partage moins restrictif et plus général aux ACE sur les autorisations de partage et verrouillez l'accès aux utilisateurs et aux groupes avec des autorisations de fichier pour un contrôle d'accès plus granulaire.

  • Évitez l’utilisation générale des ACL de refus explicites, car elles remplacent les ACL d’autorisation. Limitez l’utilisation des listes de contrôle d’accès de refus explicites pour les utilisateurs ou les groupes qui doivent être rapidement restreints dans leur accès à un système de fichiers.

  • Assurez-vous de faire attention à la "Héritage ACL" paramètres lors de la modification des autorisations ; définir l'indicateur d'héritage au niveau supérieur d'un répertoire ou d'un volume avec un nombre élevé de fichiers signifie que chaque fichier sous ce répertoire ou volume a des autorisations héritées qui lui sont ajoutées, ce qui peut créer un comportement indésirable tel qu'un accès/refus involontaire et une longue période de modification des autorisations à mesure que chaque fichier est ajusté.

Fonctionnalités de sécurité du partage SMB

Lorsque vous créez pour la première fois un volume avec accès SMB dans Google Cloud NetApp Volumes, une série de choix vous sont proposés pour sécuriser ce volume.

Certains de ces choix dépendent du niveau de Google Cloud NetApp Volumes (Performances ou Logiciel) et les choix incluent :

  • Rendre le répertoire des instantanés visible (disponible pour NetApp Volumes-Performance et NetApp Volumes-SW). Cette option contrôle si les clients SMB peuvent ou non accéder au répertoire Snapshot dans un partage SMB(\\server\share\~snapshot et/ou onglet Versions précédentes). Le paramètre par défaut est Non coché, ce qui signifie que le volume est masqué par défaut et interdit l'accès au ~snapshot répertoire et aucune copie instantanée n'apparaît dans l'onglet Versions précédentes pour le volume.

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Masquer les copies Snapshot aux utilisateurs finaux peut être souhaité pour des raisons de sécurité, de performances (masquer ces dossiers des analyses AV) ou par préférence. Les instantanés Google Cloud NetApp Volumes sont en lecture seule. Ainsi, même si ces instantanés sont visibles, les utilisateurs finaux ne peuvent pas supprimer ou modifier les fichiers du répertoire Instantanés. Les autorisations de fichiers sur les fichiers ou dossiers au moment où la copie instantanée a été prise s'appliquent. Si les autorisations d'un fichier ou d'un dossier changent entre les copies Snapshot, les modifications s'appliquent également aux fichiers ou dossiers du répertoire Snapshot. Les utilisateurs et les groupes peuvent accéder à ces fichiers ou dossiers en fonction des autorisations. Bien que les suppressions ou modifications de fichiers dans le répertoire Snapshot ne soient pas possibles, il est possible de copier des fichiers ou des dossiers hors du répertoire Snapshot.

  • Activer le chiffrement SMB (disponible pour NetApp Volumes-Performance et NetApp Volumes-SW). Le cryptage SMB est désactivé sur le partage SMB par défaut (non coché). Cocher la case active le cryptage SMB, ce qui signifie que le trafic entre le client SMB et le serveur est crypté en vol avec les niveaux de cryptage les plus élevés pris en charge négociés. Google Cloud NetApp Volumes prend en charge le chiffrement jusqu'à AES-256 pour SMB. L'activation du chiffrement SMB entraîne une baisse des performances qui peut être perceptible ou non par vos clients SMB, de l'ordre de 10 à 20 %. NetApp encourage fortement les tests pour voir si cette baisse de performance est acceptable.

  • Masquer le partage SMB (disponible pour NetApp Volumes-Performance et NetApp Volumes-SW). La définition de cette option masque le chemin de partage SMB de la navigation normale. Cela signifie que les clients qui ne connaissent pas le chemin de partage ne peuvent pas voir les partages lorsqu'ils accèdent au chemin UNC par défaut (tel que \\NetApp Volumes-SMB ). Lorsque la case à cocher est sélectionnée, seuls les clients qui connaissent explicitement le chemin de partage SMB ou dont le chemin de partage est défini par un objet de stratégie de groupe peuvent y accéder (sécurité par obscurcissement).

  • Activer l'énumération basée sur l'accès (ABE) (NetApp Volumes-SW uniquement). Cela est similaire au masquage du partage SMB, sauf que les partages ou les fichiers sont uniquement masqués aux utilisateurs ou aux groupes qui n'ont pas les autorisations d'accéder aux objets. Par exemple, si l'utilisateur Windows joe n'est pas autorisé au moins l'accès en lecture via les autorisations, puis l'utilisateur Windows joe je ne peux pas voir le partage SMB ou les fichiers du tout. Cette option est désactivée par défaut et vous pouvez l'activer en cochant la case. Pour plus d'informations sur ABE, consultez l'article de la base de connaissances NetApp "Comment fonctionne l'énumération basée sur l'accès (ABE) ?"

  • Activer la prise en charge du partage disponible en continu (CA) (NetApp Volumes-Performance uniquement). "Partages PME disponibles en continu" fournir un moyen de minimiser les interruptions d'application lors des événements de basculement en répliquant les états de verrouillage sur les nœuds du système backend Google Cloud NetApp Volumes . Il ne s’agit pas d’une fonctionnalité de sécurité, mais elle offre une meilleure résilience globale. Actuellement, seules les applications SQL Server et FSLogix sont prises en charge pour cette fonctionnalité.

Partages cachés par défaut

Lorsqu'un serveur SMB est créé dans Google Cloud NetApp Volumes, il existe "partages administratifs cachés" (en utilisant la convention de nommage $) qui sont créés en plus du partage SMB du volume de données. Il s'agit notamment de C$ (accès à l'espace de noms) et d'IPC$ (partage de canaux nommés pour la communication entre les programmes, tels que les appels de procédure à distance (RPC) utilisés pour l'accès à la console de gestion Microsoft (MMC)).

Le partage IPC$ ne contient aucune ACL de partage et ne peut pas être modifié. Il est strictement utilisé pour les appels RPC et "Windows interdit par défaut l'accès anonyme à ces partages" .

Le partage C$ permet l'accès BUILTIN/Administrateurs par défaut, mais l'automatisation de Google Cloud NetApp Volumes supprime l'ACL de partage et n'autorise l'accès à personne, car l'accès au partage C$ permet une visibilité sur tous les volumes montés dans les systèmes de fichiers Google Cloud NetApp Volumes . En conséquence, les tentatives de navigation vers \\SERVER\C$ échouer.

Comptes avec droits d'administrateur/de sauvegarde locaux/INTÉGRÉS

Les serveurs SMB Google Cloud NetApp Volumes conservent des fonctionnalités similaires aux serveurs SMB Windows classiques dans la mesure où il existe des groupes locaux (tels que BUILTIN\Administrators) qui appliquent des droits d'accès pour sélectionner des utilisateurs et des groupes de domaine.

Lorsque vous spécifiez un utilisateur à ajouter aux utilisateurs de sauvegarde, l'utilisateur est ajouté au groupe BUILTIN\Backup Operators dans l'instance Google Cloud NetApp Volumes qui utilise cette connexion Active Directory, qui obtient ensuite le "SeBackupPrivilege et SeRestorePrivilege" .

Lorsque vous ajoutez un utilisateur aux utilisateurs avec privilèges de sécurité, l'utilisateur reçoit le SeSecurityPrivilege, ce qui est utile dans certains cas d'utilisation d'application, tels que "SQL Server sur les partages SMB" .

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Vous pouvez afficher les appartenances aux groupes locaux Google Cloud NetApp Volumes via la console MMC avec les privilèges appropriés. La figure suivante montre les utilisateurs qui ont été ajoutés à l’aide de la console Google Cloud NetApp Volumes .

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Le tableau suivant montre la liste des groupes BUILTIN par défaut et les utilisateurs/groupes ajoutés par défaut.

Groupe local/BUILTIN Membres par défaut

BUILTIN\Administrateurs*

DOMAINE\Administrateurs de domaine

Opérateurs de sauvegarde BUILTIN*

Aucune

BUILTIN\Invités

DOMAINE\Invités du domaine

Utilisateurs expérimentés intégrés

Aucune

Utilisateurs du domaine BUILTIN\Domain

DOMAINE\Utilisateurs du domaine

*L'appartenance au groupe est contrôlée dans la configuration de connexion Active Directory de Google Cloud NetApp Volumes .

Vous pouvez afficher les utilisateurs et les groupes locaux (et les membres du groupe) dans la fenêtre MMC, mais vous ne pouvez pas ajouter ou supprimer des objets ni modifier les appartenances aux groupes à partir de cette console. Par défaut, seuls le groupe Administrateurs de domaine et l'administrateur sont ajoutés au groupe BUILTIN\Administrators dans Google Cloud NetApp Volumes. Actuellement, vous ne pouvez pas modifier cela.

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Accès MMC/Gestion de l'ordinateur

L'accès SMB dans Google Cloud NetApp Volumes fournit une connectivité à la console MMC de gestion de l'ordinateur, qui vous permet d'afficher les partages, de gérer les listes de contrôle d'accès (ACL) de partage et d'afficher/gérer les sessions SMB et d'ouvrir des fichiers.

Pour utiliser la console MMC afin d'afficher les partages et sessions SMB dans Google Cloud NetApp Volumes, l'utilisateur actuellement connecté doit être un administrateur de domaine. D'autres utilisateurs sont autorisés à accéder à l'affichage ou à la gestion du serveur SMB à partir de MMC et reçoivent une boîte de dialogue Vous n'avez pas d'autorisations lorsqu'ils tentent d'afficher des partages ou des sessions sur l'instance SMB de Google Cloud NetApp Volumes .

Pour vous connecter au serveur SMB, ouvrez Gestion de l’ordinateur, cliquez avec le bouton droit sur Gestion de l’ordinateur, puis sélectionnez Se connecter à un autre ordinateur. Cela ouvre la boîte de dialogue Sélectionner un ordinateur dans laquelle vous pouvez saisir le nom du serveur SMB (trouvé dans les informations de volume Google Cloud NetApp Volumes ).

Lorsque vous affichez les partages SMB avec les autorisations appropriées, vous voyez tous les partages disponibles dans l'instance Google Cloud NetApp Volumes qui partagent la connexion Active Directory. Pour contrôler ce comportement, définissez l’option Masquer les partages SMB sur l’instance de volume Google Cloud NetApp Volumes .

N'oubliez pas qu'une seule connexion Active Directory est autorisée par région.

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Figure montrant une boîte de dialogue d'entrée/sortie ou représentant un contenu écrit

Le tableau suivant présente une liste des fonctionnalités prises en charge/non prises en charge pour la MMC.

Fonctions prises en charge Fonctions non prises en charge

  • Voir les actions

  • Afficher les sessions SMB actives

  • Afficher les fichiers ouverts

  • Afficher les utilisateurs et les groupes locaux

  • Afficher les adhésions aux groupes locaux

  • Énumérer la liste des sessions, des fichiers et des connexions arborescentes dans le système

  • Fermer les fichiers ouverts dans le système

  • Clôture des séances ouvertes

  • Créer/gérer des partages

  • Création de nouveaux utilisateurs/groupes locaux

  • Gestion/affichage des utilisateurs/groupes locaux existants

  • Afficher les événements ou les journaux de performances

  • Gestion du stockage

  • Gestion des services et des applications

Informations sur la sécurité du serveur SMB

Le serveur SMB dans Google Cloud NetApp Volumes utilise une série d'options qui définissent les politiques de sécurité pour les connexions SMB, notamment le décalage d'horloge Kerberos, l'âge du ticket, le chiffrement, etc.

Le tableau suivant contient une liste de ces options, leur fonction, les configurations par défaut et si elles peuvent être modifiées avec Google Cloud NetApp Volumes. Certaines options ne s'appliquent pas à Google Cloud NetApp Volumes.

Option de sécurité Ce qu'il fait Valeur par défaut Peut-on changer ?

Décalage maximal de l'horloge Kerberos (minutes)

Décalage horaire maximal entre les Google Cloud NetApp Volumes et les contrôleurs de domaine. Si le décalage horaire dépasse 5 minutes, l’authentification Kerberos échoue. Ceci est défini sur la valeur par défaut d'Active Directory.

5

Non

Durée de vie du ticket Kerberos (heures)

Durée maximale pendant laquelle un ticket Kerberos reste valide avant de nécessiter un renouvellement. Si aucun renouvellement n'intervient avant les 10 heures, vous devez obtenir un nouveau billet. Google Cloud NetApp Volumes effectue ces renouvellements automatiquement. 10 heures est la valeur par défaut d'Active Directory.

10

Non

Renouvellement maximal des tickets Kerberos (jours)

Nombre maximal de jours pendant lesquels un ticket Kerberos peut être renouvelé avant qu'une nouvelle demande d'autorisation ne soit nécessaire. Google Cloud NetApp Volumes renouvelle automatiquement les tickets pour les connexions SMB. Sept jours est la valeur par défaut d’Active Directory.

7

Non

Délai d'expiration de la connexion Kerberos KDC (sec)

Le nombre de secondes avant l'expiration d'une connexion KDC.

3

Non

Exiger une signature pour le trafic SMB entrant

Paramètre pour exiger la signature pour le trafic SMB. Si défini sur vrai, les clients qui ne prennent pas en charge la signature échouent à la connectivité.

FAUX

Exiger une complexité de mot de passe pour les comptes d'utilisateurs locaux

Utilisé pour les mots de passe des utilisateurs SMB locaux. Google Cloud NetApp Volumes ne prend pas en charge la création d'utilisateurs locaux. Cette option ne s'applique donc pas à Google Cloud NetApp Volumes.

Vrai

Non

Utiliser start_tls pour les connexions LDAP Active Directory

Utilisé pour activer le démarrage des connexions TLS pour Active Directory LDAP. Google Cloud NetApp Volumes ne prend actuellement pas en charge cette activation.

FAUX

Non

Le chiffrement AES-128 et AES-256 pour Kerberos est-il activé ?

Cela contrôle si le cryptage AES est utilisé pour les connexions Active Directory et est contrôlé avec l'option Activer le cryptage AES pour l'authentification Active Directory lors de la création/modification de la connexion Active Directory.

FAUX

Oui

Niveau de compatibilité LM

Niveau des dialectes d’authentification pris en charge pour les connexions Active Directory. Voir la section "Dialectes d'authentification SMB " pour plus d'informations.

ntlmv2-krb

Non

Exiger le cryptage SMB pour le trafic CIFS entrant

Nécessite un cryptage SMB pour tous les partages. Ceci n'est pas utilisé par Google Cloud NetApp Volumes; à la place, définissez le chiffrement sur une base par volume (voir la section «Fonctionnalités de sécurité du partage SMB ").

FAUX

Non

Sécurité des sessions client

Définit la signature et/ou le scellement pour la communication LDAP. Cette option n'est pas actuellement définie dans Google Cloud NetApp Volumes, mais elle pourrait être nécessaire dans les versions futures pour résoudre ce problème. La correction des problèmes d'authentification LDAP dus au correctif Windows est abordée dans la section"Liaison de canal LDAP." .

Aucune

Non

SMB2 activé pour les connexions CC

Utilise SMB2 pour les connexions CC. Activé par défaut.

Système par défaut

Non

Recherche de référence LDAP

Lors de l'utilisation de plusieurs serveurs LDAP, la recherche de référence permet au client de faire référence à d'autres serveurs LDAP de la liste lorsqu'une entrée n'est pas trouvée dans le premier serveur. Ceci n'est actuellement pas pris en charge par Google Cloud NetApp Volumes.

FAUX

Non

Utiliser LDAPS pour des connexions Active Directory sécurisées

Permet l'utilisation de LDAP sur SSL. Actuellement non pris en charge par Google Cloud NetApp Volumes.

FAUX

Non

Le cryptage est requis pour la connexion DC

Nécessite un cryptage pour des connexions DC réussies. Désactivé par défaut dans Google Cloud NetApp Volumes.

FAUX

Non