Перевод учетных записей из леса Windows Server 2003 в Server 2012 R2

Выполняя миграцию леса из Server 2003 в Server 2012 R2, можно вручную удалить учетную запись каждого компьютера из исходного леса, а затем вручную присоединить его к целевому лесу. Конечно, это довольно неудобно, если требуется перенести несколько тысяч учетных записей компьютеров из одного леса в другой.

На такой случай предусмотрено специальное средство миграции Active Directory (ADMT), располагающее функциями, которые позволяют перенести учетные записи компьютера из одного домена в другой. Вы можете задействовать мастер миграции учетных записей компьютера, вызвать ADMT из командной строки или подготовить сценарий для автоматической миграции.

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

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

Информацию о переносе учетных записей компьютеров можно найти на страницах 148-153 руководства по средству миграции Active Directory (ADMT), которое опубликовано на сайте Microsoft по адресу http://www.microsoft.com/en-au/download/details.aspx?id=19188.

Политики миграции и изоляции доменов в Server 2003

Переход от Server 2003 к Server 2012 R2 — подходящая возможность повысить безопасность с помощью политик изоляции доменов. Переход от Server 2003 позволяет многим компаниям изменить способы взаимодействия клиентов с серверами. Одно из возможных изменений — внедрение политик изоляции доменов. Основная идея заключается в настройке политики сетевого экрана таким образом, чтобы серверы в компании обменивались данными только с клиентами, прошедшими проверку подлинности с использованием выбранного метода. Этот метод может подтверждать членство в домене, подлинность сертификата или даже, хотя это менее безопасно, общий секретный пароль.

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

Например, в 1990-х можно было быть вполне уверенным, что к внутренней сети компании подключены только проверенные компьютеры. Большинство сотрудников не располагали портативными компьютерами, и не в каждой сети использовался протокол DHCP. А для подключения компьютера к сети (многие из которых были сетями стандарта 10Base2 на основе коаксиального кабеля) требовался сетевой адаптер. Сегодня сетевые адаптеры окружают нас повсюду, но в середине 1990-х для большинства пользователей они не были частью повседневной жизни. Внутренние сети состояли из компьютеров, подключенных ИТ-специалистами, которые также в основном устанавливали сетевые адаптеры, загружали драйверы и физически подключали сетевые адаптеры к проводной сети.

Во время, когда был выпущен Windows Server 2003, соединительные кабели ценой в 2 доллара нечасто удавалось видеть на полках канцелярских магазинов. В 2003 году компьютеры в сети компании в основном также устанавливались ИТ-специалистами. Очень немногие сотрудники пытались подключать свои персональные компьютеры к сети компании.

Сегодня значительное число компьютеров не нужно физически подключать к сети компании, поскольку это делается беспроводным способом. Подключение личных компьютеров к общей сети настолько распространено, что в профессиональном обиходе появился термин BYOD («принеси свое устройство»).

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

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

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

Политики изоляции доменов не сделают серверы неуязвимыми при переходе от Server 2003 к Server 2012 R2, и следует принимать во внимание все возможные способы повышения уровня безопасности.

Дополнительные сведения о настройке политик изоляции доменов можно найти в руководстве Server and Domain Isolation Using IPsec and Group Policy, опубликованном на сайте Microsoft по адресу http://www.microsoft.com/en-au/download/details.aspx?id=18358.

Совершенствуем настройку сетевого экрана Windows

При переходе с Windows Server 2003 к Windows Server 2012 R2 (http://windowsitpro.com/windows-server/windows-server-2012) требуется уделить время переоценке способов настройки клиентских сетевых экранов для серверов компании. Необходимо учитывать, что во многих внутренних сетях серверные и клиентские сетевые экраны полностью отключены.

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

Надо сказать, что сетевой экран, поставляемый вместе с Windows Server 2003, имеет неважную репутацию. Именно поэтому некоторые администраторы приобрели привычку отключать сетевой экран вместо того, чтобы работать с ним. Оправданием такого подхода отчасти может служить то, что серверы все равно находятся в защищенной внутренней сети, поэтому сетевой экран как таковой не нужен.

Как отмечалось выше, локальные сети внутри компании 12-летней давности сильно отличаются от внутренних сетей современных компаний. 12 лет назад портативные компьютеры были редкостью. А сейчас они как кошки: только отвернешься, невозможно предсказать, куда они отправятся и чем займутся. И что притащат, когда вернутся в дом (в защищенную внутреннюю сеть).

Поэтому, переходя с Windows Server 2003 на Windows Server 2012 R2, ни в коем случае не отключайте сетевой экран Windows. Настраивая его, можно воспользоваться групповой политикой, чтобы обеспечить единый набор базовых правил на всех серверах, а затем назначить отдельным серверам особые правила. Включите и используйте журналы сетевого экрана, чтобы понять, какие правила нужно создать, вместо того чтобы просто отключать сетевой экран, когда он доставляет неудобства.

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

Оцениваем инфраструктуру WSUS

В большинстве сетей, в которых развернут Windows Server 2003, имеется пара серверов WSUS. Перед переходом на Server 2012 R2 следует оценить инфраструктуру WSUS и выбрать способ переноса служб WSUS для их размещения на новой операционной системе.

Напомню, что WSUS — это службы обновления Windows Server. Они предназначены для размещения локального репозитария программных обновлений. С их помощью локальные администраторы контролируют, какие обновления применяются к клиентам WSUS, не полагаясь на стандартные подтверждения при выпуске обновлений компанией Microsoft. Большинство компаний используют службы WSUS, чтобы иметь возможность одобрять обновления в удобное время.

Оценивая инфраструктуру WSUS компании, необходимо проверить следующие характеристики:

  • Где хранятся обновления. Некоторые серверы WSUS настроены таким образом, что выполняют лишь одобрение, а клиенты извлекают обновления из серверов Microsoft Update.
  • Интеграция с другими продуктами. И диспетчер параметров настроек, и диспетчер виртуальных машин могут быть интегрированы с WSUS.
  • Какая используется схема настройки — восходящая или нисходящая. В некоторых компаниях одобрения и обновления на сайтах филиалов извлекаются из центрального сервера WSUS.

Следует также попытаться выяснить, сколько серверов WSUS требуется компании. Главная особенность WSUS, которую необходимо учитывать: при включенной службе BITS каждый сервер WSUS может теоретически обслуживать до 25 000 клиентов.

Далее речь пойдет о том, как выполнить миграцию WSUS-сервера.

Перенос WSUS из Server 2003 в Server 2012 R2

Вы можете перенести экземпляр WSUS, размещенный на Windows Server 2003, на сервер Windows Server 2012 R2. Для этого достаточно выполнить определенную последовательность шагов.

Первый шаг — убедиться, что экземпляр Windows Server 2003 WSUS обновлен до уровня WSUS 3.0 SP2.

Можно выполнить миграцию, если сервер WSUS использует базу данных Windows Internal, или если сервер WSUS задействует SQL Server. Можно выполнить миграцию из исходного сервера, использующего базу данных Windows Internal, на сервер назначения, который использует базу данных Windows Internal или SQL Server, но нельзя перейти от сервера WSUS с базой данных SQL Server к целевому серверу WSUS, в котором применяется база данных Windows Internal.

При выполнении миграции для TCP-порта 7000 используются команды Send-SmigServerData и Receive-SmigServerData. Это означает, что необходимо обеспечить связь через этот порт между исходным и целевым серверами.

После того, как TCP-порт 7000 будет открыт, нужно выполнить следующие шаги:

  • Перенести двоичные файлы WSUS. Для этого можно задействовать любой метод копирования файлов или средство миграции Windows Server.
  • Перенести группы WSUS. Это можно сделать с помощью средства миграции Windows Server.
  • Выполнить резервное копирование и восстановление базы данных WSUS. Если используется база данных Windows Internal, то для выполнения этой операции потребуется осуществить несколько хитроумных ходов в SQL Server Management Studio. Если на исходном и целевом серверах используется SQL Server, то задача немного упрощается. Дополнительные сведения можно найти на веб-странице TechNet по адресу https://technet.microsoft.com/en-au/library/hh852349.aspx
  • Изменить удостоверение сервера WSUS. Таким образом, клиенты, зарегистрированные на исходном сервере WSUS, не будут использовать целевой сервер WSUS.

Дополнительные сведения о переносе WSUS с Server 2003 на Server 2012 R2 можно получить по адресу https://technet.microsoft.com/en-au/library/hh852339.aspx.