Архив рубрики: ADDS

ADDS, PowerShell, Windows Server 2016

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

Оставить комментарий

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

Вступление

Когда мы говорим о системах управления версиями (CVS), то первым делом нам в голову, разумеется, приходит программирование. В наши дни любой уважающий себя разработчик использует Git, или TFS, или Mercurial, или Subversion итд. Но это не значит, что концепция CVS нужна только разработчикам: Adobe, например, предоставляет дизайнерам собственное решение для управления версиями файлов.
А как насчёт нас, IT-администраторов? Учитывая растущую популярность концепции «инфраструктура как код», многие администраторы уже начали применять CVS для хранения скриптов и файлов конфигурации.

Сегодня я хотел бы поговорить об управлении версиями для групповых политик. Вы, наверное, знаете, что групповые политики – это не совсем текстовые файлы, поэтому традиционные CVS здесь не подходят. Именно поэтому Microsoft выпустили собственное решение, которое позволяет отслеживать изменения, сравнивать версии объектов групповых политик (GPO) и оперативно возвращаться к предыдущим: Advanced Group Policy Management (AGPM).

Интересно, что это не просто CVS, а ещё и инструмент, позволяющий делегировать административные права объектам групповых политик при помощи встроенного механизма.
Но даже если вы работаете в небольшой команде, и делегирование управления GPO вам не нужно, я всё равно рекомендую использовать AGPM в качестве системы управления версиями.

AGPM входит в Microsoft Desktop Optimization Pack, бесплатный набор ПО, доступный подписчикам Microsoft Software Assurance. Узнать об этом продукте больше вы можете по ссылке.

Warning

Установка AGPM НЕ ОТМЕНЯЕТ необходимости делать резервные копии Active Directory.

In this article:


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

ADDS, PowerShell, Windows Server 2016

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

Оставить комментарий

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

Вступление

Прощу прощения за длительный перерыв – за эти полгода произошло много всего, включая смену страны проживания и работы. А кроме того, как видно по предыдущим постам, я немного увлёкся PowerShell.
Во время написания этого поста меня тоже слегка занесло: мне даже пришлось разделить пост на две части. Поэтому сегодня у меня для вас не один, а целых два поста! Следующий находится вот здесь: Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 4-я — AGPM
До этого момента, мы работали с серверами в интерактивном режиме. Это считается не самой эффективной практикой, поскольку на поддержание интерактивной сессии тратятся ресурсы сервера. Также это достаточно неудобно при работе с большим количеством серверов.
Поэтому, в этой статье мы настроим удалённые административные рабочие станции, с помощью которых и будем в дальнейшем управлять инфраструктурой.

In this article:


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

ADDS, PowerShell, Windows Server 2016

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

Оставить комментарий

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

Вступление

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

In this article:


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

ADDS, PowerShell, Windows Server 2016

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

Оставить комментарий

Вступление

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

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

In this article:


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

ADDS, PowerShell, Windows

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

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

ADDS, Windows, Безопасность

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

Оставить комментарий

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

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

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

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

ADDS, PowerShell, Windows, Безопасность

Синхронизация 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 →

ADDS, Uncategorized

Active Directory Replication Status Tool перевыпущено

Оставить комментарий

Microsoft только что перевыпустила средство для мониторинга репликации AD «Active Directory Replication Status Tool» и теперь оно снова работает!

Если вы не знаете, что это такое и что за события разворачивались вокруг этого средства, вот краткое объяснение:
Active Directory Replication Status Tool — это маленький помощник для практически любого администратора Active Directory. Он быстро показывает статус репликации леса или домена в графическом интерфейсе (почти как repadmin, но только с GUI и проще). Ранее Microsoft решила отключить это средство в феврале 2016, все его пользователи должны были мигрировать в облачное решение по мониторингу Microsoft Operations Management Suite. Чтобы достичь этого, Microsoft опубликовала «обновлённую» версию инструмента, чьё «улучшение» состояло только в том, что в ней присутствовал таймер, запрещающий запуск AD Replication Status Tool после первого февраля.

Microsoft не учла одного: AD Replication Status Tool и OMS служат совершенно разным целям: вы используете OMS для постоянного мониторинга ИТ-инфраструктуры, в то время, как AD Replication Status Tool применяется время от времени, в тех случаях, когда нужно быстро оценить состояние репликации в AD: при обследовании нового леса, решении проблем с репликацией и т.п. Также, MS часто не думает об отключённых от интернета инфраструктурах. Наконец, некоторые организации не хотят (или не могут по закону) передавать чувствительную информацию третьим лицам, особенно через интернет.

Все эти недопонимания привели к появлению этого треда на UserVoice, где много ИТ-специалистов выражали своё недовольство и объясняли, почему облачное решение не может заменить локальное.

И вот, наконец, мы были услышаны — нам вернули локальное средство и можно было бы откинуться на спинку кресла и расслабиться, но…

Они не позволят нам уйти просто так:

В заключение, я хотел бы поблагодарить команду Operational Insights за понимание нужд IT-сообщества, Ryan Ries за создание оригинального треда на UserVoice и, конечно же, это не было бы возможно без вас — спасибо всем сисадминам, которые голосовали, спорили и убеждали команду OMS в том, что нам необходим локальный инструмент мониторинга репликации.