Lo que haga dependerá de su versión de SQL Server, así como de si puede darse el lujo de quitar el servicio de SQL Server para establecer nuevas credenciales. Los primeros dos métodos aquí no requieren reiniciar la instancia:
Para instancias de SQL Server 2005, 2008 y 2008 R2
Puede conectarse usando la NT AUTHORITY\SYSTEM
cuenta (u otros métodos de puerta trasera). Hay algunos detalles en algunas de las respuestas aquí:
También tengo un consejo sobre MSSQLTips.com que aborda este problema:
Básicamente, descarga PSExec de Microsoft, luego lo usa para iniciar Management Studio una vez que lo tiene instalado:
PsExec -s -i "C:\...\Ssms.exe"
Esto se conectará como NT AUTHORITY\SYSTEM
y le permitirá hacer cosas en Object Explorer, como:
Cambie la instancia a SQL Server y al modo de autenticación de Windows : haga clic con el botón derecho en el nombre del servidor, presione propiedades y cambie el botón de opción si actualmente está configurado solo en Windows:
Establezca la contraseña para la sa
cuenta : expanda Seguridad, expanda Inicios de sesión, haga clic con el botón derecho y presione sa
Propiedades, y en el cuadro de diálogo resultante habrá dos campos de ingreso de contraseña:
Agregue su propio inicio de sesión comosysadmin
: haga clic con el botón derecho en Inicios de sesión, Nuevo inicio de sesión ... ingrese su nombre de inicio de sesión (en el formulario DOMAIN\username
), luego vaya a la pestaña Roles del servidor y marque la sysadmin
casilla y haga clic en Aceptar:
(o, si su inicio de sesión ya está en la lista, haga clic con el botón derecho en Propiedades y asegúrese de que sysadmin
esté marcado en Roles del servidor)
Para SQL Server 2012 y las instancias más recientes
A partir de SQL Server 2012, NT Authority\SYSTEM
ya no se le otorgaron derechos a SQL Server de forma predeterminada. Así que Argenis Fernández ha detallado otra forma de hacerlo en estas versiones más nuevas :
- Si el servicio SQL VSS Writer se está ejecutando, deténgalo y suspenda todos los planes de mantenimiento o software de respaldo de terceros que puedan depender de él.
Abra regedit.exe
y cambie el valor de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLWriter\ImagePath
para apuntar SQLCMD.exe
, que va a estar adentro C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\**<...110|120|130|140...>**\Tools\Binn
. Después de editar, el valor del registro debería ser similar al siguiente (perdón por el desplazamiento):
"C:Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.exe" -S .\instancename -E -Q "ALTER ROLE sysadmin ADD MEMBER [YourDomain\YourUserName];"
Intente iniciar el servicio SQL VSS Writer nuevamente (obtendrá un error; está bien).
Ahora debería poder conectarse como sysadmin
usando YourDomain\YourUserName
. Por lo tanto, detenga el servicio SQL VSS Writer, repare el registro y reinicie el servicio (si necesita que se esté ejecutando, o si se estaba ejecutando antes de comenzar esto).
He pasado por esto con mucho más detalle en un segundo consejo:
Sin embargo, cuando escribí esa sugerencia, utilicé un enfoque más engorroso de hacer una copia SQLCMD.exe
y reemplazarla sqlwriter.exe
, mucho más fácil señalar el servicio SQLCMD.exe
directamente.
Si puede permitirse quitar el servicio de SQL Server
Hay una ruta oficial de Microsoft que requiere reiniciar la instancia en modo de usuario único:
También hay una función en dbatools.io , una solución de Powershell para administrar SQL Server, llamada Reset-DbaAdmin
:
La seguridad no es el problema principal aquí
Veo a muchas personas que piden a Microsoft que "repare" estas llamadas "vulnerabilidades". Estos son enfoques válidos para recuperar el acceso a una instancia de SQL Server que usted posee legítimamente. Todos requieren privilegios elevados en el host físico donde reside SQL Server; como le he dicho a varias personas, si no desea que los desarrolladores jueguen con las instalaciones de SQL Server, no los convierta en administradores.