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

PME

Contributeurs
PDF

"PME" Est un protocole de partage de fichiers réseau développé par Microsoft qui fournit une authentification utilisateur/groupe centralisée, des autorisations, un verrouillage et un partage de fichiers à plusieurs clients SMB sur un réseau Ethernet. Les fichiers et les dossiers sont présentés aux clients par le biais de partages, qui peuvent être configurés avec diverses propriétés de partage et offre un contrôle d'accès par le biais d'autorisations de niveau partage. SMB peut être présenté à n'importe quel client prenant en charge 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 en utilisant les méthodes configurées par les administrateurs Google Cloud NetApp volumes.

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

  • Si les noms Windows et UNIX ne correspondent pas de la même manière, LDAP doit être configuré pour permettre aux volumes Google Cloud NetApp d'utiliser la configuration de mappage de noms LDAP (voir la section "“Utilisation du protocole LDAP pour le mappage de noms asymétrique”").

  • Si LDAP n'est pas utilisé, les utilisateurs SMB Windows correspondent à un utilisateur UNIX local par défaut nommé pcuser dans les volumes Google Cloud NetApp. Il s'agit de fichiers écrits dans Windows par les utilisateurs qui correspondent à la pcuser propriété UNIX visible comme pcuser dans les environnements NAS multiprotocoles. pcuser Voici l' `nobody`utilisateur dans les environnements Linux (UID 65534).

Dans les déploiements avec SMB uniquement, le pcuser Le mappage a toujours lieu, mais cela n'a aucune 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 d'utilisateurs avec les contrôleurs de domaine Active Directory. Ce qui nécessite un échange d'nom d'utilisateur/mot de passe avec les AD DCS, qui est externe à l'instance Google Cloud NetApp volumes. L'authentification Kerberos est utilisée lorsque le \\SERVERNAME chemin UNC est utilisé par les clients SMB et que ce qui suit est vrai :

  • L'entrée DNS A/AAAA existe pour NOM_SERVEUR

  • Un code SPN valide pour l'accès SMB/CIFS existe pour NOM DE SERVEUR

Lorsqu'un volume SMB Google Cloud NetApp volumes est créé, le nom du compte de machine est créé comme défini dans la section "« Comment Google Cloud NetApp volumes apparaît dans Active Directory. »" ce nom de compte de machine devient également le chemin d'accès au partage SMB, car les volumes Google Cloud NetApp utilisent le DNS dynamique (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 de compte de machine.

Remarque Pour que les entrées PTR soient créées, la zone de recherche inverse de 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, il s'agit des entrées SPN générées par les volumes Google Cloud NetApp :

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Il s'agit du résultat de recherche DNS avant/arrière :

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

Par ailleurs, un contrôle d'accès plus important 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 noeuds finaux, l'accès n'est pas autorisé.

Utilisation des alias de nom SMB

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

Si vous souhaitez créer des alias pour le chemin du partage SMB, vous pouvez exploiter ce qu'on appelle un enregistrement CNAME dans DNS. Par exemple, si vous souhaitez utiliser le nom \\CIFS pour accéder aux partages 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 la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Il s'agit du résultat de la recherche de transfert DNS 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

Il s'agit de la requête SPN qui s'affiche après l'ajout de nouveaux SPN :

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Dans une capture de paquets, nous pouvons voir la demande de configuration de session en utilisant le SPN associé au CNAME.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Dialectes d'authentification SMB

Google Cloud NetApp volumes prend en charge les fonctionnalités suivantes "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 pouvez utiliser. Avec le cryptage AES et SMB activé, le niveau de sécurité est encore amélioré.

Les volumes Google Cloud NetApp prennent également en charge la rétrocompatibilité pour les authentifications 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). Comme ces mécanismes sont moins sécurisés, ils sont désactivés dans certains environnements Active Directory. Si les méthodes d'authentification les plus faibles sont désactivées et que Kerberos n'est pas configuré correctement, l'accès au partage échoue car il n'existe pas de méthode d'authentification valide pour revenir à.

Pour plus d'informations sur la configuration/l'affichage des niveaux d'authentification pris en charge dans Active Directory, reportez-vous à la section "Sécurité du réseau : niveau d'authentification de LAN Manager".

Modèles d'autorisation

Autorisations NTFS/File

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

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

  • Contrôle total

  • Modifier

  • Lecture et exécution

  • Lecture

  • Écriture

Lorsque vous définissez les autorisations d'un utilisateur ou d'un groupe, appelées ACE, elles résident dans une liste de contrôle d'accès. Les autorisations NTFS utilisent les mêmes principes de base en 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 prendre propriété, Créer des dossiers/ajouter des données, écrire des attributs, etc.

Les bits standard du mode UNIX ne fournissent pas le même niveau de granularité que les autorisations NTFS (par exemple, la possibilité de définir des autorisations pour des objets individuels utilisateur et groupe dans une ACL ou la définition d'attributs étendus). Cependant, les listes de contrôle d'accès NFSv4.1 offrent les mêmes fonctionnalités que les listes de contrôle d'accès 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 d'un utilisateur ou d'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 de clients SMB Windows.

Partager les autorisations

Les autorisations de partage sont plus générales que les autorisations NTFS (lecture/modification/contrôle total uniquement) et contrôlez l'entrée initiale dans un partage SMB, à l'instar des règles de règles d'export NFS.

Bien que les règles d'export NFS contrôlent l'accès via des informations basées sur l'hôte telles que des adresses IP ou des noms d'hôte, les autorisations de partage SMB peuvent contrôler l'accès à l'aide d'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 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 tous les utilisateurs ayant un contrôle total. Les listes de contrôle d’accès du fichier doivent être modifiées, mais les autorisations de partage sont surdéfinies par les autorisations de fichier sur les objets du partage.

Par exemple, si un utilisateur n'a accès qu'en lecture à la liste de contrôle d'accès du fichier du volume Google Cloud NetApp volumes, il lui est impossible de créer des fichiers et des dossiers, même si la liste de contrôle d'accès du partage est définie sur tous les utilisateurs ayant le contrôle total, comme illustré dans la figure ci-dessous.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Pour obtenir les 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 de partage et de fichiers et définissez plutôt l'accès de partage pour les utilisateurs ou les groupes.

  • Pour faciliter la gestion des utilisateurs individuels, vous pouvez utiliser des groupes pour le contrôle d'accès, et pour accélérer la suppression et l'ajout d'utilisateurs pour partager ces listes via la gestion de groupes.

  • Autorisez un accès plus général et moins restrictif au partage aux ACE depuis 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 listes de contrôle d'accès de refus explicites, car elles remplacent les listes de contrôle d'accès d'autorisation. Limiter l'utilisation des listes de contrôle d'accès de refus explicites pour les utilisateurs ou les groupes qui doivent être restreints rapidement d'un accès à un système de fichiers.

  • Assurez-vous d'accorder votre attention au "Héritage ACL" paramètres lors de la modification des autorisations ; la définition de 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 possède des autorisations héritées ajoutées à celui-ci, ce qui peut créer un comportement indésirable tel qu'un accès/un refus involontaire et une longue perte de modification des autorisations au fur et à mesure que chaque fichier est ajusté.

Fonctionnalités de sécurité de partage SMB

Lorsque vous créez pour la première fois un volume avec accès SMB dans Google Cloud NetApp volumes, vous disposez d'une série d'options pour sécuriser ce volume.

Certaines de ces options dépendent du niveau Google Cloud NetApp volumes (performances ou logiciel). Vous avez le choix entre :

  • Rendre le répertoire de snapshots visible (disponible à la fois pour NetApp volumes-Performance et NetApp volumes-SW). Cette option contrôle si les clients SMB peuvent accéder au répertoire Snapshot dans un partage SMB et/ou dans (\\server\share\~snapshot`l'onglet versions précédentes). Le paramètre par défaut n'est pas coché, ce qui signifie que le volume est par défaut masqué et interdit l'accès au `~snapshot répertoire, et qu'aucune copie Snapshot n'apparaît dans l'onglet versions précédentes du volume.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Le masquage des copies Snapshot à partir des utilisateurs finaux peut être souhaité pour des raisons de sécurité, de performances (masquage de ces dossiers à partir d'analyses antivirus) ou de préférence. Les copies Snapshot des volumes Google Cloud NetApp sont en lecture seule. Ainsi, même si ces copies sont visibles, les utilisateurs ne peuvent pas supprimer ou modifier les fichiers du répertoire Snapshot. Autorisations liées aux fichiers ou dossiers au moment de la copie Snapshot. 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. Lorsque des suppressions ou des modifications de fichiers dans le répertoire Snapshot ne sont pas possibles, il est possible de copier des fichiers ou des dossiers à partir du répertoire Snapshot.

  • Activez le chiffrement SMB (disponible à la fois pour NetApp volumes-Performance et NetApp volumes-SW). Par défaut, le chiffrement SMB est désactivé sur le partage SMB (désactivé). La case active le chiffrement SMB, ce qui signifie que le trafic entre le client SMB et le serveur est crypté à la volée avec les niveaux de cryptage les plus élevés pris en charge négociés. Google Cloud NetApp volumes prend en charge le chiffrement AES-256 pour SMB. L'activation du cryptage SMB a des retombées sur les performances de vos clients SMB, c'est-à-dire dans une plage de 10 à 20 %. NetApp encourage fortement les tests à vérifier si les performances sont acceptables.

  • Masquer le partage SMB (disponible à la fois pour NetApp volumes-Performance et NetApp volumes-SW). La définition de cette option masque le chemin du 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 lors de l'accès au chemin UNC par défaut (tel que \\NetApp Volumes-SMB ). Lorsque la case est cochée, seuls les clients qui connaissent explicitement le chemin du partage SMB ou qui ont le chemin du partage défini par un objet de stratégie de groupe peuvent y accéder (sécurité via obfuscation).

  • Activer l'énumération basée sur l'accès (ABE) (NetApp volumes-SW uniquement). Ceci est similaire au masquage du partage SMB, sauf que les partages ou les fichiers ne sont masqués que par des utilisateurs ou des groupes qui n'ont pas les autorisations d'accès aux objets. Par exemple, si l'utilisateur Windows joe n'est pas autorisé au moins à accéder en lecture via les autorisations, l'utilisateur Windows joe ne peut pas voir le partage SMB ou les fichiers. 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 des partages CA (disponibilité continue) (NetApp volumes-Performance uniquement). "Partages SMB disponibles en permanence" 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 back-end 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 masqués par défaut

Lors de la création d'un serveur SMB dans Google Cloud NetApp volumes, plusieurs "partages administratifs masqués" instances (utilisant la convention de dénomination $) sont créées en plus du partage SMB du volume de données. Il s'agit notamment de C$ (accès à l'espace de noms) et IPC$ (partage de canaux nommés pour la communication entre les programmes, tels que les appels de procédure distante (RPC) utilisés pour l'accès à la console MMC (Microsoft Management Console)).

Le partage IPC$ ne contient pas de listes de contrôle d’accès partagées et ne peut pas être modifié – il est strictement utilisé pour les appels RPC et "Windows interdit l'accès anonyme à ces partages par défaut".

Le partage C$ autorise l'accès BUILTIN/Administrators par défaut, mais l'automatisation Google Cloud NetApp volumes supprime la liste de contrôle d'accès partagée et ne permet pas l'accès à quiconque, car l'accès au partage C$ permet de voir tous les volumes montés dans les systèmes de fichiers Google Cloud NetApp volumes. Par conséquent, les tentatives de navigation \\SERVER\C$ échouent.

Comptes avec droits d'administrateur/de sauvegarde local/BUILTIN

Les serveurs SMB Google Cloud NetApp volumes offrent des fonctionnalités similaires aux serveurs SMB Windows classiques, car des groupes locaux (tels que BUILTIN\Administrators) appliquent des droits d'accès à certains utilisateurs et groupes de domaine.

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

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

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Vous pouvez afficher les appartenances aux groupes locaux de Google Cloud NetApp volumes via la console MMC avec le Privileges approprié. La figure suivante montre les utilisateurs qui ont été ajoutés à l'aide de la console Google Cloud NetApp volumes.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

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

Groupe local/BUILTIN Membres par défaut

INTÉGRÉ\administrateurs*

Administrateurs DE DOMAINE

INTÉGRÉ\opérateurs de sauvegarde*

Aucune

INTÉGRÉ\clients

Invités DOMAINE/domaine

UTILISATEURS INTENSIFS ET INTÉGRÉS

Aucune

Utilisateurs DE DOMAINE/INTÉGRÉ

Utilisateurs DU DOMAINE

*Contrôle d'appartenance à un groupe dans la configuration de la connexion Google Cloud NetApp volumes Active Directory.

Vous pouvez afficher des utilisateurs et des groupes locaux (et des membres de groupe) dans la fenêtre MMC, mais vous ne pouvez pas ajouter ou supprimer des objets ou modifier les appartenances de groupe à 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 le modifier.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Accès MMC/gestion de l'ordinateur

L'accès SMB dans Google Cloud NetApp volumes fournit la connectivité à la console MMC de gestion d'ordinateurs, qui permet de visualiser les partages, de gérer les ACL de partage, de voir/gérer les sessions SMB et les fichiers ouverts.

Pour afficher les partages SMB et les sessions dans Google Cloud NetApp volumes à l'aide de MMC, l'utilisateur connecté doit être un administrateur de domaine. Les autres utilisateurs sont autorisés à afficher ou à gérer le serveur SMB à partir de MMC et à recevoir une boîte de dialogue vous n'avez pas d'autorisations lorsque vous essayez 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 de la souris sur gestion de l'ordinateur, puis sélectionnez connexion à un autre ordinateur. La boîte de dialogue Sélectionner un ordinateur s'ouvre, dans laquelle vous pouvez saisir le nom du serveur SMB (disponible dans les informations sur le volume Google Cloud NetApp volumes).

Lorsque vous affichez les partages SMB disposant des 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 la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

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

Fonctions prises en charge Fonctions non prises en charge

  • Afficher les partages

  • Afficher les sessions SMB actives

  • Afficher les fichiers ouverts

  • Affichez les utilisateurs et groupes locaux

  • Afficher les membres du groupe local

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

  • Fermez les fichiers ouverts dans le système

  • Fermer les sessions ouvertes

  • Création/gestion de partages

  • Création de nouveaux utilisateurs/groupes locaux

  • Gestion/affichage des utilisateurs/groupes locaux existants

  • Affichez les journaux d'événements ou de performances

  • La gestion du stockage

  • Gestion des services et des applications

Informations sur la sécurité du serveur SMB

Le serveur SMB de Google Cloud NetApp volumes utilise une série d'options qui définissent les règles de sécurité pour les connexions SMB, notamment l'inclinaison de l'horloge Kerberos, l'ancienneté du ticket, le chiffrement et bien plus encore.

Le tableau suivant contient une liste de ces options, leurs fonctions, les configurations par défaut et s'il est possible de les modifier 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 Est-il possible de modifier ?

Hauteur maximale de l'horloge Kerberos (minutes)

Décalage maximal entre Google Cloud NetApp volumes et les contrôleurs de domaine. Si l'écart de temps dépasse 5 minutes, l'authentification Kerberos échoue. Cette valeur est définie sur la valeur par défaut d'Active Directory.

5

Non

Durée de vie d'un ticket Kerberos (en heures)

Durée maximale pendant laquelle un ticket Kerberos reste valide avant d'exiger un renouvellement. Si aucun renouvellement n'a lieu 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 de ticket Kerberos (jours)

Nombre maximum 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 des connexions SMB. Sept jours est la valeur par défaut d'Active Directory.

7

Non

Expiration du délai de connexion KDC Kerberos (secondes)

Nombre de secondes avant qu'une connexion KDC ne se soit interrompue.

3

Non

Signature requise pour le trafic SMB entrant

Paramètre pour exiger la signature pour le trafic SMB. Si la valeur est true, les clients qui ne prennent pas en charge la connexion échouent.

Faux

Exiger la complexité du mot de passe pour les comptes d'utilisateur 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

Utilisez START_tls pour les connexions LDAP Active Directory

Utilisé pour activer les connexions TLS de démarrage pour Active Directory LDAP. Google Cloud NetApp volumes ne prend pas encore en charge cette activation.

Faux

Non

Est compatible avec le chiffrement AES-128 et AES-256 pour Kerberos

Cette option permet de contrôler si le chiffrement AES est utilisé pour les connexions Active Directory et est contrôlé à l'aide de l'option Activer le chiffrement AES pour l'authentification Active Directory lors de la création/modification de la connexion Active Directory.

Faux

Oui.

Niveau de compatibilité LM

Niveau de 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

Cryptage SMB requis pour le trafic CIFS entrant

Chiffrement SMB requis pour tous les partages. Ceci n'est pas utilisé par Google Cloud NetApp volumes ; définissez plutôt le chiffrement par volume (voir la section « »).Fonctionnalités de sécurité de partage SMB

Faux

Non

Sécurité de la session client

Définit la signature et/ou le chiffrement pour la communication LDAP. Ce n'est pas encore configuré dans Google Cloud NetApp volumes, mais cette fonctionnalité peut être utilisée dans les futures versions. La résolution des problèmes d'authentification LDAP dus au correctif Windows est traité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

Poursuite des recommandations LDAP

Lors de l'utilisation de plusieurs serveurs LDAP, la recherche de références permet au client de se référer à d'autres serveurs LDAP de la liste lorsqu'une entrée est introuvable dans le premier serveur. Ce n'est pas pris en charge par Google Cloud NetApp volumes pour le moment.

Faux

Non

Utilisez LDAPS pour les connexions Active Directory sécurisées

Permet l'utilisation de LDAP sur SSL. Google Cloud NetApp volumes n'est actuellement pas pris en charge.

Faux

Non

Le cryptage est requis pour la connexion CC

Nécessite un chiffrement pour des connexions CC réussies. Désactivé par défaut dans Google Cloud NetApp volumes.

Faux

Non