To, co zrobisz, będzie zależeć od wersji programu SQL Server, a także od tego, czy możesz pozwolić sobie na wycofanie usługi SQL Server w celu ustanowienia nowych poświadczeń. Dwie pierwsze metody tutaj nie wymagają ponownego uruchomienia instancji:
Dla instancji SQL Server 2005, 2008 i 2008 R2
Możesz połączyć się przy użyciu NT AUTHORITY\SYSTEM
konta (lub innych metod backdoor). Niektóre odpowiedzi znajdują się tutaj:
Mam również poradę dotyczącą witryny MSSQLTips.com, która rozwiązuje ten problem:
Zasadniczo pobierasz PSExec od Microsoft, a następnie używasz go do uruchomienia Management Studio po zainstalowaniu:
PsExec -s -i "C:\...\Ssms.exe"
To połączy się NT AUTHORITY\SYSTEM
i pozwoli ci robić rzeczy w Object Explorerze, takie jak:
Zmień instancję na SQL Server i tryb uwierzytelniania systemu Windows - kliknij prawym przyciskiem myszy nazwę serwera, wybierz właściwości i zmień przycisk opcji, jeśli jest on ustawiony tylko na system Windows:
Ustaw hasło do sa
konta - rozwiń Zabezpieczenia, rozwiń Loginy, kliknij prawym przyciskiem myszy sa
i kliknij Właściwości, aw wyświetlonym oknie dialogowym pojawią się dwa pola do wpisania hasła:
Dodaj swój login jakosysadmin
- kliknij prawym przyciskiem myszy Loginy, Nowy login ... wprowadź swoją nazwę logowania (w formularzu DOMAIN\username
), następnie przejdź do zakładki Role serwera i zaznacz sysadmin
pole i kliknij OK:
(lub, jeśli twój login jest już na liście, kliknij prawym przyciskiem myszy, Właściwości i upewnij się, że sysadmin
jest zaznaczony w obszarze Role serwera)
Dla SQL Server 2012 i nowszych wystąpień
Począwszy od SQL Server 2012, NT Authority\SYSTEM
domyślnie nie otrzymał już uprawnień do SQL Server. Argenis Fernandez szczegółowo opisał inny sposób, aby to zrobić w tych nowszych wersjach :
- Jeśli usługa SQL VSS Writer jest uruchomiona, zatrzymaj ją i zawieś wszystkie plany konserwacji lub oprogramowanie do tworzenia kopii zapasowych innych firm, które mogą na niej polegać.
Otwórz regedit.exe
i zmień wartość parametru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLWriter\ImagePath
point to SQLCMD.exe
, który będzie C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\**<...110|120|130|140...>**\Tools\Binn
. Po edycji wartość rejestru powinna wyglądać mniej więcej tak (przepraszam za przewijanie):
"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];"
Spróbuj ponownie uruchomić usługę SQL VSS Writer (pojawi się błąd; w porządku).
Powinieneś być teraz w stanie połączyć się za sysadmin
pomocą YourDomain\YourUserName
. Zatrzymaj więc usługę SQL VSS Writer, napraw rejestr i zrestartuj usługę (jeśli potrzebujesz, aby była uruchomiona lub działała przed uruchomieniem tej usługi).
Omówiłem to bardziej szczegółowo w drugiej wskazówce:
Chociaż, kiedy napisałem tę wskazówkę, zastosowałem bardziej kłopotliwe podejście do tworzenia kopii SQLCMD.exe
i zastępowania sqlwriter.exe
- o wiele łatwiej jest po prostu bezpośrednio wskazać usługę SQLCMD.exe
.
Jeśli możesz sobie pozwolić na wyłączenie usługi SQL Server
Istnieje oficjalnie obsługiwana ścieżka od Microsoft, która wymaga ponownego uruchomienia instancji w trybie pojedynczego użytkownika:
Istnieje również funkcja w dbatools.io , rozwiązaniu Powershell do zarządzania SQL Server, o nazwie Reset-DbaAdmin
:
Bezpieczeństwo nie jest tutaj głównym problemem
Widzę wiele osób wzywających Microsoft do „naprawy” tych tak zwanych „luk”. Są to poprawne podejścia do odzyskiwania dostępu do wystąpienia programu SQL Server, który masz prawo. Wszystkie wymagają podwyższonych uprawnień na hoście fizycznym, na którym rezyduje SQL Server; jak powiedziałem kilku osobom, jeśli nie chcesz, aby programiści zadzierali z instalacjami programu SQL Server, nie rób ich administratorami.