O que você fará dependerá da sua versão do SQL Server e também poderá reduzir o serviço do SQL Server para estabelecer novas credenciais. Os dois primeiros métodos aqui não exigem a reinicialização da instância:
Para instâncias do SQL Server 2005, 2008 e 2008 R2
Você pode se conectar usando a NT AUTHORITY\SYSTEM
conta (ou outros métodos de backdoor). Existem alguns detalhes em algumas das respostas aqui:
Eu também tenho uma dica sobre MSSQLTips.com que aborda esse problema:
Basicamente, você baixa o PSExec da Microsoft e o utiliza para iniciar o Management Studio depois de instalá-lo:
PsExec -s -i "C:\...\Ssms.exe"
Isso se conectará NT AUTHORITY\SYSTEM
e permitirá que você faça coisas no Pesquisador de Objetos, como:
Altere a instância para o modo de autenticação do SQL Server e do Windows - clique com o botão direito do mouse no nome do servidor, clique em Propriedades e altere o botão de opção se atualmente estiver definido apenas para Windows:
Defina a senha da sa
conta - expanda Segurança, expanda Logons, clique com o botão direito do mouse sa
e pressione Propriedades e, na caixa de diálogo resultante, haverá dois campos de entrada de senha:
Adicione seu próprio logon comosysadmin
- clique com o botão direito do mouse em Logins, Novo Logon ... digite seu nome de logon (no formulário DOMAIN\username
), vá para a guia Funções do Servidor e marque a sysadmin
caixa e clique em OK:
(ou, se seu login já estiver listado, clique com o botão direito do mouse em Propriedades e verifique se sysadmin
está marcado em Funções do servidor)
Para SQL Server 2012 e instâncias mais recentes
A partir do SQL Server 2012, NT Authority\SYSTEM
não era mais concedido direitos ao SQL Server por padrão. Portanto, outra maneira de fazer isso nessas versões mais recentes foi detalhada por Argenis Fernandez :
- Se o serviço SQL VSS Writer estiver em execução, pare-o e suspenda todos os planos de manutenção ou software de backup de terceiros que possam depender dele.
Abra regedit.exe
e altere o valor de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLWriter\ImagePath
para apontar para o SQLCMD.exe
qual será exibido C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\**<...110|120|130|140...>**\Tools\Binn
. Após a edição, o valor do registro deve se parecer com o seguinte (desculpe pela rolagem):
"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];"
Tente iniciar o serviço SQL VSS Writer novamente (você receberá um erro; tudo bem).
Agora você deve conseguir se conectar como sysadmin
usando YourDomain\YourUserName
. Portanto, pare o serviço Gravador VSS do SQL, corrija o registro e reinicie o serviço (se você precisar que esteja em execução ou se estava em execução antes de iniciar isso).
Já passei por isso com muito mais detalhes em uma segunda dica:
Porém, quando escrevi essa dica, usei uma abordagem mais complicada de fazer uma cópia SQLCMD.exe
e substituir sqlwriter.exe
- muito mais fácil apenas apontar o serviço SQLCMD.exe
diretamente.
Se você pode se dar ao luxo de desativar o serviço SQL Server
Há um caminho oficialmente suportado pela Microsoft que requer a reinicialização da instância no modo de usuário único:
Há também uma função no dbatools.io , uma solução Powershell para gerenciar o SQL Server, chamada Reset-DbaAdmin
:
Segurança não é o principal problema aqui
Vejo muitas pessoas pedindo que a Microsoft "conserte" essas chamadas "vulnerabilidades". Essas são abordagens válidas para recuperar o acesso a uma instância do SQL Server que você possui por direito. Todos eles exigem privilégios elevados no host físico em que o SQL Server reside; como já disse a várias pessoas, se você não quiser que os desenvolvedores mexam nas instalações do SQL Server, não os torne administradores.