Как ограничить права пользователя в windows server 2016

Групповые политики являются одним из самых эффективных способов управления компьютерной сетью, построенной на базе Windows-сетей. Групповые политики используют для упрощения администрирования, предоставляя администраторам централизованное управление привилегиями, правами и возможностями как пользователей, так и компьютеров сети.

При помощи политики возможно:

• назначать сценарии пользователя и сценарии компьютера, запускающиеся в конкретно указанное время;
• определять политики параметров пароля учетных записей, блокировку пользователей;
• распространять программное обеспечение на компьютеры сети при помощи публикации или назначения;
• выполнять набор настроек безопасности для удаленных машин;
• ввести контроль над доступом к windows-компонентам, системным ресурсам, сетевым ресурсам, утилитам панели управления, рабочему столу и экрану;
• проводить настройку по распределению прав на доступ к файлам и папкам;
• настраивать перенаправление определенных папок из профиля пользователя.

Групповые политики возможно применять сразу на нескольких доменах, на отдельных доменах, на подгруппах в домене, на отдельных системах.

Политики, применяемые к отдельным системам, называются локальными групповыми политиками. Такие политики хранятся только на локальном компьютере. Остальные групповые политики соединены в объекты и хранятся в хранилище данных Active Directory.

Управление групповых политик имеется только в профессиональных и серверных версиях Windows.

Для каждой новой версии Windows вносились новые изменения в групповую политику. В некоторых случаях старые политики не применяются на новые версии Windows.

Обычно большинство политик прямо совместимы. Это означает, что, как правило, политики, предоставленные в Windows Server 2003, могут использоваться на Windows 7 и более поздних, а также на Windows Server 2008 и более поздних. Однако, политики для Windows 8/10 и Windows Server 2012/2016 обычно не применимы к более ранним версиям Windows. Для того, чтобы узнать какие версии поддерживает политика, можно открыть окно ее свойств – там посмотреть на поле Требование к версии или поддерживается. В нем указаны версии ОС, на которых эта политика будет работать:

Редактирование групповых политик

Консоль редактирования групповой политики входит в состав сервера, ее требуется установить в диспетчере сервера как дополнительный компонент управления групповыми политиками:

После этого в составе программ меню Администрирование появляется задача Управление групповыми политиками.

В оснастке Управление групповой политикой назначаются политики к подразделениям, а благодаря иерархической структуре можно визуально понять к какой группе относятся какая-либо политика:

Групповая политика изменяется в редакторе управления групповыми политиками – для этого требуется выбрать команду Изменить в меню Действия. Так же новую групповую политику можно создать либо «с нуля», для этого выбираем Объекты групповой политики выбираем команду Создать в меню Действие. Записываем новое имя объекта групповой политики после этого нажимаем ОК. Можно скопировать в нее параметры уже существующей политики в зависимости от требуемой задачи.

Чтобы применить созданную политику, требуется установить для нее связь с соответствующим объектом службы каталогов в оснастке Управление групповой политикой:

Примененную политику можно настроить по фильтру безопасности. Таким способом параметры данного объекта групповой политики возможно разделить только для заданных групп, пользователей и компьютеров, входящих в домен:

Рекомендации по применению политик

Главное заключается в том, чтобы не изменять политику по умолчанию. Потому как если в политике возникнет какая-либо серьезная ошибка, то возврат к начальному состоянию приведет к удалению не только последних настроек, но и всех других параметров. Поэтому для административных действий по управлению системой создавайте новые политики, тогда для изменения настроек вам потребуется только отключать/включать привязку политик к организационной структуре.

Обработка одной политики с наибольшим числом назначенных параметров, не отличается по времени от обработки нескольких политик, в каждой из которых назначается только часть этих параметров. Поэтому удобнее создавать несколько политик, чем включать все изменения в одну.

Не стоит удалять ранее созданные групповые политики – желательно просто отключить привязку их от объекта службы каталогов. Они могут потребоваться в дальнейшем для анализа в случае каких-либо проблем.

В рамках нашей услуги ИТ-обслуживание мы не только настраиваем групповые политики, но и берем на себя обслуживание всей ИТ-структуры клиента, включая все настройки, обновления ПО и поддержку в режиме 24/7.

[конспект админа] Меньше администраторов всем

Продолжим про безопасность операционных систем – на этот раз «жертвой» станет MS Windows и принцип предоставления минимальных прав для задач системного администрирования.

Сотрудникам, ответственным за определенные серверы и рабочие станции совсем не обязательно выдавать права «администратор домена». Хоть не по злому умыслу, по ошибке, но это может подпортить всем жизнь, а то и стоить чьих-то выходных. Под катом детально разберем принцип предоставления минимальных прав как одну из технологий предоставления минимальных прав.

Ограниченные группы

В качестве примера из практики могу привести грустную историю со счастливым концом. В организации исторически сложилось, что сервер печати находился на контроллере домена. В один прекрасный момент сотруднику отдела IT понадобилось перепрошить принтер, что он и проделал, запустив китайскую утилиту на сервере. Принтер заработал, но вот утилита в процессе перепрошивки перевела время на несколько лет назад. Active directory не очень любит путешественников во времени, и контроллер домена благополучно отправился в «захоронение» (tombstone).

Инцидент добавил седых волос, но второй контроллер домена спас ситуацию: роли FSMO перевели на него, а путешественника во времени повторно сделали контроллером домена. С тех пор в компании права «администратора домена» нужно заслужить.

Для профилактики подобных ситуаций неплохо будет выдавать желающим ровно столько прав, сколько нужно: если нужно администрировать только рабочие станции, достаточно выдать права только на компьютеры пользователей.

Когда компьютеров немного, включить доменную группу безопасности «helpdesk» в локальную группу «администраторы» можно и руками. А вот на большом объеме приходят на помощь групповые политики. Удобных способов два.

Первый способ: через Группы с ограниченным доступом (Restricted groups), расположенные в групповых политиках по адресу Конфигурация компьютера – Политики – Параметры безопасности.

Расположение политик Restricted groups.

Далее нужно создать группу «Администраторы» и добавить в нее нужную группу. Есть только один нюанс – если сделать именно так, то из локальной группы «Администраторы» исчезнут все, кроме встроенного администратора и самой группы. Даже Domain Admins:

Добавляем группу «Администраторы», в которую добавляем группу helpdesk.

И получаем локальную группу «Администраторы» без Domain admins.

Конечно, эту возможность можно использовать и во благо – зачистить локальные группы от лишних участников. Если же хочется избежать такой зачистки, то можно создать в «Группах ограниченного доступа» доменную группу и ее же назначить входящей в группу «Администраторы»:

При такой настройке локальная группа «Администраторы» не будет зачищена.

Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.

Настройка группы безопасности через GPP.

Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.

Таким же способом можно дать права и на определенные серверы нужным сотрудникам. Например, дать права группе разработчиков на тестовый стенд.

Использование встроенных групп безопасности

Конечно, сотрудников отдела IT и системные учетные записи (например, под которыми выполняются задачи резервного копирования) проще сразу включить в группу «Enterprise Admins» и не знать горя.

Но из соображений безопасности лучше так не делать. В Windows существует набор встроенных учетных записей с набором типовых прав. Группы немного различаются для компьютера и для домена, а также ряд сервисов привносит свои группы.

Если стандартных групп не хватает, то Windows позволяет настроить права доступа более тонко. Например, выдать отдельной группе пользователей право менять время или возможность принудительно завершать работу сервера по сети. Для этого существует механизм «назначение прав пользователей». Искать можно в локальной политике безопасности – secpol.msc или в групповой политике по адресу Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Назначение прав пользователя.

Настройка прав доступа через групповые политики.

Использовать эту настройку я рекомендую в крайних случаях, и ее обязательно надо документировать. Помните о том, что когда-нибудь вас кто-то сменит и будет разбираться, почему работает так, а не иначе.

Вообще лучше всегда все документировать. Представьте ситуацию, что вы уволились из организации и вместо вас пришел человек с улицы. Поставьте себя на место этого человека. Если начал дергаться глаз или зашевелились волосы – посвятите время написанию документации. Пожалуйста!

Существует еще один хороший метод ограничения доступа к объектам – делегирование. Про эту технологию на Хабре уже писали, поэтому я лишь добавлю, что с помощью делегирования удобно выдаются права для ввода нового компьютера в домен.

Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 102016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.

Достаточно администрирования

Just Enough Administration (JEA) – технология предоставления доступа к командлетам PowerShell. Работает на операционных системах вплоть до Windows 7 при установке Windows Management Framework 5.1 (правда, в самых старых операционных системах поддержка ограничена). Работа производится через так называемые «виртуальные аккаунты» и специально подготовленные файлы конфигурации. Примером использования JEA является выдача ограниченных прав на управление определенными виртуальными машинами – например, для ваших разработчиков.

Подробнее про JEA можно почитать в официальной документации, поэтому разберем конкретный пример предоставления возможности перезапуска виртуальной машины.

Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.

Проверка версии и разрешение удаленных подключений при помощи PS.

Создадим группу безопасности и специального пользователя:

$VMOperatorGroup = New-ADGroup -Name "VM-operators" -GroupScope DomainLocal -PassThru
$OperatorUser = New-ADUser -Name "VMOperator" -AccountPassword (ConvertTo-SecureString 'P@ssword1' -AsPlainText -Force) -PassThru
Enable-ADAccount -Identity $OperatorUser
Add-ADGroupMember -Identity $VMOperatorGroup -Members $OperatorUser

Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:

New-Item -Path "C:Program FilesWindowsPowerShellModulesDemo_Module" -ItemType Directory
New-ModuleManifest -Path "C:Program FilesWindowsPowerShellModulesDemo_ModuleDemo_Module.psd1"
New-Item -Path "C:Program FilesWindowsPowerShellModulesDemo_ModuleRoleCapabilities" -ItemType Directory

А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:

$VMRoleCapabilityParams = @{
  Author = 'Сервер Молл'
  Description = 'VM Role Capability File'
  CompanyName = 'ServerMall'
VisibleCmdlets= 'Get-VM',
 @{ Name='Start-VM'; Parameters=@{ Name='Name'; ValidateSet='win' } },
 @{ Name = 'Stop-VM'; Parameters = @{ Name = 'Name'; ValidateSet = 'win'}}
New-PSRoleCapabilityFile -Path "$ENV:ProgramFilesWindowsPowerShellModulesDemo_ModuleRoleCapabilitiesVMRoleCapability.psrc" @VMRoleCapabilityParams

Теперь необходимо подготовить файл сессии PowerShell:

$NonAdministrator = "DOMAINVM-win-Operators"

$ConfParams = @{
  SessionType = 'RestrictedRemoteServer'
  RunAsVirtualAccount = $true
  RoleDefinitions = @{
    $NonAdministrator = @{ RoleCapabilities = 'VMRoleCapability'}
  }
  TranscriptDirectory = "$env:ProgramDataJEAConfigurationTranscripts"
}

New-Item -Path "$env:ProgramDataJEAConfiguration" -ItemType Directory
$SessionName = 'VM_OperatorSession'
New-PSSessionConfigurationFile -Path "$env:ProgramDataJEAConfigurationVM.pssc" @ConfParams

Зарегистрируем файл сессии:

Register-PSSessionConfiguration -Name 'VM_OperatorSession' -Path "$env:ProgramDataJEAConfigurationVM.pssc"

Теперь все готово для проверки. Попробуем подключиться к серверу с учетными данными созданного пользователя командлетом:

Enter-PSSession -ComputerName SERVERNAME -ConfigurationName VM_OperatorSession -Credential (Get-Credential)

Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.

Доступ к серверу ограничен управлением одной виртуальной машиной.

Для облегчения создания файлов конфигурации сообществом была создана утилита под названием JEA Toolkit Helper, где графический интерфейс поможет создать файлы с необходимыми параметрами.

Интерфейс JEA Toolkit Helper.

При необходимости есть возможность через групповые политики включить аудит выполнения модулей по адресу Конфигурация компьютера – Административные шаблоны – Windows Powershell – Включить ведение журнала модулей. Тогда в журнале Windows будут отображаться записи о том что, где и когда.

Журнал выполнения PowerShell.

Альтернативой будет включение записи в файл. Также через групповые политики настраивается параметр «Включить транскрипции PowerShell». Путь можно задать как в самой политике (и тогда запись туда будет вестись для всех модулей), так и в файле конфигурации сессии JEA в параметре TranscriptDirectory.

Файловый журнал JEA.

С помощью делегирования, назначения прав и JEA можно добиться отказа от использования учетных записей с администраторскими правами в повседневной работе. В конце-концов, к UAC в Windows ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».

В каждой операционной системе Windows по умолчанию присутствует встроенная (built-in) учетная запись администратора. Эта учетная запись имеет неограниченные права и при ее компрометации злоумышленник получает полный контроль над системой. Чтобы этого не произошло, встроенную учетную запись администратора необходимо защитить.

Существует множество различных способов защиты и сегодня мы рассмотрим некоторые из них.

Отключение и переименование

Одной из наиболее распространенных атак является перебор паролей. Обычно от перебора защищаются с помощью политик блокировки, ограничивающих количество попыток ввода пароля. Однако особенностью встроенной учетной записи администратора является то, что она не зависит от количества неправильного ввода пароля и ее невозможно заблокировать. Поэтому учетная запись администратора является распространенной целью для подобного рода атак.

Одним из способов защиты от перебора является отключение учетной записи либо, если отключение невозможно, то ее переименование.

В производственной среде сделать это проще всего с помощью групповых политик. Нужные нам параметры находятся в разделе Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.

Для получения доступа к системе необходимо узнать две вещи — имя пользователя и его пароль. В случае со встроенной учеткой администратора по умолчанию имя всегда Administrator (или Администратор в русскоязычной версии системы). Переименование усложнит процесс взлома, поскольку злоумышленнику придется сначала выяснить имя пользователя, а уже затем приступить к перебору.

За переименование отвечает параметр политики с именем Accounts: Rename administrator account. Надо открыть его, отметить чекбокс ″Define this policy settings″ и задать новое имя пользователя. Имя может быть любое, насколько хватит фантазии. Как вариант, можно переименовать администратора в гостя (Guest), а гостя в администратора. Поскольку у гостевой учетной записи практически нулевые права в системе, то взломав ее злоумышленник будет неприятно удивлен 🙂

Переименование учетной записи повышает безопасность, однако эта мера недостаточно эффективна. Учетная запись администратора имеет известный идентификатор безопасности (SID) и существуют средства, позволяющие проходить аутентификацию с использованием SID а не имени пользователя.

Поэтому более эффективным способом защиты учетной записи администратора является ее отключение. Для отключения используется параметр политики с названием Accounts: Administrator account status. Надо открыть его, отметить чекбок ″Define this policy settings″ и поставить переключатель в положение Disabled.

Ну а для большей безопасности учетную запись можно и переименовать и отключить. В результате должно получиться что то типа этого.

Примечание. Если вы сначала переименуете учетную запись администратора, а потом захотите ее отключить, то ничего не получится. Видимо дело в том, что политика жестко привязана к имени пользователя и при его изменении просто не находит нужную учетку. А вот в обратном порядке все отлично работает и переименовать отключенную учетную запись можно без проблем.

Запрет на вход

И переименование и даже отключение учетной записи администратора вовсе не гарантируют ее полную безопасность. Поэтому следующим этапом защиты будет минимизация потерь в том случае, если учетная запись все же оказалась скомпрометирована.

Надо сказать, что ограничить права локального администратора в системе практически невозможно, но зато можно запретить сам вход в систему. Для этого мы ограничим права входа для учетной записи локального администратора, также с помощью групповых политик.

Примечание. Права входа (Logon Rights) определяют способы входа в систему, доступные для пользователя.

В разделе Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment находятся следующие параметры:

Deny log on locally — запретить локальный вход в систему;
Deny log on through Remote Desktop Service — запретить доступ с помощью службы удаленных рабочих столов;
Deny access to this computer from the network — запретить доступ к компьютеру по сети. Доступ по сети используется при удаленном доступе к файловой системе или приложениям;
Deny log on as a service — запретить пользователю регистрироваться в качестве службы. Это право обеспечивает работу служб Windows в фоновом режиме;
Deny log on as a batch job — запретить пользователю регистрацию в качестве пакетного задания. Это право используется планировщиком заданий (Task Scheduler) и некоторыми другими службами.

Для активации параметра политики надо надо открыть его, отметить чекбок ″Define this policy settings″ и указать пользователей или группы, для которого эта политика будет применяться. В нашем случае надо указать имя Administrator.

Microsoft рекомендует отключать для локального администратора все способы входа кроме локального, в результате должно получиться примерно так.

После применения запрещающих политик надо проверить их работу. Для проверки запрета на вход по RDP попробуем зайти на сервер с помощью RDP клиента, и если все получилось, то получим примерно такое сообщение.

Проверить запрет на доступ по сети несколько сложнее. Для проверки надо зайти на сервер локально, запустить от имени администратора командную консоль и выполнить команду net use. Например:

net use \SRV2C$

Если политика отработала корректно, то вместо ответа будет выдана ошибка с номером 1385.

Для проверки запрета на запуск в виде сервиса надо открыть оснастку Services, выбрать любой некритичный сервис, например сервис печати (Print spooler), и попробовать запустить его от имени локального администратора.

В результате должна получиться следующая ошибка.

Ну и проверить запрет на запуск в виде пакетного задания можно с помощью планировщика заданий (Task scheduler). Для этого создадим в планировщике задание и укажем его запуск от имени учетной записи локального администратора.

В случае успеха при сохранении задания мы получим ошибку.

Заключение

В заключение некоторые важные моменты, о которых необходимо помнить:

• Если вы решили отключить встроенную учетную запись администратора, то не забудьте создать на компьютере хотя бы одного пользователя с административными правами;
• Не рекомендуется применять вышеописанные политики к контроллерам домена. Дело в том, что на контроллерах домена нет локальных учетных записей и политики применяться к учетной записи DSRM администратора. При недоступности этой учетной записи вы не сможете зайти на контроллер домена в режиме восстановления Active Directory;
• При отключении политики переименования учетной записи администратора имя пользователя может не измениться на исходное. В этом случае потребуется в политике прописать стандартное имя, подождать пока она применится, и только потом ее отключать.

Использование локальных учетных записей (в том числе локального администратора) для доступа по сети в средах 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. Одна включает в себя всех локальных пользователей, а вторая всех локальных администраторов.

Теперь для ограничения доступа локальным учетным записям не нужно перечислять все возможные варианты SID локальных учёток, а использовать их общий SID.

Данные группы добавляются в токен доступа пользователя при входе в систему под локальной учетной записью.

Чтобы убедится, что в Windows 10/Windows Server 2016 локальной учетной записи присвоены две новый группы
NT AUTHORITYLocal account (SID S-1-5-113)
и
NT AUTHORITYLocal account and member of Administrators group (SID S-1-5-114)
, выполните команду:

whoami /all

Эти встроенные группы безопасности можно исопльзовать и в Windows 7, Windows 8, Windows Server 2008 R2 и Windows Server 2012, установив обновление KB 2871997 ( обновление от июня 2014 г.).

Проверить, имеются ли данные группы безопасности в вашей Windows можно по их SID так:

$objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-113")
$objAccount = $objSID.Translate([System.Security.Principal.NTAccount])
$objAccount.Value

Если скрипт возвращает NT AuthorityLocal 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 доступ в Windows разрешён администраторам и членам локальной группы Remote Desktop Users.

Если вы хотите запретить 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.

Запрещающая политика имеет приоритет над политикой Allow log on through Remote Desktop Services (Разрешить вход в систему через службу удаленных рабочих столов). Если пользователь или группа будет добавлен в обоих политиках, RDP доступ для него будет запрещен.

Теперь, если вы попытаетесь подключиться к компьютеру по 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. Также стоит всегда запрещать анонимный доступ и доступ под гостевым аккаунтом.

Для доменной среды рекомендуется с помощью этой политики полностью запретить доступ к рабочим станциям и рядовым серверам домена под учетными записями из групп Domain Admins и Enterprise Administrators. Эти аккаунты должны использоваться только для доступа к контроллерам доменам. Тем самым вы уменьшите риски перехвата хэша административных аккаунтов и эскалации привилегий.

После применения политики вы не сможете удаленно подключиться к этому компьютеру по сети под любой локальной учетной записью. При попытке подключиться к сетевой папке или подключить сетевой диск с этого компьютера под локальной учетной записью, появится ошибка:

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.

Системный администратор ограничил типы входа в систему (сетевой или интерактивный), которые можно использовать. Обратитесь за помощью к системному администратору или в службу технической поддержки.

Важно. Если вы примените эту политику к компьютеру, который находится в рабочей группе (не присоединен к домену Active Directory), вы сможете войти на такой компьютер только локально.

Запретить локальный вход в Windows

С помощью политики Deny log on locally (Запретить локальных вход) вы можете запретить и интерактивный вход на компьютер/сервер под локальными учетными записями. Перейдите в секцию GPO User Rights Assignment, отредактируйте политику Deny log on locally. Добавьте в нее нужную локальную группу безопасности.

Будьте особо внимательны с запрещающими политиками. При некорректной настройке, вы можете потерять доступ к компьютерам. В крайнем случае сбросить настройки локальной GPO можно так.

Теперь, если пользователь или администратор попытается авторизоваться на компьютере под локальной учетной записью, появится сообщение.

The sign-in method you are trying to use isn’t allowed. For more info, contact your network administrator.

Этот метод входа запрещено использовать. Для получения дополнительных сведений обратитесь к администратору своей сети.

Таким образом, вы можете ограничить доступ под локальными учетными записями на компьютеры и сервера домена, увеличить защищенность корпоративной сети.