¿Por qué el usuario maestro de mi instancia de RDS para SQL Server ya no tiene acceso y cómo puedo recuperarlo?

6 minutos de lectura
0

El usuario maestro de mi instancia de Amazon Relational Database Service (Amazon RDS) para SQL Server ya no tiene acceso. O bien necesito conceder al usuario maestro acceso a una base de datos que creó otro usuario. ¿Qué debo hacer para restablecer el acceso o concedérselo a mi usuario maestro?

Descripción corta

Cuando se crea una nueva instancia de base de datos, el usuario maestro predeterminado recibe de forma automática ciertos privilegios para esa instancia de base de datos. No puede cambiar el nombre del usuario maestro una vez que se ha creado la instancia de la base de datos.

Nota: Se recomienda no usar la cuenta del usuario maestro directamente en las aplicaciones. En lugar de eso, emplee un usuario de la base de datos que haya creado con los privilegios mínimos que necesite su aplicación.

Si, de forma accidental, elimina los permisos del usuario maestro, puede restablecerlos modificando la instancia de la base de datos y definiendo una nueva contraseña para el usuario maestro. Si desea obtener más información, consulte Master user account privileges (Privilegios de la cuenta de usuario maestro).

Resolución

A continuación se muestran algunas situaciones comunes que pueden provocar que el usuario maestro pierda el acceso a la conexión a la instancia de base de datos. O bien es posible que el usuario maestro no consiga conectarse ni acceder a una base de datos de usuarios específica.

Situación 1: El usuario maestro no consigue conectarse a la instancia de base de datos debido a una DENEGACIÓN explícita

Es posible que el usuario maestro no consiga conectarse a la instancia de base de datos debido a que se ha definido una condición explícita de DENY (Denegar) en el privilegio Connect SQL. De forma predeterminada, el usuario maestro recibe el privilegio Connect SQL desde la cuenta del administrador del sistema de Amazon RDS (rdsa). Sin embargo, en Microsoft SQL Server, una condición DENY explícita tiene prioridad sobre una condición GRANT (Conceder) explícita.

Para solucionarlo, siga estos pasos:

1.    Conéctese a RDS para SQL Server utilizando las credenciales de la cuenta que definió la condición DENY explícita en Connect SQL para el inicio de sesión del usuario maestro.

2.    Utilice el siguiente comando de T-SQL para revocar la condición DENY explícita. En el ejemplo siguiente, el inicio de sesión del usuario maestro de RDS es master_user y la entidad principal que concede la autorización es grantor_principal. Modifique estos valores para que se ajusten a su caso de uso.

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

Situación 2: El usuario maestro no consigue conectarse a una base de datos específica porque no está asignada a ningún usuario de la base de datos

Esto puede producirse en las siguientes circunstancias:

  • La base de datos se creó con el inicio de sesión de otra cuenta. Además, el inicio de sesión del usuario maestro no está asignado a un usuario en la base de datos y no se le conceden privilegios relativos a esta.
  • El usuario de la base de datos previamente asignado al inicio de sesión del usuario maestro con los permisos adecuados se eliminó de manera explícita.

Para solucionar este problema, restablezca la contraseña del usuario maestro. Al restablecer la contraseña, se creará un usuario de la base de datos asignado al inicio de sesión del usuario maestro, si dicho usuario se había eliminado. Asimismo, concede al usuario el rol fijo db_owner para la base de datos. Si desea obtener instrucciones sobre cómo restablecer la contraseña del usuario maestro, consulte How do I reset the master user password for my Amazon RDS DB instance? (¿Cómo restablezco la contraseña de usuario maestra de mi instancia de base de datos de Amazon RDS?).

Nota: El usuario de AWS Identify and Access Management (IAM) que vaya a restablecer la contraseña debe tener permiso para llevar a cabo la acción ModifyDBInstance en el recurso de RDS.

Al actualizar la contraseña del usuario maestro, se produce lo siguiente:

  • Se concede al usuario maestro el rol db_owner a nivel de toda la base de datos para una creada por otro usuario.
  • Se restauran los privilegios de sistema para el usuario maestro.
  • Se restauran los roles a nivel de servidor para el usuario maestro.
  • Se restauran los permisos a nivel de servidor para el usuario maestro.
  • Se restaura el acceso a los procedimientos almacenados en el sistema para el usuario maestro.
  • Se restaura el acceso a los procedimientos almacenados específicos de RDS para el usuario maestro.

Situación 3: El usuario maestro no puede llevar a cabo determinadas acciones

El usuario maestro cuenta con el permiso del rol db_owner para la base de datos, pero no puede llevar a cabo determinadas acciones, como CONNECT, SELECT, INSERT, UPDATE, ALTER, etc. Esto puede producirse cuando al usuario de la base de datos asignado al inicio de sesión del usuario maestro se le deniegan explícitamente determinados permisos en la base de datos.

Si desea ver la lista de roles de la base de datos y cuáles son los usuarios de la base de datos que pertenecer a dichos roles, ejecute el siguiente comando de T-SQL. A continuación, sustituya database_namecon los valores correctos para su caso de uso.

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;

Ejecute los siguientes comandos para ver la lista de permisos que posee un usuario en una base de datos en particular. En el ejemplo siguiente, sustituya database_name con el valor correcto para su caso de uso.

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

En este ejemplo, el usuario maestro se agrega a los roles fijos de la base de datos db_denydatawriter y db_denydatareader. A pesar de ser miembro del rol fijo de la base de datosdb_owner, los privilegios de denegación de db_denydatawriter y db_denydatareader anulan los permisos SELECT, INSERT, UPDATE y DELETE en la base de datos.

Para resolver este problema:

1.    Inicie sesión en la instancia de RDS para SQL Server con el usuario maestro.

2.    Use el siguiente comando de T-SQL para eliminar al usuario maestro como miembro de estos dos roles:

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

Cuando se hayan completado los comandos, el usuario maestro contará de nuevo con los permisos SELECT, INSERT, UPDATE y DELETE en la base de datos.

Si desea obtener más información sobre los roles específicos del usuario maestro, consulteMaster user account privileges (Privilegios de la cuenta de usuario maestro).


Información relacionada

Restablecer la contraseña para el rol db_owner

Seguridad en Microsoft SQL Server

DENY (Transact-SQL)