Сетевая безопасность: разрешить учетной записи локальной системы использовать удостоверение компьютера для NTLM Network security: Allow Local System to use computer identity for NTLM

Область применения Applies to

Описывает расположение, значения, управление политиками и вопросы безопасности для сетевой безопасности: разрешить локальной системе использовать удостоверение компьютера для параметра политики безопасности NTLM. Describes the location, values, policy management, and security considerations for the Network security: Allow Local System to use computer identity for NTLM security policy setting.

Справочные материалы Reference

Если службы подключаются к устройствам под управлением версий операционной системы Windows более ранних версий, чем Windows Vista или Windows Server 2008, службы, которые работают как локализованная система и используют SPNEGO (Согласование), которые вернуться к NTLM, будут анонимными. When services connect to devices that are running versions of the Windows operating system earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will authenticate anonymously. В Windows Server 2008 R2 Windows 7 и более поздних версиях, если служба подключается к компьютеру под управлением Windows Server 2008 или Windows Vista, системная служба использует удостоверение компьютера. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer identity.

Когда служба подключается с удостоверением устройства, для обеспечения защиты данных поддерживается подпись и шифрование. When a service connects with the device identity, signing and encryption are supported to provide data protection. (При анонимном подключении службы создается системный ключ сеанса, который не обеспечивает защиты, но позволяет приложениям подписывать и шифровать данные без ошибок. (When a service connects anonymously, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors. Анонимная проверка подлинности использует сеанс NULL, который является сеансом с сервером, на котором проверка подлинности пользователей не выполняется; и, следовательно, анонимный доступ разрешен.) Anonymous authentication uses a NULL session, which is a session with a server in which no user authentication is performed; and therefore, anonymous access is allowed.)

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

Параметр Setting	Windows Server 2008 и Windows Vista Windows Server 2008 and Windows Vista	Как минимум Windows Server 2008 R2 Windows 7 At least Windows Server 2008 R2 and Windows 7
Включено Enabled	Службы, работающие в качестве локальной системы, которые используют согласование, будут использовать удостоверение компьютера. Services running as Local System that use Negotiate will use the computer identity. Это значение может привести к сбойу некоторых запросов проверки подлинности между операционными системами Windows и регистрации ошибки. This value might cause some authentication requests between Windows operating systems to fail and log an error.	Службы, работающие в качестве локальной системы, которые используют согласование, будут использовать удостоверение компьютера. Services running as Local System that use Negotiate will use the computer identity. Это является стандартным поведением. This is the default behavior.
Отключено Disabled	Службы, работающие в качестве локальной системы, которые используют согласование при реверсе проверки подлинности NTLM, будут анонимными. Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. Это является стандартным поведением. This is the default behavior.	Службы, работающие в качестве локальной системы, которые используют согласование при реверсе проверки подлинности NTLM, будут анонимными. Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.
Ни один из них Neither	Службы, работающие в качестве локальной системы, которые используют согласование при реверсе проверки подлинности NTLM, будут анонимными. Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.	Службы, работающие в качестве локальной системы, которые используют согласование, будут использовать удостоверение компьютера. Services running as Local System that use Negotiate will use the computer identity. Это может привести к сбойу некоторых запросов проверки подлинности между операционными системами Windows и регистрации ошибки. This might cause some authentication requests between Windows operating systems to fail and log an error.

Расположение Location

Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Параметры безопасности Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

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

В следующей таблице перечислены фактические и эффективные значения по умолчанию для этой политики. The following table lists the actual and effective default values for this policy. Значения по умолчанию также можно найти на странице свойств политики. Default values are also listed on the policy’s property page.

Тип сервера или объект групповой политики (GPO) Server type or Group Policy object (GPO)	Значение по умолчанию Default value
Политика домена по умолчанию Default domain policy	Не определено Not defined
Политика контроллера домена по умолчанию Default domain controller policy	Не определено Not defined
Параметры по умолчанию для отдельного сервера Stand-alone server default settings	Не определено Not defined
Параметры по умолчанию для контроллера домена Domain controller effective default settings	Не применяются Not applicable
Эффективные параметры по умолчанию для серверов-членов Member server effective default settings	Не применяются Not applicable
Эффективные параметры GPO по умолчанию на клиентских компьютерах Effective GPO default settings on client computers	Не определено Not defined

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

В этом разделе описываются функции и средства, которые помогут вам управлять этой политикой. This section describes features and tools that are available to help you manage this policy.

Необходимость перезапуска Restart requirement

Нет. None. Изменения этой политики становятся эффективными без перезапуска устройства, если они сохраняются локально или распространяются посредством групповой политики. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.

Вопросы конфликтов политик Policy conflict considerations

Политика сетевой безопасности: разрешить откат сеанса LocalSystem NULL(если он включен), позволит использовать проверку подлинности NTLM или Kerberos при попытке проверки подлинности системной службой. The policy Network security: Allow LocalSystem NULL session fallback, if enabled, will allow NTLM or Kerberos authentication to be used when a system service attempts authentication. Это увеличит успешность работы за счет безопасности. This will increase the success of interoperability at the expense of security.

В Windows Server 2008 и Windows Vista поведение анонимной проверки подлинности отличается от поведения более поздних версий Windows. The anonymous authentication behavior is different for Windows Server 2008 and Windows Vista than later versions of Windows. Настройка и применение этого параметра политики в этих системах может не дать одинаковых результатов. Configuring and applying this policy setting on those systems might not produce the same results.

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

Этот параметр политики можно настроить с помощью консоли управления групповыми политиками (GPMC) для распространения через объекты групповой политики (GGPOs). This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). Если эта политика не содержится в распределенном GPO, эту политику можно настроить на локальном компьютере с помощью оснастки «Локализованная политика безопасности». If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.

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

В этом разделе описывается, каким образом злоумышленник может использовать компонент или его конфигурацию, как реализовать меры противодействия, а также рассматриваются возможные отрицательные последствия их реализации. This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.

Уязвимость Vulnerability

Когда служба подключается к компьютерам под управлением более ранних версий Windows, чем Windows Vista или Windows Server 2008, службы, которые работают как локализованная система и используют SPNEGO (Согласование), которые вернуться к NTLM, будут использовать сеанс NULL. When a service connects to computers running versions of Windows earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will use NULL session. В Windows Server 2008 R2 Windows 7 и более поздних версиях, если служба подключается к компьютеру под управлением Windows Server 2008 или Windows Vista, системная служба использует удостоверение компьютера. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer identity.

Когда служба подключается с удостоверением компьютера, для обеспечения защиты данных поддерживается подпись и шифрование. When a service connects with the computer identity, signing and encryption are supported to provide data protection. При подключении службы к сеансу NULL создается системный ключ сеанса, который не обеспечивает защиты, но позволяет приложениям подписывать и шифровать данные без ошибок. When a service connects with a NULL session, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors.

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

Можно настроить сетевую безопасность: разрешить локальной системе использовать удостоверение компьютера для параметра политики безопасности NTLM, чтобы разрешить локальным системным службам, которые используют согласование, использовать удостоверение компьютера при реверсе проверки подлинности NTLM. You can configure the Network security: Allow Local System to use computer identity for NTLM security policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.

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

Если этот параметр политики не настроен в Windows Server 2008 и Windows Vista, службы, работающие под управлением локальной системы, которые используют учетные данные по умолчанию, будут использовать сеанс NULL и вернуться к проверке подлинности NTLM для операционных систем Windows до Windows Vista или Windows Server 2008. If you do not configure this policy setting on Windows Server 2008 and Windows Vista, services running as Local System that use the default credentials will use the NULL session and revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008. Начиная с Windows Server 2008 R2 и Windows 7, система позволяет локальным системным службам, которые используют согласование, использовать удостоверение компьютера при реверсе проверки подлинности NTLM. Beginning with Windows Server 2008 R2 and Windows 7, the system allows Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.

6 способов контроля доступа устройств к ресурсам сети

С контролем доступа к ресурсам сети (например, файловым) все просто — есть пользователи, есть ресурсы, устанавливаем права доступа на уровне ресурса и готово. Но как обстоят дела с контролем доступа на уровне устройств? Как сделать так, чтобы доступ определялся и на уровне пользователя, и на уровне устройства, с которого осуществляется подключение? Далее опишу подходы, позволяющие снизить вероятность подключения к ресурсам организации с не доверенных узлов.

name=»‘more'»>
Прежде конкретизируем задачу: внутри локальной сети сервера с ресурсами и рабочие места пользователей. Важно, чтобы доступ к ресурсам пользователи получали только с доменных компьютеров (части компьютеров), на которые установлены средства защиты и контроля. Речь о внутренней инфраструктуре и средства межсетевого экранирования уровня сети не рассматриваем.

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

Итак, как контролировать доступ c устройств техническими мерами:

Взаимодействие только с сетевой инфраструктурой:

1. Port security

Базовая защитная мера уровня коммутационного оборудования, заключающаяся в ограничении доступа в сеть в зависимости от MAC адреса устройства. Входит в Топ 30 мер по защите коммутационного оборудования .
Недостатки: мера малоэффективна и является скорее защитой от дурака случайных нарушений, т.к. подделка MAC адреса задача тривиальная.
Условия внедрения: наличие контроля над коммутационным оборудованием, наличие требуемых функций на оборудовании.

Взаимодействие с серверной и сетевой инфраструктурой:

2. 802.1x / NAC

Если все коммутационное оборудование под контролем, то возможно развертывание инфраструктуры 802.1x на базе RADIUS сервера или технологии Network Access Control (у Microsoft это роль Network Policy Server c компонентом Network Access Protection (NAP).

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

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

Взаимодействие только с серверной инфраструктурой:

3. Microsoft Dynamic Access control

Решение, полностью решающее задачу контроля доступа с устройств к файловым ресурсам. Начиная с MS Windows Server 2012 для управления доступом к ресурсам могут использоваться реквизиты ( clames ) и пользователя, и компьютера, с которого осуществляется подключение. Достаточно определить политику, устанавливающую одним из требований на доступ к файловым ресурсам наличие компьютера, с которого осуществляется доступ, в нужной группе службы каталогов. Доступ на основе клэйма компьютера это не главное преимущество технологии динамического контроля доступа, но для решения нашей задачи оно ключевое. Для погружения в вопрос рекомендую это видео .

Главное ограничение, которое ставит крест на внедрении этого решения в большинстве инфраструктур в том, что клэймы устройств работают только если клиентом выступает ОС Windows 10 и выше.

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

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

4. IPSec

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

Схема контроля доступа на базе IPSec

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

Если мы защищаем конкретный сервис (например, файловую шару, БД, Web-сервис) то и переводить на IPSec будем только порты защищаемого протокола, а не все соединения с сервером, что снизит нагрузку на сеть и оборудование.

Так же, если защита от перехвата трафика в задачах не стоит, то IPSec достаточно настроить в режиме контроля целостности по MD5, а шифрование отключить, что еще больше снизит нагрузку.

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

Без взаимодействия с инфраструктурой:

5. Скрипты

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

• Проверка логов контроллера домена (или файлового сервера) на предмет событий авторизации пользователя;
• Выделение из событий авторизации имени компьютера, с которого подключился пользователь;
• Попытка подключиться к этому компьютеру по протоколам SMB (CIFS) или WMI. Если подключение не удалось — значит узел не входит в домен (или у него проблемы с доступом, что тоже не порядок).
• Реагирование на нарушение: занесение информации о проблемных узлах в лог скрипта, уведомление администратора безопасности, отключение учетной записи

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

6 Сканирование

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

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

Резюме

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

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