То, что вы будете делать, будет зависеть от вашей версии SQL Server, а также от того, сможете ли вы позволить себе отключить службу SQL Server, чтобы установить новые учетные данные. Первые два метода здесь не требуют перезапуска экземпляра:
Для экземпляров SQL Server 2005, 2008 и 2008 R2
Вы можете подключиться, используя NT AUTHORITY\SYSTEM
учетную запись (или другие методы бэкдора). Есть некоторые детали в некоторых ответах здесь:
У меня также есть подсказка на MSSQLTips.com, которая решает эту проблему:
По сути, вы загружаете PSExec от Microsoft, а затем используете его для запуска Management Studio после его установки:
PsExec -s -i "C:\...\Ssms.exe"
Это соединит вас NT AUTHORITY\SYSTEM
и позволит вам делать вещи в Object Explorer, например:
Измените экземпляр на SQL Server и режим проверки подлинности Windows - щелкните правой кнопкой мыши имя сервера, выберите свойства и установите переключатель, если в данный момент он установлен только для Windows:
Установите пароль для sa
учетной записи - разверните Security, разверните Logins, щелкните правой кнопкой мыши sa
и нажмите «Properties», и в появившемся диалоговом окне появятся два поля ввода пароля:
Добавьте свой собственный логин какsysadmin
- щелкните правой кнопкой мыши Logins, New Login ... введите ваше логин (в форме DOMAIN\username
), затем перейдите на вкладку Server Roles и установите sysadmin
флажок и нажмите OK:
(или, если ваш логин уже указан, щелкните правой кнопкой мыши «Свойства» и убедитесь, что sysadmin
установлен флажок «Роли сервера»).
Для SQL Server 2012 и более новых экземпляров
Начиная с SQL Server 2012, NT Authority\SYSTEM
больше не были предоставлены права на SQL Server по умолчанию. Итак, еще один способ сделать это в этих новых версиях был подробно описан Аргенисом Фернандесом :
- Если служба SQL VSS Writer работает, остановите ее и приостановите все планы обслуживания или стороннее программное обеспечение для резервного копирования, которое может на него полагаться.
Откройте regedit.exe
и измените значение, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLWriter\ImagePath
чтобы указать SQLCMD.exe
, что будет в C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\**<...110|120|130|140...>**\Tools\Binn
. После редактирования значение реестра должно выглядеть примерно так (извините за прокрутку):
"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];"
Попробуйте снова запустить службу SQL VSS Writer (вы получите сообщение об ошибке; ничего страшного).
Теперь вы должны быть в состоянии подключиться как sysadmin
используя YourDomain\YourUserName
. Поэтому остановите службу SQL VSS Writer, исправьте реестр и перезапустите службу (если вам нужно, чтобы она была запущена или работала до того, как вы ее запустили).
Я рассмотрел это более подробно во втором совете:
Хотя, когда я писал этот совет, я использовал более громоздкий подход к созданию SQLCMD.exe
и замене копии sqlwriter.exe
- гораздо проще просто указать сервис SQLCMD.exe
напрямую.
Если вы можете позволить себе отключить службу SQL Server
Существует официально поддерживаемый путь от Microsoft, который требует перезапуска экземпляра в однопользовательском режиме:
В dbatools.io , решении Powershell для управления SQL Server, также есть функция Reset-DbaAdmin
:
Безопасность не главная проблема здесь
Я вижу множество людей, призывающих Microsoft «исправить» эти так называемые «уязвимости». Это допустимые подходы для восстановления доступа к экземпляру SQL Server, который по праву принадлежит вам. Все они требуют повышенных привилегий на физическом хосте, где находится SQL Server; как я уже говорил нескольким людям, если вы не хотите, чтобы разработчики возились с установками SQL Server, не назначайте их администраторами.