Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 2-я — Пост-конфигурация

В предыдущей части — Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 1 — Installation

Вступление

В этом посте мы займёмся пост-конфигурацией Active Directory: Мы определим зоны безопасности, которые в дальнейшем станут краеугольными камнями в вопросе делегирования разрешений, и ограничим добавление объектов в домен. Также, мы немного донастроим службу DNS.


Читать далее Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 2-я — Пост-конфигурация

Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Вступление

По сей день, Active Directory Domain Services (AD DS) остаются ядром Windows-инфраструктуры. С каждым релизом Windows Server, AD DS получает новые возможности , сохраняя превосзходную обратную совместимость. Windows Server 2016 привносит следующие улучшения в AD DS:

В этой статье мы заложим краеугольный камень нашей будущей инфраструктуры: высоко-доступный экземпляр AD DS из двух контроллеров домена. Схема будет простейшей: два обычных контроллера домена в одном сайте.


Читать далее Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Строим высоко-доступную Windows-инфраструктуру в командной строке

Несколько месяцев назад была выпущена Windows Server 2016. В этом релизе Microsoft произвела 2 существенных изменения в вариантах установки Windows Server:

  • Появился Nano Server.
  • Установка «Server with a GUI» теперь включает «desktop experience» и называется соответствующе: «Server with Desktop Experience». Т.к. не существует поддерживаемого способа удалить компоненты desktop experience, Это должно мотивировать ИТ-администраторов использовать Server Core, вместо версии с графическим интерфейсом.

Т.е. всё за то, чтобы прекратить, наконец-то, использовать графический интерфейс при управлении Windows Server и начать полноценно работать в командной строке.
Этот пост — первый в серии о том, как построить свою собственную высоко-доступную инфраструктуру на Windows, используя исключительно PowerShell (и немного других утилит командной строки). В идеале я планирую обсудить следующее:

  • Active Directory Domain Services,
  • Active Directory Certificate Services,
  • Desired State Configuration,
  • Key Management Services,
  • DHCP,
  • SCDPM,
  • SCCM,
  • Exchange Server,
  • And, possibly, S4B Server, as well.

Пока я не могу говорить об управлении и развёртывании Hyper-V, т.к. вся моя инфраструктура полностью виртуальная и, к сожалению, хостовые машины работают под управлением Windows Server 2012 R2.

PowerShell-код в статьях этой серии не будет содержать никаких жёстко заданных значений. Вместо этого, в начале каждого поста, я буду помещать набор переменных, используемых дальше по тексту — таким образом вы сможете просто и быстро применить это в своей инфраструктуре без изменения кода.

И первая часть уже здесь! Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Большая переработка 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

Множество компаний использует одну и ту же доменную зону, как во внутренней инфраструктуре, так и во внешней. В случае, если внутренняя зона, по совместительству, является именем домена 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