Использование локальных учетных записей (в том числе локального администратора) для доступа по сети в средах Active Directory нежелательно по ряду причин. Зачастую на многих компьютерах используются одинаковые имя и пароль локального администратора, что может поставить под угрозу множество систем при компрометации одного компьютера (угроза атаки Pass-the-hash). Кроме того, доступ под локальными учетными записями по сети трудно персонифицировать и централизованно отследить, т.к. подобные события не регистрируются на контроллерах домена AD.
Для снижения рисков, администраторы могут изменить имя стандартной локальной учетной записи администратора Windows (Administrator). Для регулярной смены пароля локального администратора на всех компьютерах в домене можно использовать MS LAPS (Local Administrator Password Solution). Но этими решениями не удастся решить проблему ограничения сетевого доступа под локальными учетными записями, т.к. на компьютерах может быть больше одной локальной учетки.
Ограничить сетевой доступ для локальных учетных записей можно с помощью политики Deny access to this computer from the network. Но проблема в том, что в данной политике придется явно перечислить все имена учетных записей, которым нужно запретить сетевой доступ к компьютеру.
В Windows 8.1 and Windows Server 2012 R2 появилась две новые группы безопасности (Well-known group) с известными SID. Одна включает в себя всех локальных пользователей, а вторая всех локальных администраторов.
S-1-5-113 | NT AUTHORITY\Local account | Все локальные учетная запись |
S-1-5-114 | NT AUTHORITY\Local account and member of Administrators group | Все локальные учетные записи с правами администратора |
Теперь для ограничения доступа локальным учетным записям не нужно перечислять все возможные варианты SID локальных учёток, а использовать их общий SID.
Данные группы добавляются в токен доступа пользователя при входе в систему под локальной учетной записью.
Чтобы убедится, что в Windows 10/Windows Server 2016 локальной учетной записи присвоены две новый группы
NT AUTHORITY\Local account (SID S-1-5-113)
и
NT AUTHORITY\Local account and member of Administrators group (SID S-1-5-114)
, выполните команду:
whoami /all
Проверить, имеются ли данные группы безопасности в вашей Windows можно по их SID так:
$objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-113")
$objAccount = $objSID.Translate([System.Security.Principal.NTAccount])
$objAccount.Value
Если скрипт возвращает NT Authority\Local account, значит данная локальная группа (с этим SID) имеется.
Чтобы запретить сетевой доступ под локальным учетным записями, с этими SID-ами в токене, можно воспользоваться политиками из раздела GPO Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
Запрет на вход через RDP для локальных пользователей и администратора
Политика Deny log on through Remote Desktop Services (Запретить вход в систему через службу с удаленного рабочего стола) позволяет указать пользователей и группы, которым явно запрещен удаленный вход на компьютер через RDP. Вы можете запретить RDP доступ к компьютеру для локальных или доменных учетных записей.
Если вы хотите запретить RDP подключения только локальных пользователей (в том числе локальных администраторов), откройте локальной редактор GPO gpedit.msc (если вы хотите применить эти настройка на компьютерах в домене AD, используйте редактор доменных политик –
gpmc.msc
). Перейдите в указанную выше секцию GPO и отредактируйте политику Deny log on through Remote Desktop Services.
Добавьте в политику встроенные локальные группу безопасности Local account and member of Administrators group и Local account. Обновите настройки локальных политик с помощью команды: gpupdate /force.
Теперь, если вы попытаетесь подключиться к компьютеру по RDP, появится ошибка:
To sign in remotely, you need the right to sign in through Remote Desktop Services. By default, members of the Remote Desktop Users group have this right. If the group you’re in doesn’t have this right, or if the right has been removed from the Remote Desktop Users group, you need to be granted this right manually.
Чтобы войти в систему удаленно, вам нужно право на вход через службы удаленных рабочих столов. По умолчанию такое право имеют члены группы Администраторы. Если у вашей группы нет этого права или оно было удалено для группы Администраторы, попросите предоставить его вам вручную.
Запрет сетевого доступа к компьютеру по сети
Вы можете запретить сетевой доступ к компьютеру под локальными учетными данными с помощью политики Deny access to this computer from the network (Отказать в доступе к этому компьютеру из сети).
Добавьте в политику Deny access to this computer from the network локальные группы Local account и Local account and member of Administrators group. Также стоит всегда запрещать анонимный доступ и доступ под гостевым аккаунтом.
После применения политики вы не сможете удаленно подключиться к этому компьютеру по сети под любой локальной учетной записью. При попытке подключиться к сетевой папке или подключить сетевой диск с этого компьютера под локальной учетной записью, появится ошибка:
Microsoft Windows Network: Logon failure: the user has not been granted the requested logon type at this computers.
При попытке установить RDP сессию под учетной записью локального администратора (.\administrator) появится сообщение об ошибке.
The system administrator has restricted the types of logon (network or interactive) that you may use. For assistance, contact your system administrator or technical support.
Системный администратор ограничил типы входа в систему (сетевой или интерактивный), которые можно использовать. Обратитесь за помощью к системному администратору или в службу технической поддержки.
Запретить локальный вход в Windows
С помощью политики Deny log on locally (Запретить локальных вход) вы можете запретить и интерактивный вход на компьютер/сервер под локальными учетными записями. Перейдите в секцию GPO User Rights Assignment, отредактируйте политику Deny log on locally. Добавьте в нее нужную локальную группу безопасности.
Теперь, если пользователь или администратор попытается авторизоваться на компьютере под локальной учетной записью, появится сообщение.
The sign-in method you are trying to use isn’t allowed. For more info, contact your network administrator.
Этот метод входа запрещено использовать. Для получения дополнительных сведений обратитесь к администратору своей сети.
Таким образом, вы можете ограничить доступ под локальными учетными записями на компьютеры и сервера домена, увеличить защищенность корпоративной сети.
Спасибо за прекрасную статью !!!
Но у меня неожиданно возникла проблема с распространением данных настроек через GPO на контроллере домена под управлением русской версии Server 2008 R2.
Группа безопасности S-1-5-114 называется в русской версии Локальная учетная запись и член группы «Администраторы» (с кавычками в названии). При добавлении этой группы появляется сообщение «Имя пользователя и группы не может содержать ни одного из следующих знаков…», далее перечисляются знаки в том числе и кавычки. Что делать-то ?
Вот за это я предпочитаю ставить английские версии серверного ПО…
Пробовали руками добавить группу в GPO? В окне добавления выберите:
1. местоположение (имя_сервера)
2. Кнопка дополнительно
3. Найти сейчас
4. В списке групп и учеток выбрать «Локальная учетная запись и член группы «Администраторы»»
5. Ок
Для русско-язычных страдальцев). Используйте тулзу от MS server 2003: ntrights.exe (в справке по командам SeInteractiveLogonRight отсутствует 😉 сама утилитка имеет корни с nt 4.0)
сначала доверьте права на группу: ntrights.exe +r SeInteractiveLogonRight -u «локальная учетная запись»
потом удалите права: ntrights.exe -r SeInteractiveLogonRight -u «локальная учетная запись»
в результате вновь созданный локальный пользователь не будет иметь доступ и права запускать процесс (даже если его поместить в группу админы)
Не забудьте залочить таким образом и локального «админа» или другие уже созданные учетки.
Ну и предусмотреть аварийный сценарий восстановления прав (имейте ввиду, что это не локальные шаблоны безопасности и GPO настройки)…
Распространяем через GPO тулзу и не затейный код в логон скрипт. Протестированно для Win7x64 и Win10x64, все с последними обновами.
Если хотите еще альтернативу по блокировке много чего: https://www.powershellgallery.com/packages/cUserRightsAssignment/1.0.2
https://github.com/SNikalaichyk/cUserRightsAssignment/blob/master/DSCResources/cUserRight/cUserRight.psm1
Пробовал — не получается также. Через GPO никак не получилось.
Работает только вариант настройки через оснастку gpedit.msc, ее кавычки при добавлении группы не смущают. Но это означает ручной труд на каждой машине.
Попробуйте в доменную GPO добавить непосредственно SID-ы групп: S-1-5-113, S-1-5-114
Нашел каталог с политикой в \\sysvol\имя домена\Policies
Внес руками следующие настройки
[Privilege Rights]
SeDenyNetworkLogonRight = *S-1-5-113,*S-1-5-114
На компьютере под этой политикой запустил rsop.msc, увидел, что ошибки при применении политики.
Смотрю лог C:\Windows\security\logs\winlogon.log и что там вижу: !!!!!!!!!!!!!!!!
—-Настройка прав пользователя…
Настройка Локальная учетная запись и член группы Администраторы.
Ошибка 1332: Сопоставление между именами пользователей и идентификаторами безопасности не было произведено.
Не удалось найти Локальная учетная запись и член группы Администраторы.
Настройка S-1-5-113.
Настройка S-1-5-21-2306648808-2876377639-3490863382-514.
Ошибка при настройке прав пользователя.
Волшебным образом на клиенте ищется группа с названием Локальная учетная запись и член группы Администраторы без кавычек в названии. Естественно ее нет, т.к. запуск powershell — скрипта
$objSID = New-Object System.Security.Principal.SecurityIdentifier («S-1-5-114»)
$objAccount = $objSID.Translate([System.Security.Principal.NTAccount])
$objAccount.Value
возвращает значение с кавычками
NT AUTHORITY\Локальная учетная запись и член группы «Администраторы»
Мне это напомнило лажу с *S-1-5-33 или ЗАПИСЬ ОГРАНИЧЕНА — ругается, что такого пользователя нет!
— Как нет? У кого тогда разрешено TRACELOG_LOG_EVENT?
Ну и как настроить его в «Поставщиках отслеживания» (perfmon.msc: «Группы сборщиков данных\Сеасны отслеживания событий запуска» – выбираем журнал и видим вкладку с этим названием, ищем «поставщика» и жмём кнопку Безопасность…)? В HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT далеко не всё доступно для настройки…
Ещё бесит, что любой «ныне отсутствующий» SID через GUI-шное окошко ввода имени пользователя/группы добавить нельзя!
А вот то, что винда почему-то делает лишнюю работу, преобразуя SID`ы в локализированные имена (т.е. «самой-себе-не-понятные») там, где это не должно быть предусмотрено – с другой стороны это даже мило =)
Здравствуйте. Есть домен и сервер 2003. Сейчас к нему подключаюсь по RDP для работы то от лок. администратора, то от доменной уч. записи администратора. Пользователи не могут войти на сервер. Вопрос: под кем тогда подключаться по RDP лучше всего? Если лок. админа нужно ограничить, а под доменным администратором нельзя. Спасибо.
Если у вас есть домен — то однозначно пользуйтесь доменными учетными записями. Чтобы дать право пользователю на RDP-подключение, достаточно добавить его в локальную группу Remote Desktop Users (в админы добавлять не нужно).
Если нужен RDP доступ пользователю к контроллеру домена (DC), можно сделать так: https://winitpro.ru/index.php/2015/02/27/kak-razreshit-obychnym-polzovatelyam-rdp-dostup-k-kontrolleru-domena/
Друзья, а возможно ли запретить учётной записи с правами админа вход в систему, при этом оставив возможность запускать программы от имени этой УЗ?
Если заблокировать interactive login (Deny log on locally) в GPO для учетки, скорее всего и в runus ее не получиться использовать.
Windows 7 GPO Preventing admins from interactively logging in, but still allowing Run As / permission escalation
_https://serverfault.com/questions/612289/windows-7-gpo-preventing-admins-from-interactively-logging-in-but-still-allowin
Совершенно верно, не получится, я проверял.
Хотя вот нашел костыль с запуском команды logoff для пользователя с правами админа при входе в систему через GPO.
_https://www.authlite.com/kb/allow-runas-but-block-interactive-logon