Иллюстрированный самоучитель по Microsoft Windows 2003

Установка центра сертификации

Центр сертификации (ЦС) – важный элемент в системе безопасности организации, поэтому в большинстве организаций имеется собственный ЦС. В Windows Server 2003 центры сертификации могут быть двух классов: ЦС предприятия (Enterprise СА) и изолированный ЦС (Stand-alone CA). Внутри каждого класса могут быть два типа ЦС: корневой (root) и подчиненный (subordinate).

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

Для развертывания собственного ЦС:

1. Выберите на панели управления значок Add or Remove Programs (Установка и удаление программ).
2. В открывшемся окне нажмите кнопку Add/Remove Windows Components (Добавление и удаление компонентов Windows).
3. В окне мастера Windows Components Wizard (Мастер компонентов Windows) установите флажок Certificate Services (Службы сертификации) (при этом система предупредит вас о последствиях установки этих служб) и нажмите кнопку Next (Далее).
4. На следующей странице мастера необходимо выбрать тип ЦС. Существуют четыре типа ЦС:
   • Enterprise root СА (Корневой ЦС предприятия) – установите переключатель в это положение, если данный ЦС будет выпускать сертификаты для всех устройств, подключенных к сети в организации, и будет зарегистрирован в Active Directory. Данный ЦС является корнем в корпоративной иерархии ЦС и может устанавливаться только на контроллере домена. Обычно корневой ЦС предприятия выпускает сертификаты только для подчиненных ЦС;
   • Enterprise subordinate СА (Подчиненный ЦС предприятия) – если у вас уже установлен корневой ЦС предприятия, выберите это положение переключателя. Однако данный ЦС не имеет наивысшего доверия в организации, поскольку он подчиняется корневому ЦС. Может устанавливаться только на контроллере домена;
   • Stand-alone root CA (Изолированный корневой ЦС) – данный ЦС устанавливается для выпуска сертификатов за пределами корпоративной сети. Например, требуется установить изолированный корневой ЦС, если этот ЦС не будет участвовать в корпоративном домене и будет выпускать сертификаты для узлов во внешних сетях. Корневой ЦС обычно используется для выпуска сертификатов для подчиненных ЦС;
   • Stand-alone subordinate CA (Изолированный подчиненный ЦС) – подчиненный ЦС, который выпускает сертификаты для узлов за пределами корпоративной сети.
5. Если вы собираетесь изменить параметры шифрования по умолчанию, установите флажок Use custom setting to generate the key pair and CA certificate (Использовать специальные параметры для генерации пары ключей и сертификата ЦС).
6. Нажмите кнопку Next.
7. Укажите имя ЦС и срок действия сертификатов. Введите необходимую информацию и нажмите кнопку Next.
8. Укажите папку на локальном или общем диске для хранения сертификатов и нажмите кнопку Next.
9. По окончании процедуры инсталляции нажмите кнопку Finish (Готово).

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Windows Server. Создание автономного центра сертификации.

Windows Server. Создание автономного центра сертификации.

Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (PKI) и службы сертификации Windows.

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

Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

Для создания центра сертификации нам понадобится сервер, работающий под управлением Windows Server, который может быть как выделенным, так и совмещать роль центра сертификации с другими ролями. Однако следует помнить, что после развертывания центра сертификации вы не сможете поменять имя компьютера и его принадлежность к домену (рабочей группе).

Центр сертификации (ЦС) может быть двух типов: ЦС предприятия и изолированный (автономный) ЦС, рассмотрим их отличительные особенности:

ЦС предприятия

• Требует наличия ActiveDirectory
• Автоматическое подтверждение сертификатов
• Автоматическое развертывание сертификатов
• Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

• Не требует наличия ActiveDirectory
• Ручное подтверждение сертификатов
• Отсутствие возможности автоматического развертывания
• Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

Для возможности использования Web-интерфейса для выдачи сертификатов нам понадобится установленный web-сервер IIS. Установим его через диспетчер сервера: Пуск — Управление данным сервером — Добавить или удалить роль.
В списке ролей выбираем роль Сервера приложений. В следующем окне устанавливаем галочку Включить ASP.NET, если IIS уже установлен данный шаг можно пропустить.

После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ — Установка компонентов Windows, где выбираем Службы сертификации.

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

Далее вводим имя ЦС (должно совпадать с именем сервера) и пути размещения файлов. В процессе установки программа предложит перезапустить IIS и, если не была включена поддержка страниц ASP.NET, предложит ее включить, с чем следует согласиться.

Windows Server 2008 R2

В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера — Роли — Добавить роли, в списке ролей выбираем Службы сертификации Active Directory.

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

Дальнейшая настройка аналогична Windows Server 2003. Вводим тип ЦС, его имя и место хранения файлов, подтверждаем выбор компонент и завершаем установку.

Проверка работы ЦС

Для первоначальной проверки работоспособности ЦС можете запустить оснастку Центр сертификации (Пуск — Администрирование — Центр Сертификации). Если все сделано правильно вы должны увидеть следующее окно:
Попробуем теперь получить сертификат для клиентского ПК. Запустим браузер, в адресной строке которого укажем адрес http://имя_сервера/certsrv, где имя_сервера — имя сервера ЦС. Вы попадете на главную страницу центра сертификации.
Прежде всего необходимо загрузить сертификат ЦС и поместить его в хранилище доверенных коренных центров сертификации. Если в вашей сети несколько ЦС следует загрузить и установить цепочку сертификатов. Для этого выбираем: Загрузка сертификата ЦС, цепочки сертификатов или CRL, затем Загрузка сертификата ЦС или Загрузка сертификата ЦС и сохраняем сертификат в любое удобное место.

Теперь перейдем к установке, для этого щелкнем правой кнопкой на файле сертификата и выберем Установить сертификат, откроется мастер импорта, в котором откажемся от автоматического выбора хранилища вручную выбрав Доверенные корневые центры сертификации, теперь данный ПК будет доверять всем сертификатам выданным данным ЦС.

Для получения клиентского сертификата снова откроем сайт ЦС и выберем Запрос сертификата — расширенный запрос сертификата — Создать и выдать запрос к этому ЦС. Заполняем форму запроса, в качестве имени указываем имя ПК или пользователя, в качестве типа сертификата указываем Сертификат проверки подлинности клиента и жмем кнопку Выдать.

При попытке создать запрос сертификата вы можете получить следующее предупреждение:

В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

Теперь на сервере откроем оснастку Центр сертификации и в разделе Запросы на ожидание найдем наш запрос и щелкнув на него правой кнопкой выберем Все задачи — Выдать.

Теперь вернемся на клиентский ПК и еще раз откроем сайт ЦС. На этот раз выберем Просмотр состояния ожидаемого запроса сертификата, вы увидите свой запрос, щелкнув на которой вы попадете на страницу Сертификат выдан и сможете сразу его установить.

Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Завершающие этапы миграции с Windows Server 2003

Переносим в новую среду службы сертификатов, сценарии регистрации и многое другое

Некоторые специалисты обеспокоены тем, что разработчики Microsoft, увлеченные внедрением «облака», забудут о локальных серверах или вовсе откажутся от них. Сомневаюсь, что это так. Место для локальных серверов будет всегда. «Облако» может оказаться хорошей заменой для многих локальных рабочих нагрузок с технической и финансовой точек зрения, но из этого не следует, что все организации внезапно прекратят размещать свои рабочие нагрузки локально. Достаточно взглянуть на число компаний, предпочитающих «облаку» переход с Server 2003 на Server 2012 R2 (см. врезку «60% отстающих»), чтобы понять: «облако» — удачное решение для многих, но не идеальное для всех.

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

Если вы хотите узнать, какие обстоятельства могут помешать переходу в «облако», особенно если вы живете за пределами США, ознакомьтесь с интервью Джона Оливера, взятым у Эрика Сноудена.

Существуют рабочие нагрузки, такие как файловые службы и инфраструктурные службы, например DHCP, DNS и Active Directory, которые почти всегда требуется размещать локально. Следующая версия Windows Server, как и предшествующие, будет превосходно приспособлена для локального размещения. Даже при недавно обнаружившемся интересе Microsoft к Linux ни при каких обстоятельствах компания не передаст роли размещения локальных файловых серверов, серверов DHCP, серверов DNS на компьютеры с операционными системами Red Hat или CentOS из-за отсутствия желания выпускать Windows Server или в попытке загнать всех в «облако».

Нельзя отрицать, что в последнее время известия о Windows Server были довольно скудными, и некоторые спешат заполнить информационный вакуум собственными размышлениями (как я в этой статье). Надеюсь, что после завершения эксплуатации Server 2003 и проведения мероприятий Build и Ignite ИТ-сообщество и Microsoft начнут осмысленный диалог о будущем Windows Server.

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

Среда тестирования миграции

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

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

Итак, что создает хорошее окружение для тестирования миграции?

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

Например, вы обдумываете развертывание восьми узлов отказоустойчивого кластера Hyper-V для размещения перенесенных производственных нагрузок, где каждый узел имеет много оперативной памяти и неограниченную емкость диска. Не нужно развертывать восемь узлов отказоустойчивого кластера Hyper-V для окружения тестирования. Чтобы проверить механизм отказоустойчивости, достаточно двух узлов.

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

Миграция службы сертификатов

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

Существует четыре разновидности серверов сертификатов, работающих на Windows Server 2003.

• Корневой удостоверяющий центр предприятия. Он должен быть установлен на компьютере, присоединенном к домену. Если имеется только один удостоверяющий центр и вы регистрируете и управляете сертификатами автоматически с использованием Active Directory, то, скорее всего, это корневой удостоверяющий центр предприятия.
• Подчиненный удостоверяющий центр предприятия.Он также должен быть установлен на компьютере, присоединенном к домену. Если у вас имеется два или несколько удостоверяющих центров и вы регистрируете или обновляете сертификаты с использованием Active Directory, то, скорее всего, ваши сертификаты выдаются подчиненным удостоверяющим центром предприятия.
• Автономный корневой удостоверяющий центр. Автономный корневой удостоверяющий центр может быть установлен на компьютере, присоединенном к домену, или на компьютере, который не присоединен к нему. Компании, которые серьезно относятся к безопасности удостоверяющего центра, используют так называемый «автономный корневой удостоверяющий центр», представляющий собой отдельный корневой удостоверяющий центр, отключенный большую часть времени (потому что трудно взломать нечто, не подключенное к сети). Автономные корневые удостоверяющие центры подключаются к сети, только чтобы выдать новые сертификаты для подписи подчиненным удостоверяющим центрам. Недостаток автономного удостоверяющего центра состоит в невозможности настроить его для автоматической выдачи сертификатов на основе групповой политики.
• Автономный подчиненный удостоверяющий центр.Автономные подчиненные удостоверяющие центры могут быть установлены на компьютерах, как присоединенных, так и не присоединенных к домену. Выдача сертификатов производится вручную. Такие удостоверяющие центры часто размещаются на периметре сети.

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

Факторы, имеющие значение для миграции служб сертификации

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

Перечислим некоторые из них:

• что делать с корневым удостоверяющим центром организации;
• что делать с точками распространения CRL;
• что делать с существующими сертификатами.

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

Подобным образом возникают проблемы с миграцией точек распространения CRL. Точки распространения CRL должны быть доступны, пока действуют любые связанные с ними сертификаты. Если используются многолетние сертификаты, то точки распространения CRL должны быть доступны в течение всего срока жизни этих сертификатов. Далее мы рассмотрим, как решать каждую из этих проблем.

Миграция корневого центра сертификации

Корневой удостоверяющий центр находится на вершине цепочки центров сертификации, поэтому миграция корневого удостоверяющего центра предприятия или автономного корневого удостоверяющего центра — сложная задача.

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

Теоретически можно составить цепочку обновлений от Server 2003 до 2008, а затем до 2008 R2 и 2012 или новой версии. Но это чрезвычайно трудоемкий путь, и развертывание Windows Server 2003 выполняется, как правило, на платформе x86. Все версии, начиная с Server 2008 R2, рассчитаны на платформу x64. Невозможно выполнить обновление на месте от x86 до x64, поэтому такой путь закрыт для всех, кроме немногочисленных пользователей, развернувших Server 2003 на аппаратном обеспечении формата x64.

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

На высоком уровне для этого следует выполнить:

• резервное копирование базы данных удостоверяющего центра и закрытого ключа на корневом удостоверяющем центре 2003;
• резервное копирование параметров реестра удостоверяющего центра на корневом удостоверяющем центре 2003;
• резервное копирование CAPolicy.inf на корневом удостоверяющем центре 2003;
• удаление роли удостоверяющего центра из корневого удостоверяющего центра 2003;
• удаление корневого удостоверяющего центра 2003 из домена (при необходимости);
• построение сервера 2012 R2 с тем же именем;
• присоединение нового сервера 2012 R2 к домену (при необходимости);
• добавление роли удостоверяющего центра к серверу 2012 R2;
• восстановление базы данных и параметров удостоверяющего центра на сервере 2012 R2 (в том числе некоторых параметров реестра, при необходимости);
• настройку контейнеров AIA и CDP.

Вы можете составить более полное представление о процедуре, обратившись на сайт по адресу: technet.microsoft.com/en-us/library/ee126140%28v=ws.10%29.aspx. А я перехожу к следующему вопросу миграции с Server 2003, переносу сценариев регистрации и предпочтений групповой политики.

Сценарии регистрации и предпочтения групповой политики

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

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

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

Далее мы рассмотрим возможности предпочтений групповой политики и выясним, почему их полезно использовать вместо сценариев регистрации после перехода с Windows Server 2003.

Перечислим некоторые возможности предпочтений групповой политики, а затем разберемся с тем, как управлять этими параметрами с учетом свойств компьютера. Рекомендую первым делом взглянуть на параметры, доступные в разделе предпочтений групповой политики объекта GPO, размещенного на контроллере домена функционального уровня Windows Server 2012 R2.

С помощью предпочтений групповой политики можно выполнить следующие операции:

• установка переменных среды;
• создание, замена, обновление и удаление определенных файлов;
• создание, замена, обновление и удаление определенных папок;
• создание, замена, обновление и удаление конкретных INI-файлов;
• изменение конкретных настроек реестра;
• предпочтения групповой политики гарантируют наличие определенных общих сетевых ресурсов;
• предпочтения групповой политики гарантируют наличие определенных ярлыков;
• настройка источников данных;
• предпочтения групповой политики указывают, включены или выключены определенные устройства в зависимости от их класса;
• настройка параметров папок;
• настройка параметров Интернета;
• обеспечивается присутствие или удаление определенных локальных пользователей и групп;
• настройка сетевых параметров;
• настройка параметров электропитания;
• настройка принтеров;
• настройка региональных параметров;
• управление назначенными заданиями;
• настройка меню «Пуск».

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

Хорошо, что можно настроить все эти параметры, но особенно важна возможность точно указать группы пользователей и компьютеров, к которым применяются параметры.

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

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

• наличие батареи;
• имя компьютера;
• быстродействие центрального процессора;
• совпадение даты;
• пространство на диске;
• домен;
• переменная среды;
• совпадение файлов;
• диапазон IP-адресов;
• язык;
• запрос LDAP;
• диапазон MAC-адресов;
• запрос MSI;
• сетевое подключение;
• операционная система;
• организационная единица;
• наличие слота PCMCIA;
• портативный компьютер;
• режим обработки;
• оперативная память;
• совпадение реестров;
• группа безопасности;
• сайт;
• терминальный сеанс;
• временной диапазон;
• пользователь;
• запрос WMI.

Редактор нацеливания располагает графическим интерфейсом. Выбрав один из перечисленных выше элементов, вы переходите к настройке конкретных его свойств. Например, если выбран диапазон IP-адресов, то выводится диалоговое окно для ввода диапазона. Конечно, воспользоваться этим способом гораздо проще, чем помнить имя переменной и синтаксис для разнообразных элементов.

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

Альтернатива групповой политике

15 лет назад, когда групповые политики начали применяться, большинство компьютеров в компаниях неподвижно стояли на рабочих столах. Современные компьютеры — другие, отличаются, в частности, и способы, применяемые в компаниях для управления их настройками. Сегодня компьютеры чаще переносные, чем привязанные к рабочему месту, не все они работают с Windows, а среди располагающих этой операционной системой не все присоединены к домену. Современным ИТ-подразделениям приходится управлять параметрами самых разнообразных устройств. Эти устройства могут быть подключены к корпоративной сети или обращаться только к корпоративным ресурсам через подключение удаленного доступа. Для управления параметрами этих устройств, как правило, необходимо решение с возможностями, превышающими те, что обеспечиваются групповой политикой.

Вряд ли групповая политика будет изменена так глубоко, чтобы учесть эти проблемы. Со времени появления предпочтений групповой политики в Server 2008 изменения в групповой политике были эволюционными. Из этого не следует, что групповая политика уходит в прошлое. Полагаю, что в следующей версии Windows Server, а также в Windows 10 появятся дополнительные политики. Также можно с достаточной уверенностью предположить, что групповая политика будет применяться и в будущем.

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

Теперь я расскажу о технологиях Microsoft, которые можно задействовать для управления параметрами устройств с Windows и другими операционными системами, как подключенных к корпоративной сети, так и связанных только через средства удаленного доступа.

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

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

System Center Configuration Manager обеспечивает локальное управление настройками клиентов, а также располагает функциями для управления клиентами через Интернет. Служба Windows Intune, которая может применяться отдельно или совместно с Configuration Manager, также пригодна для управления параметрами клиентских систем на мобильных устройствах.

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

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

Среди сторонних инструментов можно выделить PolicyPak Cloud (www.policypak.com), с помощью которого можно управлять присоединенными к домену, не присоединенными к домену и удаленными компьютерами с использованием большинства средств, доступных в групповой политике (в том числе административные шаблоны, настройки, параметры безопасности и параметры приложения). В будущем я напишу о PolicyPak подробнее, а сейчас вы можете получить представление о принципах работы программы по адресу: http://www.policypak.com/products/policypak-suite-cloud-edition.html. Компании, уходящие от управления компьютерами Windows XP с использованием групповой политики, размещенной на серверах с операционной системой Windows Server 2003, найдут для себя много интересного в развивающейся вычислительной среде с динамическими рабочими местами.

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

Я согласен с тем, что одна из привлекательных сторон работы администратора сервера — возможность найти удобный для себя способ выполнения задачи. Но иногда администраторы выбирают избыточно сложные пути. Это обстоятельство привлекло к себе мое внимание после недавнего объявления о появлении в Windows Server Technical Preview варианта установки Nano Server. На момент написания статьи я не располагал полными сведениями о Nano Server и не успел воспользоваться дополнительной информацией с мероприятий BUILD и Ignite, на которых была предоставлена для испытаний новая ознакомительная техническая версия. Пока могу сообщить следующее (цитирую сообщение из журнала по адресу: http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx?WT.mc_id=Blog_ServerCloud_Announce_TTD):

«Отсутствует поддержка локальной регистрации или удаленного рабочего стола. Все управление осуществляется удаленно через WMI и PowerShell. Мы добавляем роли Windows Server и функциональные возможности с использованием компонентов Windows по требованию и системы обслуживания образов развертывания (DISM). Усовершенствованы функции удаленного управления через PowerShell благодаря службе настройки требуемого состояния, а также удаленной передачи файлов, удаленной разработки и отладки скриптов. Мы работаем над набором новых веб-инструментов управления для замены инструментов управления».

Похоже, администраторы, использующие удаленный рабочий стол для соединения с Server Core, не понимают, что лучше всего управлять Server Core удаленно (протокол RDP псевдо локален; он «переносит» вас на сервер). Одна рабочая станция управляет многими серверами — не через многочисленные сеансы удаленного рабочего стола, но с использованием сценариев, команд и консолей, таких как консоль Server Manager, подключаемая ко многим серверам. Не нужно запускать Server Manager на 100 серверах. Достаточно запустить диспетчер серверов на одном компьютере и использовать одну консоль для управления 100 серверами.

Единственная ситуация, когда локальный доступ к системе Server Core действительно необходим, — в ходе начальной установки. Благодаря новым технологиям вам не нужно (а в случае с Nano Server, похоже, и невозможно) напрямую выполнять регистрацию для настройки в процессе установки и после нее. На первый взгляд это сложно, но в действительности процесс, скорее всего, будет очень простым. Цель — добиться, чтобы потребители использовали Nano Server в ситуациях, когда это целесообразно. Но если для развертывания данной версии Windows Server потребуется такой же полет фантазии, как в произведениях современных художников, никто не захочет браться за такую задачу.

Я с нетерпением жду новых сведений о Nano Server. Очень интересно, можно ли будет довести традиционную установку до Nano Server и как можно преобразовать версию Windows Server 2012 R2 с графическим интерфейсом в Server Core (или наоборот, расширить версию, добавляя нужные компоненты по мере надобности). Но пока давайте вернемся к теме статьи и поговорим о миграции служб удаленного доступа Windows Server 2003.

Миграция удаленного доступа Server 2003

Для большинства компаний переход от Server 2003 к Server 2012 R2 мало отражается на удаленном доступе. Причина простая: большинство компаний с инфраструктурой удаленного доступа используют для удаленного доступа выделенные аппаратные средства. Сейчас удаленный доступ уже не означает коммутируемый канал связи. Это почти всегда виртуальная частная сеть (VPN). Windows Server 2003 поддерживает VPN на основе протоколов PPTP и L2 TP/IPsec, но не более новые технологии, такие как SSTP и IKEv2, или даже шлюз удаленных рабочих столов Remote Desktop Gateway.

Поэтому, обдумывая миграцию инфраструктуры удаленного доступа, в первую очередь следует задать вопрос, каким образом пользователи выполняют удаленные подключения, а затем узнать, какова роль Windows Server 2003 в этом процессе.

В большинстве случаев функция Windows Server 2003 при удаленном доступе — обеспечить проверку подлинности для аппаратного устройства, поддерживающего RADIUS. Аппаратное устройство обращается к Windows Server 2003, чтобы определить, имеет ли пользователь полномочия для работы с VPN. Если вас все устраивает, можете перейти на новый сервер с операционной системой Windows Server 2012 R2, чтобы безо всяких хлопот получить такую же услугу.

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

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

Если вы используете Windows Server 2003 в качестве сервера удаленного доступа, то можно принимать подключения от клиентов, работающих с протоколами PPTP и L2 TP/IPsec. Если заменить сервер удаленного доступа на Windows Server 2012 R2 и задействовать клиенты Windows 7, то можно устанавливать и соединения SSTP и IKEv2. Кроме того, есть варианты, которые нельзя назвать настоящей VPN, но пригодные для удаленного доступа, на основе DirectAccess и шлюза удаленных рабочих столов.

Эти варианты (некоторые из них появились достаточно давно, но могут оказаться новыми для тех, кто не следил за техническим прогрессом) обеспечивают следующие возможности:

• SSTP: VPN over HTTPS.Преиму­щество этого протокола в том, что он работает через большинство брандмауэров.
• IKEv2. Этот протокол обеспечивает автоматическое восстановление соединения VPN без повторной проверки подлинности. Его преимущество — в допустимости прерываний связи длительностью до 8 часов. При использовании VPN с протоколом IKEv2 можно переключать сетевые соединения, сохраняя соединение VPN. Например, безупречно выполняется переключение с узла доступа WiFi в зале ожидания аэропорта на сотовую сеть.
• DirectAccess.Это «постоянно действующая проверка подлинности VPN IPv6». Преимущество DirectAccess в том, что удаленный доступ обеспечивается без необходимости проверки подлинности вручную. Подключение DirectAccess устанавливается сразу же, как только компьютер распознает интернет-соединение. Если вы располагаете только соединением IPv4, то формируется туннель IPv6 через IPv4.
• Шлюз удаленных рабочих столов.Это не традиционное подключение удаленного доступа. Шлюз удаленных рабочих столов может применяться для организации соединений с рабочим столом для компьютера во внутренней сети благодаря шлюзу в сети периметра.

Несмотря на все перечисленные возможности, многие компании предпочтут использовать специализированные аппаратные устройства для организации VPN-соединений. Если на Windows Server 2003 возложена функция проверки подлинности для пограничного аппаратного устройства, совместимого с протоколом RADIUS, то следует перенести роль сервера проверки подлинности в Интернете (IAS) с компьютера Server 2003 на компьютер с ролью сервера сетевых политик (NPS) и операционной системой Windows Server 2012 R2. Специалисты Microsoft представили соответствующие технические рекомендации в статье TechNet по адресу: https://technet.microsoft.com/en-au/library/hh831652.aspx.

60% отстающих

На момент, когда оставалось меньше 100 дней до окончания срока поддержки, 60% компаний в Азиатско-Тихоокеанском регионе по-прежнему располагали по крайней мере одним экземпляром Server 2003. По результатам опроса, проведенного компанией Spiceworks в Австралии, Новой Зеландии, Индонезии, Малайзии, Филиппинах, Сингапуре и Таиланде, приблизительно 60% предприятий по-прежнему используют хотя бы один экземпляр Server 2003.

Более подробно с результатами опроса можно ознакомиться по адресу: http://news.microsoft.com/apac/2015/04/10/less-than-100?days-to-windows-server-2003?end-of-support-balancing-act-or-unprecedented-opportunity-to-modernize/. Также примечательна сравнительная информация о том, насколько далеко продвинулась каждая страна по пути миграции от Server 2003. Год назад показатель был на 5% выше. Но за 100 дней до истечения срока обслуживания цифра в 60%, несомненно, вызывает беспокойство.

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

Планирование миграции Active Directory

Существует две основных стратегии, которым вы можете следовать, перемещаясь из леса Active Directory Forest с контроллерами домена под управлением Windows Server 2003 в лес Active Directory с контроллерами домена под управлением Windows Server 2012 R2:

• выполнить обновление леса;
• выполнить миграцию леса.

Миграция леса, несомненно, требует больших усилий. Ведь в данном случае вам предстоит создать некоторые или все объекты, имеющиеся в исходном лесу, в лесу назначения. Польза от миграции Active Directory заключается в том, что вы можете (теоретически) избавиться от большого количества «мусора», который накапливается в окружении Active Directory с течением времени. Недостатком же можно считать сложность процесса, в случае, если у вас есть интегрированные со службой Active Directory приложения, такие как Exchange.

Обновление выполнить проще, к тому же вам не нужно затевать операции вроде полной очистки, как при миграции, просто потому, что достаточно обновить Active Directory, не ломая голову над тем, понадобятся ли вам обновляемые объекты (некоторые или все) в дальнейшем. Выполняя миграцию, в какой-то момент вы должны решить, следует ли перенести объект, и это решение требует времени.

На высоком уровне обновить Active Directory с Windows Server 2003 до Windows Server 2012 R2 достаточно просто. Потребуется сделать следующее:

• добавить рядовые серверы Windows Server 2012 R2;
• повысить их до контроллеров домена;
• передать роли FSMO контроллеров домена Windows Server 2003 контроллерам домена Windows Server 2012 R2;
• понизить роли контроллеров домена Windows Server 2003.