Résoudre les problèmes liés à l’authentification Active Directory pour SQL Server sur Linux et les conteneurs
S’applique à :
SQL Server - Linux
Cet article aide à résoudre les problèmes d’authentification Active Directory Domain Services avec SQL Server sur Linux et des conteneurs. Il comprend des vérifications de la configuration requise et des conseils pour une configuration Active Directory réussie, ainsi qu’une liste des erreurs courantes et des procédures de dépannage.
Validation de la configuration actuelle
Avant de commencer la résolution des problèmes, vous devez valider les paramètres de l’utilisateur actuel, mssql.conf, du nom du principal du service (SPN) et du domaine.
Obtenez ou renouvelez le ticket TGT (Ticket-Granting Ticket) Kerberos à l’aide de
kinit:kinit privilegeduser@CONTOSO.COMExécutez la commande suivante, en veillant à le faire en tant qu’utilisateur ayant accès à
mssql.keytab:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytabPour plus d’informations sur la commande
validate-ad-config, consultez l’aide grâce à la commande/opt/mssql/bin/mssql-conf validate-ad-config --help.
Recherches DNS et DNS inversé
Les recherches DNS sur le nom de domaine et le nom NetBIOS doivent renvoyer la même adresse IP, qui correspond généralement à l’adresse IP du contrôleur de domaine. Exécutez ces commandes à partir de la machine hôte SQL Server.
nslookup contoso nslookup contoso.comSi les adresses IP ne correspondent pas, consultez Jonction de SQL Server sur un hôte Linux à un domaine Active Directory pour corriger les recherches DNS et la communication avec le contrôleur de domaine.
Effectuez une recherche DNS inversé (rDNS) pour chacune des adresses IP indiquées dans les résultats précédents. Cela comprend les adresses IPv4 et IPv6, le cas échéant.
nslookup <IPs returned from the above commands>Toutes doivent renvoyer
<hostname>.contoso.com. Si ce n’est pas le cas, vérifiez les enregistrements PTR (pointeur) créés dans Active Directory.Vous devrez peut-être vous rapprocher de votre administrateur de domaine pour que la recherche rDNS fonctionne. Si vous ne pouvez pas ajouter d’entrées PTR pour toutes les adresses IP renvoyées, vous pouvez également limiter SQL Server à un sous-ensemble de contrôleurs de domaine. Cette modification affecte les autres services qui utilisent
krb5.confsur l’hôte.Pour plus d’informations sur les DNS inversés, consultez Présentation des DNS inversés.
Vérification du fichier keytab et des autorisations
Vérifiez que vous avez créé le fichier keytab (« key table », « table de clés ») et que mssql-conf est configuré pour utiliser le bon fichier avec les autorisations appropriées. Le fichier keytab doit être accessible au compte d’utilisateur
mssql. Pour plus d’informations, consultez Configuration de l’authentification Active Directory avec SQL Server sur Linux à l’aide de la commande adutil.Vérifiez que vous pouvez afficher le contenu du fichier keytab et que les noms SPN, le port, le type de chiffrement et le compte d’utilisateur que vous avez ajoutés sont justes. Si vous ne tapez pas correctement les mots de passe lors de la création des noms SPN et des entrées keytab, vous rencontrerez des erreurs lorsque vous tenterez de vous connecter en utilisant l’authentification Active Directory.
klist -kte /var/opt/mssql/secrets/mssql.keytabVoici un exemple de fichier keytab opérationnel. qui emploie deux types de chiffrement. Vous ne pouvez en utiliser un ou plusieurs selon ce qui est pris en charge dans votre environnement.
sqluser@CONTOSO.COMreprésente le compte privilégié (qui correspond au paramètre network.privilegedadaccount de mssql-conf). Le nom d’hôte de SQL Server estsqllinux.contoso.com, à l’écoute sur le port par défaut, 1433.$ kinit privilegeduser@CONTOSO.COM Password for privilegeduser@CONTOSO.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: privilegeduser@CONTOSO.COM Valid starting Expires Service principal 01/26/22 20:42:02 01/27/22 06:42:02 krbtgt/CONTOSO.COM@CONTOSO.COM renew until 01/27/22 20:41:57 $ klist -kte mssql.keytab Keytab name: FILE:mssql.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes128-cts-hmac-sha1-96)
Validation des informations de domaine dans krb5.conf
Dans
krb5.conf(situé à l’adresse/etc/krb5.conf), vérifiez que vous avez indiqué la valeur du domaine par défaut, des informations de domaine et du mappage de domaine (« domain ») à domaine (« realm »). Voici un exemple de fichierkrb5.conf. Pour plus d’informations, consultez Fonctionnement de l’authentification Active Directory pour SQL Server sur Linux et les conteneurs.[libdefaults] default_realm = CONTOSO.COM [realms] CONTOSO.COM = { kdc = adVM.contoso.com admin_server = adVM.contoso.com default_domain= contoso.com } [domain_realm] .contoso.com = CONTOSO.COM contoso.com = CONTOSO.COMVous pouvez limiter SQL Server de sorte qu’il contacte un sous-ensemble de contrôleurs de domaine. Cette solution est utile si votre configuration DNS renvoie plus de contrôleurs de domaine que SQL Server n’a besoin d’en contacter. SQL Server sur Linux vous permet de spécifier la liste des contrôleurs de domaine que SQL Server contacte en mode tourniquet (round robin) lors de l’exécution d’une recherche LDAP.
Vous devez pour cela suivre deux étapes. Tout d’abord, modifiez
krb5.confen ajoutant le nombre de contrôleurs de domaine dont vous avez besoin, avec le préfixekdc =.[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }Gardez à l’esprit que
krb5.confest un fichier de configuration de client Kerberos courant. Toutes les modifications apportées à ce fichier impacteront d’autres services en plus de SQL Server. Consultez votre administrateur de domaine avant d’effectuer un changement.Vous pouvez ensuite activer le paramètre network.enablekdcfromkrb5conf en utilisant mssql-conf, puis redémarrer SQL Server :
sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Résoudre les problèmes liés à Kerberos
Aidez-vous des informations suivantes pour résoudre les problèmes d’authentification Active Directory et identifier des messages d’erreur spécifiques.
Trace Kerberos
Après avoir créé l’utilisateur, les noms SPN et les fichiers keytab, et paramétré mssql-conf de sorte que la configuration Active Directory pour SQL Server sur Linux soit correcte, vous pouvez afficher les messages de trace Kerberos dans la console (stdout) lorsque vous tentez d’obtenir ou de renouveler le ticket TGT Kerberos avec le compte privilégié, à l’aide de la commande suivante :
root@sqllinux mssql# KRB5_TRACE=/dev/stdout kinit -kt /var/opt/mssql/secrets/mssql.keytab sqluser
En l’absence de problèmes, la sortie se présente comme suit. Si ce n’est pas le cas, la trace donne du contexte sur les étapes à examiner.
3791545 1640722276.100275: Getting initial credentials for sqluser@CONTOSO.COM
3791545 1640722276.100276: Looked up etypes in keytab: aes256-cts, aes128-cts
3791545 1640722276.100278: Sending unauthenticated request
3791545 1640722276.100279: Sending request (202 bytes) to CONTOSO.COM
3791545 1640722276.100280: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100281: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100282: Received answer (185 bytes) from stream 10.0.0.4:88
3791545 1640722276.100283: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100284: Response was from master KDC
3791545 1640722276.100285: Received error from KDC: -1765328359/Additional pre-authentication required
3791545 1640722276.100288: Preauthenticating using KDC method data
3791545 1640722276.100289: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
3791545 1640722276.100290: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100291: Retrieving sqluser@CONTOSO.COM from /var/opt/mssql/secrets/mssql.keytab (vno 0, enctype aes256-cts) with result: 0/Success
3791545 1640722276.100292: AS key obtained for encrypted timestamp: aes256-cts/E84B
3791545 1640722276.100294: Encrypted timestamp (for 1640722276.700930): plain 301AA011180F32303231313XXXXXXXXXXXXXXXXXXXXXXXXXXXXX, encrypted 333109B95898D1B4FC1837DAE3E4CBD33AF8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
3791545 1640722276.100295: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
3791545 1640722276.100296: Produced preauth for next request: PA-ENC-TIMESTAMP (2)
3791545 1640722276.100297: Sending request (282 bytes) to CONTOSO.COM
3791545 1640722276.100298: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100299: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100300: Received answer (1604 bytes) from stream 10.0.0.4:88
3791545 1640722276.100301: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100302: Response was from master KDC
3791545 1640722276.100303: Processing preauth types: PA-ETYPE-INFO2 (19)
3791545 1640722276.100304: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100305: Produced preauth for next request: (empty)
3791545 1640722276.100306: AS key determined by preauth: aes256-cts/E84B
3791545 1640722276.100307: Decrypted AS reply; session key is: aes256-cts/05C0
3791545 1640722276.100308: FAST negotiation: unavailable
3791545 1640722276.100309: Initializing KCM:0:37337 with default princ sqluser@CONTOSO.COM
3791545 1640722276.100310: Storing sqluser@CONTOSO.COM -> krbtgt/CONTOSO.COM@CONTOSO.COM in KCM:0:37337
3791545 1640722276.100311: Storing config in KCM:0:37337 for krbtgt/CONTOSO.COM@CONTOSO.COM: pa_type: 2
3791545 1640722276.100312: Storing sqluser@CONTOSO.COM -> krb5_ccache_conf_data/pa_type/krbtgt/CONTOSO.COM@CONTOSO.COM@X-CACHECONF: in KCM:0:37337
$ sudo klist
Ticket cache: KCM:0:37337
Default principal: sqluser@CONTOSO.COM
Valid starting Expires Service principal
12/28/2021 20:11:16 12/29/2021 06:11:16 krbtgt/CONTOSO.COM@CONTOSO.COM
renew until 01/04/2022 20:11:16
Activation de Kerberos et de la journalisation PAL pour la sécurité
Vous pouvez activer la journalisation security.kerberos et security.ldap pour identifier des messages d’erreur spécifiques dans la couche PAL (Platform Abstraction Layer). Créez un fichier logger.ini comprenant le contenu suivant à l’adresse /var/opt/mssql/, redémarrez SQL Server, puis reproduisez la défaillance. Les messages d’erreur et de débogage Active Directory de la couche PAL sont consignés dans /var/opt/mssql/log/security.log.
[Output:security]
Type = File
Filename = /var/opt/mssql/log/security.log
[Logger]
Level = Silent
[Logger:security.kerberos]
Level = Debug
Outputs = security
[Logger:security.ldap]
Level = debug
Outputs = security
Il n’est pas nécessaire de redémarrer SQL Server pour que les modifications de l’enregistreur d’événements soient récupérées à partir de logger.ini. Cependant, des échecs peuvent se produire pendant l’initialisation du service Active Directory au démarrage de SQL Server qui, sinon, passeraient inaperçus. Le redémarrage de SQL Server garantit que tous les messages d’erreur sont capturés.
Le journal de sécurité continue à écrire sur le lecteur jusqu’à ce que vous supprimiez les modifications dans logger.ini. N’oubliez pas de désactiver la journalisation security.kerberos et security.ldap une fois que vous avez identifié et résolu le problème afin d’éviter de manquer d’espace sur le lecteur.
L’enregistreur d’événements PAL génère des fichiers journaux au format suivant :
<DATETIME> <Log level> [<logger>] <<process/thread identifier>> <message>
Voici un exemple de ligne du journal :
12/28/2021 13:56:31.609453055 Error [security.kerberos] <0003753757/0x00000324> Request ticket server MSSQLSvc/sql.contoso.com:1433@CONTOSO.COM kvno 3 enctype aes256-cts found in keytab but cannot decrypt ticket
Une fois que vous avez activé la journalisation PAL et reproduit le problème, recherchez le premier message présentant le niveau de journalisation Error. Ensuite, aidez-vous du tableau suivant pour trouver l’erreur et suivez les instructions et recommandations pour résoudre le problème.
Messages d’erreur courants
Message d’erreur : « Échec de la connexion. La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec l’authentification intégrée. »
Cause possible
Cette erreur se produit lorsque vous essayez de vous connecter avec un compte Active Directory, une fois que vous avez configuré l’authentification Active Directory.
Instructions
Il s’agit d’un message d’erreur générique. Vous devez activer la journalisation PAL pour identifier le message d’erreur spécifique.
Consultez cette liste d’erreurs courantes pour identifier la cause possible de chaque erreur, puis suivez les instructions de dépannage pour résoudre le problème.
Message d’erreur : Utilisateur ou groupe Windows NT « CONTOSO\user » introuvable
Cause possible
Vous pouvez rencontrer cette erreur lorsque vous tentez de créer la connexion Windows ou lors de l’actualisation du groupe.
Conseils
Pour valider le problème, suivez les instructions décrites dans la section « Échec de la connexion. La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec l’authentification intégrée. » (Microsoft SQL Server, erreur : 18452). Activez la journalisation PAL pour identifier l’erreur spécifique et résolvez les problèmes en conséquence.
Message d’erreur : « Impossible de rechercher le nom de domaine court en raison d’une erreur »
Cause possible
La syntaxe Transact-SQL à utiliser pour créer une connexion Active Directory est la suivante :
CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
Le nom NetBIOS (CONTOSO) est requis dans la commande. Dans le serveur principal cependant, lors de l’exécution d’une connexion LDAP, le nom de domaine complet du domaine (contoso.com) doit être fourni. Pour effectuer cette conversion, une recherche DNS est effectuée sur CONTOSO afin de le résoudre en adresse IP d’un contrôleur de domaine, qui peut ensuite faire l’objet d’une liaison pour les requêtes LDAP.
Instructions
Le message d’erreur « Impossible de rechercher un nom de domaine court en raison d’une erreur » indique que nslookup pour contoso ne peut pas être résolu en adresse IP du contrôleur de domaine. Examinez les recherches DNS et DNS inversé afin de vérifier que nslookup correspond pour le nom NetBIOS et le nom de domaine.
Messages d’erreur : « Impossible d’effectuer une recherche rDNS pour l’hôte <nom_hôte> en raison d’une erreur » et « Nom de domaine complet non renvoyé par la recherche rDNS »
Cause possible
Ce message d’erreur indique principalement que les enregistrements DNS inversés (enregistrements PTR) n’existent pas pour tous les contrôleurs de domaine.
Instructions
Consultez Recherches DNS et DNS inversé. Une fois les contrôleurs de domaine dépourvus d’entrées rDNS identifiés, deux options s’offrent à vous :
Ajouter des entrées rDNS pour tous les contrôleurs de domaine :
Il ne s’agit pas d’un paramètre SQL Server. Cette solution doit être configurée au niveau du domaine. Vous devrez peut-être vous rapprocher de votre équipe d’administration de domaine pour créer les enregistrements PTR requis pour tous les contrôleurs de domaine renvoyés lors de l’exécution de
nslookupsur le nom de domaine.Restreindre SQL Server à un sous-ensemble de contrôleurs de domaine
Si l’ajout d’enregistrements PTR n’est pas possible pour tous les contrôleurs de domaine renvoyés, vous pouvez limiter SQL Server à un sous-ensemble de contrôleurs de domaine.
Message d’erreur : « Échec de la liaison au serveur LDAP ldap://CONTOSO.COM:3268: Local Error »
Cause possible
Il s’agit d’une erreur générique provenant d’OpenLDAP. Toutefois, elle présente généralement deux significations possibles :
- Ne pas demander les informations d'identification
- Problèmes rDNS
Voici un exemple de message d’erreur de ce type :
12/09/2021 14:32:11.319933684 Error [security.ldap] <0000000142/0x000001c0> Failed to bind to LDAP server ldap://[CONTOSO.COM:3268]: Local error
Instructions
Absence d’informations d’identification
D’autres messages d’erreur sont générés en premier si les informations d’identification ne se chargent pas pour les connexions LDAP. Activez la journalisation PAL et recherchez dans le journal des erreurs des messages d’erreur précédant celui-ci. En l’absence d’autres erreurs, il est très probable qu’il ne s’agisse pas d’une erreur d’informations d’identification. S’il existe un message d'erreur, essayez de le corriger. Dans la plupart des cas, il s’agit de l’un de ceux qui sont traités dans cet article.
Problèmes rDNS
Consultez Recherches DNS et DNS inversé.
Lorsque la bibliothèque OpenLDAP se connecte à un contrôleur de domaine, le nom de domaine complet du domaine (
contoso.com) ou celui du contrôleur de domaine (kdc1.contoso.com) est indiqué. Une fois la connexion établie (mais avant de renvoyer un message de réussite à l’appelant), la bibliothèque OpenLDAP vérifie l’adresse IP du serveur auquel elle est connectée. Elle effectue ensuite une recherche DNS inversé et contrôle que le nom du serveur avec lequel la connexion est établie (kdc1.contoso.com) correspond au domaine pour lequel la connexion a été demandée (contoso.com). Dans le cas contraire, elle fait échouer la connexion par mesure de sécurité. Cela fait partie de la raison pour laquelle les paramètres rDNS sont si importants pour SQL Server sur Linux et se trouvent au centre de cette documentation.
Message d’erreur : « Entrée de la table de clés introuvable »
Cause possible
Cette erreur indique des problèmes d’accès au fichier keytab, ou l’absence de certaines entrées requises dans ce fichier.
Instructions
Vérifiez que le fichier keytab dispose du niveau d’accès et des autorisations nécessaires. L’emplacement par défaut et le nom du fichier keytab sont /var/opt/mssql/secrets/mssql.keytab. Pour afficher les autorisations actuelles sur tous les fichiers figurant dans le dossier secrets, exécutez la commande suivante :
sudo ls -lrt /var/opt/mssql/secrets
Utilisez les commandes suivantes pour définir les autorisations et le niveau d’accès sur le fichier keytab :
sudo chown mssql /var/opt/mssql/secrets/mssql.keytab
sudo chmod 440 /var/opt/mssql/secrets/mssql.keytab
Pour plus d’informations sur l’affichage des entrées keytab et la définition des autorisations appropriées, consultez la section Vérification du fichier keytab et des autorisations ci-dessus. Si l’une des conditions de cette section n’est pas remplie, l’erreur "Key table entry not found" ou une erreur équivalente apparaît.
Message d’erreur : « Aucune entrée de table de clés trouvée pour le <principal> »
Cause possible
Lors de la tentative de récupération des informations d’identification de <principal> à partir du fichier keytab, aucune entrée applicable n’a été trouvée.
Instructions
Suivez la section Vérification du fichier keytab et des autorisations de ce document pour afficher toutes les entrées du fichier keytab. Assurez-vous que <principal> est présent. Dans le cas présent, le compte principal correspond généralement au compte network.privilegedadaccount auquel les noms SPN sont inscrits. Si ce n’est pas le cas, ajoutez-le à l’aide de la commande adutil. Pour plus d’informations, consultez Configuration de l’authentification Active Directory avec SQL Server sur Linux à l’aide de la commande adutil.
Message d’erreur : « Ticket de requête serveur <principal> introuvable dans le fichier keytab (numéro de version de la clé du ticket : <KVNO>) »
Cause possible
Cette erreur indique que SQL Server n’a pas trouvé d’entrée keytab pour le ticket demandé avec le KVNO (numéro de version de la clé) spécifié.
Instructions
Suivez la section Vérification du fichier keytab et des autorisations de ce document pour afficher toutes les entrées du fichier keytab. Si vous ne trouvez pas de message d’erreur correspondant à <principal> et au numéro de version de la clé, ajoutez cette entrée. Pour cela, mettez à jour le fichier keytab suivant la procédure indiquée dans cette section.
Vous pouvez également exécuter la commande suivante pour récupérer les derniers numéros de version de la clé auprès du contrôleur de domaine. Avant d’exécuter cette commande, vous devez obtenir ou renouveler le ticket TGT Kerberos à l’aide de la commande kinit. Pour plus d’informations, consultez Création d’un utilisateur Active Directory pour SQL Server et définition du nom de principal du service (SPN) à l’aide de la commande adutil.
kvno MSSQLSvc/<hostname>
Message d’erreur : « Ticket de requête serveur <principal> (numéro de version de la clé : <KVNO>) trouvé dans le fichier keytab, mais pas avec le <type de chiffrement> enctype »
Cause possible
Cette erreur signifie que le type de chiffrement demandé par le client n’était pas présent dans le fichier keytab de SQL Server.
Instructions
Pour procéder à la validation, suivez la section Vérification du fichier keytab et des autorisations de ce document afin d’afficher toutes les entrées du fichier keytab. Si vous ne trouvez pas de message d’erreur correspondant au principal, au numéro de version de la clé et au type de chiffrement, ajoutez cette entrée. Pour cela, mettez à jour le fichier keytab suivant la procédure indiquée dans cette section.
Message d’erreur : « <principal> du serveur de ticket de la demande (numéro de version de la clé : <KVNO>, type de chiffrement : <type de chiffrement>) trouvé dans le fichier keytab, mais impossible de déchiffrer le ticket »
Cause possible
Cette erreur indique que SQL Server n’a pas pu utiliser les informations d’identification du fichier keytab pour déchiffrer la requête d’authentification entrante. Elle est souvent liée à un mot de passe incorrect.
Instructions
Recréez le fichier keytab à l’aide du bon mot de passe. Si vous utilisez adutil, suivez pour cela la procédure indiquée dans Configuration de l’authentification Active Directory avec SQL Server sur Linux à l’aide de la commande adutil.
Ports courants
Ce tableau indique les ports couramment utilisés par SQL Server sur Linux pour configurer et administrer l’authentification Active Directory.
| Service Active Directory | Port |
|---|---|
| DNS | 53 |
| LDAP | 389 |
| LDAPS | 636 |
| Kerberos | 88 |
Contenu associé
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour