Quello che farai dipenderà dalla tua versione di SQL Server, oltre che dalla possibilità di permetterti di disattivare il servizio SQL Server per stabilire nuove credenziali. I primi due metodi qui non richiedono il riavvio dell'istanza:
Per istanze di SQL Server 2005, 2008 e 2008 R2
È possibile connettersi utilizzando l' NT AUTHORITY\SYSTEM
account (o altri metodi backdoor). Ci sono alcuni dettagli in alcune delle risposte qui:
Ho anche un suggerimento su MSSQLTips.com che risolve questo problema:
In sostanza, scarichi PSExec da Microsoft, quindi lo usi per avviare Management Studio dopo averlo installato:
PsExec -s -i "C:\...\Ssms.exe"
Questo si connetterà come NT AUTHORITY\SYSTEM
e ti permetterà di fare cose in Esplora oggetti, come:
Cambia l'istanza in SQL Server e la modalità di autenticazione di Windows : fai clic con il pulsante destro del mouse sul nome del server, premi proprietà e modifica il pulsante di opzione se è attualmente impostato solo su Windows:
Imposta la password per l' sa
account : espandi Sicurezza, espandi Login, fai clic con il pulsante destro del mouse sa
e premi Proprietà e nella finestra di dialogo risultante ci saranno due campi di immissione della password:
Aggiungi il tuo login comesysadmin
: fai clic con il pulsante destro del mouse su Login, Nuovo accesso ... inserisci il tuo nome di accesso (nel modulo DOMAIN\username
), quindi passa alla scheda Ruoli del server e seleziona la sysadmin
casella e fai clic su OK:
(oppure, se il tuo accesso è già elencato, fai clic con il pulsante destro del mouse su Proprietà e assicurati che sysadmin
sia selezionato in Ruoli server)
Per SQL Server 2012 e istanze più recenti
A partire da SQL Server 2012, NT Authority\SYSTEM
per impostazione predefinita non sono stati dati i diritti a SQL Server. Quindi un altro modo per farlo in queste versioni più recenti è stato dettagliato da Argenis Fernandez :
- Se il servizio SQL VSS Writer è in esecuzione, interromperlo e sospendere tutti i piani di manutenzione o software di backup di terze parti che potrebbero fare affidamento su di esso.
Apri regedit.exe
e modifica il valore di HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLWriter\ImagePath
puntare a SQLCMD.exe
, che sarà C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\**<...110|120|130|140...>**\Tools\Binn
. Dopo la modifica, il valore del registro dovrebbe essere simile al seguente (scusate lo scorrimento):
"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];"
Prova a riavviare il servizio SQL VSS Writer (visualizzerai un errore; va bene).
Ora dovresti essere in grado di connetterti come sysadmin
usando YourDomain\YourUserName
. Quindi interrompere il servizio SQL VSS Writer, correggere il registro e riavviare il servizio (se è necessario che sia in esecuzione o se era in esecuzione prima di iniziare questo).
Ho esaminato questo aspetto in modo molto più dettagliato in un secondo suggerimento:
Anche se quando ho scritto quel suggerimento ho usato un approccio più ingombrante per fare una copia SQLCMD.exe
e sostituirla sqlwriter.exe
- molto più semplice puntare SQLCMD.exe
direttamente il servizio .
Se puoi permetterti di disattivare il servizio SQL Server
Esiste un percorso ufficialmente supportato da Microsoft che richiede il riavvio dell'istanza in modalità utente singolo:
Esiste anche una funzione in dbatools.io , una soluzione Powershell per la gestione di SQL Server, chiamata Reset-DbaAdmin
:
La sicurezza non è il problema principale qui
Vedo molte persone che chiedono a Microsoft di "correggere" queste cosiddette "vulnerabilità". Questi sono approcci validi per il recupero dell'accesso a un'istanza di SQL Server di cui si possiede correttamente. Richiedono tutti privilegi elevati sull'host fisico in cui risiede SQL Server; come ho detto a diverse persone, se non si desidera che gli sviluppatori facciano casino con le installazioni di SQL Server, non renderli amministratori.