Résoudre les problèmes liés à l’authentification Active Directory pour SQL Server sur Linux et les conteneurs

S’applique à :SQL Server sur Linux

Cet article aide à résoudre les problèmes d’authentification services de domaine Active Directory 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 le dépannage, validez l’utilisateur actuel, mssql.confle nom du principal de service (SPN) et les paramètres du domaine.

  1. Obtenez ou renouvelez le Kerberos TGT (ticket d’attribution de billets) avec kinit:

    kinit privilegeduser@CONTOSO.COM
    
  2. Exécutez la commande suivante, et assurez-vous que l’utilisateur qui l’exécute a accès à :mssql.keytab

    /opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytab
    

    Pour plus d’informations sur la validate-ad-config commande, exécutez /opt/mssql/bin/mssql-conf validate-ad-config --help.

Recherches DNS et DNS inversé

  1. 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.com
    

    Si 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.

  2. Effectuez une recherche DNS inversée (rDNS) pour chaque adresse IP à partir des résultats précédents. Incluez les adresses IPv4 et IPv6 lorsque cela est pertinent.

    nslookup <IPs returned from the above commands>
    

    Toutes doivent renvoyer <hostname>.contoso.com. Sinon, vérifiez les enregistrements PTR (pointeur) dans Active Directory.

    Vous devrez peut-être collaborer avec votre administrateur de domaine pour faire fonctionner le rDNS. Si vous ne pouvez pas ajouter d'entrées PTR pour toutes les adresses IP retournées, vous pouvez aussi limiter SQL Server à un sous-ensemble de contrôleurs de domaine. Cette modification affecte les autres services qui utilisent krb5.conf sur 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

  1. Vérifiez que vous avez créé le fichier keytab (table de clés), et que vous avez configuré mssql-conf pour utiliser le bon fichier avec les permissions 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.

  2. 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 SPN et des entrées keytab, vous rencontrez des erreurs lorsque vous essayez de vous connecter avec l'authentification Active Directory.

    klist -kte /var/opt/mssql/secrets/mssql.keytab
    

    Voici un exemple de fichier keytab opérationnel. L’exemple utilise deux types de chiffrement, mais vous pouvez n’en utiliser qu’un seul ou plusieurs en fonction des types de chiffrement pris en charge dans votre environnement. Dans l’exemple, sqluser@CONTOSO.COM est le compte privilégié (qui correspond au paramètre network.privilegedadaccount dans mssql-conf), et le nom d’hôte de SQL Server est sqllinux.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 /var/opt/mssql/secrets/mssql.keytab
    
    Keytab name: FILE:/var/opt/mssql/secrets/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

  1. 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 »). Examinez le fichier exemple krb5.conf suivant. Pour plus d’informations, consultez Fonctionnement de l’authentification Active Directory pour SQL Server sur Linux et les conteneurs.

    [libdefaults]
    default_realm = CONTOSO.COM
    default_keytab_name = /var/opt/mssql/secrets/mssql.keytab
    default_ccache_name = ""
    
    [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.COM
    
  2. Vous 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 une liste de contrôleurs de domaine que SQL Server contacte de manière à la fois en round-robin lors d’une recherche dans un protocole d’accès à répertoires légers (LDAP).

    Complétez ces deux étapes. D’abord, modifiez krb5.conf en ajoutant les contrôleurs de domaine dont vous avez besoin, précédés de kdc =.

    [realms]
    CONTOSO.COM = {
      kdc = kdc1.contoso.com
      kdc = kdc2.contoso.com
      ..
      ..
    }
    

    Le krb5.conf fichier est un fichier de configuration client Kerberos courant, donc toute modification que vous apportez à ce fichier affecte d’autres services en plus de SQL Server. Avant d’effectuer toute modification, consultez votre administrateur de domaine.

    Activez le network.enablekdcfromkrb5conf paramètre avec mssql-conf, puis redémarrez 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

Les détails suivants vous aident à résoudre les problèmes d’authentification Active Directory et à identifier les messages d’erreur spécifiques.

Trace Kerberos

Après avoir créé l’utilisateur, les SPN, les keytabs, et configuré, mssql-confvérifiez la configuration d’Active Directory.

Pour vérifier la configuration de SQL Server sur Linux, utilisez le compte privilégié pour obtenir ou renouveler le TGT Kerberos. Exécutez cette commande pour afficher les messages de trace Kerberos dans la console (stdout) :

root@sqllinux mssql# KRB5_TRACE=/dev/stdout kinit -kt /var/opt/mssql/secrets/mssql.keytab sqluser

S’il n’y a aucun problème, vous devriez obtenir un résultat semblable à l’exemple suivant. Sinon, la trace fournit un 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

Activer Kerberos et la journalisation PAL basée sur la sécurité

Pour identifier les messages d’erreur spécifiques dans le PAL (Platform Abstraction Layer), activez security.kerberos et security.ldap enregistrez. Créez un logger.ini fichier avec le contenu suivant à /var/opt/mssql/, puis redémarrez SQL Server pour capturer toute erreur d’initialisation. Reproduisez l’erreur. Le PAL enregistre les erreurs d’Active Directory et envoie les messages de débogage 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

SQL Server détecte les modifications logger.ini du journal sans redémarrage, mais les pannes lors de l’initialisation du service Active Directory au démarrage de SQL Server passent autrement inaperçues. Redémarrer SQL Server capture tous les messages d’erreur.

Le journal de sécurité continue à écrire sur le lecteur jusqu’à ce que vous supprimiez les modifications dans logger.ini. Désactivez et security.ldap enregistrez security.kerberos une fois que vous avez identifié et résolu le problème, pour éviter de manquer d’espace sur le disque.

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 activez la journalisation PAL et reproduisez le problème, cherchez le premier message avec un niveau de journal de Error. Utilisez le tableau suivant pour trouver l’erreur et suivez les recommandations et recommandations pour dépanner et résoudre le problème.

Messages d'erreur courants

Message d’erreur : « Échec de la connexion. La connexion provient d’un domaine non fiable et ne peut pas être utilisée avec l’authentification intégrée. »

Cause potentielle

Vous rencontrez cette erreur lorsque vous essayez de vous connecter avec un compte Active Directory après avoir configuré l’authentification Active Directory.

Conseils

Ce message d’erreur générique vous oblige à activer la journalisation PAL pour identifier l’erreur spécifique.

Consultez la liste suivante des erreurs courantes pour identifier la cause possible de chaque erreur, puis suivez les conseils de dépannage pour résoudre le problème.

Messages d’erreur
Utilisateur ou groupe Windows NT « CONTOSO\user » introuvable
Impossible de rechercher un nom de domaine court en raison d’une erreur
Impossible d’effectuer la recherche rDNS pour l’hôte <nom_hôte> en raison d’une erreur
Nom de domaine complet non renvoyé par la recherche rDNS
Échec de la liaison au serveur LDAP
Entrée introuvable dans la table des clés
Aucune entrée dans la table des clés n’est introuvable pour <principal>
Ticket de requête serveur <principal> introuvable dans le fichier keytab (numéro de version de la clé du ticket : <KVNO>)
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
Ticket de requête serveur <principal> (numéro de version de la clé : <KVNO>, <type de chiffrement> enctype) trouvé dans le fichier keytab, mais impossible de déchiffrer le ticket

Message d’erreur : Utilisateur ou groupe Windows NT « CONTOSO\user » introuvable

Cause potentielle

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 consignes « É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) » et activer la journalisation PAL pour identifier l’erreur spécifique et dépanner en conséquence.

Message d’erreur : « Impossible de rechercher le nom de domaine court en raison d’une erreur »

Cause potentielle

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, mais le FQDN du domaine (contoso.com) doit être fourni en arrière-plan lors de l’exécution d’une connexion LDAP. 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.

Conseils

Le message d’erreur « Impossible de chercher un nom de domaine court en raison d’une erreur » suggère que nslookup for contoso ne se résout pas à l’adresse IP du contrôleur de domaine. Examinez les recherches DNS et inversées DNS pour confirmer que nslookup cela correspond à la fois au NetBIOS et au nom de domaine.

Messages d’erreur : « Impossible d’effectuer la recherche rDNS pour l’hôte <hostname> en raison d’une erreur » ou « Nom de domaine complet non renvoyé par la recherche rDNS »

Cause potentielle

Ces messages d’erreur indiquent généralement que les enregistrements DNS inversés (enregistrements PTR) n’existent pas pour tous les contrôleurs de domaine.

Conseils

Vérifiez les recherches DNS et DNS inverses. Après avoir identifié les contrôleurs de domaine qui n’ont pas d’entrées rDNS, vous avez deux options :

  • Ajouter des entrées rDNS pour tous les contrôleurs de domaine :

    Ce paramètre n'est pas un réglage SQL Server, et vous devez le configurer au niveau du domaine. Vous devrez peut-être travailler avec votre équipe d’administration de domaine pour créer les enregistrements PTR requis pour tous les contrôleurs de domaine qui nslookup retournent le nom de domaine.

  • Restreindre SQL Server à un sous-ensemble de contrôleurs de domaine

    Si vous ne pouvez pas ajouter d'enregistrements PTR pour tous les contrôleurs de domaine retourné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 potentielle

Cette erreur générique provenant d’OpenLDAP présente généralement deux significations possibles :

  • Aucun identifiant
  • Problèmes de rDNS

Voici un exemple de message d’erreur :

12/09/2021 14:32:11.319933684 Error [security.ldap] <0000000142/0x000001c0> Failed to bind to LDAP server ldap://[CONTOSO.COM:3268]: Local error

Conseils

  • Absence d’informations d’identification

    D’autres messages d’erreur apparaissent en premier si les identifiants ne se chargent pas pour les connexions LDAP. Activez la journalisation PAL et vérifiez le journal d’erreur pour les messages d’erreur avant 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. Si vous trouvez une erreur, corrigez-la avant de passer à autre chose. Dans la plupart des cas, c’est l’un des messages d’erreur couverts par cet article.

  • Problèmes rDNS

    Vérifiez les recherches DNS et DNS inverses.

    Lorsque la bibliothèque OpenLDAP se connecte à un contrôleur de domaine, elle fournit soit le nom de domaine entièrement qualifié (FQDN), qui dans cet exemple est contoso.com, soit le FQDN du DC (kdc1.contoso.com). Après avoir établi la connexion (mais avant de retourner le succès à l’appelant), la bibliothèque OpenLDAP vérifie l’adresse IP du serveur auquel elle s’est connectée. Il effectue ensuite une recherche DNS inversée et vérifie que le nom du serveur auquel il est connecté (kdc1.contoso.com) correspond au domaine demandé (contoso.com). Si ce n’est pas le cas, la bibliothèque OpenLDAP rejette la connexion comme mesure de sécurité. Ce décalage explique en partie pourquoi les paramètres rDNS sont importants pour SQL Server sur Linux, et sont au cœur de cet article.

Message d’erreur : « Entrée de la table de clés introuvable »

Cause potentielle

Cette erreur indique des problèmes d’accès avec le fichier keytab ou des entrées manquantes dans le keytab.

Conseils

Vérifiez que le fichier keytab dispose du niveau d’accès et des autorisations nécessaires. L’emplacement et le nom par défaut du fichier keytab sont /var/opt/mssql/secrets/mssql.keytab. Pour voir les permissions actuelles sur tous les fichiers du dossier secrets, exécutez cette commande :

sudo ls -lrt /var/opt/mssql/secrets

Utilisez ces commandes pour définir les permissions 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 vous ne remplissez aucune des conditions de cette section, vous voyez cette erreur ou une erreur équivalente : "Key table entry not found".

Message d’erreur : « Aucune entrée dans la table des clés n’a été trouvée pour <principal> »

Cause potentielle

Lorsque vous essayez de récupérer les identifiants <principal> depuis l’onglet clavier, vous ne trouvez aucune entrée applicable.

Conseils

Pour afficher toutes les entrées du fichier keytab, suivez la section Vérification du fichier keytab et des autorisations de cet article. Assurez-vous que <principal> est présent. Dans ce cas, le compte principal est généralement celui network.privilegedadaccount où vous enregistrez les SPN. Si ce n’est pas le cas, ajoutez-le avec la adutil commande. 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 potentielle

Cette erreur indique que SQL Server ne trouve pas d'entrée keytab pour le ticket demandé avec le Key Version Number (KVNO) spécifié.

Conseils

Pour afficher toutes les entrées du fichier keytab, suivez la section Vérification du fichier keytab et des autorisations de cet article. Si vous ne trouvez pas de message d’erreur correspondant à <principal> et KVNO, mettez à jour le fichier keytab pour ajouter cette entrée, en suivant les étapes de cette section.

Vous pouvez également exécuter la commande suivante pour obtenir le KVNO le plus récent depuis le contrôleur de domaine. Avant d’exécuter cette commande, obtenez ou renouvelez le TGT Kerberos avec cette kinit commande. 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 potentielle

Cette erreur signifie que l'onglet de clé de SQL Server ne contient pas le type de chiffrement que le client demande.

Conseils

Pour valider, suivez la section Vérifier le fichier keytab et les permissions de cet article pour lister toutes les entrées dans l’onglet clé. Si vous ne trouvez pas de message d’erreur correspondant au principe, au KVNO et au type de chiffrement, mettez à jour le fichier keytab pour ajouter cette entrée, en suivant les étapes de cette section.

Message d’erreur : « Ticket de requête serveur <principal> (numéro de version de la clé : <KVNO>, <type de chiffrement> enctype) trouvé dans le fichier keytab, mais impossible de déchiffrer le ticket »

Cause potentielle

Ce message d'erreur indique que SQL Server ne peut pas utiliser une identifiante du fichier keytab pour déchiffrer la demande d'authentification entrante. Un mot de passe incorrect provoque souvent cette erreur.

Conseils

Recréez l’onglet des touches avec le bon mot de passe. Si vous utilisez adutil, créez l’onglet de clés avec le bon mot de passe et suivez les étapes du tutoriel : Utilisez adutil pour configurer l’authentification Active Directory avec SQL Server sur Linux.

Ports courants

Ce tableau présente les ports courants utilisés par SQL Server sur Linux pour configurer et administrer l’authentification Active Directory.

service d’annuaire Active Directory Port
DNS 53
LDAP 389
LDAPS 636
Kerberos 88