Архив рубрики: Безопасность

Презентация LAPS

Как я писал ранее, в декабре я выступал на IT Pro UG с докладом о LAPS.
Видео, наконец-то, обработано и доступно:

Саму презентацию вы можете скачать здесь.

После доклада задали пару вопросов:
Q: Передаётся ли пароль открытым текстом по сети в момент его обновления или считывания утилитой?
A: Нет, LDAP-соединение в таких случаях защищается при помощи SASL. Однако же, если при установке соединения в собственных средствах/скриптах вы явно укажете LDAP_OPT_ENCRYPT = 0 или будете использовать ldap_simple_bind без TLS/SSL, тогда всё будет передаваться открытым текстом.

Q: Почему бы вообще локальные учетки не отключать? При каком бизнес-сценарии нам понадобится управлять их паролями?
A: Например, в том случае, если машина потеряла домен и надо получить к ней доступ с минимальными изменениями (без перезагрузок, оффлайн-сброса пароля и т.п.). Кеш доменного пароля толже может не помочь в таком сценарии, если на машине не сохранён ни один из известных — с LAPS можно быть более уверенным, что доступ к системе получишь.

Встреча сообщества IT Pro 21 декабря

Через неделю, 21 декабря, в Microsoft Technology Center на Белорусской пройдёт встреча сообщества IT-профессионалов, посвящённая защите привилегированных учётных записей. Я там тоже буду докладывать про LAPS.
А Олег Ржевский расскажет про Remote Credential Guard, Just Enough Administration и Just-In-Time Administration.

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

SCDPM в зонированной инфраструктуре

Построение безопасной инфраструктуры в компании обычно подразумевает разделение ресурсов по нескольким зонам безопасности, которые управляются разными администраторами (или, по крайней мере, одними и теми же администраторами, но под разными учётными записями). Например, можно выделить серверы с важными данными, такие как центры сертификации PKI, хостовые машины Hyper-V или машины содержащие персональные данные, и определить их как «Зона 1». Остальные серверы можно обозначить как «Зона 2». Разрешения настраиваются таким образом, чтобы в каждой зонае были свои собственные локальные администраторы, логоны пользователей между зонами — запрещаются (кроме сетевого входа в систему — он обычно не несёт рисков безопасности).

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

Что это означает для SCDPM? DPM не предназначен для резервного копирования между зонами безопасности, но мы можем его заставить.
После того, как вы установили агент SCDPM на сервер в зоне 2, вы должы прикрепить его к серверу SCDPM в зоне 1. На этом шаге, пользователи, под которым вы прикрепляете агента, должен быть локальным администратором одновременно и на сервере, и на клиенте. В зонированной инфраструктуре это невоможно, т.к. одна учётная запись не может быть локальным администратором на машинах в двух разных зонах.
Что же делать? Придётся предоставить необходимые разрешения гранулированно:

Шаг 1

Мы должны предоставить для администратора зоны 1 следующие разрешения на корень WMI на сервере из зоны 2:

  • Enable
  • MethodExecute
  • RemoteAccess
  • ReadSecurity

Вы можете назначить эти разрешения через графический интерфейс (wmimgmt.msc) или через PowerShell.
Если вы выберете PowerShell, используйте эту версию сценария Set-WmiNamespaceSecurity.ps1. В этой версии исправлено назначение наследований разрешений — оригинальный сценарий Стива Ли падает с ошибкой «Invoke-WmiMethod : Invalid parameter».
Запустите сценарий на клиенте из зоны 2 с такими параметрами:
Set-WmiNamespaceSecurity.ps1 -namespace 'root' -operation 'add' -account 'EXAMPLE\tier1-admin' -permissions 'Enable','MethodExecute','RemoteAccess','ReadSecurity' -allowInherit $true

При назначении разрешений через графический интерфейс, они должны выглядеть так:

Шаг 2

Второй шаг немного контр-интуитивный: Как известно, сервер SCDPM запрашивает с агента его часовой пояс и сохраняет в своей базе. Почему-то, назначение разрешений из шага 1 не даёт не-администратору возможность удалённо запросить эти данные. В качестве обходного пути, выполните вот такой запрос к WMI на клиенте SCDPM: select * from Win32_TimeZone. После этого, не-администратор в течение некоторого времени сможет запрашивать часовой пояс удалённого компьютера.
Команда PowerShell для этого: Get-WmiObject -Query 'select * from Win32_TimeZone'

После выполнения этих двух шагов, у вас должно получиться успешно добавить агента из зоны 2 на сервер SCDPM в зоне 1. После этого, вы можете отозвать только что выданные разрешения: Set-WmiNamespaceSecurity.ps1 -namespace root -operation delete -account 'EXAMPLE\tier1-admin'

Синхронизация split-brain DNS

Последнюю версию скрипта вы всегда можете найти на GitHub.

Множество компаний использует одну и ту же доменную зону, как во внутренней инфраструктуре, так и во внешней. В случае, если внутренняя зона, по совместительству, является именем домена Active Directory и внутренние пользователи должны обращаться к некоторым серверам из этой зоны с использованием их внешних IP-адресов, возникает проблема: Каким то образом все такие записи должны присутствовать в синхронизированном состоянии и на внешних, и на внутренних DNS-серверах.
Существует несколько способов решения такой проблемы:

1. Использовать контроллеры домена Active Directory для разрешения имён и внешними, и внутренними пользователями.

За:

  • Единая точка управления.
  • Не требуется никакого дополнительного ПО на контроллерах домена.

Против:

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

За:

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

Против:

  • Две точки управления. DNS-записи могут стать рассинхронизированными.
3. Использовать новую функциональность Windows Server 2016 — политики DNS.

(https://blogs.technet.microsoft.com/teamdhcp/2015/08/31/split-brain-dns-in-active-directory-environment-using-dns-policies/)
За:

  • Единая точка управления.
  • Можно сделать так, чтобы для одного и того же имени внешним и внутренним пользователям возвращалась разная информация.

Против:

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

 

Лично я пока предпочитаю второй способ, с различными внешними и внутренними DNS-серверами. В этом случае появляется еще одна проблема: Как обеспечить своевременную синхронизацию тех DNS-записей, которые должны быть одинаковыми для внутренних и внешних пользователей?
Читать далее Синхронизация split-brain DNS

Как разрешить пользователям вводить свои машины в домен самостоятельно?

Представьте, что половина ваших пользователей — локальные администраторы на своих машинах. Довольно часто они переустанавливают ОС и просят службу поддержки ввести их компьютеры заново в корпоративный домен Active Directory. Обычно, у нас есть два способа помочь им в этой ситуации: или подойти к рабочему месту пользователя и использовать свои учётные данные для ввода в домен, или пересоздать компьютерный аккаунт, одновременно делегировав им право ввода компьютера в домен. В первом случае, сотруднику службы поддержки приходится ногами идти к рабочему месту пользователя, что может быть довольно выматывающе, особенно для отдалённых локаций. Во втором же, членство компьютера в группах скорее всего будет утеряно и его потребуется восстанавливать вручную.
Возможно ли сократить затраты времени и сил, необходимых на решение таких задач? Да, конечно!

Всё, что нам нужно, это представить пользователю следующие разрешения на учётную запись его компьютера:

  • Validated write to DNS host name
  • Validated write to service principal name
  • List the children of an object
  • Read
  • Read security information
  • List the object access
  • Control access right
  • Delete an object and all of its children
  • Delete
  • Write to the following properties:
    • sAMAccountName
    • displayName
    • description
    • Logon Information
    • Account Restrictions

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

Я сделал небольшой PowerShell-сценарий, чтобы помочь вам в выдаче таких разрешений. Пожалуйста обратимость к его секции помощи (можете использовать командлет Get-Help) за информацией о синтаксисе и примерами использования.

Если вы используете Windows 8.1/Server 2012 R2, вам может потребоваться установить исправление из KB 3092002, иначе сценарий будет работать только при запуске от имени учётной записи, входящей в группу «Domain Admins». Это происходит из-за ошибки в реализации командлета Set-Acl. Исправление для Windows 10 включено в последний выпуск RSAT.

Если вы испытываете какие-либо проблемы или ошибки при использовании сценария, пожалуйста, оставьте ниже комментарий или свяжитесь со мной напрямую.

Утверждение AuthenticationSilo не выпускается

Вы настраиваете Active Directory Authentication Policy и, в качестве условия контроля доступа, устанавливаете необходимость членства в определённом Authentication Policy Silo. Далее, вы используете эту политику в silo, определённом выше, для соответствующих типов объектов. Вы настраиваете этот silo только на аудит ограничений.

В этом случае, утверждение типа AuthenticationSilo не выпускается для ваших объектов безопасности.

Почему это происходит?

Как описано в разделе 3.1.1.11.2.18 GetAuthSiloClaim технической спецификации по Active Directory, утверждение типа AuthenticationSilo выпускается только тогда, когда Authentication Silo находится в режиме принудительного применения ограничений («Enforce policy restrictions»):
/*
Check if user is assigned to an enforced silo.
*/
assignedSilo := pADPrincipal!msDS-AssignedAuthNPolicySilo
if (assignedSilo = NULL ||
assignedSilo!msDS-AuthNPolicySiloEnforced = FALSE)
return NULL
endif

Решение

Я пока не нашёл способа изменить это поведение, просто помните о нём, пока настраиваете ваши Authentication Policies.

«0x80070721 A security package specific error occurred» при подключении к WMI между доменами

Симптомы:

Предположим, у вас есть 2 сервера IBM System x с установленной ОС Windows Server 2012 или более новой и с активированным сетевым интерфейсом IBM USB Remote NDIS Network Device. Они расположены в одном лесу Active Directory, но в разных доменах.
Вы пытаетесь установить соединение к WMI между ними (например, с использованием wbemtest). В этом случае, соединение не установится, и вы получите следующую ошибку:

Number: 0x80070721 Facility: Win32 Description: A security package specific error occurred.»
In System log of the server which initiates the connection we have:
Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 10/6/2013 9:13:09 PM
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SRV1.alpha.example.com
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server srv1$. The target name used was host/srv2.beta.example.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (ALPHA.EXAMPLE.COM) is different from the client domain (BETA.EXAMPLE.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Почему это происходит?

Начиная с Windows Server 2012, когда вы подключаетесь к WMI другого компьютера, Windows запрашивает список IP-адресов сетевых интерфейсов у удалённой системы. Далее, клиент определяет, к какому из полученных от удалённой системы IP-адресу ему лучше подключаться.
В случае серверов IBM System x, на них на обоих есть сетевой интерфейс с одним и тем же IP-адресом — 169.254.95.120. Windows выбирает его, как наиболее подходящий для установки соединения, но, т.к. клиентская машина обладает таким же IP-адресом, она подключается сама к себе. В результате, вы видите ошибку.

Когда вы пытаетесь подключиться к удалённому компьютеру с помощью wbemtest, вы вызываете WMI API. В фоне, WMI использует DCOM для связи с другими серверами. Когда DCOM устанавливает сессию, он использует запрос «ServerAlive2», чтобы проверить другой сервер.
Вот, как это выглядит в записи сетевого траффика:

14 14:38:55 10.01.2014 0.0111483 srv2.beta.example.com 135 (0x87) 91.103.70.14 55535 (0xD8EF) DCOM DCOM:IObjectExporter:ServerAlive2 Response {MSRPC:10, TCP:9, IPv4:8}
NetworkAddress: srv1
NetworkAddress: 169.254.95.120
NetworkAddress: 192.0.2.1

Тот же траффик, если мы попробуем подключиться с обратной стороны:

38 14:37:12 10.01.2014 37.1871388 srv1.alpha.example.com 135 (0x87) 10.253.12.2 59278 (0xE78E) DCOM DCOM:IObjectExporter:ServerAlive2 Response {MSRPC:14, TCP:13, IPv4:8}
NetworkAddress: srv2
NetworkAddress: 169.254.95.120
NetworkAddress: 203.0.113.2

Уровень приложения выбирает общий IP и заворачивает соединение назад. DCOM получает билет Kerberos и пробует аутентифицироваться с ним, вот почему мы видим ошибку AP_ERR_MODIFIED. То есть соединение на основе DCOM (WMI, как пример) не будет работать, если участники имеют общий IP-адрес.

Эта проблема известна Microsoft и не будет исправлена, т.к. это работает так, как задумано.

Как лучше всего выходить из такой ситуации?

  1. Отключите сетевой интерфейс IMM USB Network Interface на, по крайней мере, одном из серверов. Но будьте внимательны: обновление микрокода IMM из Windows или использование средства ASU64 включит этот интерфейс обратно.
    Если вы выберите этот способ, я рекомендую вам настроить вашу систему мониторинга таким образом, чтобы она предупреждала вас, если этот сетевой интерфейс будет активирован.
  2. Измените IP-адрес на любом из сетевых интерфейсов на какой-нибудь другой. Вы можете использовать практически любой адрес из частных сетей, но вот рекомендации IBM по этому поводу.