Его нельзя отключить полностью по двум причинам:
На установке, логины обеспечиваются резервы NT AUTHORITY\SYSTEM
, NT SERVICE\SQLSERVERAGENT
(или группа , содержащая учетную запись службы агента SQL), и NT SERVICE\MSSQLSERVER
(или группа , содержащей SQL учетной записи службы двигателя базы данных). Это sysadmin
логины высокого уровня, которые должны быть доступны для правильной работы SQL Server.
Несмотря на то, что быстрый тест показал, что удаление всех этих трех имен входа только препятствовало перезапуску агента SQL (ядро базы данных работало нормально), я уверен, что есть другие функции, которые полагаются на два других входа ... они были созданы по умолчанию по какой-то причине, поэтому я не стал бы возиться с ними. (К вашему сведению, если вы сами это проверите: опция сценариев Drop & Create для входа в SSMS не поддерживает членство в роли сервера).
В однопользовательском режиме локальным администраторам автоматически предоставляются sysadmin
привилегии уровня независимо от того, существует ли созданный логин, который «содержит» этих пользователей. Это вешалка для одежды, когда вы заперли ключи в машине.
Как упоминалось в другом ответе, доступ к соединению будут иметь только явно созданные учетные записи Windows (мой исходный комментарий был неверным) - для предотвращения доступа достаточно удалить все созданные пользователем учетные записи Windows.
Если вам нужно пойти на шаг дальше и Предотвратить Windows , логины от того создан , вот отправной точкой (управление на основе политик, по крайней мере , в 2008 году, не поддерживает предотвращения этого , как это происходит):
CREATE TRIGGER trg_PreventWindowsLogins
ON ALL SERVER
AFTER CREATE_LOGIN
AS
BEGIN
SET NOCOUNT ON;
IF (EVENTDATA().exist('/EVENT_INSTANCE[1]/LoginType[1]/text()[1] eq "Windows (NT) Login"') = 1)
BEGIN
RAISERROR(N'Not allowed to create Windows logins!', 16, 1);
ROLLBACK;
END
END
Конечно, любой, у кого достаточно прав, может победить это, но это отдельная проблема ...