Dynamic Access Control для Windows 7

В своих новых (некогда) ОС Windows 8 и Windows Server 2012 Microsoft реализовала ряд технологий, получивших общее маркетинговое название «динамическое управление доступом» (Dynamic Access Control, DAC). В частности, динамическое управление доступом включает в себя использование для авторизации доступа к файл-серверу не только SID учётных записей пользователей и групп безопасности, в которые эти записи входят, но и других атрибутов учётных  записей в каталоге Active Directory (таких, как принадлежность к определённому подразделению) через посредство утверждений (claims) о пользователе. Технологии эти, похоже, оказались интересными пользователям, но, к сожалению, Microsoft плохо озаботилась тем, чтобы подробно их документировать в Technet Library — ограничившись, по существу, лишь описанием типовых сценариев развёртывания. И теперь время от времени на различных форумах я натыкаюсь на вопрос, вынесенный в заголовок — можно ли использовать динамическое управление доступом для клиентов файл-сервера, работающих под управленем более ранних версий ОС Windows — такими, как Windows 7. Читать далее

О перерывах в репликации Active Directory

Как и многих специалистов IT, у меня есть своя домашняя лаборатория. Устроена она на обычном компьютере (правда, с 32 ГБ памяти), под VMWare Workstation.  На виртуальных машинах в наше время можно попробовать очень многое. Но после того, как попробовал, я очень редко ликвидирую старые, некогда настроенные стенды — наборы виртуальных машин. Большинство из них спокойно лежат на диске и ждут своего часа (мало ли что понадобится посмотреть для ответа на вопрос на форуме Technet), но это возможно не всегда. Например, если в состав набора входит несколько контроллеров домена в одном лесу, то оставлять их лежать просто так нельзя  — пролежат они больше времени жизни захороненных объектов и откажутся после этого реплицироваться. Поэтому такие виртуалки, на которых находятся контроллеры доменов, я время от времени (раз в один-два месяца) запускаю, чтобы они не забыли друг про друга.

Один из таких наборов содержит у меня три контроллера домена (КД) под управлением Windows 2012 R2 в двух подсетях, соединённых маршрутизатором: два — в одной подсети (и сайте), один — в другой (и тоже в отдельном сайте) . На днях я в очередной раз запустил всё это хозяйство, и решил вдруг проверить — а действительно ли они реплицируются, и тут выяснилось — что нет: по некоторым (неважным для последующего рассказа) причинам один из интерфейсов маршрутизатора отключился от виртуального сегмента LAN, в результате чего связь между подсетями оказалась потеряна. Причём потеряна она была не далеко в этот раз, но (к счастью) до того, как истекло время жизни захороненных объектов — всё это неплохо было видно в выдаче команды repadmin /showrepl.

После восстановления работоспособности маршрутизатора я решил провести реплликацию вручную, через консоль AD Sites & Services. Репликация от одиночного КД прошла нормально, но вот обратная репликация — на одиночный КД с группы из двух КД идти отказалась. Ошибка при этом вылезла странная: «The naming context is in the process of being removed or is not replicated from the specified server». Странная — потому что все контексты (т.е. разделы каталога) давным-давно были реплицированы куда надо и ниоткуда не удалялись.

Читать далее

Чистьте Active Directory!

Я уже писал ранее о том, как не удалённый вовремя из Active Directory  вышедший из строя контроллер домена может мешать её работе. И вот, форумы русского Technet принесли ещё один пример того, как не вычищенные вовремя из Active Directory следы «мёртового» контроллера домена могут мешать нормальному функционированию. Автор вопроса на форумах наткнулся на ситуацию, когда он не может добавить в домен новую рабочую станцию. При этом, в журнале событий фиксировалось событие с кодом 16651 от источника Microsoft-Windows-Directory-Services-SAM , говорящее об исчерпании пула относительных идентификаторов (RID) и о проблеме получения нового пула. Однако, автор вопроса уверял, что контроллер — владелец роли RID Master работоспособен. Дополнительный опрос и диагностика показали следующую картину: у автора вопроса физически был ровно один контроллер домена, который являлся владельцем всех ролей FSMO, но в базе данных Active Directory остались записи для другого, неработоспособного контроллера домена, и тесты dcdiag сообщали о совершенно естественных проблемах репликации с этим, физически отсутствующим контроллером. И именно это послужило источником проблемы. Дело в том, что владелец роли FSMO (при настройках по умолчанию) после запуска не начинает функционировать в качестве такового до тех пор, пока он не проведёт начальную синхронизацию раздела каталога, с которым связана соответствующая роль FSMO, с каким-либо другим контроллером домена, на котором есть копия этого раздела. Сделано это из соображений безопасности — чтобы случайно включенный в сеть бывший владелец роли, у которого роль была принудительно изъята и передана другому контроллеру, не нарушил функционирование Active Directory. Поэтому у автора, хотя роль RID master и была перенесена на функционирующий контроллер, этот контроллер не начал выполнять функции RID master, потому что не мог провести начальную синхронизацию, о необходимости которой говорило наличие в AD другого контроллера домена. После удаления из AD записей о неработоспособном контроллере, когда  необходимость в начальной синхронизации отпала, проблема была решена — новый пул RID был получен и рабочая станция была успешно добавлена. Мораль всей этой истории такова — не оставляйте в AD следы вывденных из эксплуатации контроллеров доменов: они могут помешать работе.

USN Rollback, великий и ужасный

Что такое USN Rollback

Представьте себе, что в один не очень прекрасный день вы решили восстановить один из ваших контроллеров домена (КД) из резервной копии, которую вы по привычке сделали старым проверенным средством снятия образа диска, типа Acronis TrueImage. Или решили откатить ваш виртуализованный КД к старому снимку, сделанному средствами гипервизора (и всё это работало не под Windows Server 2012). Или же вам, как и мне однажды, не повезло: из-за сбоя RAID-контроллера, который управляет аппаратным зеркальным томом, содержащим систему КД, некоторое время тому назад из  этого зеркала вылетел один диск, а после перезапуска RAID-контроллер решил загрузить систему именно с этой, устаревшей половинки зеркала.

И вот, после перезагрузки вы обнаруживаете, что ваш контроллер домена — уже не совсем контроллер домена: он совершенно не желает авторизовывать пользователей и реплицировать изменения базы данных Active Directory (AD) с другими КД.  Читать далее

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

Введение.

Недавно на форуме русского Microsoft Technet мне попался такой вопрос одного из участников: «возможно ли задавать условия по двум критериям для доступа к терминальному серверу («узел сессий удаленного рабочего стола») под управлением Windows Server 2008 — диапазон ip (или список имен компьютеров) и логин (или группа)» Т.е., спрашивающий хотел разрешить вход с каждого из компьютеров (или их групп) только определённым пользователям (или группам пользователей).

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

Задача мне показалась интересной, и я решил промоделировать её решение в лабораторной среде.

Основой решения является использование защиты подключений с помощью IPSec с расширением от Microsoft (протокол AuthIP).Это расширение позволяет производить при подключении аутентификацию и пользователя, и компьютера, с которого было выполнено подключение. Интеграция же IPSec с брандмауэром Windows позволяет в правилах брандмауэра использовать эту информцию — то есть, указать, к каким пользователям и компьютерам это правило применяется.

Пример настройки, приведенный ниже, годится для терминального сервера, работающего под управлением Windows Server 2008 R2 и выше, и компьютеров, с которых произодится подключение, под управлением ОС Windows 7 и выше. Однако, с некоторыми модификациями — а именно, отказом от неподдерживаемой в Windows Vista и Windows Server 2008 возможности указания портов протокола TCP в правилах безопасности подключения — такая настройка возможна и для терминального сервера под управлением Windows Server 2008, и для клиентов под управлением Windows Vista.

Читать далее

DsRemoveDsDomainW error 0x21a2

Расчищал сегодня сервер Hyper-V с тестовыми виртуальными машинами. Больно много их накопилось — место на диске много занимают. Многие давно не запускались.

В частности, наткнулся на набор из трех контроллеров домена (под Win2K8 R2) в двух доменах в одном дереве (и двух разных сайтах) — два в корневом домене и один в дочернем. Это я хотел в свое время проверить, исправили ли в программе установки Exchange 2010 в SP2 некую древнюю ошибку (сейчас уже неважно, какую), а потому так сложно . Не запускались они аж с марта, а потому репликация AD между ними умерла (tombstone lifetime exceeded — 180 дней уже прошло, однако). И решил я два контроллера доменов удалить, вместе с дочерним доменом, а один — оставить для будущих экспериментов: одиночный КД репликации не требует, а потому — не портится. Расчищать приходится, естественно, через ntdsutil, т.к. штатное понижение КД через мастер dcpromo при отсутствии репликации не работает.

Сказано — сделано. Запускаю ntdsutil, подключаюсь к единственному оставшемуся серверу, набираю metadata cleanup, выбираю (select operation target — list domains — select domain 1 ) дочерний домен, в нем (list sites — select site 1 — list servers for domain in site — select server 0) — единственный КД, возвращаюсь из режима выбора, и удаляю этот контроллер (remove selected server). После чего пытаюсь удалить домен (remove selected domain) и получаю отлуп:

DsRemoveDsDomainW error 0x2015(The directory service can perform the requested operation only on a leaf object).

Ну, причина отлупа мне сразу становится очевидной: вспоминаю, что DNS в дочернем домене я настраивал, причем — стандартным образом, с хранением зоны домена в подразделе DomainDNSZones («область репликации — все DNS-серверы указанного домена»). Поминаю недобрым словом Microsoft за то, что они не удосужились добавить удаление этого раздела вместе с разделом домена, и принимаюсь за его удаление уже известным мне способом: выбираю (select operation target — list n c — select n c 6), возвращаюсь из режима выбора и пытаюсь удалить контекст именования: remove selected n c. Хрен там — получаю совершенно неожиданную ошибку:

DsRemoveDsDomainW error 0x21a2(The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner).

Тут бы мне сразу остановиться и призадуматься, но… Пытаюсь зайти с другой стороны: выхожу из режима metadata cleanup, захожу в режим partition management и пытаюсь удалить нужный контекст именования оттуда (delete nc DC=DomainDNSZones,DC=subdom,DC=domain,DC=loc). Получаю ту же ошибку.
Следующие минут пятнадцать-двадцать проходят в поиске решения сначала в MS Knowledge Base (его там нет), затем — на сайте Microsoft (тоже нет), затем — во всем интернете (первые несколько релевантных ссылок ведут на вопросы без ответов). И вот тут я понял, что придется думать самому.
Вчитавшись внимательно в текст, я задумался, а о каком FSMO role ownership идет речь. Ведь явно — не об infrastructure master раздела для зон DNS: его в любом случае быть не должно, т.к. контроллера домена, содержащего этот раздел больше ни одного нет.
И тут меня осенило.Поскольку репликация в момент запуска текущего КД (владеющего всем ролями FSMO) была в развалившемся состоянии, то требования начальной синхронизации для всех этих ролей (подробности см.  в MS KB) выполнена не была, а потому операции, требующие использования соответствующий роли (в нашем случае — domain naming master) недоступны. Именно об этом мне и пыталась сообщить Windows.
Ну, а коли причина проблемы установлена, то решить ее теперь — дело простое. Т.к. все остальные контроллеры домена предназначены к уничтожению, то нужно удалить их из Active Directory. Контроллер поддомена я удалил, но ведь остался еще один дополнительный контроллер корневого домена: я отложил его удаление на потом — а зря! Удаляю этот контроллер через консоль AD Sites and Services (можно и через ntdsutil, но нужная консоль у меня уже была открыта), на всякий случай вручную прогоняю KCC (через локальное меню оставшегося сервера в той же консоли). Теперь повторяю удаление контекста именования раздела приложений для зон DNS, затем — удаление поддомена. Всё сработало. Победа разума над искусственным интеллектом состоялась.

Мораль сей басни такова: прежде чем удалять поддомены, почините репликацию с оставшимися в живых КД. Встретив ошибку 0x21a2, удалите все мертвые КД, и добейтесь успешной репликации с оставшимися в живых (если таковые остались).

Добавление сетевого интерфейса в RRAS в Windows 2008

Сегодня возникла нужда добавить дополнительную сетевую карту на шлюзовой (NAT в Интернет и VPN в центральный офис) сервер на одной из площадок — у начальства возникла идея сделать гостевой WiFi с доступом в интернет. Дело нехитрое, сетевую карту наш техник вставил, сервер включил. Но интерфейс в оснастке управления службы маршрутизации и удаленного доступа (RRAS не появился). Что было совершенно ожидаемо — сервер работает под Windows 2008, а в ней Microsoft почему-то выпилила автоматическое добавление в RRAS интерфейсов для новых сетевых адаптеров.
Проблема эта известная, но штатный способ борьбы с ней не отличается изяществом: надо деактивировать, а затем — заново активировать и настроить службу маршрутизации и удаленного доступа. Это означает и существенный перерыв в обслуживании, и риск внесения ошибок при конфингурировании (впрочем, последнего можно избежать, если перед деактивацией сохранить конфигурацию RRAS командой netsh, а после активации — применить сохраненную конфигурацию).
К счастью, народ нашел более простой способ добавления новых интерфейсов в RRAS — только он не документирован, а описание его погребено в толще форумов Technet, в последнем сообщении вот этой темы.
В связи с этим, я вижу смысл опубликовать его здесь.

Читать далее