Authentification Microsoft Entra pour Azure SQL

S’applique à :Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics

Cet article présente une vue d’ensemble de l’utilisation de l’authentification Microsoft Entra avec d’Azure SQL Database, Azure SQL Managed Instance, SQL Server sur machines virtuelles, Synapse SQL dans Azure Synapse Analytics et SQL Server pour Windows et Linux.

Si vous souhaitez configurer l'authentification Microsoft Entra, passez en revue :

• Azure SQL Database et Azure SQL Managed Instance
• SQL Server sur machines virtuelles Azure

Vue d’ensemble

Microsoft Entra ID vous permet de gérer de manière centralisée les identités des humains et des services dans votre patrimoine de données. En intégrant Microsoft Entra à Azure SQL pour l’authentification, vous pouvez simplifier la gestion des identités et des autorisations tout en activant un accès conditionnel et une gouvernance détaillés sur toutes les connexions à vos données.

L’utilisation de l’authentification Microsoft Entra offre les avantages suivants :

• Remplace les méthodes d'authentification moins sûres telles que les noms d'utilisateur et les mots de passe.
• Supprime ou aide à bloquer la prolifération des identités utilisateur sur plusieurs serveurs.
• Les groupes Microsoft Entra permettent à la gestion des autorisations de base de données d’être extraite des comptes individuels et dans des groupes opérationnels.
• Permet une rotation du mot de passe dans un emplacement unique.
• L'authentification Microsoft Entra-only constitue une alternative complète à l'authentification SQL.
• Les identités managées pour les ressources Azure éliminent la nécessité de stocker des mots de passe pour les services qui se connectent à vos bases de données et les connexions de vos bases de données à d’autres ressources Azure.
• Permet des contrôles de sécurité modernes, y compris une authentification multifactorielle forte avec une gamme d'options de vérification simples, telles qu'un appel téléphonique, un SMS, une carte à puce avec code PIN ou une notification d'application mobile.
• Microsoft Entra ID permet l’intégration à de nombreux protocoles d’authentification modernes, notamment OpenID Connect, OAuth2.0, délégation Kerberos contrainte, etc.
• Permet une surveillance centralisée des connexions aux sources de données.
• Active les contrôles d’accès conditionnel, tels que l’exigence d’appareils conformes ou de méthodes d’authentification pour les connexions réussies.
• Gérez et surveillez l’authentification de manière centralisée avec les stratégies Azure.

Étapes de configuration

Les étapes générales de la configuration de l'authentification Microsoft Entra sont les suivantes :

1. Créer et alimenter un locataire Microsoft Entra.
2. Créez un serveur logique ou une instance dans Azure.
3. Attribuez un administrateur Microsoft Entra au serveur ou à l’instance.
4. Créez des principaux SQL dans votre base de données mappés sur les identités Microsoft Entra.
5. Configurez vos applications clientes pour vous connecter à l’aide des bibliothèques d’identités Azure et des méthodes d’authentification.
6. Vous connecter à votre base de données avec des identités Microsoft Entra.

Identités et méthodes d’authentification prises en charge

Azure SQL prend en charge l’utilisation des identités Microsoft Entra suivantes en tant que connexions et utilisateurs (principaux) dans vos serveurs et bases de données :

• Utilisateurs de Microsoft Entra : tout type d’utilisateur dans un client Microsoft Entra, y compris les membres internes, externes, invités et membres. Les membres d’un domaine Active Directory configuré pour la fédération avec l’ID Microsoft Entra sont également pris en charge et peuvent être configurés pour l’authentification unique transparente.
• Applications : les applications qui existent dans Azure peuvent utiliser des principaux de service ou des identités managées pour s’authentifier directement auprès d’Azure SQL. L’utilisation d’identités managées pour l’authentification est préférée car l'authentification se fait sans mot de passe et élimine le besoin d'informations d'identification gérées par le développeur.
• Les Groupes Microsoft Entra, qui peuvent simplifier la gestion des accès au sein de votre organisation en gérant l’accès des utilisateurs et des applications appropriés en fonction de leur appartenance au groupe.

Les méthodes d'authentification suivantes sont prises en charge pour les identités des utilisateurs :

• Microsoft Entra Integrated (Authentification Windows) pris en charge par Microsoft Entra Hybrid Identities with Active Directory [federation].
• Microsoft Entra ADG ou l’authentification multifacteur, qui nécessite des vérifications de sécurité supplémentaires au-delà des connaissances de l’utilisateur.
• Authentification par mot de passe Microsoft Entra, qui utilise les informations d’identification utilisateur stockées et gérées dans l’ID Microsoft Entra.
• Authentification Microsoft Entra Par défaut , qui analyse différents caches d’informations d’identification sur la machine de l’application et peut utiliser des jetons utilisateur pour s’authentifier auprès de SQL.

Pour les identités de service ou de charge de travail, les méthodes d’authentification suivantes sont prises en charge :

• Identités gérées pour les ressources Azure, qu'elles soient attribuées par l'utilisateur ou par le système. L’authentification d’identité managée est basée sur des jetons, dans laquelle l’identité est affectée à la ressource qui souhaite s’authentifier à l’aide de celle-ci. La plateforme Azure Identity valide cette relation, qui active l’authentification sans mot de passe.
• Nom du principal du service Microsoft Entra et secret de l'application (client). Cette méthode d’authentification n’est pas recommandée en raison du risque associé à la divulgation des mots de passe.
• Authentification Microsoft Entra Par défaut , qui analyse différents caches d’informations d’identification sur l’ordinateur de l’application et peut utiliser des jetons d’application pour s’authentifier auprès de SQL.

Administrateur Microsoft Entra

Pour activer l’authentification Microsoft Entra, un administrateur Microsoft Entra doit être défini pour votre serveur logique ou votre instance managée. Cet administrateur existe en même temps que l’administrateur SQL Server (SA). L’administrateur Microsoft Entra peut être n’importe quel objet de sécurité dans votre locataire Azure, y compris les utilisateurs, groupes, principaux de service et identités managées Microsoft Entra. L’administrateur Microsoft Entra est une propriété unique, et non une liste, ce qui signifie qu’une seule identité peut être configurée à tout moment. La suppression de l’administrateur Microsoft Entra du serveur désactive toutes les connexions basées sur l’authentification Microsoft Entra, même pour les utilisateurs Microsoft Entra existants disposant d’autorisations dans une base de données.

L’administrateur Microsoft Entra joue un rôle spécial : il s’agit du premier compte qui peut créer d’autres connexions Microsoft Entra (en préversion dans SQL Database) et des utilisateurs, collectivement appelés principaux. L’administrateur est un utilisateur de base de données autonome dans la base de données master du serveur. Les comptes administrateur de serveur sont des membres du rôle db_owner de chaque base de données utilisateur, et chaque base de données d'utilisateurs est saisie en tant qu'utilisateur dbo. Pour plus d'informations sur les comptes administrateur, consultez Gestion des bases de données et des connexions.

Principaux Microsoft Entra

Les identités Microsoft Entra peuvent être créées en tant que principaux dans Azure SQL de trois façons :

• en tant que principaux de serveur ou connexions (en préversion pour Azure SQL Database)
• en tant qu’utilisateurs basés sur la connexion (type de principal de base de données)
• en tant qu’utilisateurs de base de données autonome

connexions (Principaux de serveur)

Les principaux de serveur (connexions) pour les identités Microsoft Entra sont généralement disponibles pour Azure SQL Managed Instance, SQL Server 2022 et SQL Server sur des machines virtuelles Azure. Les logins Microsoft Entra sont en avant-première pour Azure SQL Database.

Le T-SQL suivant montre comment créer une connexion Microsoft Entra :

CREATE LOGIN [MSEntraUser] FROM EXTERNAL PROVIDER

Une connexion Microsoft Entra a les valeurs de propriété suivantes dans sys.server_principals :

Utilisateurs basés sur la connexion

Les utilisateurs basés sur la connexion héritent des rôles et autorisations au niveau du serveur affectés à sa connexion Microsoft Entra. Les utilisateurs basés sur les connexions Microsoft Entra sont en préversion pour Azure SQL Database.

Le T-SQL suivant montre comment créer un utilisateur basé sur une connexion pour une identité Microsoft Entra :

CREATE USER [MSEntraUser] FROM LOGIN [MSEntraUser]

Le tableau suivant détaille les valeurs de propriété utilisateur basées sur microsoft Entra dans sys.database_principals :

Utilisateurs de base de données autonome

Les utilisateurs de la base de données autonome sont portables avec la base de données. Ils n’ont aucune connexion aux identités définies dans le serveur ou l’instance, et peuvent donc être facilement déplacées avec la base de données d’un serveur ou d’une instance vers une autre sans interruption.

Le T-SQL suivant montre comment créer un utilisateur de base de données autonome pour une identité Microsoft Entra :

CREATE USER [MSEntraUser] FROM EXTERNAL PROVIDER

Un utilisateur basé sur une base de données Microsoft Entra a les mêmes valeurs de propriété que les utilisateurs basés sur la connexion dans sys.database_principals, à l’exception de la façon dont le SID est construit :

Pour obtenir le GUID Microsoft Entra d’origine sur lequel repose le SID, utilisez la conversion T-SQL suivante :

SELECT CAST(sid AS UNIQUEIDENTIFIER) AS EntraID FROM sys.database_principals

Utilisez la requête T-SQL suivante pour déterminer si un utilisateur de base de données est un utilisateur basé sur la connexion ou un utilisateur de base de données autonome :

SELECT CASE
    WHEN CONVERT(VARCHAR(100), sid, 2) LIKE '%AADE' AND len(sid) = 18 THEN 'login-based user'
    ELSE 'contained database user'
    END AS user_type,
    *
FROM sys.database_principals WHERE TYPE = 'E' OR TYPE = 'X'

Utilisez la requête T-SQL suivante pour afficher tous les principaux Microsoft Entra dans une base de données :

SELECT
  name,
  CAST(sid AS UNIQUEIDENTIFIER) AS EntraID,
  CASE WHEN TYPE = 'E' THEN 'App/User' ELSE 'Group' AS user_type,
  sid
FROM sys.database_principals WHERE TYPE = 'E' OR TYPE = 'X'

Authentification Microsoft Entra uniquement

Une fois l’authentification Microsoft Entra uniquement activée, toutes les autres méthodes d’authentification sont désactivées et ne peuvent pas être utilisées pour se connecter au serveur, à l’instance ou à la base de données, ce qui inclut les comptes SA et tous les autres comptes basés sur l'authentification SQL pour Azure SQL, ainsi que l'authentification Windows pour Azure SQL Managed Instance.

Pour commencer, consultez Configurer l'authentification Microsoft Entra-only..

Authentification multifacteur (MFA)

L’authentification multifacteur Microsoft Entra est une fonctionnalité de sécurité fournie par le service de gestion des identités et des accès basé sur le cloud de Microsoft. L’authentification multifacteur (MFA) améliore la sécurité des connexions utilisateur en obligeant les utilisateurs à fournir des étapes de vérification supplémentaires autres qu’un mot de passe.

L’authentification multifacteur Microsoft Entra contribue à sécuriser l’accès aux données et aux applications tout en répondant à la demande de l’utilisateur d’un processus d’authentification simple. L’authentification multifacteur ajoute une couche de sécurité supplémentaire aux connexions utilisateur en obligeant les utilisateurs à fournir deux facteurs d’authentification ou plus. Ces facteurs incluent généralement quelque chose que l’utilisateur sait (mot de passe), quelque chose que l’utilisateur possède (smartphone ou module de sécurité matériel), et/ou quelque chose que l’utilisateur est (données biométriques). En combinant plusieurs facteurs, l’authentification multifacteur réduit considérablement la probabilité d’un accès non autorisé.

L’authentification multifacteur est une méthode d’authentification prise en charge pour Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics et SQL Server 2022 (16.x) et les versions ultérieures.

Pour commencer, consultez Configurer l'authentification multifacteur de Microsoft Entra.

Prise en charge de Microsoft Entra B2B

L’authentification multifacteur Microsoft Entra prend également en charge la collaboration B2B Microsoft Entra qui permet aux entreprises de faire collaborer des utilisateurs invités avec leur organisation. Les utilisateurs invités peuvent se connecter à des bases de données en tant qu’utilisateurs individuels ou membres d’un groupe Microsoft Entra. Pour plus d’informations, consultez Créer un utilisateur invité.

Architecture d’approbation pour la fédération Microsoft Entra vers Active Directory

Microsoft Entra ID s’intègre également aux solutions de gestion des identités et des accès familières comme Active Directory. La jonction hybride à votre Annonce local permet aux identités Windows fédérées via l’ID Microsoft Entra d’utiliser les informations d’identification de l’authentification unique pour se connecter à Azure SQL.

Pour la fédération, Microsoft Entra ID fournit deux méthodes d’authentification sécurisées : l’authentification directe et l’authentification par hachage de mot de passe. Si vous envisagez de fédérer votre Active Directory local à Microsoft Entra ID, consultez Choisir la méthode d’authentification appropriée pour votre solution d’identité hybride Microsoft Entra.

Pour plus d’informations sur la configuration et la synchronisation des identités hybrides Microsoft Entra, consultez les articles suivants :

• Implémenter synchronisation de hachage du mot de passe avec Microsoft Entra Connect Sync
• Authentification directe Microsoft Entra
• Déployer des services de fédération Active Directory (AD FS) dans Azure et Microsoft Entra Connect et fédération

Consultez ce diagramme pour obtenir un exemple d’authentification fédérée avec l’infrastructure ADFS (ou utilisateur/mot de passe pour les informations d’identification Windows). Les flèches indiquent les voies de communication.

Le diagramme suivant indique la fédération, l’approbation et les relations d’hébergement qui autorisent un client à se connecter à une base de données en soumettant un jeton. Microsoft Entra ID authentifie le jeton, et la base de données l’approuve et valide l’émetteur et d’autres détails. Le client 1 peut représenter Microsoft Entra ID avec des utilisateurs natifs ou avec des utilisateurs fédérés. Le client 2 représente une solution possible incluant des utilisateurs importés qui, dans cet exemple, proviennent d’une fédération Microsoft Entra ID dont l’ADFS est synchronisé avec Microsoft Entra ID. Il est important de comprendre que l’accès à une base de données à l’aide de l’authentification Microsoft Entra exige que l’abonnement d’hébergement soit associé à Microsoft Entra ID. Le même abonnement doit être utilisé pour créer les ressources Azure SQL Database ou Azure Synapse.

autorisations

Les autorisations attribuées à l’administrateur Microsoft Entra sont différentes des autorisations attribuées aux principaux dans Azure SQL. Dans quelques scénarios, Azure SQL a également besoin des autorisations Microsoft Graph pour utiliser l’authentification Microsoft Entra.

Autorisations d’administration

L’administrateur Microsoft Entra reçoit les autorisations et rôles suivants lors de la création :

• Le db_owner de chaque base de données sur le serveur ou l’instance

Autorisations Azure SQL

Un principal a besoin de l’autorisation ALTER ANY USER dans la base de données pour créer un utilisateur. Par défaut, ALTER ANY USER est attribué à : comptes d’administrateur de serveur, utilisateurs de base de données avec CONTROL ON DATABASE et membres du rôle de base de données db_owner.

Pour créer un principal Microsoft Entra dans Azure SQL, l’identité demandeur doit interroger Microsoft Graph pour plus d’informations sur le principal. Lors du déploiement initial, la seule identité capable d’interroger MS Graph est l’administrateur Microsoft Entra ; ainsi, l’administrateur doit être la première identité pour créer d’autres principaux Microsoft Entra. Après cela, il peut affecter ALTER ANY USER à d’autres principaux pour leur permettre de créer également d’autres principaux Microsoft Entra.

Déploiements sans contact avec l’authentification Microsoft Entra

Étant donné que l’administrateur Microsoft Entra doit être la première identité à se connecter à la base de données et créer d’autres utilisateurs Microsoft Entra, il peut être utile d’ajouter l’identité de votre infrastructure de déploiement en tant qu’administrateur. Vos déploiements peuvent ensuite effectuer une configuration initiale, comme la création d’autres principaux Microsoft Entra et leur attribution d’autorisations. Les déploiements peuvent utiliser des outils tels que des modèles ARM PowerShell pour générer des scripts de création de principal automatisé. Azure SQL ne prend pas en charge les API natives aujourd’hui pour configurer la création et la gestion des autorisations des utilisateurs ; ces opérations sont uniquement autorisées à être effectuées avec une connexion directe à l’instance SQL.

Autorisations Microsoft Graph

Pour créer des principaux Microsoft Entra et quelques autres scénarios, Azure SQL doit effectuer des appels Microsoft Graph pour récupérer des informations et valider l’existence de l’identité dans Microsoft Entra ID. Pour ce faire, le processus SQL doit avoir, ou obtenir, l’accès aux autorisations de lecture MS Graph au sein du locataire client, ce qui s’obtient de plusieurs façons :

• Si le principal SQL exécutant la commande est une identité utilisateur, aucune autorisation supplémentaire sur l’instance SQL n’est requise pour interroger MS Graph.
• Si le principal SQL exécutant la commande est une identité de service, par exemple un principal de service ou une identité managée, l’instance Azure SQL requiert ses propres autorisations pour interroger MS Graph.
  • Les autorisations d’application peuvent être affectées à l’identité du serveur principal (identité managée) du serveur logique ou de l’instance managée. Le processus SQL peut utiliser l’identité du serveur principal pour s’authentifier auprès d’autres services Azure dans un client, comme MS Graph. Le tableau suivant décrit différents scénarios et les autorisations MS Graph requises pour que la commande s’exécute correctement.

Outils pris en charge

SQL Server Management Studio (SSMS) prend en charge plusieurs options de connexion d’authentification Microsoft Entra, notamment l’authentification multifacteur.

SQL Server Data Tools (SSDT) pour Visual Studio, à compter de 2015, prend en charge l’authentification par mot de passe, intégrée et interactive avec l’ID Microsoft Entra. Pour plus d'informations, consultez la rubrique Prise en charge de Microsoft Entra ID dans SQL Server Data Tools (SSDT).

• Actuellement, les utilisateurs Microsoft Entra ne sont pas affichés dans l’explorateur d’objets SSDT. Comme solution de contournement, vous pouvez afficher les utilisateurs dans sys.database_principals.

Versions minimales

Pour utiliser l’authentification Microsoft Entra avec Azure SQL, vous avez besoin des versions minimales suivantes lors de l’utilisation de ces outils :

• SQL Server Management Studio (SSMS) version 18.6 ou ultérieure
• SQL Server Data Tools for Visual Studio 2015, version 14.0.60311.1 (avril 2016) ou ultérieure
• Fournisseur de données .NET Framework pour SQL Server dans .NET Framework 4.6
• À partir de la version 15.0.1, l’utilitaire sqlcmd et l’utilitaire bcp prennent en charge l’authentification interactive Active Directory ainsi que l’authentification multifacteur.
• Le pilote Microsoft JDBC 6.0 pour SQL Server prend en charge l’authentification Microsoft Entra. Consultez également Définition des propriétés de connexion.

Connexion avec Microsoft Entra aux ressources Azure SQL

Une fois l’authentification Microsoft Entra configurée pour votre ressource Azure SQL, vous pouvez vous connecter à l’aide de SQL Server Management Studio, de SQL Server Data Tools et d’une application cliente.

Limites

Lorsque vous utilisez l’authentification Microsoft Entra avec Azure SQL, tenez compte des limitations suivantes :

• Les utilisateurs de Microsoft Entra et les mandants de service (applications Microsoft Entra) qui sont membres de plus de 2048 groupes de sécurité Microsoft Entra ne sont pas pris en charge et ne peuvent pas se connecter à la base de données.

• Ces fonctions système ne sont pas prises en charge. Elles renvoient des valeurs NULL lorsqu’elles sont exécutées par des principaux Microsoft Entra :

  • SUSER_ID()
  • SUSER_NAME(<ID>)
  • SUSER_SNAME(<SID>)
  • SUSER_ID(<name>)
  • SUSER_SID(<name>)

• Nous vous conseillons de définir l’expiration du délai de connexion à 30 secondes.

Azure SQL Database et Azure Synapse Analytics

Lorsque vous utilisez l’authentification Microsoft Entra avec Azure SQL Database et Azure Synapse Analytics, tenez compte des limitations suivantes :

• Les utilisateurs de Microsoft Entra qui font partie d'un groupe membre du rôle de base de données db_owner peuvent voir l'erreur suivante lorsqu'ils tentent d'utiliser la syntaxe CREATE DATABASE SCOPED CREDENTIAL contre Azure SQL Database et Azure Synapse :

  SQL Error [2760] [S0001]: The specified schema name 'user@mydomain.com' either doesn't exist or you do not have permission to use it.

  Pour atténuer le problème lié à CREATE DATABASE SCOPED CREDENTIAL, accordez le rôle db_owner directement à l’utilisateur individuel Microsoft Entra.

• Azure SQL Database et Azure Synapse Analytics ne crée pas d’utilisateurs implicites pour les utilisateurs qui sont connectés dans le cadre d’une appartenance à un groupe Microsoft Entra. Pour cette raison, diverses opérations qui nécessitent une attribution de propriété échouent, même si le groupe Microsoft Entra est ajouté comme membre à un rôle disposant de ces autorisations.

  Par exemple, un utilisateur connecté à une base de données par le biais d’un groupe Microsoft Entra avec le rôle db_ddladmin ne pourra pas exécuter les instructions CREATE SCHEMA, ALTER SCHEMA et d’autres instructions de création d’objets sans avoir un schéma explicitement défini (à l’instar d’une table, une vue ou un type). Pour résoudre ce problème, un utilisateur Microsoft Entra doit être créé pour cet utilisateur, ou le groupe Microsoft Entra doit être modifié afin d’attribuer DEFAULT_SCHEMA à dbo.

• Lors de l'utilisation de la géo-réplication et des groupes de basculement, l'administrateur Microsoft Entra doit être configuré à la fois pour le serveur primaire et le serveur secondaire. Si un serveur n’a pas d’administrateur Microsoft Entra, les connexions Microsoft Entra et les utilisateurs reçoivent une erreurCannot connect.

• La suppression de l'administrateur Microsoft Entra pour le serveur empêche toute connexion d'authentification Microsoft Entra au serveur. Si nécessaire, des utilisateurs Microsoft Entra inutilisables peuvent être supprimés manuellement par un administrateur SQL Database.

Azure SQL Managed Instance

Lorsque vous utilisez l'authentification Microsoft Entra avec Azure SQL Managed Instance, tenez compte des limitations suivantes :

• Les principaux de serveur (connexions) et les utilisateurs Microsoft Entra sont pris en charge pour SQL Managed Instance.

• La définition des connexions Microsoft Entra en tant que propriétaire de base de données n’est pas prise en charge dans SQL Managed Instance.

  • Par extension, quand vous ajoutez un groupe dans le cadre du rôle serveur dbcreator, les utilisateurs de ce groupe peuvent se connecter à SQL Managed Instance et créer des bases de données, mais non accéder à la base de données. En effet, le propriétaire de la nouvelle base de données est SA et non l’utilisateur Microsoft Entra. Ce problème ne se manifeste pas si le rôle serveur dbcreator est accordé à l’utilisateur concerné.

• Les principaux de serveur (connexions) Microsoft Entra pour SQL Managed Instance permettent de créer connexions pouvant être ajoutés au rôle sysadmin.

• La gestion de l'agent SQL et l'exécution des tâches sont prises en charge pour les connexions Microsoft Entra.

• Les opérations de sauvegarde et de restauration de base de données peuvent être exécutées par les principaux de serveur (connexions) Microsoft Entra.

• L’audit de toutes les instructions liées aux principaux de serveur (connexions) Microsoft Entra et aux événements d’authentification est pris en charge.

• La connexion administrateur dédiée destinée aux principaux de serveur (connexions) Microsoft Entra, membres du rôle serveur sysadmin, est prise en charge.

  • Prise en charge par le biais de l’utilitaire SQLCMD et de SQL Server Management Studio.

• Les déclencheurs d’ouverture de session sont pris en charge pour les événements d’ouverture de session provenant de principaux de serveur (connexions) Microsoft Entra.

• Vous pouvez configurer Service Broker et DB mail à l’aide d’un principal de serveur (connexion) Microsoft Entra.

• Lors de l’utilisation de groupes de basculement, l’administrateur Microsoft Entra doit être configuré pour les instances primaires et secondaires. Si une instance n’a pas d’administrateur Microsoft Entra, les connexions Microsoft Entra et les utilisateurs reçoivent une erreur de serveur Cannot connect.

• PolyBase ne peut pas s’authentifier avec l’authentification Microsoft Entra.

• La suppression de l'administrateur Microsoft Entra pour l'instance empêche toute connexion d'authentification Microsoft Entra à l'instance. Si nécessaire, un administrateur SQL Managed Instance peut supprimer manuellement les utilisateurs Microsoft Entra inutilisables.

Contenu connexe

• Configurer et gérer l’authentification Microsoft Entra avec Azure SQL
• Didacticiel : Sécuriser avec les connexions Microsoft Entra - Azure SQL Managed Instance
• Configurer SQL Database, SQL Managed Instance et Azure Synapse Analytics pour autoriser l’accès aux bases de données
• Principaux de base de données
• Rôles de bases de données
• Syntaxe CREATE LOGIN pour SQL Managed Instance Microsoft Entra principaux de serveur (connexions)
• Règles de pare-feu IP Azure SQL Database et Azure Synapse