запретить удаленный доступ учетных записей с административными правами

Управление административными шарами (Admin$, IPC$, C$, D$) в Windows 10

По-умолчанию Windows создает следующие админ шары:

Можно получить список доступных административных шар на удаленном компьютере с помощью команды:

net view \\computername /all

Получить доступ к административным шарам могут только члены локальной группы администраторов компьютера (и группы Backup Operators) при условии, что у вас включен SMB протокол, общий доступ (Turn on file and printer sharing) и доступ по 445 порту TCP не блокируется Windows Defender Firewall.

Как отключить/включить административные шары в Windows 10?

Административные шары Windows удобны для удаленного администрирования компьютера, но несут дополнительные риски безопасности (Как минимум не стоит использовать одинаковый пароль локального администратора на всех компьютерах. Чтобы сделать пароли уникальными, используйте LAPS). Вы можете полностью запретить Windows создавать эти скрытые ресурсы.

Самый простой способ – щелкнуть правой кнопкой мыши по имени административного ресурса в оснастке управления компьютером и выбрать Stop sharing (или использовать команду net share IPC$ /delete ). Однако после перезагрузки Windows она пересоздастся автоматически.

Чтобы запретить Windows публиковать административные шары, нужно открыть редактор реестра regedit.exe, перейти в ветку реестра HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters и добавить Dword параметр с именем AutoShareWks (для десктопных версий Windows) или AutoShareServer (для Windows Server) и значением 0.

Можно создать это параметр реестра вручную, из командной строки reg add или через PowerShell:

reg add HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters /f /v AutoShareWks /t REG_DWORD /d 0

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

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

Чтобы Windows пересоздала административные шары, достаточно перезапустить службу Server командой:

Разрешаем удаленный доступ к административным шарам Windows 10

При работе с административными шарами Windows на компьютере, который не добавлен в домен Active Directory (состоит в рабочей группе) есть одна важная особенность. Windows 10 блокирует удаленный доступ к дефолтным административным шарам под пользователем, входящим в группу локальных администраторов. Причем под учетной записью встроенного локального администратора (по умолчанию она отключена) такой доступ работает.

Немного подробнее как выглядит проблема. Я пытаюсь с удаленного компьютера обратится к встроенным административным ресурсам компьютера Windows 10, состоящего в рабочей группе (при отключенном файерволе) таким образом:

В окно авторизации ввожу имя и пароль учетной записи, состоящей в группе локальных администраторов Windows 10, на что появляется ошибка доступа (Access is denied). При этом доступ к общим сетевым каталогам и принтерам на Windows 10 работает нормально (компьютер виден в сетевом окружении). Доступ под встроенной учетной записью administrator к административным ресурсам при этом тоже работает. Если же этот компьютер включить в домен Active Directory, то под доменными аккаунтами с правами администратора доступ к админским шарам также не блокируется.

Дело в еще одном аспекте политики безопасности, появившемся в UAC – так называемом Remote UAC (контроль учетных записей для удаленных подключений), который фильтрует токены доступа локальных записей и аккаунтов Microsoft, блокируя удаленный административный доступ под такими учеткам. При доступе под доменным аккаунтом такое ограничение не применяется.

Отключить Remote UAC можно путем создания в системном реестре параметра LocalAccountTokenFilterPolicy

reg add «HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System» /v «LocalAccountTokenFilterPolicy» /t REG_DWORD /d 1 /f

После перезагрузки попробуйте удаленно открыть административный каталог C$ на Windows 10 компьютере. Авторизуйтесь под учетною записью, входящей в группу локальных администраторов. Должно открыться окно проводника с содержимым диска C:\.

Итак, мы разобрались как с помощью параметра LocalAccountTokenFilterPolicy разрешить удаленный доступ к скрытым админ-ресурсам для всех локальных администраторов компьютера Windows. Инструкция применима также к Windows 8.1, 7 и Windows Server.

Источник

Windows: Запретить сетевой доступ под локальным учетным записям

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

Запрет на вход через 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, появится ошибка:

Запрет сетевого доступа к компьютеру по сети

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

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

При попытке установить RDP сессию под учетной записью локального администратора (.\administrator) появится сообщение об ошибке.

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

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

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

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

Источник

Запретить вход в систему через службу удаленных рабочих столов

Относится к:

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

Справочники

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

Возможные значения

Рекомендации

Location

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Значения по умолчанию

В следующей таблице перечислены фактические и эффективные значения политики по умолчанию для последних поддерживаемых версий Windows. Значения по умолчанию также можно найти на странице свойств политики.

Управление политикой

В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой.

Для активации этого параметра политики не требуется перезагрузка компьютера.

Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.

Свойство Remote System управляет настройками для служб удаленного рабочего стола (разрешить или предотвратить удаленные подключения к компьютеру) и для удаленной помощи (Разрешить удаленные подключения к этому****компьютеру).

Групповая политика

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

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

Когда локальный параметр серый, он указывает, что GPO в настоящее время контролирует этот параметр.

Вопросы безопасности

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

Уязвимость

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

Противодействие

Назначьте вход в систему Deny через пользователя remote Desktop Services правом на встроенную учетную запись локального гостя и все учетные записи службы. Если установлены необязательные компоненты, например ASP.NET, может потребоваться назначить этому пользователю право на дополнительные учетные записи, необходимые для этих компонентов.

Возможное влияние

Если вы назначите вход в систему Deny с помощью пользователя remote Desktop Services праве на другие группы, можно ограничить возможности пользователей, которым назначены определенные административные роли в вашей среде. Учетные записи, которые имеют это право пользователя, не могут подключаться к устройству с помощью служб удаленного рабочего стола или удаленной помощи. Необходимо подтвердить, что делегированная задача не влияет отрицательно.

Источник

Запретить удаленный доступ учетных записей с административными правами

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами разобрали, как удалить net framework, без оставления хвостов. Сегодня я хочу вас научить запрещению входа по RDP на удаленный сервер для любой учетной записи, при этом права администратора у ней могут остаться. Данная заметка будет полезна для увеличения безопасности в Active Directory, я так же покажу ряд сценариев, где вы сможете это применить. Думаю каждый найдет ля себя частичку полезного из данной публикации.

Для чего нужно запрещать вход на удаленный рабочий стол

Ранее мы с вами изучали, как подключаться к удаленному рабочему столу и познакомились с рядом клиентов RDP. Теперь у нас обратная задача, сделать все наоборот. Приведу несколько ситуацию в которых будет полезно запретить интерактивный и RDP вход:

Как запретить RDP подключение через групповую политику

Первый метод будет рассчитан на инфраструктуру построенную на Active Directory, где централизация является важным фактором управления. Тут мы с вами создадим отдельную групповую политику рассчитанную на группу RDSH хостов. Открываем редактор «Управление групповой политикой» и создаем новый объект GPO на нужном организационном подразделении.

Переходим в раздел:

Там есть политика «Запретить вход в систему через службы удаленных рабочих столов (Deny log on through Remote Desktop Services)». Именно данная политика позволяет внести в нее пользователей или группы, у которых нужно отнять возможность входа по RDP.

Откроем оснастку ADUC и создадим новую группу безопасности «RDP-Deny»

Я включу в нее тестовую учетную запись Барбоскина Геннадия Викторовича, обратите внимание, что он является администратором домена и по умолчанию имеет доступ на все компьютеры в домене.

Активируем галку «Определить следующие параметры политики», после чего у вас станет доступна кнопка «Добавить пользователей или группу«. Через кнопку обзор производим поиск нашей группы «RDP-Deny».

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

Теперь даже обладая административными правами на сервер с Windows Server 2019, вы получите вот такое уведомление:

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

Переходим в раздел:

Там есть политика «Запретить вход в систему через службы удаленных рабочих столов (Deny log on through Remote Desktop Services)».

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

Вы так же можете при желании запретить и интерактивный вход на сервер или компьютер. Делается, это чаще всего из-за безопасности, когда сервер физически располагается там, где у вас нет 100% гарантии его защиты, и вы хотели бы отключить возможность входа локально, а оставить только удаленное подключение. Тут вы делаете все тоже самое, что я описывал выше, единственное, что вам в самом конце нужно будет выбрать политику

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

Источник

Блокировка удаленного использования локальных учетных записей в Windows

В этой статье описывается, как блокировать удаленное использование локальных учетных записей в Windows.

Оригинальная версия продукта: SQL Server 2016 SQL Server 2016 Enterprise, SQL Server 2016 Enterprise Core
Исходный номер КБ: 4488256

Аннотация

При использовании локальных учетных записей для удаленного доступа в средах Active Directory может возникнуть несколько различных проблем. Наиболее существенная проблема возникает, если у административной локальной учетной записи одинаковые имя пользователя и пароль на нескольких устройствах. Злоумышленник, который имеет административные права на одном устройстве в этой группе, может использовать hash-хаш пароля учетных записей из локальной базы данных диспетчера учетных записей безопасности (SAM) для получения административных прав над другими устройствами в группе, которые используют методы «передать хаш».

Дополнительные сведения

Наши последние рекомендации по безопасности отвечают на эти проблемы, Windows для блокировки удаленных логотипов локальными учетной записью. Windows 8.1 и Windows Server 2012 R2 представили следующие идентификаторы безопасности (SID):

S-1-5-113: учетная запись NT AUTHORITY\Local

S-1-5-114: учетная запись NT AUTHORITY\Local и член группы администраторов

Эти SID также определяются в Windows 7, Windows 8, Windows Server 2008 R2 и Windows Server 2012 после установки обновления Microsoft Security Advisory: Update to improve credentials protection and management: May 13, 2014.

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

Эти СИД могут предоставить доступ или запретить доступ ко всем локальным учетным записям или ко всем административным локальным учетным записям. Например, эти СИИ можно использовать в группах «Назначение прав пользователей», чтобы «Запретить доступ к этому компьютеру из сети» и «Запретить вход через удаленные службы настольных компьютеров». Это рекомендуемая практика в наших последних руководствах по безопасности. Чтобы добиться такого же эффекта до определения этих новых СИД, необходимо явно назвать каждую локализованную учетную запись, которую необходимо ограничить.

В первоначальном выпуске руководства Windows 8.1 и Windows Server 2012 R2 мы отказано в сетевом и удаленном логотипе настольного компьютера в локальной учетной записи (S-1-5-113) для всех конфигураций клиентов Windows и сервера. Это блокирует удаленный доступ ко всем локальным учетным записям.

Мы снова обнаружили, что кластеризация неудачных процессов зависит от локальной учетной записи (CLIUSR) для управления кластерными узлами, а блокировка доступа к сетевым логотипам приводит к сбойным службам кластерных служб. Поскольку учетная запись CLIUSR не является членом группы администраторов, замена S-1-5-113 на S-1-5-114 в параметре «Отказ в доступе к этому компьютеру из сети» позволяет кластерным службам работать правильно. Он делает это, обеспечивая при этом защиту от атак типа «передать хаш», отказывая в логосе сети в административных локальных учетных записях.

Хотя мы могли бы сохранить руководство без изменений и добавить сноску «специальный случай» для сценариев кластера отказов, вместо этого мы решили упростить развертывание и изменить базовый Windows Server 2012 R2 Member Server, как указано в следующей таблице.

Это изменение применимо только к базовой линии Member Server. Ограничение на логотип удаленного рабочего стола не меняется. Организации по-прежнему могут принимать решения об отказе в доступе к учетной записи Локальной сети для незавершенных серверов.

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

Дополнительные информацию о учетной записи CLIUSR

Учетная запись CLIUSR — это учетная запись локального пользователя, созданная функцией кластеризация failover, если эта функция установлена в Windows Server 2012 или более поздних версиях.

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

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

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

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

Для проверки подлинности учетная запись была переключена для использования объекта компьютера, связанного с кластерным именем, которое называется объектом кластерного имени (CNO) для общего удостоверения. Так как этот CNO является учетной записью компьютера в домене, он автоматически вращается пароль, как это определено политикой домена для вас. (По умолчанию это каждые 30 дней.)

Начиная с Windows Server 2008 R2, администраторы начали виртуализировать все в своих центрах обработки данных. Это включает контроллеры домена. Кроме того, была представлена функция кластерных общих томов (CSV), которая стала стандартом для частного облачного хранилища. Некоторые администраторы приняли виртуализацию и виртуализировали каждый сервер в их центрах обработки данных. Это включает добавление контроллеров домена в качестве виртуальной машины в кластер и использование диска CSV для удержания VHD/VHDX VM.

Это создало сценарий «Catch 22» для многих компаний. Чтобы установить диск CSV для доступа к VMs, для получения CNO необходимо связаться с контроллером домена. Однако запустить контроллер домена не удалось, так как он работает на CSV.

Медленное или ненадежное подключение к контроллерам домена также влияет на диски I/O для CSV. CSV занимается внутрикластерной связью через SMB, аналогично подключению к файлам. Чтобы подключиться к SMB, подключение должно проверить подлинность. В Windows Server 2008 R2 для проверки подлинности CNO с помощью удаленного контроллера домена.

Для Windows Server 2012 мы должны были подумать о том, как мы могли бы принять лучшее из обоих миров и избежать некоторых проблем, которые мы видели. Мы по-прежнему используем право пользователя с уменьшенной сетевой службой для запуска службы кластеров. Однако для удаления всех внешних зависимостей для проверки подлинности между узлами используется учетная запись локального (не доменного) пользователя.

Эта локализованная учетная запись «пользователя» не является административной учетной записью или учетной записью домена. Эта учетная запись автоматически создается для каждого узла при создании кластера или на новом узле, который добавляется в существующий кластер. Эта учетная запись управляется службой кластеров самостоятельно. Он автоматически вращает пароль для учетной записи и синхронизирует все узлы для вас. Пароль CLIUSR вращается с той же частотой, что и CNO, как это определено политикой домена. (По умолчанию это каждые 30 дней.) Так как учетная запись локальна, она может проверить подлинность и установить CSV, чтобы виртуализированные контроллеры домена могли успешно начать работу. Теперь вы можете виртуализировать все контроллеры домена без страха. Таким образом, мы увеличим устойчивость и доступность кластера за счет сокращения внешних зависимостей.

Эта учетная запись — учетная запись CLIUSR. Его можно определить по описанию в оснастке «Управление компьютером».

Часто возникает вопрос, можно ли удалить учетную запись CLIUSR. С точки зрения безопасности во время аудита могут быть помечены дополнительные локальные учетные записи (не по умолчанию). Если администратор сети не знает, для чего эта учетная запись (т. е. не читает описание локальной идентичности кластера failover), он может удалить ее, не понимая последствий. Чтобы кластеризация failover функционировала правильно, эта учетная запись необходима для проверки подлинности.

Присоединение узла запускает службу кластера и передает учетные данные CLIUSR.

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

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

Резюмировать. Учетная запись CLIUSR является внутренним компонентом службы кластеров. Это самообуправление, чтобы вам не требовалось настраивать или управлять им.

В Windows Server 2016 мы пошли еще дальше, воспользовавшись сертификатами, чтобы позволить кластерам работать без каких-либо внешних зависимостей. Это позволяет создавать кластеры с помощью серверов, расположенных в различных доменах или за пределами всех доменов.

Источник