Utilisation de Microsoft Entra ID avec le pilote ODBC

Télécharger le pilote ODBC

Remarque

Bien que Microsoft Entra ID soit le nouveau nom d’Azure Active Directory (Azure AD) pour empêcher l’interruption des environnements existants, Azure AD reste toujours dans certains éléments codés en dur, tels que les champs d’interface utilisateur, les fournisseurs de connexions, les codes d’erreur et cmdlets. Dans cet article, les deux noms sont interchangeables.

Objectif

La version 13.1 de Microsoft ODBC Driver for SQL Server et les versions ultérieures permettent aux applications ODBC de se connecter à une base de données Azure SQL ou à une Azure SQL Managed Instance à l’aide d’identités dans Microsoft Entra ID. L’authentification peut être effectuée avec un nom d’utilisateur et un mot de passe, un jeton d’accès Microsoft Entra, une identité managée Microsoft Entra (17.3+) ou une authentification Windows intégrée dans un environnement fédéré joint à un domaine (17.6+ sur Linux/macOS). Pour la version 13.1 du pilote ODBC, l’authentification par jeton d’accès Microsoft Entra est Windows uniquement. La version 17 et les versions ultérieures du pilote ODBC prennent en charge cette authentification sur toutes les plateformes (Windows, Linux et macOS). Une nouvelle méthode d’authentification interactive Microsoft Entra, qui prend en charge l’authentification multifacteur, est introduite dans la version 17.1 du pilote ODBC pour Windows. Une nouvelle méthode d'authentification des identités managées par Microsoft Entra a été ajoutée dans la version 17.3.1.1 du pilote ODBC pour les identités attribuées au système et à l'utilisateur. Toutes ces options sont accomplies en utilisant de nouveaux mots clés de chaîne de connexion et de DSN, ainsi que des attributs de connexion.

Pour utiliser l’authentification Microsoft Entra, vous devez configurer votre source de données Azure SQL. Pour plus d’informations, consultez Configurer et gérer l’authentification Microsoft Entra avec Azure SQL.

Remarque

Le pilote ODBC sur Linux et macOS avant la version 17.6 prend uniquement en charge l’authentification Microsoft Entra directement par rapport à Microsoft Entra ID. Si vous utilisez l’authentification Microsoft Entra par nom d’utilisateur / mot de passe à partir d’un client Linux ou macOS et que votre configuration Microsoft Entra exige l’authentification du client auprès d’un point de terminaison Microsoft Entra Federation Services, l’authentification risque d’échouer. À compter de la version du pilote 17.6, cette limitation a été supprimée.

Mots clés de DSN et de chaîne de connexion nouveaux et/ou modifiés.

Le mot-clé Authentication peut être utilisé pour se connecter avec un DSN ou une chaîne de connexion afin de contrôler le mode d'authentification. La valeur définie dans la chaîne de connexion remplace celle du DSN, si elle est fournie. La valeur préattribut du paramètre Authentication est la valeur calculée à partir des valeurs de chaîne de connexion et de nom de source de données.

Nom	Valeurs/Valeur par défaut	Description
Authentication	(not set)(par défaut), (empty string), , SqlPasswordActiveDirectoryIntegrated, ActiveDirectoryInteractiveActiveDirectoryMsi, ActiveDirectoryServicePrincipal, ActiveDirectoryPassword [DÉCONSEILLÉ]	Contrôle le mode d’authentification. (not set) - Mode d’authentification déterminé par d’autres mots clés (options de connexion héritées existantes.) (empty string) - (Chaîne de connexion uniquement.) Remplacez et supprimez une valeur Authentication définie dans le DSN. SqlPassword - S’authentifier directement auprès de SQL à l’aide d’un nom d’utilisateur et d’un mot de passe. ActiveDirectoryIntegrated - Windows et Linux/Mac 17.6+, pilote uniquement. S'authentifier avec des identifiants Windows fédérés via Microsoft Entra ID avec l'authentification intégrée. ActiveDirectoryInteractive - Pilote Windows uniquement. Authentification avec une identité Microsoft Entra à l’aide de l’authentification interactive. ActiveDirectoryMsi - S’authentifier auprès d’une identité managée Microsoft Entra. Pour une identité attribuée par l'utilisateur, définissez UID comme étant l'ID client de l'identité pour Azure App Service ou Azure Container Instance ; sinon, utilisez son ID d'objet. Pour l'identité affectée par le système, l'UID n'est pas obligatoire. ActiveDirectoryServicePrincipal - (17.7+) Authentifiez-vous auprès d’un principal de service Microsoft Entra. UID est défini sur l’ID client du principal de service. PWD est défini sur le secret client. ActiveDirectoryPassword - [DÉCONSEILLÉ] S’authentifier auprès d’une identité Microsoft Entra à l’aide d’un nom d’utilisateur et d’un mot de passe. ActiveDirectoryPassword est déconseillé. Pour plus d’informations, voir ActiveDirectoryPassword est déconseillé.
Encrypt	(not set)(par défaut), Yes/Mandatory (versions 18.0 et ultérieures),OptionalNo/(versions 18.0 et ultérieures), Strict (versions 18.0 et ultérieures)	Contrôle le chiffrement pour une connexion. Lorsque vous ne définissez pas explicitement le chiffrement, le pilote 17 se met par défaut sur Yes si la valeur pré-attribut de Authentication n’est pas none ou SQL_COPT_SS_ACCESS_TOKEN est définie ; sinon, la valeur par défaut est No. Dans le pilote 18.0.1 et les versions ultérieures, la valeur par défaut est Yes (Mandatory). L’authentification et le chiffrement restent des paramètres distincts. Si SQL_COPT_SS_AUTHENTICATION remplace la valeur de pré-attribut de Authentication, définissez explicitement le chiffrement dans le DSN, la chaîne de connexion ou l’attribut de connexion SQL_COPT_SS_ENCRYPT.

Nouveaux attributs de connexion et attributs modifiés

Les attributs de connexion préconnexion suivants ont été introduits ou modifiés de façon à prendre en charge l’authentification Microsoft Entra. Lorsqu’un attribut de connexion présente un mot clé de chaîne de connexion ou de nom de source de données correspondant et qu’il est défini, il est prioritaire.

Attribut	Type	Valeurs	Par défaut	Description
SQL_COPT_SS_AUTHENTICATION	SQL_IS_INTEGER	SQL_AU_NONE, SQL_AU_PASSWORD, SQL_AU_AD_INTEGRATED, SQL_AU_AD_PASSWORD, SQL_AU_AD_INTERACTIVE, SQL_AU_AD_MSI, SQL_AU_AD_SPA, SQL_AU_RESET	(non défini)	Voir la description du mot clé Authentication ci-dessus. SQL_AU_NONE est fourni pour remplacer explicitement une valeur Authentication définie dans le nom de source de données ou la chaîne de connexion, tandis que SQL_AU_RESET annule l’attribut si celui-ci a été défini, ce qui donne la priorité à la valeur de la chaîne de connexion ou du nom de source de données.
SQL_COPT_SS_ACCESS_TOKEN	SQL_IS_POINTER	Pointeur vers ACCESSTOKEN ou NULL	NULL	Si la valeur est non Null, spécifie le jeton d’accès Microsoft Entra à utiliser. C’est une erreur de spécifier un jeton d’accès ainsi que les mots clés de chaîne de connexion UID, PWD, Trusted_Connection ou Authentication, ou leurs attributs équivalents. REMARQUE : La version 13.1 du pilote ODBC prend en charge ce paramètre seulement sur Windows.
SQL_COPT_SS_ENCRYPT	SQL_IS_INTEGER	SQL_EN_OFF, SQL_EN_ON	(voir description)	Contrôle la demande de chiffrement du client. SQL_EN_OFF Cela n’empêche pas le serveur de nécessiter un chiffrement. Dans le pilote 17, si vous ne définissez pas explicitement le chiffrement et que la valeur de pré-attribut de Authentication n'est pas none ou que SQL_COPT_SS_ACCESS_TOKEN est définie, le défaut est SQL_EN_ON. Sinon, le pilote 17 est défini par défaut sur SQL_EN_OFF. Dans Driver 18.0.1 et versions ultérieures, la valeur par défaut est SQL_EN_ON indépendamment de l’authentification lorsque vous ne définissez pas explicitement le chiffrement. Si SQL_COPT_SS_AUTHENTICATION remplace la valeur de pré-attribut de Authentication, définissez explicitement le chiffrement dans le DSN, la chaîne de connexion, ou cet attribut. Pour le comportement de chiffrement et de validation de certificats, voir Exemples de chaînes de connexion.
SQL_COPT_SS_OLDPWD	-	-	-	Non pris en charge avec Microsoft Entra ID, car les modifications de mot de passe apportées aux principaux Microsoft Entra ne peuvent pas être effectuées via une connexion ODBC. L’expiration du mot de passe pour l’authentification SQL Server a été introduite dans SQL Server 2005. L’attribut SQL_COPT_SS_OLDPWD a été ajouté pour permettre au client de fournir à la fois l’ancien mot de passe et le nouveau dans le cadre de la connexion. Quand cette propriété est définie, le fournisseur ne va pas utiliser pas le pool de connexions pour la première connexion ou pour les connexions futures , car la chaîne de connexion contient l’« ancien mot de passe », qui a maintenant changé.
SQL_COPT_SS_INTEGRATED_SECURITY	SQL_IS_INTEGER	SQL_IS_OFF,SQL_IS_ON	SQL_IS_OFF	Obsolète ; utilisez SQL_COPT_SS_AUTHENTICATION défini sur SQL_AU_AD_INTEGRATED à la place. Force l’utilisation de l’authentification Windows (Kerberos sur Linux et macOS) pour la validation de l’accès lors de la connexion au serveur. Lorsque l’authentification Windows est utilisée, le pilote ignore les valeurs d’identificateur d’utilisateur et de mot de passe fournies dans le cadre du traitement SQLConnect, SQLDriverConnect ou SQLBrowseConnect.

Le ActiveDirectoryPassword est obsolète

Important

L’option d’authentification ActiveDirectoryPassword (authentification par mot de passe avec l’ID Microsoft Entra) est déconseillée dans les pilotes Microsoft SQL. Ce flux d’authentification à haut risque est incompatible avec l’authentification multifacteur obligatoire Microsoft Entra (MFA) et peut ne pas fonctionner dans les locataires où l’authentification multifacteur est appliquée. Prévoyez de migrer vers une autre méthode d’authentification Microsoft Entra.

L’authentification par mot de passe avec l’ID Microsoft Entra est basée sur l’octroi des informations d’identification de mot de passe du propriétaire des ressources OAuth 2.0, qui permet à une application de connecter l’utilisateur en gérant directement son mot de passe.

Microsoft recommande de ne pas utiliser le flux ROPC, car il n'est pas compatible avec l'authentification multifacteur. Dans la plupart des scénarios, des alternatives plus sécurisées sont disponibles et recommandées. Ce flux nécessite un degré élevé de confiance dans l’application et comporte des risques qui ne sont pas présents dans d’autres flux. Utilisez ce flux uniquement lorsque les flux plus sécurisés ne sont pas viables. Microsoft s’éloigne de ce flux d’authentification à haut risque pour protéger les utilisateurs contre les attaques malveillantes. Pour plus d’informations, consultez Planification de l’authentification multifacteur obligatoire pour Azure.

Lorsqu’un utilisateur est présent lors de la connexion, utilisez l’authentification ActiveDirectoryInteractive ou ActiveDirectoryIntegrated afin que les attributs de piste d’audit de l’utilisateur connecté et des stratégies d’accès conditionnel s’appliquent.

Pour les scénarios de service à service non supervisés, suivez les recommandations relatives aux comptes de service Microsoft Entra :

• Si votre application s’exécute sur Azure infrastructure, utilisez ActiveDirectoryMSI (ou ActiveDirectoryManagedIdentity dans certains pilotes). Les identités managées éliminent la surcharge liée à la maintenance et à la rotation des secrets et des certificats.
• Si l'identité managée n'est pas disponible (par exemple, l'application s'exécute en dehors de Azure), utilisez ActiveDirectoryServicePrincipal. Pour les emplacements pris en charge par le pilote, préférez un certificat client plutôt qu’un secret client. Avec un certificat, la clé privée reste sur le client et seule une assertion signée est envoyée à Microsoft Entra pour authentifier le client. Si la clé est stockée sur un support matériel (tel qu’un TPM ou un HSM) ou marquée comme non exportable, elle ne peut pas être extraite sous forme de chaîne, comme on peut le faire avec un secret client.
• N'utilisez pas de compte d'utilisateur Microsoft Entra en tant que compte de service.

Ajouts d’interface utilisateur pour Microsoft Entra ID (pilote Windows uniquement)

Les interfaces utilisateur de configuration du nom de source de données et de connexion du pilote ont été améliorées en intégrant les options supplémentaires nécessaires pour s’authentifier avec Microsoft Entra ID.

Créer et modifier les DSN dans l’interface utilisateur

Vous pouvez utiliser les nouvelles options d’authentification Microsoft Entra quand vous créez ou modifiez un nom de source de données existant à l’aide de l’interface utilisateur de configuration du pilote :

Authentication=ActiveDirectoryIntegrated pour l’authentification intégrée avec Microsoft Entra sur Azure SQL

Authentication=ActiveDirectoryPassword pour l’authentification par nom d’utilisateur / mot de passe avec Microsoft Entra sur Azure SQL

Remarque

ActiveDirectoryPassword est déconseillé. Pour plus d’informations, voir ActiveDirectoryPassword est déconseillé.

Authentication=ActiveDirectoryInteractive pour l’authentification interactive avec Microsoft Entra sur Azure SQL

Remarque

À partir de la version 17.9 du pilote, le comportement de l’authentification interactive a changé. Les utilisateurs sont toujours invités à saisir leurs informations d’identification, sauf si le pilote dispose d’un jeton d’accès valide en cache. Cette modification empêche les utilisateurs sur les appareils Microsoft Entra joints d’ignorer l’invite et de se connecter automatiquement à l’aide des informations d’identification en cache en cas d’utilisation de l’authentification ActiveDirectoryInteractive.

Authentication=SqlPassword pour l’authentification par nom d’utilisateur / mot de passe sur SQL Server et Azure SQL

Trusted_Connection=Yes pour l’authentification intégrée de l’interface SSPI (Security Support Provider Interface) Windows héritée

Authentication=ActiveDirectoryMsi pour l’authentification par identité managée avec Microsoft Entra

Authentication=ActiveDirectoryServicePrincipal pour l’authentification du principal de service Microsoft Entra ID

Les six options correspondent respectivement à Trusted_Connection=Yes (authentification intégrée Windows SSPI héritée uniquement) et à Authentication=ActiveDirectoryIntegrated, SqlPassword, ActiveDirectoryPassword, ActiveDirectoryInteractive, ActiveDirectoryMsi et ActiveDirectoryServicePrincipal.

Fenêtre SQLDriverConnect (pilote Windows uniquement)

La boîte de dialogue d’invite affichée par SQLDriverConnect lorsqu’il demande les informations nécessaires pour établir la connexion contient quatre nouvelles options pour l’authentification avec Microsoft Entra :

Ces options correspondent aux six options disponibles dans l'interface utilisateur de configuration DSN.

Exemples de chaîne de connexion

Remarque

Les descriptions de chiffrement et de validation des certificats dans ces exemples s’appliquent aux connexions distantes ordinaires sans DSN ou dérogations d’attributs de connexion, aux paramètres du Registre Windows Force Protocol Encryption, ou aux rappels internes de validation des certificats Windows. Ils décrivent l’absence de chiffrementStrict. Le chiffrement limité à la connexion protège l’échange d’authentification, et non les données d’application ultérieures.

Avec TrustServerCertificate=no et Encrypt=yes (par défaut), les pilotes 17 et 18 demandent le chiffrement de la session complète et valident le certificat serveur. Si le client définit Encrypt=no mais que le serveur nécessite un chiffrement de session complète, le pilote 17 ne sélectionne pas la validation normale du certificat pour cette requête côté serveur uniquement. Le pilote 18 vérifie l’état de chiffrement négocié pour l’ensemble de la session et valide le certificat sauf TrustServerCertificate=yes. Dans le chemin ordinaire non-Strict, TrustServerCertificate=yes supprime la validation normale ; le chiffrement forcé par le registre Windows peut sélectionner la validation indépendamment de ce paramètre, et un callback interne de Windows peut remplacer le chemin de validation normal.

1. Authentification SQL Server : ancienne syntaxe. Le certificat de serveur n’est pas validé et le chiffrement est utilisé seulement s’il est appliqué par le serveur. Le nom d’utilisateur/mot de passe est transmis dans la chaîne de connexion.

   server=Server;database=Database;UID=UserName;PWD=<password>;Encrypt=no;TrustServerCertificate=yes;

2. Authentification SQL : nouvelle syntaxe. En utilisant Authentication=SqlPassword et en omettant le chiffrement comme indiqué, les pilotes 17 et 18 demandent par défaut un chiffrement de session complète. Le pilote valide le certificat du serveur avec le TrustServerCertificate=no par défaut. Le nom d’utilisateur et le mot de passe sont dans la chaîne de connexion.

   server=Server;database=Database;UID=UserName;PWD=<password>;Authentication=SqlPassword;

3. Authentification Windows intégrée (Kerberos sur Linux et macOS) avec SSPI (vers SQL Server ou SQL IaaS) : syntaxe actuelle. Avec Encrypt=no, le chiffrement de session complet n’est utilisé que si le serveur l’exige. Pour cette requête côté serveur uniquement, le pilote 17 ne sélectionne pas la validation normale du certificat ; le pilote 18 valide avec le TrustServerCertificate=no par défaut.

   server=Server;database=Database;Trusted_Connection=yes;Encrypt=no;

4. (Pilote Windows uniquement.) Authentification intégrée de Windows avec SSPI (si la base de données cible se trouve dans SQL Server ou SQL Serveur sur les ordinateurs virtuels Azure) : nouvelle syntaxe. En utilisant Authentication=ActiveDirectoryIntegrated et en omettant le chiffrement comme indiqué, les pilotes 17 et 18 demandent par défaut un chiffrement de session complète. Le pilote valide le certificat serveur avec le TrustServerCertificate=no par défaut.

   server=Server;database=Database;Authentication=ActiveDirectoryIntegrated;

5. Authentification par nom d’utilisateur et mot de passe Microsoft Entra (si la base de données cible se trouve dans Azure SQL Database ou Azure SQL Managed Instance). La demande explicite Encrypt=yes requiert un chiffrement de session complet. Le pilote valide le certificat serveur avec le TrustServerCertificate=no par défaut. Le nom d’utilisateur et le mot de passe sont dans la chaîne de connexion.

   Remarque

   ActiveDirectoryPassword est déconseillé. Pour plus d’informations, voir ActiveDirectoryPassword est déconseillé.

   server=Server;database=Database;UID=UserName;PWD=<password>;Authentication=ActiveDirectoryPassword;Encrypt=yes;

6. (Windows, et versions Linux/macOS 17.6 et ultérieures, pilote uniquement.) Authentification Windows intégrée via ADAL ou Kerberos, qui consiste à échanger les identifiants du compte Windows contre un jeton d’accès Microsoft Entra, en supposant que la base de données cible soit dans Azure SQL. La requête explicite Encrypt=yes demande un chiffrement de session complet. Le pilote valide le certificat serveur avec le TrustServerCertificate=no par défaut. Sur Linux/macOS, un ticket Kerberos approprié doit être disponible. Pour plus d’informations, voir Considérations pour l’utilisation des comptes fédérés ADFS sur Linux/macOS et Utilisation de l’authentification intégrée.

   server=Server;database=Database;Authentication=ActiveDirectoryIntegrated;Encrypt=yes;

7. (Pilote Windows uniquement.) L’authentification interactive Microsoft Entra utilise la technologie d’authentification multifactorielle Microsoft Entra pour établir une connexion. Vous pouvez omettre UID avec le pilote 17.8 et les versions ultérieures, ou le définir sur le compte utilisateur pour vous authentifier. Lorsque vous fournissez UID, la boîte de dialogue de connexion peut ne pas permettre de sélectionner un autre compte. Pour utiliser un autre compte, modifiez UID avant de vous connecter, ou omettez-le avec le pilote 17.8 et les versions ultérieures. Le pilote ouvre une boîte d’authentification Azure afin que l’utilisateur puisse effectuer toute vérification supplémentaire.

   server=Server;database=Database;UID=UserName;Authentication=ActiveDirectoryInteractive;Encrypt=yes;

   

8. L'authentification par identité gérée Microsoft Entra peut utiliser une identité gérée attribuée par le système ou par l'utilisateur. Pour une identité attribuée par l'utilisateur, définissez UID comme étant l'ID client de l'identité pour Azure App Service ou Azure Container Instance ; sinon, utilisez son ID d'objet. Pour l'identité affectée par le système, l'UID n'est pas obligatoire.

   Pour l'identité attribuée par le système :

   server=Server;database=Database;Authentication=ActiveDirectoryMsi;Encrypt=yes;

   Pour l’identité affectée par l’utilisateur avec l’ID objet myObjectId:

   server=Server;database=Database;UID=myObjectId;Authentication=ActiveDirectoryMsi;Encrypt=yes;

9. Authentification du principal de service Microsoft Entra ID

   server=Server;database=Database;UID=clientId;PWD=<password>;Authentication=ActiveDirectoryServicePrincipal;Encrypt=yes;

Notes

• Si vous utilisez les options Microsoft Entra avec le pilote ODBC Windows antérieur à la version 17.4.2, vérifiez que la Bibliothèque d’authentification Active Directory pour SQL Server a été installée. Si vous utilisez les pilotes Linux et macOS, vérifiez que libcurl est installé. Pour la version 17.2 et les versions ultérieures du pilote, il ne s’agit pas d’une dépendance explicite, car elle n’est pas requise pour les autres méthodes d’authentification ni les opérations ODBC.

• Lorsque la configuration Microsoft Entra comprend des stratégies d’accès conditionnel et que le client est Windows 10 ou Server 2016 ou une version ultérieure, l’authentification via Integrated ou le nom d’utilisateur / mot de passe peut échouer. Les stratégies d’accès conditionnel exigent l’utilisation du gestionnaire de comptes Web (WAM), pris en charge dans la version 17.6 et les versions ultérieures du pilote pour Windows. Pour utiliser WAM, créez une nouvelle valeur de chaîne nommée ADALuseWAM dans HKLM\Software\ODBC\ODBCINST.INI\ODBC Driver 17 for SQL Server, HKCU\Software\ODBC\ODBC.INI\<your-user-DSN-name> ou HKLM\Software\ODBC\ODBC.INI\<your-system-DSN-name> pour la configuration globale, le nom de source de données de l'utilisateur ou la configuration de l'étendue du nom de source de données système et attribuez-lui la valeur 1. Notez que l’authentification avec WAM ne prend pas en charge l’exécution de l’application en tant qu’utilisateur différent avec runas. Les scénarios qui requièrent des stratégies d’accès conditionnel ne sont pas pris en charge pour Linux ou macOS.

• Pour vous connecter avec un nom d’utilisateur de compte SQL Server et un mot de passe, vous pouvez maintenant utiliser la nouvelle option SqlPassword, tout particulièrement recommandée pour Azure SQL, car elle offre des paramètres de connexion plus sécurisés.

• Pour vous connecter avec un nom d’utilisateur de compte Microsoft Entra et un mot de passe, spécifiez Authentication=ActiveDirectoryPassword dans la chaîne de connexion et les mots clés UID et PWD avec respectivement le nom d’utilisateur et le mot de passe.

  Remarque

  ActiveDirectoryPassword est déconseillé. Pour plus d’informations, voir ActiveDirectoryPassword est déconseillé.

• Pour vous connecter avec l’authentification intégrée Windows ou Microsoft Entra (pilote Windows et Linux/macOS 17.6+ seulement), spécifiez Authentication=ActiveDirectoryIntegrated dans la chaîne de connexion. Le pilote choisira automatiquement le mode d’authentification approprié. Avec la version 17.7 et les versions antérieures du pilote, UID et PWD ne doivent pas être spécifiés. À partir de la version 17.8 du pilote, UID et PWD sont ignorés.

• Pour se connecter en utilisant l’authentification interactive Microsoft Entra (pilote Windows uniquement), vous pouvez omettre UID avec le pilote 17.8 et versions ultérieures, ou le définir sur le compte utilisateur pour authentification. La boîte de dialogue de connexion peut ne pas vous permettre de changer de compte lorsque vous saisissez UID. Pour utiliser un autre compte, modifiez UID avant de vous connecter, ou omettez-le avec le pilote 17.8 et les versions ultérieures. Les versions 17.7 et antérieures du pilote exigent UID et interdisent PWD. À partir de la version 17.8 du pilote, PWD est ignoré.

• À compter de la version 18.1, Trusted_Connection=Yes n’utilise plus l’authentification fédérée Microsoft Entra ID par défaut et utilise l’intégration SSPI à la place. Pour utiliser Microsoft Entra ID pour cette option, configurez TrustedConnection_UseAAD=Yes.

• Les versions 17.7 et antérieures du pilote ODBC présentent un problème connu avec le délai d’expiration de la connexion quand l’authentification Microsoft Entra et le chiffrement forcé sont activés sur une instance SQL Server. Le journal des erreurs de SQL Server peut contenir des messages d’erreur comme : « Erreur : 33155, Gravité : 20, État : 1. Un événement de déconnexion a été généré alors que le serveur attend un jeton d’authentification fédérée. Cela pourrait être dû à la fermeture du client ou à l’expiration du délai d’un serveur. ». Si vous utilisez des solutions de haute disponibilité comme des groupes de disponibilité Always On ou des instances de cluster de basculement, la communication interne du cluster pour SQL Server peut être affectée par ce comportement qui peut impacter la disponibilité des ressources. Dans le journal du cluster, vous pouvez voir des messages d’erreur comme : [hadrag] Connect to SQL Server ...ODBC Error: [HY000] [Microsoft][ODBC Driver 17 for SQL Server]An unknown error has occurred. Detailed error information is not available. (0). Les versions 17.10 et ultérieures du pilote ODBC corrigent ce problème et, avec SQL Server 2022 GDR KB5021522 / CU1 KB5022375, le dernier pilote contenant ce correctif est installé lors de l’installation de SQL Server. Vous pouvez vérifier la version du pilote ODBC que vous avez installée en vous référant à l’administrateur de source de données ODBC.

• À partir de la version 18.3 du pilote ODBC, l’authentification par identité managée (ActiveDirectoryMSI) est prise en charge sur Azure Arc et Azure Cloud Shell.

S’authentifier avec un jeton d’accès

L’attribut préconnexion SQL_COPT_SS_ACCESS_TOKEN permet d’utiliser un jeton d’accès obtenu auprès de Microsoft Entra ID pour l’authentification au lieu du nom d’utilisateur et du mot de passe, et de contourner la négociation et l’obtention d’un jeton d’accès par le pilote. Pour utiliser un jeton d’accès, définissez l’attribut de connexion SQL_COPT_SS_ACCESS_TOKEN sur un pointeur désignant une structure ACCESSTOKEN :

typedef struct AccessToken
{
    DWORD dataSize;
    BYTE data[];
} ACCESSTOKEN;

ACCESSTOKEN est une structure de longueur variable composée d’une longueur de 4 octets suivie de longueur octets de données opaques qui constituent le jeton d’accès. En raison de la façon dont SQL Server gère les jetons d’accès, un jeton d’accès obtenu au moyen d’une réponse JSON OAuth 2.0 doit être développé pour que chaque octet soit suivi d’un octet de remplissage à l’aide de zéros, comme une chaîne UCS-2 contenant uniquement des caractères ASCII. Toutefois, le jeton est une valeur opaque et la longueur spécifiée, en octets, ne doit comprendre aucune marque de fin null. En raison de ses contraintes de format et de longueur considérables, cette méthode d’authentification n’est disponible que programmatiquement, par le biais de l’attribut de connexion SQL_COPT_SS_ACCESS_TOKEN.

Vous devez conserver ACCESSTOKEN alloué aussi longtemps que la poignée de connexion est allouée. Sinon, des erreurs de violation d’accès peuvent survenir. Lorsque vous utilisez le gestionnaire de pilotes ODBC Windows, le pointeur de jeton fait partie de la clé du pool de connexion, donc un autre pointeur sélectionne un autre pool. Gardez le tampon associé à la même identité lorsque vous remplacez un jeton expiré. La mise à jour du tampon ne change pas l’identité d’une connexion déjà authentifiée.

Caution

Sur Linux et macOS, le pooling de connexions unixODBC ne sert SQL_COPT_SS_ACCESS_TOKEN pas à distinguer les identités. Lorsque vous utilisez la même chaîne de connexion, une requête de connexion avec un jeton différent peut réutiliser une connexion poolée authentifiée sous l’identité précédente. Si votre processus se connecte avec des jetons pour différentes identités, désactivez le pooling unixODBC avant de le lancer : définissez Pooling=No dans la [ODBC] section du fichier effectif odbcinst.ini , et assurez-vous que votre application et ses bibliothèques n’activent pas le pooling ODBC. Redémarrez les processus applicatifs existants après avoir modifié la configuration. Ne comptez pas sur le changement de pointeurs de jeton pour isoler les identités.

Il n’y a aucun DSN ni mot clé de chaîne de connexion correspondant. La chaîne de connexion ne doit pas contenir de mots clés UID, PWD, Authentication ni Trusted_Connection.

Remarque

La version 13.1 du pilote ODBC ne prend en charge cette authentification que sur Windows. Les versions ultérieures prennent en charge cette authentification sur toutes les plateformes.

Exemple de code d’authentification Microsoft Entra

L’exemple suivant illustre le code nécessaire pour se connecter à SQL Server à l’aide de Microsoft Entra ID avec les mots clés de connexion. Vous n’avez pas besoin de changer le code d’application lui-même. La chaîne de connexion, ou le nom de source de données s’il est utilisé, est la seule modification nécessaire pour pouvoir utiliser l’authentification Microsoft Entra ID :

    ...
    SQLCHAR connString[] = "Driver={ODBC Driver 18 for SQL Server};Server={server};UID=myuser;PWD=<password>;Authentication=ActiveDirectoryInteractive;Encrypt=yes;"
    ...
    SQLDriverConnect(hDbc, NULL, connString, SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT);
    ...

L’exemple suivant illustre le code nécessaire pour se connecter à SQL Server à l’aide de l’authentification par jeton d’accès avec Microsoft Entra. Dans ce cas, vous devez modifier le code d’application pour traiter le jeton d’accès et définir l’attribut de connexion associé.

    SQLCHAR connString[] = "Driver={ODBC Driver 18 for SQL Server};Server={server};Encrypt=yes;"
    SQLCHAR accessToken[] = "eyJ0eXAiOi..."; // In the format extracted from an OAuth JSON response
    ...
    DWORD dataSize = 2 * strlen(accessToken);
    ACCESSTOKEN *pAccToken = malloc(sizeof(ACCESSTOKEN) + dataSize);
    pAccToken->dataSize = dataSize;
    // Expand access token with padding bytes
    for(int i = 0, j = 0; i < dataSize; i += 2, j++) {
        pAccToken->data[i] = accessToken[j];
        pAccToken->data[i+1] = 0;
    }
    ...
    SQLSetConnectAttr(hDbc, SQL_COPT_SS_ACCESS_TOKEN, (SQLPOINTER)pAccToken, SQL_IS_POINTER);
    SQLDriverConnect(hDbc, NULL, connString, SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT);
    ...
    free(pAccToken);

Voici un exemple de chaîne de connexion à utiliser avec l’authentification interactive avec Microsoft Entra. Il ne contient pas de champ PWD, car le mot de passe est entré dans l’écran Authentification Azure.

SQLCHAR connString[] = "Driver={ODBC Driver 18 for SQL Server};Server={server};UID=myuser;Authentication=ActiveDirectoryInteractive;Encrypt=yes;"

L’exemple de chaîne de connexion suivant est utilisé avec l’authentification d’identité gérée par Microsoft Entra. UID est défini sur l’ID d’objet/client de l’identité d’utilisateur en cas d’utilisation d’une identité affectée par l’utilisateur.

// For system-assigned identity,
SQLCHAR connString[] = "Driver={ODBC Driver 18 for SQL Server};Server={server};Authentication=ActiveDirectoryMsi;Encrypt=yes;"
...
// For user-assigned identity with object ID equals to myObjectId
SQLCHAR connString[] = "Driver={ODBC Driver 18 for SQL Server};Server={server};UID=myObjectId;Authentication=ActiveDirectoryMsi;Encrypt=yes;"

Considérations relatives à l’utilisation des comptes fédérés ADFS sur Linux/macOS

À partir de la version 17.6, les pilotes pour Linux et macOS prennent en charge l’authentification à l’aide des comptes fédérés par ADFS Microsoft Entra à l’aide d’un nom d’utilisateur / mot de passe (ActiveDirectoryPassword) ou de Kerberos (ActiveDirectoryIntegrated). Certaines limitations dépendent de la plateforme lorsque vous utilisez le mode intégré.

Quand l’utilisateur qui s’authentifie a un suffixe UPN différent du domaine Kerberos, c’est-à-dire qu’un autre suffixe UPN est utilisé, vous devez utiliser l’option Principal d’entreprise (utilisez l’option -E avec kinit et fournissez le nom du principal au format user@federated-domain) pour obtenir les tickets Kerberos. De cette façon, le pilote peut correctement déterminer le domaine fédéré et le domaine Kerberos.

Vous pouvez vérifier qu’un ticket Kerberos approprié est disponible en inspectant la sortie de la commande klist. Si le domaine fédéré est le même que le domaine Kerberos et le suffixe UPN, le nom du principal a le format user@realm. S’il est différent, le nom principal doit être au format user@federated-domain@realm.

Linux

Sur SUSE 11, la version 1.6.x par défaut de la bibliothèque Kerberos ne prend pas en charge l’option Principal d’entreprise qui permet d’utiliser d’autres suffixes UPN. Pour utiliser d’autres suffixes UPN avec l’authentification intégrée Microsoft Entra, mettez à niveau la bibliothèque Kerberos au profit de la version 1.7 ou d’une version plus récente.

Sur Alpine Linux, le libcurl par défaut ne prend pas en charge l’authentification SPNEGO/Kerberos nécessaire pour l’authentification intégrée avec Microsoft Entra.

macOS

La bibliothèque Kerberos système kinit prend en charge le Principal d’entreprise avec l’option --enterprise, mais effectue également implicitement une canonicalisation des noms, ce qui empêche d’utiliser d’autres suffixes UPN. Pour utiliser d’autres suffixes UPN avec l’authentification intégrée avec Microsoft Entra, installez une bibliothèque Kerberos plus récente via brew install krb5 et utilisez son kinit avec l’option -E comme décrit ci-dessus.

Contenu connexe

• Prise en charge de l'authentification par jeton pour la base de données Azure SQL avec l'authentification Microsoft Entra
• Utilisation de l’authentification intégrée