Большая переработка Synchronize-DNSZones.ps1

Сегодня я закончил серьёзную переработку моего сценария синхронизации DNS-зон Synchronize-DNSZones (больше о нём вы можете прочитать здесь). Основной причиной для переработки, являлось добавление поддержки записей на уровне непосредственно самой зоны. Для того, чтобы делать это эффективно, я разбил большой кусок кода на несколько функций (и вижу, что можно его подробить ещё).
В связи с новой функциональностью, появились и новые предупреждения:
55 — DNS-zone creation is not yet supported. (И не думаю, что когда-либо будет поддерживаться)
72 — Function New-DnsRecord failed.
82 — Cannot import DNSClient PowerShell module.

В процессе переработки я, наконец-то, заменил все глаголы в именах функций на одобренные (см. Get-Verb). Имя самого сценария я изменю чуть позже.
Исправил ситуацию с возвращением функцией Receive-DnsData пустого ответа.
Исправил опечатки, некорректную обработку ошибок, немного улучшил комментарии.
Также, вернул на место забытое объявление переменной $SMTPCc.

В будущем планирую добавить поддержку ShouldProcess (WhatIf).

Ваши пулл-реквесты и сообщения о проблемах приветствуются!

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

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

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

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

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

Google Glazier

Ого, Google только что выложил штуку для автоматической установки Windows. Штука написана на питоне и называется Glazier (стекольщик). Образы ОС в ней строятся на основании конфигурационных файлов, написанных на YAML — можно их хранить в системе контроля версий и очень удобно отслеживать изменения, откатываться и т.д.

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

Распространяется по лицензии Apache 2.0, пулл реквесты приветствуются.

Полезные блоги

Сегодня я хочу с вами поделиться списком блогов, которые я лично читаю и отслеживаю. Практически все из них ведутся независимыми IT-профессионалами, которые хорошо известны в сообществе и обладают наградами ala Microsoft MVP и ими подобными.
Рекомендую вам добавить эти блоги в RSS-читалку.

Конечно же я читаю и блоги TechNet/MSDN, но о них вы и так, я уверен, знаете, поэтому пока не буду ничего из них рекомендовать.

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

Встреча сообщества 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