Аудит доменных служб Active Directory в Windows Server 2008 R2 / Хабр

Глава 18. аудит и мониторинг active directory – active directory полное руководство – 2е изд.

Каркас кибербезопасностиNIST
(National Institute of Standards and Technology)
зиждется на трёх основных моментах: защите, выявлении и отклике. Все эти составляющие связаны друг с другом.
Когда мы реализуем некую систему, нам вначале требуется понять что защищать и как это защищать. До сих пор в
этой книге я объяснял важность некой инфраструктуры идентификации, а также как и что мы моем делать для защиты
этого от возникающих угроз. Основываясь на этом мы можем строить некую защищённую инфраструктуру идентификации,
но мы должны понимать, что мы не можем закрывать все имеющиеся двери. Мы обязаны ожидать взлома в любой момент.
Однако если он произойдёт, нам следует иметь готовой некую систему для его выявления и нашего уведомления. Это
позволит нам быстро и отвечать на возникающую ситуацию и минимизировать разрушения. Для выявления аналогичных
происшествий важно иметь в готовности надлежащие системы и процессы. Именно здесь вступают в дело аудит и мониторинг.
Они способствуют нам в том, чтобы гарантировать, что построенная нами система защиты работает как ожидалось; а,
если имеется неожиданное и не авторизованное поведение, он записывается и о нём выдаются отчёты. Такие находки
помогают инженерам действовать на опережение и предотвращать взломы.

Прежде чем воспользоваться Лондонской подземкой, я всегда проверяю текущее состояние вебсайта
TFL
(Transport for London) для просмотра значения состояния
службы нужной мне линии метро.Это некая предоставляемая TFL служба, которая гарантирует своим пользователям, что
они надлежащим образом спланируют свою поездку во избежание задержек. Сама система должна быть готовой для отслеживания
состояния конкретной линии, предлагая нам два преимущества. В качестве поставщика службы, TFL способна выявлять
имеющуюся проблему и немедленно начинает её решать. В то же самое время некие фильтруемые сведения предаются
гласности, что будет важно для ваших поездок.

Аналогично, аудит и мониторинг позволяют инженером не только выявлять проблемы. Они также должны проводить фильтрацию,
компонуя сведения по различным частям в общем деле, что важно для их ролей и ответственностей. Как пример, определённый
ИТ управляющий желал бы знать общую доступность службы домена за последний месяц. Но ему не важно знать обо всех
всевозможных событиях , которые происходили в этой системе на протяжении всех последних 30 дней, хотя это может быть важным
для инженеров ИТ.

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

В данной главе мы рассмотрим следующее:

В действительности Microsoft располагает встроенными свойствами и инструментами мониторинга и аудита сред AD.
В этом разделе мы намерены выполнить обзор этих функциональностей и инструментов.

В качестве инженера, я уверен, вам хорошо знаком Обозреватель событий Windows (Windows Event Viewer). Это
встроенный инструмент, который можно применять для просмотра и фильтрации зарегистрированных событий в локальном
или удалённом компьютере. События здесь вырабатываются самой операционной системой, службами, ролями сервера, а
также приложениями. Это наиболее распространённый инструментарий в системах Windows для целей аудита и устранения
неисправностей.

Как показывается на следующем снимке экрана, Event Viewer
(Local)
Windows имеет четыре различные категории для группирования журналов событий:


Индивидуальные представления

Обозреватель событий позволяет создавать Индивидуальные представления
(Custom Views) на основании уровня события, времени, типа
регистрации, типа источника, идентификатора события, категории задачи, ключевых слов, пользователей или компьютеров.
Обозреватель событий перехватывает тысячи разнообразных событий. Применяя
Custom Views, мы можем фильтровать события и получать доступ
к нужным нам сведениям. Все такие индивидуальные обзоры будут перечисляться в разделе
Custom Views. Он также имеет предварительно заданные
индивидуальные обзоры.

Подобные предварительно определённые индивидуальные обзоры основываются на установленных ролях. При добавлении
ролей Active Directory Domain Services также создаются
некоторые индивидуальные обзоры в имеющемся журнале событий, причём все они сгруппированы в разделе, относящемся к
событиям Active Directory Domain Services, как это показано
на следующем снимке экрана:


Журналы Windows

Раздел Журналов Windows (Windows Logs) содержит
пять файлов журналов Windows. Это в основном события, связанные с операционной системой:

  • Application log: Данный журнал содержит события,
    собираемые из различных приложений, запущенных в данной системе. Это могут быть приложения Microsoft или иные
    прочие.

  • Security log: Этот журнал содержит такие события,
    как успешные регистрации в системе или отказы в ней. Инженеры имеют возможность задавать какие события безопасности
    нужно записывать при помощи этой политики аудита.

  • Setup log: Содержит связанные с установкой и добавлением/
    удалением ролей сервера события.

  • System log: Этот журнал содержит события, относящиеся
    к компонентам системы Windows. В качестве примера, в этом журнале могут перечисляться отказы в автоматическом запуске
    службы.

  • Forwarded Events: Применяя Обозреватель событий, мы можем
    подключаться к прочим удалённым компьютерам и просматривать их события. Однако, может потребоваться отслеживать особые
    события из множества источников. Как пример, давайте допустим, что нам требуется собирать события с идентификатором
    4321 из трёх компьютеров. Применяя событие
    Subscriptions (Подписка), мы можем собирать события и
    переправлять их в соответствующий журнал Forwarded Events.

Журналы приложений и служб

Категория Application and Services Logs была введена
после Windows Server 2008. Она хранит все события, относящиеся к приложениям и их компонентам. Большинство из
перечисляемых здесь событий более подходят разработчикам для отладки и выявления неисправностей уровня приложения.

Данная категория имеет четыре типа журналов:

Подписки

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

Когда мы открываем какое- то событие, оно выдаёт различные уровни сведений, например, такие:

Журналы событий AD DS

Помимо событий в самой категории Windows Logs category,
Active Directory Domain Services и связанные с ней службы событий могут быть найдены в приводимых ниже журналах.
Они расположены в категории Applications and Services Logs:

Файлы журналов AD DS

Кроме событий, Active Directory Domain Service и относящиеся к ней службы другие файлы системной регистрации,
которые записывают данные относительно установки/ деинсталляции служб, производительности, ошибок/ отказов службы
и тому подобное. Эти файлы журналов можно применять для целей аудита, выявления неисправностей или отладки.

Определённым по умолчанию местоположением этих файлов выступает
%SystemRoot%Debug:

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

Существует 10 категорий событий, для которых мы можем выполнять аудит в некой системе Windows:

Абсолютно все категории также имеют подчинённые категории.

Аудит этих категорий может быть включён при помощи групповых политик. Они расположены под
Computer Configuration | Windows Settings | Security Settings |
Advanced Audit Policy Configuration | Audit Policies
, как это показано на следующем снимке
экрана:

Все эти категории способны собирать множество событий системы и служб, относящихся к действиям инфраструктуры
AD. Однако в данном разделе мы намерены сосредоточиться лишь на конкретной категории событий
DS Access (Доступа DS) и её подчинённых категорий.
Она отслеживает события, относящиеся к доступу к объектам AD и изменению объектов AD. Кроме того, все установки
из этой категории применяются только к самим контроллерам домена.

Такая категория событий DS Access содержит четыре
подчинённые категории:

Данная категория записывает события при доступе к некоторому объекту AD DS. Она будет работать только когда
настроен SACL
(system access control list, Список системного управления
доступом) и были добавлены соответствующие объекты. Это аналогично доступу к службе каталога при наследуемом
аудите.

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

Данная категория записывает события, которые относятся к изменениям объекта AD DS,а именно:

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

Эта категория регистрирует события при начале и завершении репликации между двумя контроллерами домена. При
включённом аудите мы можем отыскать такие события в соответствующих журналах:

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

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

Обозреватель событий можно запросто открыть, исполнив eventvwr.msc.
Ту же самую оснастку MMC можно также применить для подключения к некому удалённому компьютеру при помощи
варианта Connect to Another Computer…, как это
выделено в следующем снимке экрана:

Мы можем упростить это, создав в Диспетчере сервера (Server
Manager
группу серверов. Группа серверов позволит нам запускать аналогичные роли сервера или
действовать как часть некой распределённой системы.

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

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

  2. Нам требуется включить WinRM
    (Windows Remote Management). После Windows Server
    2022, WinRM включается по умолчанию. Существующие настройки WinRM можно просмотреть при помощи команды
    PowerShell winrm get winrm/config. Если они не включены, мы можем их включить
    воспользовавшись командой winrm quickconfig.

  3. Даже когда мы зарегистрированы в качестве администратора домена или администратора предприятия, по умолчанию,
    не допускается сбор событий с удалённых компьютеров. Для выполнения этого нам требуется добавить некую учётную
    запись компьютера коллектора (тот сервер, в котором создаётся данная группа сервера) в группу
    Event Log Readers. Это встроенная локальная группа. Участники этой группы
    могут считывать журналы событий со своей локальной машины. Мы можем добавить некую учётную запись компьютера в
    эту группу при помощи следующей команды:

    
    Add-ADGroupMember –identity 'Event Log Readers' –members REBELNET-PDC01$
     	   
  4. Для создания группы сервера, проследуйте в Диспетчер сервера (Server
    Manager
    ) в своей инструментальной панели и выберите Создать новую группу
    (Create a server group), как это показано на следующем
    снимке экрана:


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


  6. После создания группы вы можете получать к ней доступ при помощи панели с левой стороны в Диспетчере сервера
    (Server Manager). Внутри этого окна группы имеется
    отдельный раздел с названием Выбранное (EVENTS).
    Когда мы перемещаемся по участникам, он будет отображать нам связанные с каждым участником события в этом окне
    событий, как это показано на снимке экрана внизу:


Мы можем настраивать данные этого события и менять их следующим образом:

Наш следующий снимок экрана поясняет как мы можем настраивать как мы можем настраивать данные события при
помощи различных параметров:

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

Ещё один наш снимок экрана показывает как после создания единожды такого запроса, к нему можно обращаться всякий раз,
когда это потребуется:

Обозреватель событий содержит большое число разнообразных записей событий. Может иметься несколько тысяч событий в
день. Даже когда событие и предоставляет какие- то полезные сведения, нам не требуется проходить их абсолютно все
когда мы заинтересованы в устранении неисправности конкретного приложения или осуществления аудита службы.
Существуют конкретные события, относящиеся ко всяким ролям сервера, приложениям, службам и системным компонентам.
При некоторых обстоятельствах, когда нам требуется аудит или устранение неисправности, нам требуется просмотреть
события на множестве компьютеров. Обозреватель событий позволяет нам подключаться за раз только к одному компьютеру
в определённый момент времени. Это может быть локальный или удалённый компьютер. Подписки на события позволяют нам
собирать журналы событий с удалённых компьютеров и просматривать их в одной консоли.

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

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

После того как удовлетворены предварительные требования, выполните такую последовательность:

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


wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'
		

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
содержит настройки полномочий чтения (READ) для учётной записи сетевой службы (A;;0x1;;;).
В нашем предыдущем коде указано значение SID для учётной записи необходимой сетевой службы
(S-1-5-20) и значение доступа к необходимому каналу
(O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)). После того
как мы это выполним, через несколько минут мы можем наблюдать получаемые
Forwarded Events (Передаваемые события).

Как мы видели ранее, для успешного аудита нам требуется иметь настроенным некий SACL под соответствующие объекты AD.
Если нет никакой записи SACL, для такого объекта не будут вырабатываться никакие события. Чтобы настроить необходимый SACL
осуществите следующие шаги:

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

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

Вплоть до Windows Server 2008 существовало девять основных категорий и подчинённых категорий аудита. Они продолжают
оставаться и под Windows Server 2022. Рекомендуется впредь не смешивать их и применять вместо них исключительно
современные. Мы можем принуждать свою систему применять только современные настройки политик аудита когда к той
же самой категории применимы наследуемые настройки политики.

Это можно сделать включив соответствующие установки Групповой политики в
Computer Configuration | Windows Settings | Security Settings | Local
Policies | Security Options | Audit: Force audit policy subcategory settings (Windows Vista or later) to override
audit policy category settings
(Аудит: Принудительно применять настройки политик аудита – Windows Vista или
последующие версии – для перекрытия настроек категории политик аудита).

Для обзора журналов событий или их фильтрации в локальных или удалённых компьютерах мы также можем применять команды
PowerShell без каких бы то ни было дополнительных настроек службы. Первейшим cmdlet, который мы можем использовать для
этой задачи выступает Get-EventLog, как это показано в примере ниже:


Get-EventLog -List
		

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


Get-EventLog -LogName 'Directory Service' | fl
		

Эта предыдущая команда перечислит все события в соответствующем файле журнала
Directory Service. Мы также можем ограничить подлежащих перечислению общее
число событий. В качестве примера нам могут требоваться лишь самые последние 5
событий из своего файла журнала Directory Service и мы можем воспользоваться
такой командой:


Get-EventLog -Newest 5 -LogName 'Directory Service'
		

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


Get-EventLog -Newest 5 -LogName 'Directory Service' -EntryType Error
		

Наша предыдущая команда перечислит самые первые 5 ошибок из файла журнала
Directory Service. К тому же мы можем добавить некий временной придел для дальнейшей
фильтрации таким манером:


Get-EventLog -Newest 5 -LogName 'Directory Service' -EntryType Error –After (Get-Date).AddDays(-1)
		

Наша предыдущая команда выведет перечень событий с ошибкой, имеющей тип Error
в пределах последних 24 часов из соответствующего файла Directory Service.
Мы также способны следующим образом получать и события с удалённого компьютера:


Get-EventLog -Newest 5 -LogName 'Directory Service' -ComputerName 'REBEL-SRV01' | fl -Property *
		

Наша предыдущая команда перечислит самые первые 5 событий из файла журнала
Directory Service с удалённого компьютера REBEL-SRV01,
как это показано на снимке экрана ниже:

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


Get-EventLog -Newest 5 -LogName 'Directory Service' -ComputerName "localhost","REBEL-SRV01"
		

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


Get-EventLog -LogName 'Directory Service' -Source "NTDS KCC"
		

Предыдущая команда перечислит события из источника NTDS KCC. Это также
позволит нам выполнять поиск определённых идентификаторов событий, как это показано в нашем следующем примере:


Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 1000}
		

Наша предыдущая команда перечислит события с eventID равным
1000.

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

Microsoft построил AD и сопровождает его к настоящему времени более 20 лет. Многие инженеры ежедневно работают с
этим продуктом для выполнения последующих улучшений. Каждый день они имеют дело с квитанциями, относящимися к связанным с
инфраструктурой AD проблемами, включая безопасность. У них к тому же имеется Azure AD, которую люди используют через
открытые сетевые среды. Поэтому если кто- то и знает соответствующие угрозы входам и выходам безопасности инфраструктуры
идентификации, так это должен быть сам Microsoft. Основываясь на том гигантском объёме данных и знаний относительно угроз
инфраструктуре идентификации, Microsoft продолжает вводить новые инструменты и службы для защиты локальных, исключительно
облачных и гибридных инфраструктур идентификации. Microsoft ATA также выступает одним из таких инструментов, который
предоставляет некий простой, быстрый и точный способ выявления угроз инфраструктуре идентификации на некой ранней стадии
отлавливая подозрительных пользователей и активности устройств при помощи встроенного интеллекта. Он также предоставляет
ясные сведения в виде уведомлений электронной почтой и обзором временного ряда, причём через веб интерфейс.

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

Какие угрозы выявляет ATA?

Вот типы угроз, которые способен определять ATA:

Имеются три компоненты ATA, вовлечённые в развёртывание:

Центр ATA

Именно он выступает основным компонентом общего развёртывания ATA. Центр ATA выполняет такие вещи:

Такой Центр ATA рекомендуется устанавливать на неком обособленном сервере. Для одного леса рекомендуется один
Центр ATA. Настройки между лесами не поддерживаются.

Шлюз ATA

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

Облегчённый шлюз ATA

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

Оба шлюза выполняют следующие вещи:

Развёртывание ATA поддерживает три топологии:

Предварительные требования развёртывания ATA

Прежде чем запускать развёртывание ATA, следует выполнить такие предварительные требования:

В этом разделе я намерен продемонстрировать как установить ATA Microsoft. В своей демонстрационной
среде мы выполним следующее:

Сам Центр ATA может быть развёрнут при помощи такой последовательности:

Установка Облегчённого шлюза ATA проста. Мы можем установить его воспользовавшись такой последовательностью:

Это завершает начальное развёртывание ATA – он готов к работе.

Самый простой способ проверки функционирования ATA состоит в имитации атаки с разновидностью разведки DNS
следующим образом:

Как мы можем видеть, сам процесс установки и настройки ATA достаточно прост. Однако те преимущества, которые она
предоставит, экстраординарны. Этот продукт только сообщает о возникающих угрозах в некой среде AD. Исправление и
предотвращение подобных отчётов об угрозах всё ещё зависит от навыков инженеров.

До сих пор мы изучали инструменты, которые мы можем применять для мониторинга локальной среды AD. Microsoft также
имеет решения для отслеживания прочих приложений и систем. Прекрасным примером этого является SCOM. Он может применяться
для отслеживания приложений, служб, операционных систем, оборудования и сетевых устройств Windows. Если вы когда либо
применяли какой- нибудь продукт системного центра, вы уже знаете насколько сложно его настраивать, применять и
сопровождать. SCOM также способен отслеживать имеющуюся текущую жизнеспособность установленной среды AD. Это достойный
инструмент, но я не думаю что он подходит для мониторинга современных инфраструктур.

Microsoft уже осознал это и ввёл Монитор Azure для предоставления всеобъемлющего решения по сбору, анализу и
представлению приложений, служб и системных данных, получаемых из локальных и облачных сред. Первоначально
был известен под названием OMS
(Operations Management Suite). Это основанное целиком
на облаке решение. Монитор Azure сбор и анализ измерений и регистрационных сведений от различных источников, таких как
приложения, операционные системы, ресурсы Azure, подписки Azure, а также арендаторов Azure.
Metrics (Измерения) являются численными значениями,
описываемыми как определённое состояние службы, системы или приложения в определённый момент времени. В качестве примера,
конкретное состояние (то есть поднято или остановлено) службы в некий заданный момент времени является Измерением.
Оно определённо и просто для анализа. Метрики в основном применяются со сведениями производительности.
Logs (Регистрационные данные) содержат сведения событий.
Этот тип данных подлежит анализу при помощи запросов для фильтрации определённых данных.

Монитор Azure включает такие преимущества, которые дополнительно увеличивают его значимость:

  • Минимум настройки и сопровождения: Если вы ранее
    работали с SCOM, вы можете представлять как много различных компонентов нам требуется настраивать, например,
    управление серверами, SQL серверами, серверами шлюзов, сертификатами авторизации и тому подобным. Но применяя
    Монитор Azure всё что нам требуется, это некая подписка и самая начальная настройка агентов мониторинга или
    определённого шлюза; больше нет никакой рутины сложного сопровождения.

  • Он масштабируем: Последние отчёты Microsoft показывают,
    что Монитор Azure уже применяется более чем 50 000 пользователей. Было собрано 20ПБ данных и в неделю обрабатывалось
    более 188 миллионов запросов. Применяя решения на основе облака нам больше не требуется беспокоиться относительно ресурсов
    при расширении. Сама подписка основывается на тех свойствах и тех объёмах данных, которые вы загружаете. Вам не надо платить
    за вычислительную мощность. Я уверен, что Microsoft далёк от исчерпания ресурсов!

  • Интеграция с SCOM: Монитор Azure целиком поддерживает интеграцию
    с SCOM. Это позволяет инженерам определять какие системы и сведения следует анализировать Монитором Azure. Это также
    делает возможной гладкую поэтапную миграцию с SCOM в Монитор Azure. И Монитор Azure, и SCOM применяют один и тот же
    агент (Агент мониторинга Microsoft), а следовательно настройка стороны клиента минимальна.

  • Частые обновления свойств: Microsoft выпускает
    новую версию Системного центра раз в четыре года. Однако обновления Монитора Azure регулярны и новые службы поступают более
    часто. Это позволяет Microsoft быстрее решать требования отрасли.

  • Инструментальные панели: Одним из величайших свойств
    Монитора Azure является его богатство визуализации сведений. SCOM в целом ориентированная на уведомления система и
    имеет очень ограниченные возможности визуализации. Визуализация данных способствует инженерам в более быстром доступе
    к существенным данным. Они к тому же позволяют нам создавать индивидуальные заголовки на основе своих собственных
    запросов. Такая инструментальная панель способна представлять Изменения и Регистрационные данные.

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

В некой гибридной среде мы способны интегрировать локальные системы с Монитором Azure применяя три таких метода:

В некой среде SCOM мы способны отслеживать компоненты и службы AD применяя важные пакеты управления. Они собирают
гигантский объём сведений. Однако для выявления потенциальных проблем инженерам требуется анализировать такие получаемые
данные. Монитор Azure предоставляет два пакета решений, которые собирают сведения из некой среды AD и анализируют
их за вас. После анализа они будут визуализированы в дружественном пользователю виде. Они также предоставит вам
суть того как исправить выявленные проблемы, а также предоставит руководства относительно того как улучшить
производительность, безопасность и высокую доступность имеющейся среды следующим образом:

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

Самый первый этап настройки состоит во включении модулей AD в Мониторе Azure. Мы можем разрешить их,
воспользовавшись такой последовательностью шагов:

Наш следующий этап конфигурирования состоит в установке необходимых агентов аналитик в своих контроллерах домена и
их подключения к Монитору Azure. Это делается следующим образом:

  1. Зарегистрируйтесь в своём контроллере домена в качестве Администратора домена.

  2. Зарегистрируйтесь в портале Azure/

  3. Проследуйте в All Services и затем отыщите
    Log Analytics workspaces.

  4. Кликните по подходящему рабочему пространству в данном списке.

  5. Затем пройдите в Advanced Settings, как это
    показано на следующем снимке экрана:


  6. После этого перейдите в Windows Servers и кликните по
    Download Windows Agent (64 bit) для получения
    необходимого агента. Кроме того, выпишите идущие следом WORKSPACE ID
    и PRIMARY KEY, так как они потребуются в процессе
    установки этого агента, как показывает наш следующий снимок экрана:


  7. После выгрузки необходимого агента запустите его от имени Администратора. В появившемся окне
    Agent Setup Options выберите вариант
    Connect the agent to Azure Log Analytics (OMS)
    и кликните по Next, как это показано на снимке экрана
    внизу:


  8. В появляющемся следом окне предоставьте Workspace ID и
    Workspace Key. Кроме того, выберите подходящее
    Azure Cloud. Если вы расположены за посредником (прокси),
    вам следует в этом окне также задать и установки этого посредника. По завершению кликните по
    Next, как это показано на снимке экрана далее:


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

  10. Через несколько минут, перейдя в
    Advanced Settings | Connected Sources | Windows Servers
    мы можем обнаружить приводимый ниже снимок экрана в котором вновь добавленные серверы подключены в качестве источников
    сведений:


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

Я надеюсь, теперь вы обладаете базовыми сведениями относительно того как Монитор Azure отслеживает некую
среду AD. Существует великое множество моментов, которые мы можем обнаружить при помощи Монитора Azure и очень
сложно осветить все эти возможности в короткой главе. Я настоятельно призываю вас ознакомиться с доступной
документацией
по Монитору Azure, чтобы получить из неё всё самое необходимое.

В своей предыдущей главе мы изучили что из себя представляет Azure AD Connect и как он работает в гибридной среде
Azure AD. Azure AD Connect отвечает за синхронизацию между Azure AD и локальным AD. Следовательно важно отслеживать
состояние жизнеспособности службы Azure AD Connect чтобы быть уверенным что он работает как ожидалось. В вычислительной
инфраструктуре в определённый момент времени может быть активным лишь один экземпляр Azure AD Connect, поэтому на
жизнеспособность данной службы оказывается большая нагрузка. Такая служба Azure AD Connect является службой Windows,
поэтому для отслеживания состояния этой службы имеется множество инструментов, например SCOM и Монитор Azure. Однако
даже когда эта служба поднята и запущена, это ещё не означает жизнеспособность синхронизации.

Для отслеживания жизнеспособности Azure AD Connect имеется служба
Azure AD Connect Health, поставляемая в
Azure AD Premium. Azure AD Connect Health способна выполнять мониторинг следующих типов ошибок синхронизации:

Внутренние сведения Azure AD Connect Health собираются через агентов жизнеспособности. Имеются три типа агентов,
применяемых Azure AD Connect Health:

  • Azure AD Connect (sync): Он устанавливается как часть
    Azure AD Connect. Данный агент будет получать сведения, относящиеся к Azure AD Connect, такие как состояние службы,
    правила синхронизации, название службы, время последней синхронизации, ошибки синхронизации и предупреждения.

  • Azure AD Connect Health Agent for Active Directory Federation
    Services (AD FS)
    : Этот агент способен получать дополнительные сведения для отслеживания
    жизнеспособности Azure AD Connect в некой федеративной среде. Такой агент будет получать такие сведения, как
    общее число обработанных AD FS запросов, основанных на доверительной стороне запросов, применяемых запросами методов
    аутентификации, предупреждения, отказов в запросах и тому подобное.

  • Azure AD Connect Health Agent for Active Directory Domain Services
    (AD DS)
    : Этот агент способен получать дополнительные сведения от некой локальной средф AD, которая
    будет предоставлять больше внутренней информации для выявления лежащих в основе каталога проблем в гибридной среде.
    Данный агент получает такие сведения как: уровни функционирования леса и домена, держатели роли
    FSMO
    (Flexible Single Master Operation), состояние репликации,
    число обработанных запросов аутентификации и тому подобное.

Для применения Azure AD Connect Health нам требуются такие предварительные условия:

Демонстрация

В этом разделе мы намерены рассмотреть работу Azure AD Connect Health. В своей демонстрационной среде у меня
имеется установленной самая последняя версия Azure AD Connect. Azure AD Connect Health (sync) поставляется как
его часть, что показано на снимке экрана ниже:

Однако я хочу установить Azure AD Connect Health Agent for
AD DS
для получения дополнительных сведений из своей локальной среды AD. Для этого выполните следующие
шаги:

Azure AD Connect Health в целом сосредоточен на мониторинге жизнеспособности синхронизации каталога.
Дополнительные внутренние сведения, собираемые из агентов AD FS и AD DS в основном помогают устранять неисправности
проблемы жизнеспособности синхронизации каталога. Тем не менее, жизнеспособность синхронизации не означает что
у нас запущена жизнеспособная гибридная среда Azure AD. Это можно гарантировать только путём мониторинга угроз
безопасности инфраструктуры идентификации. Microsoft обладает разнообразными службами, которые способны выполнять
мониторинг угроз безопасности инфраструктуры идентификации. Хорошими примерами этого выступают Azure Security Center
и Azure Sentinel. Я настоятельно рекомендую ознакомиться с этими решениями для дальнейшего улучшения общей
жизнеспособности вашей инфраструктуры идентификации.

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

В этой главе мы начали с рассмотрения инструментов локального Windows и тех методов, которые могут применяться для
отслеживания и аудита сред AD. Прежде всего мы начали с инструментов GUI, а затем перешли к аудиту на основе PowerShell.
Далее мы рассмотрели ATA Microsoft и то как он способен выявлять угрозы идентификации в инфраструктуре, которые
невозможно выявлять обычными инструментами и методами. Позднее мы рассмотрели современный мониторинг на основании
Облачного решения Microsoft и решения аналитик журналов, Монитора Azure. Воспользовавшись демонстрацией, я также пояснил
как мы можем настраивать и отслеживать жизнеспособность конкретной среды AD. И наконец, последнее, но не менее важное,
мы также изучили как Azure AD Connect Health способен помогать жизнеспособности синхронизации установленной гибридной
среды Azure AD.

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

Логирование входа (аутентификации) пользователей и компьютеров в домене в базу mssql | windows для системных администраторов

Давным-давно, еще во времена Windows Server 2003, у меня возникла необходимость логировать информацию о входах пользователей на компьютеры домене в удобном виде. Тогда задача решалась простым батник, который запускался как логон скрипт в GPO. Батник записывал в блокнот логин пользователя, имя компьютера, дата и время входа. С тех пор утекло много воды, батник усложнялся и переезжал с одного места работы на другое. Со временем скрипт был переделан на рельсы PowerShell, а информация стала писаться во внешнюю базу данных MS SQL.

Скрипт будет полезен администраторам, безопасникам и людям, которые занимаются инвентаризацией компьютеров в организации. Изначально скрипт писал данные в csv файл в сетевой папке. Но со временем, размера CSV файл сильно вырастал, и он стал открываться очень долго. Приходилось создавался новый файл. В итоге решил складывать информацию о регистрации пользователей в сети в отдельной небольшой базе. Для удобства просмотра содержимого базы данных сделал небольшую веб-страницу на PHP.

PowerShell скрипт для сбора инвентаризационной информации о компьютере и времени входа пользователя выглядит так:

#Собираем данные
$computerSystem = Get-CimInstance CIM_ComputerSystem
$windowsInfo = Get-CimInstance -ClassName win32_operatingsystem
$username = $env:USERNAME
$computername = $env:COMPUTERNAME
$vendor = Get-CimInstance -ClassName Win32_ComputerSystemProduct | foreach { $_.vendor }
$computerver = Get-CimInstance -ClassName Win32_ComputerSystemProduct | foreach { $_.version }
$serial = get-wmiobject win32_bios | foreach { $_.serialnumber }
$computerCPU = Get-CimInstance CIM_Processor |foreach { $_.Name }
$computerHDD = Get-CimInstance Win32_LogicalDisk -Filter "DeviceID = 'C:'"
$lastboot = Get-CimInstance CIM_OperatingSystem
$timeformat='MM-dd-yyyy hh:mm:ss tt'
$time = (Get-Date).ToString($timeformat)
$model = $computerSystem.Model
$HDD = "{0:N2}" -f ($computerHDD.Size/1GB)
$HDDFree = "{0:N2}" -f ($computerHDD.FreeSpace/1GB)
$RAM = "{0:N2}" -f ($computerSystem.TotalPhysicalMemory/1GB)
$Build = $windowsInfo.Version
$lastbootUP = $lastboot.LastBootUpTime
#Подключаемся к базе
$connection = New-Object System.Data.SqlClient.SqlConnection
$connection.ConnectionString = "Data Source=servername,1433;Initial Catalog=basename;Integrated Security=SSPI;"
$connection.Open()
#Вставляем данные в базу
$cmd = New-Object System.Data.SqlClient.SqlCommand
$cmd.connection = $connection
$cmd.CommandText = "INSERT INTO BaseTable (Datetime,Username,Computer,vendor,model, compversion,Serial,CPU,HDD,HDDFree,RAM,Build,lastboot)
VALUES('{0}','{1}','{2}','{3}','{4}','{5}','{6}','{7}','{8}','{9}','{10}','{11}','{12}')" -f
$time,$username,$computername,$vendor, $model, $computerver,$serial,$computerCPU , $HDD, $HDDFree,$RAM,$Build, $lastbootUP
$cmd.ExecuteNonQuery()
#Закрываем соединение
$connection.Close()

Данный PowerShell скрипт нужно запускать при входе пользователя через GPO.

В качестве базы данных используется бесплатная редакция Microsoft SQL Server в редакции Express. Это бесплатная редакция с максимальным размером БД 10 Гб, чего за глаза хватит для наших нужд. MSSQL Server можно установить на выделенный хост, или использовать один из существующих серверов. Кроме того, за счет использования нативной БД Microsoft не придется ставить дополнительных драйверов или коннекторов на компьютеры пользователей для подключения к MSSQL из PowerShell.

Рассмотрим строку подключения к базе данных:

$connection.ConnectionString = "Data Source=servername,1433;Initial Catalog=basename;Integrated Security=SSPI;"

  • servername
    — имя сервера, на котором запущена база данных MS SQL
  • basename
    — имя базы данных

При добавлении информации в базу данных SQL запросом указывается:

  • BaseTable
    — имя таблицы базы данных
  • Datetime,Username,Computer,vendor,model, compversion,Serial,CPU,HDD,HDDFree,RAM,Build,lastboot
    — имена столбцов.

база данных с информацией о входе пользователей на компьютеры в домене

За 3 месяца у меня набежало 7190 строк.

Для вывода информации было решено создать простую страничку на php, которая будет читать с базы данных. Для этого на сервере с БД нужно установить веб сервер IIS и PHP.

К сожалению, знаний php не имел, поэтому пришлось учиться на ходу. У меня получился такой код:

<form name="search" method="POST" action="">
<input type="text" name="query" placeholder="Поиск">
<button type="submit">Go</button>
</form>
<?php
if (isset($_POST['query'])) $query = $_POST['query'];
$serverName = "servername\sqlexpress";
$connectionInfo = array( "Database"=>"basename" , "CharacterSet" => "UTF-8");
$conn = sqlsrv_connect( $serverName, $connectionInfo);
if (isset($query)) {
$tsql = "SELECT * FROM BaseTable WHERE Computer LIKE '%$query%' OR Username LIKE '%$query%' OR vendor LIKE '%$query%' OR Model LIKE '%$query%' OR Serial LIKE '%$query%'";
} else {
$tsql = "SELECT * FROM BaseTable";
}
$stmt = sqlsrv_query( $conn, $tsql );
//$stext = $_POST['name'];
if ($stmt) {
echo '<table border="1" cellpadding="7" cellspacing="0">';
/* Header */
?>
<tr>
<th>Username</th>
<th>Computer</th>
<th>Vendor</th>
<th>Model</th>
<th>Compversion</th>
<th>Serial</th>
<th>CPU</th>
<th>HDD</th>
<th>HDDFree</th>
<th>RAM</th>
<th>Build</th>
<th>DateTime</th>
<th>Lastboot</th>
</tr>
<?php
/* Body */
while ($row = sqlsrv_fetch_array($stmt, SQLSRV_FETCH_ASSOC)) {
echo '<tr>';
foreach ($row as $key => $value) {
echo "<td  bgcolor='#D3EDF6' >{$value}</td>";
}
echo '</tr>';
}
echo '</table>';
}
?>

Ну и теперь просто переходя на URL адрес http://computername/ можно видеть информацию о входах пользователей в домен, а также инвентаризационную информацию.

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

html страница с информцией о регистрации компьютеров и пользователей в домене

Таблица 1. список событий аудита событий active directory в windows server 2008

Проверка учетных данныхИДЕНТИФИКАТОР Сообщение4774 Учетная запись была сопоставлена для входа в систему.4775 Не удалось сопоставить учетную запись для входа в систему.4776 Предпринята попытка проверить учетные данные для учетной записи контроллера домена.4777 Не удается проверить учетные данные для учетной записи контроллера домена.

Управление учетной записью компьютераИДЕНТИФИКАТОР Сообщение4741 Создана учетная запись компьютера.4742 Изменена учетная запись компьютера.4743 Удалена учетная запись компьютера.

Управление группами рассылкиИДЕНТИФИКАТОР Сообщение4744 Создана локальная группа с отключенной проверкой безопасности.4745 Изменена локальная группа с отключенной проверкой безопасности.4746 Добавлен пользователь к локальной группе с отключенной проверкой безопасности.

4747 Удален пользователь из локальной группы с отключенной проверкой безопасности.4748 Удалена локальная группа с отключенной проверкой безопасности.4749 Создана глобальная группа с отключенной проверкой безопасности.4750 Изменена глобальная группа с отключенной проверкой безопасности.

4751 Добавлен пользователь к глобальной группе с отключенной проверкой безопасности.4752 Удален пользователь из глобальной группы с отключенной проверкой безопасности.4753 Удалена глобальная группа с отключенной проверкой безопасности.4759 Создана универсальная группа с отключенной проверкой безопасности.

4760 Изменена универсальная группа с отключенной проверкой безопасности.4761 Член добавлен к универсальной группы с отключенной проверкой безопасности.4762 Удален пользователь из универсальной группы с отключенной проверкой безопасности.Другие события управления учетными записямиИДЕНТИФИКАТОР Сообщение4739 Изменена политика домена.

4782 Хэш пароля учетной записи доступа к нему.4793 Был вызван API проверку политики паролей.Управление группой безопасностиИДЕНТИФИКАТОР Сообщение4727 Создана глобальная группа с включенной безопасностью.4728 Добавлен пользователь к глобальной группе с включенной безопасностью.

4729 Удален пользователь из глобальной группы с включенной безопасностью.4730 Удалена глобальная группа с включенной безопасностью.4731 Создана локальная группа с включенной безопасностью.4732 Добавлен пользователь в локальную группу с включенной безопасностью.

4733 Удален пользователь из локальной группы с включенной безопасностью.4734 Удалена локальная группа с включенной безопасностью.4735 Изменена локальная группа с включенной безопасностью.4737 Изменена глобальная группа с включенной безопасностью.

4754 Создана универсальная группа с включенной безопасностью.4755 Изменена универсальная группа с включенной безопасностью.4756 Добавлен пользователь к универсальной группе с включенной безопасностью.4757 Удален пользователь из универсальной группы с включенной безопасностью.4758 Удалена универсальная группа с включенной безопасностью.4764 Изменен тип группы.

Управление учетными записями пользователейИДЕНТИФИКАТОР Сообщение4720 Учетная запись пользователя создана.4722 Учетная запись пользователя включена.4723 Изменен пароль учетной записи.4724 Сброс пароля пользователя.4725 Учетная запись пользователя отключена.

4726 Учетная запись пользователя удалена.4738 Изменена учетная запись пользователя.4740 Учетная запись пользователя заблокирована.4765 Журнал SID был добавлен к учетной записи.4766 Не удалось добавить журнал SID учетной записи.4767 Учетная запись пользователя была разблокирована.

4780 Список управления Доступом был установлен на учетные записи, которые являются членами группы администраторов.4781 Было изменено имя учетной записи.4794 Была предпринята попытка задать режим восстановления служб каталогов.5376 Диспетчер учетных данных: учетные данные были сохранены.5377 Диспетчер учетных данных: учетные данные были восстановлены из резервной копии.

Другие событияИДЕНТИФИКАТОР Сообщение1102 Очищен журнал безопасности4624 Успешный вход в систему4625 Не удачный вход в систему

В ветке Политика аудита также активируются и другие возможности (см.рис.1): аудит входа/выхода в систему, аудит управления учетными записями, доступ к объектам, изменения политик и так далее. Например, настроим аудит доступа к объектам на примере папки с общим доступом.

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

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

Аудит доменных служб Active Directory в Windows Server 2008 R2 / Хабр
Рис.5 Настраиваем аудит папки с общим доступом

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

Больший контроль событий, записываемых в журнал, достигается применением политики детализированного аудита (Granular Audit Policy), которая настраивается в Параметры безопасности/Локальные политики/Advanced Audit Policy Configuration. Здесь 10 подпунктов:

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

— Подробное отслеживание – событий RPC и DPAPI, создания и завершения процессов; — Доступ к службе каталогов DS – аудит доступа, изменений, репликации и подробной репликации службы каталогов; — Вход/выход – аудит блокировки учетных записей, входа и выхода в систему, использования IPSec, сервера политики сети;

— Доступ к объектам – аудит объектов ядра, работы с дескрипторами, событий создаваемых приложениями, служб сертификации, файловой системы, общих папок, платформой фильтрации; — Изменение политики – изменения политики аудита, проверки подлинности, авторизации, платформы фильтрации, правил службы защиты MPSSVC и другие;

— Использование прав – аудит прав доступа к различным категориям данных; — Система – аудит целостности системы, изменения и расширения состояния безопасности, драйвера IPSec и других событий; — Аудит доступа к глобальным объектам – аудит файловой системы и реестра.

Похожее:  Windows SSO | Справка Firefox
1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector