Pourquoi l'utilisateur principal de mon instance RDS for SQL Server a-t-il perdu l'accès et comment puis-je le récupérer ?

Brève description

Lorsque vous créez une nouvelle instance de base de données, l'utilisateur principal par défaut reçoit automatiquement certains privilèges pour cette instance de base de données. Vous ne pouvez pas changer le nom de l'utilisateur principal après la création de l'instance de base de données.

Remarque : ne pas utiliser l'utilisateur principal directement dans vos applications constitue une bonne pratique. Utilisez plutôt un utilisateur de base de données créé avec les privilèges minimaux requis pour votre application.

Si vous supprimez accidentellement les autorisations de l'utilisateur principal, vous pouvez les rétablir en modifiant l'instance de base de données et en définissant un nouveau mot de passe d'utilisateur principal. Pour plus d'informations, consultez Privilèges du compte utilisateur principal.

Solution

Les scénarios suivants sont courants et peuvent conduire à ce que l'utilisateur principal ne puisse plus se connecter à l'instance de base de données. Il est également possible que l'utilisateur principal ne soit pas en mesure de se connecter et d'accéder à une base de données utilisateur spécifique.

Scénario 1 : l'utilisateur principal ne peut pas se connecter à l'instance de base de données en raison d'un DENY explicite

L'utilisateur principal peut ne pas être en mesure de se connecter à l'instance de base de données parce qu'un DENY explicite est défini sur le privilège Connect SQL. Par défaut, l'utilisateur principal se voit accorder le privilège Connect SQL par l'identifiant Amazon RDS System Administrator (rdsa). Cependant, dans Microsoft SQL Server, un DENY explicite a la priorité sur un GRANT explicite.

Pour résoudre ce problème, procédez comme suit :

1.    Connectez-vous à RDS for SQL Server en utilisant l'identifiant du concédant qui a placé le DENY explicite sur Connect SQL pour l'identifiant de l'utilisateur principal.

2.    Utilisez la commande T-SQL suivante pour révoquer le DENY explicite. Dans l'exemple suivant, l'identifiant de l'utilisateur principal RDS est master_user et le principal du concédant est grantor_principal. Modifiez ces valeurs pour qu'elles correspondent à votre cas d'utilisation.

USE [master];
GO
REVOKE CONNECT SQL TO [master_user] AS [grantor_principal];
GO

Scénario 2 : l'utilisateur principal ne peut pas se connecter à une base de données spécifique car il n'est pas mappé à un utilisateur dans la base de données

Cela peut se produire dans les circonstances suivantes :

• La base de données a été créée par un autre compte de connexion. Et, l'identifiant de l'utilisateur principal n'est pas mappé à un utilisateur de la base de données et n'a pas obtenu de privilèges pour la base de données.
• L'utilisateur de la base de données précédemment mappé à l'identifiant de l'utilisateur principal avec les autorisations appropriées a été explicitement supprimé.

Pour résoudre ce problème, réinitialisez le mot de passe de l'utilisateur principal. La réinitialisation du mot de passe crée un utilisateur de la base de données mappé à l'identifiant de l'utilisateur principal si cet utilisateur a été supprimé. Elle accorde également le rôle de base de données fixe db_owner à l'utilisateur. Pour obtenir des instructions sur la réinitialisation du mot de passe de l'utilisateur principal, consultez Comment réinitialiser le mot de passe de l'utilisateur principal pour mon instance de base de données Amazon RDS ?

Remarque : l'utilisateur AWS Identify and Access Management (IAM) qui réinitialise le mot de passe doit avoir l'autorisation d'exécuter l'action ModifyDBInstance sur la ressource RDS.

La mise à jour du mot de passe de l'utilisateur principal a les effets suivants :

• Accorde à l'utilisateur principal le rôle de niveau base de données db_owner à une base de données créée par un autre utilisateur.
• Restaure les privilèges du système à l'utilisateur principal.
• Restaure les rôles au niveau du serveur pour l'utilisateur principal.
• Restaure les autorisations au niveau du serveur pour l'utilisateur principal.
• Restaure l'accès aux procédures stockées dans le système pour l'utilisateur principal.
• Restaure l'accès aux procédures stockées spécifiques à RDS pour l'utilisateur principal.

Scénario 3 : l'utilisateur principal ne peut pas effectuer certaines actions

L'utilisateur principal dispose d'une autorisation de rôle db_owner sur la base de données mais ne peut pas effectuer certaines actions, telles que CONNECT, SELECT, INSERT, UPDATE, ALTER, etc. Cela peut se produire lorsque l'utilisateur de la base de données mappé à l'identifiant de l'utilisateur principal s'est vu explicitement refuser certaines autorisations sur la base de données.

Pour voir la liste des rôles de base de données et les utilisateurs de base de données qui sont membres de ces rôles, exécutez la commande T-SQL suivante. Dans ce qui suit, remplacez database_namepar les valeurs correctes pour votre cas d'utilisation.

USE [database_name];
  GO
  SELECT DP1.name AS DatabaseRoleName,
   isnull (DP2.name, 'No members') AS DatabaseUserName
 FROM sys.database_role_members AS DRM
 RIGHT OUTER JOIN sys.database_principals AS DP1
   ON DRM.role_principal_id = DP1.principal_id
 LEFT OUTER JOIN sys.database_principals AS DP2
   ON DRM.member_principal_id = DP2.principal_id
WHERE DP1.type = 'R'
ORDER BY DP1.name;

Exécutez les commandes suivantes pour voir la liste des autorisations dont dispose un utilisateur dans une base de données particulière. Dans l'exemple suivant, remplacez database_name par la valeur correcte pour votre cas d'utilisation.

USE [database_name];
GO
EXECUTE AS USER = 'master_user';
SELECT * FROM sys.fn_my_permissions(NULL, 'DATABASE');
GO

Dans cet exemple, l'utilisateur principal est ajouté aux rôles de base de données fixes db_denydatawriter et db_denydatareader. Bien qu'il soit membre du rôle de base de données fixe db_owner, les privilèges de refus de db_denydatawriter et db_denydatareader interdisent les autorisations SELECT, INSERT, UPDATE et DELETE sur la base de données.

Pour résoudre ce problème :

1.    Connectez-vous à l'instance RDS for SQL Server en utilisant l'utilisateur principal.

2.    Utilisez la commande T-SQL suivante pour supprimer l'utilisateur principal en tant que membre de ces deux rôles :

USE [database_name];
GO
ALTER ROLE [db_denydatawriter] DROP MEMBER [master_user];
ALTER ROLE [db_denydatareader] DROP MEMBER [master_user];
GO

Une fois les commandes terminées, l'utilisateur principal dispose à nouveau des autorisations SELECT, INSERT, UPDATE et DELETE sur la base de données.

Pour plus d'informations sur les rôles spécifiques de l'utilisateur principal, consultez Privilèges du compte utilisateur principal.

---

Informations connexes

Réinitialisation du mot de passe du rôle db_owner

Sécurité de Microsoft SQL Server

DENY (Transact-SQL)