Otsi
Vajad kellegagi rääkida?
Küsi julgelt abi LasteAbi
Logi sisse ☰

Windows vene keeles (0)

Keeled - Vene keel
1 Hindamata
Punktid
Vene keel - vene keelsed luuletused
WINDOWS OUTSIDE
Версия 1.00
С пожеланиями обращайтесь по адресу 1.skruks@ gmail .com.
© skruks, 2013
Каждый имеет право воспроизводить, распространять и/или вносить изменения в настоящий Документ в соответствии с условиями GNU Free Documentation License, Версией 1.3 или любой более поздней версией, опубликованной Free Software Foundation;
данный Документ не содержит Неизменяемых разделов, не содержит Текста, помещаемого на первой странице обложки и не содежит Текста, помещаемого на последней страницы обложки.
Копия лицензионного соглашения размещена по адресу: www.gnu.org/ copyleft /fdl.html.
Неофициальный перевод данного соглашения на русский язык: ru.wikipedia.org/wiki/Википедия:Текст_лицензии_GNU_Free_Documentation_License_1.3

О книге


Красным шрифтом указана информация, которая является кандидатом на удаление в следующих версиях книги.
Сокращение WServer означает последнюю на сегодняшний день серверную версию Windows. WСlient — клиентскую. Это справедливо, т.к. 90% описания не меняется десятилетиями.

Windows Server


Окно Задачи начальной настройки всегда можно открыть, запустив в окне Выполнить команду oobe.
Для сервера доступно 3 варианта интерфейса: один с GUI
и два варианта без него. В первой версии без GUI управление осу-
ществляется с помощью командной строки, а во второй ( Features
On Demand) вместо GUI и IE в качестве инструментов управления
предлагаются Server Manager и ММС. Но главное — теперь можно
легко менять интерфейс без переустановки сервера (перезагрузка). Благодаря этому можно настроиться так, чтобы добиться оптимального соотношения между производительностью, безопасностью и удобством управления.

Конфигурирование IP

Сетевые свойства клиента


WServer включает 2 основные области конфигурирования сетевых свойств клиента:
1. Центр управления сетями и общим доступом ( Network and Sharing Center )
2. Сетевые подключения.
Если выбрать для компьютера частное сетевое размещение (Private), будут включены сетевое обнаружение и сетевая карта.
Если компьютер WClient присоединен к домену службы каталогов AD, существующей сети будет автоматически назначен тип сетевого размещения Домен ( Domain ). Доменный тип сетевого размещения аналогичен частному, за исключением того, что в домене конфигурация брандмауэра Windows, сетевого обнаружения и сетевой карты определяется групповой политикой. При выборе профиля Домена Сетевая карта по умолчанию отключается, но ее можно включить средствами групповой политики.
Сетевая карта основана на функциональности двух компонентов.
1. Компонент Link Layer Topology Discovery (LLTD) Mapper запрашивает в сети устройства для включения их в карту.
2. Компонент Отвечающее устройство LLTD (LLTD Responder) отвечает на запросы компонента LLTD Mapper.
Хотя эти компоненты включены только в WClient и WServer, компонент Responder можно установить на компьютере XP, чтобы он отображался в сетевой карте на других компьютерах.

Сетевые подключения


Окно Сетевые подключения можно открыть введя в поле Начать поиск или окно Выполнить команду ncpa.cpl или control netconnections.
Сами по себе подключения не позволяют сетевым хостам осуществлять коммуникации. Возможность осуществления коммуникаций обеспечивают сетевые клиенты, службы и протоколы, которые привязаны к подключениям. На вкладке Общие окна свойств подключения показаны компоненты - клиенты, службы и протоколы, привязанные к этому подключению.
Сетевые клиенты - компоненты программного обеспечения, например, для сетей Microsoft , позволяющих локальному компьютеру подключаться к сетям отдельных операционных систем. По умолчанию компонент Клиент для сетей Microsoft является сетевым клиентом, привязанным ко всем подключениям по локальным сетям. Он позволяет клиентским компьютерам Windows подключаться к общим ресурсам на других компьютерах Windows.
Сетевые службы. Компоненты программного обеспечения, обеспечивающие дополнительную функциональность для сетевых подключений. Но умолчанию ко всем подключениям по локальным сетям привязаны 2 сетевые службы — Служба доступа к файлам и принтерам сетей Microsoft (File And Printer Sharing For Microsoft Networks ) и Планировщик пакетов QoS. Служба доступа к файлам и принтерам сетей Microsoft позволяет локальному компьютеру назначить общий сетевой доступ к своим папкам.
Сетевые протоколы. Компьютеры могут осуществлять коммуникации через подключение только с помощью протоколов, привязанных к подключению. По умолчанию ко всем сетевым подключениям привязаны 4 сетевых протокола: IPv4 , IPv6 , Тополог канального уровня LLTD (Link-Layer Topology Discovery (LLTD) Mapper) и Ответчик LLTD (LLTD Responder).
Чтобы просмотреть дополнительные параметры подключений, откройте окно Изменение параметров адаптеров/Сетевые подключения и в меню Дополнительно выберите опцию Дополнительные параметры. В диалоговом окне Дополнительные параметры отображается порядок (приоритет) каждого подключения. Для каждого подключения можно также изменить порядок привязок используемых служб.
Вкладка Порядок служб доступа (Provider Order ) Эта вкладка диалогового окна Advanced Settings, отображает порядок, в котором подключение будет пытаться осуществлять коммуникации с другими компьютерами с использованием различных сетевых служб доступа, таких как служба Microsoft Windows Network и Службы терминалов Microsoft. Отметим, что порядок служб доступа к сети, указанный в этом диалоговом окне, применяется ко всем сетевым подключениям.
В некоторых случаях на компьютере можно комбинировать множество сетевых подключений, чтобы система Windows интерпретировала их как одну сеть (в одном широковещательном домене). Например, к одной точке беспроводного доступа (WAP) можно назначить общий доступ со множеством различных топологий подключений.
Для того чтобы создать сетевой мост, с помощью клавиши Ctrl выберите на сервере несколько сетевых подключений. Затем ПКМ и примените команду Настройка моста ( Bridge Networks).

Конфигурация адресов


IP-конфигурация подключения состоит, как минимум, из IРv4-адреса и маски подсети, или IРv6-адреса и префикса подсети. Помимо этих минимальных данных IP-конфигурация может включать такие сведения, как основной шлюз, адреса DNS-сервера, DNS-суффиксы и адреса WINS-сервера.
Статические адреса удобно использовать в такой инфраструктуре серверов, как доменные контроллеры, DNS-серверы, DHCP -серверы, WINS-серверы и маршрутизаторы.
Задание предпочитаемого DNS-сервера:
netsh interface ipv4 set dns " local area connection " static 192.168.10.1
В большинстве случаев конфигурацию IPv6 не нужно настраивать вручную, поскольку обычно статические IPv6-адреса назначаются только маршрутизаторам, а не узлам (хостам).
Укажите IРу6-адрес, длину префикса подсети (как правило, 64) и (при желании) основной шлюз. Отметим, что в случае настройки статического IPv6-адреса требуется также указать статический IPv6-адрес DNS-сервера.
Для настройки IP-конфигурации сетевого подключения можно использовать утилиту командной строки netsh.
Чтобы назначить в командной строке статический IPv4-aдpес и маску подсети
netsh interface ip set address "local area connection" static 192.168.33.5 255.255.255.0
Для того чтобы помимо конфигурации IPv4 определить основной шлюз, в конец команды можно добавить соответствующий адрес.
Существует множество приемлемых вариаций синтаксиса Netsh. Например, вместо команды netsh interface ip можно ввести команду netsh interface ipv4.
Чтобы в командной строке назначить для подключения статический IPv6-адрес, введите следующую команду, указав имя подключения и IPv6-адрес.
netsh interface ipv6 set address "Имя_подключония" Адрес
Например, чтобы назначить подключению по локальной сети адрес 001:db8:290c:1291::l (и оставить префикс подсети по умолчанию 64), введите следующую команду:
netsh interface ipv6 set address "local area connection" 2001:db8:290c:1291::1
Утилита Netsh имеет много других опций настройки IPv4 и IPv6. Более подробные сведения о синтаксисе и опциях Netsh можно найти в справке этой утилиты
netsh help

Автоматическое получение адреса для IРv4-подключения


По умолчанию всем подключениям IPv4-aдpeca назначаются автоматически. Если же DHCP-сервер недоступен, подключение само автоматически назначает себе определенную альтернативную конфигурацию. Если альтернативная конфигурация не определена, подключение автоматически назначит себе в качестве IPv4-aдpeca частный адрес AРIРA ( Automatic Private IP Addressing). Для автоматического назначения IPv4-aдpeca можно также использовать утилиту Netsh.
netsh interface ip set address "Имя_подключения" dhcp
Адреса DHCP всегда располагают более высоким приоритетом по отношению к другим методам автоматической настройки конфигурации IPv4. Хост или сеть IP может получать IP-адрес от DHCP-сервера, если в пределах широковещательного диапазона находится DHCP-сервер (или агент-ретранслятор DHCP (DHCP Relay Agent )).
Такое широковещание транслируется через все устройства уровней 1 и 2 (например, кабели, повторители, концентраторы, мосты и переключатели) и блокируется устройствами на уровне 3 (маршрутизаторы).
Альтернативную конфигурацию подключения можно определить на вкладке Альтернативная конфигурация (Alternate Configuration) диалогового окна Свойства: Протокол Интернета версии 4 (TCP/IPv4). Отметим, что в альтернативной конфигурации можно указать IP-адрес, маску подсети, основной шлюз, DNS-сервер и WINS-сервер.
Поскольку альтернативная конфигурация позволяет использовать конкретную и детальную конфигурацию IP, когда DHCP-сервер недоступен, ее имеет смысл определять на мобильных компьютерах, которые подключаются к различным сетям с DHCP-серверами и без них.
Функцию APIPA удобно использовать в некоторых временных сетях без точки доступа. Если компьютеру автоматически назначается IP-адрес, то в случае недоступности DHCP-сервера и при наличии альтернативной конфигурации компьютер использует APIPA для назначения себе частного IP-адреса в диапазоне от 169.254.0.1 до 169.254.255.254, а также маски подсети 255.255.0.0.
По умолчанию в случае недоступности DHCP-сервера всем сетевым подключениям назначаются адреса APIPA (Срабатывает вкладка Альтернативная конфигурация).
Если позже DHCP-сервер становится доступным, адрес APIPA заменяется адресом, полученным от DHCP-сервера.
Если два клиентских компьютера видят друг друга, но не могут подключаться к остальным устройствам в сети (или к Интернету), эти компьютеры используют APIPA. Хотя адрес APIPA позволяет осуществлять некоторые сетевые коммуникации, с назначением таких адресов связаны значительные ограничения.
Такие компьютеры не могут получать доступ в Интернет. Кроме того, при использовании APIPA компьютеру нельзя назначить адрес DNS-cepвepa, адрес основного шлюза и адрес WINS-сервера.
На рис. 1-26 показана конфигурация APIPA.
Если адрес APIPA назначен подключению в сети с рабочим DНCP-сервером, нужно вначале попытаться обновить конфигурацию IP или использовать функции диагностики. Для обновления конфигурации IP введите в командную строку команду ipconfig /renew.

IP 4


Маршрутизация и основные шлюзы


При необходимости отправить пакет по удаленному адресу компьютер сравнивает ID своей сети с ID конечной сети, указанной в пакете IPv4 (Для определения этих ID компьютер всегда использует свою локально отконфигурированную маску подсети). Если идентификаторы обеих сетей совпадают, сообщение определяется как локальное, после чего осуществляется его широковещание в локальной подсети.
Если же идентификаторы сетей не совпадают, компьютер отправляет пакет по адресу так называемого основного шлюза. Основной шлюз должен совместно использовать идентификатор той же сети и располагаться в том же широковещательном домене, где расположены обслуживаемые узлы. Затем маршрутизатор по адресу этого основного шлюза пересылает датаграмму IPv4 в соответствии с таблицами маршрутизации.
В роли маршрутизатора с функцией NAT может выступать компьютер WServer.

IP 6


Обе версии, IPv4 и IPv6, включены по умолчанию. IPv6 виртуально не требует конфигурирования. Он полностью поддерживается в таких ролях, как DNS, DHCP и IIS. В состав WServer даже входят такие дополнительные средства, как зона GlobalNames для обеспечения поддержки используемых с IPv6 односоставных имен ( single -label names ).
IPv6-aдpeca используют сетевые префиксы, выражаемые в представлении с косой чертой, однако лишь для описания маршрутов и диапазонов адресов, а не для указания ID сети. Например, в таблице маршрутизации IPv6 можно встретить такую запись: 2001:DB8:3FA9::/48.
Хотя IPv6 можно конфигурировать и вручную (обычно это требуется для маршрутизаторов), конфигурация IPv6 на компьютерах практически всегда назначается автоматически. Компьютеры могут получать IPv6-адреса от соседних маршрутизаторов или DHCPv6-cepвepoв. Кроме того, компьютеры всегда сами назначают себе адрес для использования исключительно в локальной подсети.
В отличие от адреса APIPA, канальный адрес LLA назначается интерфейсу как вспомогательный даже после получения маршрутизируемого адреса для этого интерфейса.
Если при отключенных службах разрешения имён в окно Выполнить введите команду \\fd00-1.ipv6-literal.net. Откроется окно \\fd00-1.ipv6-literal.net, отображающее папки компьютера. Этот синтаксис требуется использовать для подключения компьютера, указав в UNC-пути его IPv6-адрес. Отметим, что в UNC-пути IPv6 можно заменить все двоеточия в исходном IРу6-адресе дефисом и добавить к адресу суффикс .ipv6-literal.net.
Идентификатор зоны для локального IPv6-aдpeca канала назначается на основе так называемого индекса сетевого интерфейса. Список индексов интерфейсов на компьютере можно просмотреть, запустив в командной строке команду
netsh interface ipv6 show interface
Узлы IPv6, как правило, автоматически конфигурируют IPv6-адpeca, взаимодействуя с IPv6-маршрутизатором. В течение короткого промежутка времени между первым назначением адреса и проверкой его уникальности адрес называется пробным. Компьютеры используют обнаружение дубликатов адресов, чтобы идентифицировать другие компьютеры с тем же IPv6-адресом, отправляя запрос обнаружения соседей ( Neighbor Solicitation) с предварительным адресом. Если какой-либо компьютер ответил на запрос, адрес считается недействительным. Если на запрос не ответил ни один компьютер, адрес считается уникальным и действительным. Действительный адрес называется основным в течение срока действия, назначенного маршрутизатором или в автоматической конфигурации. По истечении этого жизненного цикла действительный адрес считается устаревшим. В существующих сеансах коммуникаций может использоваться устаревший адрес.
В IPv4 адрес 127.0.0.1 называется адресом обратной связи и всегда относится к локальному компьютеру. В IPv6 адресом обратной связи служит ::1. На компьютере с адресом IPv4 или IPv6 можно проверить адрес обратной связи с помощью команды ping .
Если к машине Boston подключен лишь один сетевой адаптер, должно быть назначено 3 подключения по локальной сети (программные интерфейсы): Подключение по локальной сети (Local Area Connection), соответствующее физическому сетевому адаптеру, туннельный интерфейс ISATAP и туннельный интерфейс Teredo.
fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
Эти локальные адреса узла используются для автоматического обнаружения DNS-серверов, если локальному компьютеру DNS-сервером не был назначен адрес. Чтобы ускорить автоматическое обнаружение, эти адреса можно назначить DNS-серверам в организации.
Назначение уникального локального адреса
  • IPv6-адрес: fd00::l
  • Длина префикса подсети ( Subnet Prefix Length ): 64
  • Основной шлюз: оставьте поле пустым.
  • Предпочитаемый DNS-сервер ( Preferred DNS Server): оставьте поле пустым.
  • Альтернативный DNS-сервер: оставьте поле пустым.
    В WServer по умолчанию включен туннельный интерфейс ISATAP. Обычно этот интерфейс назначается для подключения Туннельный адаптер Подключение по локальной сети* 8.
    Системы WClient и WServer содержат функции узла-ретранслятора Teredo, которая включается при назначении компьютеру глобального 1Рv6-адреса. Туннельный интерфейс Teredo включен в WServer по умолчанию. Обычно этот интерфейс назначается подключению Туннельный адаптер Подключение по локальной сети* 9 ( Tunnel Adapter Local Area Connection* 9). Звездочка означает, что это подключение по локальной сети представляет туннельный интерфейс.

    Командная строка


    Основным средством устранения неполадок служит утилита ipconfig. Отображает и модифицирует параметры конфигурации IP. Далее приведен список распространенных переключателей этой команды:
    /all — для отображения всех параметров конфигурации сети в системе;
    /renew — для запроса обновления динамического IРv4-адреса из DHCP;
    / release — для освобождения динамического IРv4-адреса;
    /release6 — для освобождения динамического IРv6-адреса;
    /flushdns —для очистки кэша разрешителя DNS в системе;
    /registerdns — для обновления динамической регистрации DNS в системе.
    Все протоколы в системе можно заменять другими протоколами. Набор протоколов TCP/IP основан на модели взаимодействия открытых систем (OSI), а не на собственной модели. 4 сетевых уровня TCP/IP часто соответствуют модели OSI.
    Инкапсуляция данных всеми 4-мя протоколами (в OSI эти уровни нумеруются как 2, 3, 4 и 7) выполняется не во всех пакетах. Например, многие пакеты обеспечивают сквозные коммуникации лишь для ниже расположенных уровней, как TCP, и соответственно включают меньше протоколов. Другие пакеты могут включать более четырех протоколов, если используют по несколько протоколов на каждом уровне. Скажем, в одном пакете на уровне 3 могут использоваться протоколы ICMP , IP и ARP.
    Чтобы указать имя компьютера с помощью командной строки, введите команду:
    netdom renamecomputer %computername% /newname:Serverl / reboot
    В Windows довольно много программ для диагностики и мониторинга сети:
    nskookup — просмотр записей DNS-сервера;
    route — вывод и изменение таблицы маршрутизации;
    netsh (routemon) — управление маршрутизатором.
    Особого внимания заслуживают команды net и netstat.
    Net — управение сетью из командной строки; С помощью неё можно произвести много различных операций. Введи команду net без параметров — в ответ получишь список команд:
    accounts — используется для обновления базы данных регистрационных записей и изменения параметров входа в сеть;
    computer — добавляет или удаляет компьютеры из базы данных домена NT;
    config — выводит информацию о службах сервера или рабочей станции; net config server – даёт информацию о количестве возможных подключений извне.
    file — используется для установки и снятия блокировки с совместно используемого файла, а также для вывода списка блокировок;
    group — выводит информацию о глобальных группах сервера, также используется для изменения глобальных групп;
    localgroup — управляет локальными группами на локальном компьютере;
    name — управляет псевдонимами этого компьютера;
    pause — приостанавливает выполнение заданной службы, продолжить работу службы можно с помощью команды net continue ;
    print — управляет очередью печати;
    send — отправляет короткое сообщение пользователям (или конкретному пользователю) сети;
    session — управляет сеансами связи этого компьютера с другими компьютерами; net session / delete — удаляет текущие подключения
    share — разрешает/запрещает использовать ресурсы этого компьютера другим компьютерам сети;
    start — запускает остановленную сетевую службу;
    stop — останавливает службу;
    statistics — выводит журнал статистики для локальной службы рабочей станции или сервера;
    time — синхронизирует время этого компьютера с временем другого компьютера сети;
    use — используется для подключения общих ресурсов другого компьютера сети;
    user — создает и изменяет учетные записи пользователя, используется только на сервере;
    view — выводит список общих ресурсов этого компьютера.
    Получить справку по конкретной команде можно так:
    net help имя_команды
    Netstat — вывод информации о сети, статистику использования сети и отображает информацию о текущих соединениях. Представим, что на твоем компьютере закрыты все приложения, которые могут обращаться к сети, а обращение к ней все равно происходит, о чем свидетельствуют индикаторы в system tray. Введи команду «netstat -o» и узнаешь, какая программа это делает (параметр '-o' используется для вывода PID процесса).

    Маршрутизация


    В реальном мире компьютеры почти никогда не используются как маршрутизаторы. Аппаратные маршрутизаторы обеспечивают более высокую производительность, стоят дешевле и гарантируют высокий уровень надежности. Поскольку маршрутизаторы выполняют лишь маршрутизацию и ничего более, они меньше подвержены ошибкам.
    На одном сетевом адаптере довольно редко назначено несколько IРv4-адресов.
    В самой простой схеме клиентские компьютеры пересылают все сообщения через отдельный маршрутизатор, называемый основным шлюзом. Каждому компьютеру, маршрутизатору и сетевому интерфейсу должен быть назначен уникальный IP-адрес.
    Компьютер посылает пакет с исходным IP-адресом 192.168.1.10 и конечным IP-адресом 192.168.2.10. Компьютер сравнивает конечный IP-адрес с ID (IP без маски) локальной подсети и определяет, что пакет требуется переслать в удаленную сеть. Поскольку доступ к удаленным сетям всегда выполняется через маршрутизаторы, компьютер пересылает пакет на основной шлюз с IP-адресом 192.168.1.1. Если шлюз не прописан, то пакет никуда не уйдёт.
    Когда конечный маршрутизатор получает пакет, он также проверяет его конечный IP-адрес 192.168.2.10 и определяет, что его сетевой интерфейс напрямую подключен к конечной сети. Маршрутизатор пересылает пакет прямо на сервер, отправляя его в локальную сеть сервера.
    Конечный IP-адрес (адрес уровня 3) пакета никогда не меняется и всегда соответствует IP-адресу конечного компьютера. Чтобы пересылать пакеты на маршрутизатор без изменения конечного IP-адреса, компьютеры используют МАС-адрес (адрес уровня 2). Однако начальный и конечный МАС-адреса переписываются в каждой сети между клиентом и сервером.
    Утилиты Ping, Tracert и Path Ping используют протокол обмена сообщениями ICMP уровня 3. По умолчанию этот протокол блокируется брандмауэром WClient и WServer, а также некоторыми маршрутизаторами и функционально независимыми брандмауэрами.

    Анализ сетевых маршрутов


    Если средства диагностики и команда ipconfig /renew не решают проблему, следует использовать такие утилиты, как Ping, Tracert, PathPing и Arр.
    С помощью команд pathping и tracert можно определить маршрут пересылки пакетов между вашим компьютером и пунктом назначения. Утилита TraceRt быстрей выводит результат, а утилита pathping выполняет более детальный и основательный анализ производительности сетей. PathPing аналогична утилите Tracert, за исключением того, что PathPing предназначена для определения потерь данных на промежуточных узлах. Утилита PathPing отправляет пакеты на каждый маршрутизатор на пути к конечной точке и вычисляет процентное соотношение пакетов, возвращаемых в каждом прыжке. Поскольку утилита PathPing показывает степень потери пакетов на каждом маршрутизаторе или узле, с ее помощью можно точно определить маршрутизаторы и узлы, на которых возникают сетевые проблемы. В нижеприведенных результатах показан маршрут к узлу www.microsoft.com, определенный утилитой PathPing:
    Трассировка маршрута к microsoft.com [157.54.1.196] с максимальным числом прыжков 30:
    0 172.16.87.35
    1 172.16.87.218
    2 192.168.52.1
    3 192.168.80.1
    4 157.54.247.14
    5 157.54.1.196
    Подсчет статистики за: 125 сек. ...
    Исходный узел Маршрутный узел/
    Прыжок RTT Утер./Отпр. % Утер./Отпр % Адрес 0
    172.16.87.35
    0/ 100 = 0% |
    1 41ms 0/ 100 = 0% 0/ 100 = 0% 172.16.87.218
    13/ 100 = 13% |
    2 22ms 16/ 100 = 16% 3/ 100 = 3% 192.168.52.1
    0/ 100 = 0% |
    3 24ms 13/ 100 = 13% 0/ 100 = 0% 192.168.80.1
    0/ 100 = 0% |
    4 21ms 14/ 100 = 14% 1/ 100 = 1% 157.54.247.14
    0/ 100 = 0% |
    5 24ms 13/ 100 = 13% 0/ 100 = 0% 157.54.1.196
    Трассировка завершена.
    Соединение между узлами 172.16.87.218 (прыжок 1) и 192.168.52.1 (прыжок 2) теряет 13 % пакетов. Остальные соединения работают нормально. Маршрутизаторы на прыжках 2 и 4 также теряют адресованные им пакеты (как показано в столбце Маршрутный узел), но данная потеря не сказывается на пути, по которому они перенаправляют данные.
    Степень потерь пакетов в соединениях между маршрутизаторами (соединения обозначает символ | в правом столбце) показывает потерю пакетов в пути. Она свидетельствует о заторе в канале связи. Степень потерь пакетов на маршрутизаторах (в правом столбце таких строк указан IP-адрес маршрутизатора) показывает, что процессоры этих маршрутизаторов перегружены. Такие маршрутизаторы могут также быть причиной неполадок связи между двумя узлами, особенно если пакеты перенаправляются программными маршрутизаторами.
    3 символа звездочки (*) отображаются в том случае, если узел не отвечает на ICMP-запросы. Серверы конфигурируют так, чтобы они не отвечали на ICMP-запросы. Такие серверы не отображаются в списке, даже если находятся в сети и отвечают на другие запросы. На машрутизаторах, которые расположены дальше от вас, значение задержки больше, поскольку пакетам требуется пройти большое расстояние через множество маршрутизаторов.
    Обратите внимание на то, что в вышеприведенных результатах вначале перечислены пять прыжков на пути к указанному конечному узлу, а затем вычисляется процентное соотношение потерь данных в каждом из этих прыжков. В этом случае утилитой PathPing будет указана потеря данных в 13 % между локальным компьютером (72.16.87.35) и первым прыжком (172.16.87.218).

    TraceRt


    TraceRt лишь отправляет по 3 пакета на каждый маршрутизатор и отображает задержку каждого из этих пакетов. Переключатель -d используется для отмены разрешения каждого IP-адреса в имя и повышения скорости тестирования. Максимальное число прыжков - 30.
    Если последние несколько строк в результате TraceRt отображают сообщение Превышен интервал ожидания для запроса (Request Timed Out). Это сообщение генерируется потому, что, в соответствии со своей конфигурацией, веб-сервер www.microsoft.com не отвечает на запросы IСMP.

    Протоколы маршрутизации


    WServer поддерживает протокол маршрутизации RIP 2. Предыдущие версии Windows поддерживали протокол маршрутизации OSPF.
  • Добавьте роль Службы политики сети и доступа со службой ролей Маршрутизация.
  • Диспетчер сервера/Роли/Службы политики сети и удаленного доступа (Routing And Remote Access Services ) и выберите элемент Маршрутизация и удаленный доступ (Routing And Remote Access). ПКМ элемент в левой панели Маршрутизация и удаленный доступ и примените команду Настроить и включить маршрутизацию и удаленный доступ. Запустится Мастер установки сервера маршрутизации и удаленного доступа (Routing And Remote Access Server Setup Wizard).
  • На странице Конфигурация выберите опцию Особая конфигурация ( Custom Configuration) и щелкните кнопку Далее.
  • На странице Настраиваемая конфигурация (Custom Configuration) установите флажок Маршрутизация локальной сети (LAN Routing).
  • На странице Завершение мастера сервера маршрутизации и удаленного доступа (Completing The Routing And Remote Access Server Wizard) щелкните кнопку Готово.
  • В открывшемся диалоговом окне Маршрутизация и удаленный доступ (Routing And Remote Access) щелкните кнопку Запустить службу (Start Service ).
    Теперь вы можете настроить протокол RIP, как описано в следующем подразделе, или используйте графические инструменты для настройки статических маршрутов, как описано в том же подразделе далее.
    При включении протокола RIP системе WServer разрешается оповещать о маршрутах соседние маршрутизаторы, а также автоматически обнаруживать соседние маршрутизаторы и удаленные сети. Чтобы включить протокол RIP, выполните следующие действия.
    1. В Диспетчере сервера разверните узел Роли, разверните Службы политики сети и удаленного доступа (Routing And Remote Access Services), затем откройте папку IPv4, ПКМ элемент Общие и примените команду Новый протокол маршрутизации (New Routing Protocol ).
    2. В диалоговом окне Новый протокол маршрутизации (New Routing Protocol) выберите протокол RIP версии 2 для IP (RIP Version 2 For Internet Protocol) и щелкните ОК.
    3. Разверните узел Роли (Roles), разверните Службы политики сети и удаленного доступа, затем откройте папку IPv4, ПКМ элемент RIP и примените команду Новый интерфейс.
    4. В диалоговом окне Новый интерфейс для RIP версии 2 для IP (New Interface For RIP Version 2 For Internet Protocol) выберите интерфейс, о котором хотите рассылать оповещения с помощью RIP. Затем щелкните ОК. Откроется диалоговое окно Свойства RIP (RIP Properties).
    5. Отконфигурируйте параметры RIP, как в соседних маршрутизаторах.
    Параметры, заданные по умолчанию, работают в большинстве сред. Параметры можно изменять с помощью четырех вкладок окна свойств RIP:
    • Общие (General) Выберите версию RIP для использования (1 или 2) и укажите требование проверки подлинности.
    • Безопасность. Опции фильтрации оповещения маршрутизатора. Поскольку протокол маршрутизации может использоваться для оповещения вредоносного компьютера о маршруте, с помощью RIP можно выполнять сетевые атаки. Поэтому следует ограничить оповещаемые маршруты.
    • Соседи (Neighbors) Позволяет вручную перечислить соседей, с которыми компьютер будет обмениваться данными.
    • Дополнительно (Advanced) Здесь можно отконфигурировать интервалы оповещений и время ожидания, а также другие редко используемые параметры.

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

    Статическая маршрутизация и утилита Route


    В большинстве сетей клиентские компьютеры конфигурируются с одним основным шлюзом, который управляет всеми входящими и исходящими сетевыми подключениями. В некоторых случаях для обеспечения избыточности сетевые администраторы могут разместить два основных шлюза в одной подсети.
    Независимо от количества используемых основных шлюзов вам не потребуется конфигурировать статическую маршрутизацию. Просто настройте основные шлюзы с использованием таких стандартных технологий сетевой конфигурации, как DHCP.
    IP-адрес маршрутизатора всегда должен располагаться в той же подсети, где размещен компьютер.
    Если для подключения к разным удаленным сетям компьютеру требуется использовать различные маршрутизаторы, потребуется отконфигурировать статическую маршрутизацию. Например, в сети, показанной на рис. 5-4, клиентский компьютер использует основной шлюз 192.168.1.1 (поскольку он обеспечивает доступ в Интернет, где размещено большинство конечных IP-адресов).
    Однако администратору требуется отконфигурировать статический маршрут для подсети 192.168.2.0/24, которая использует шлюз с адресом 192.168.1.2.
    Статические маршруты требуются в конфигурации, где к локальной сети подключено множество шлюзов и один или несколько из них не принадлежат к числу основных шлюзов.
    Эта настройка, как правило, выполняется с помощью утилиты командной строки route. В примере, показанном на рис. 5-4, доступ к сети 192.168.2.0/24 можно разрешить с помощью следующей команды:
    route -р add 192.168.2.0 MASK 255.255.255.0 192.168.1.2
    После запуска этой команды компьютер создаст маршрут трафика, предназначенного для подсети 192.168.2.0/24, через маршрутизатор 192.168.1.2. Все другие коммуникации будут осуществляться через основной шлюз.
    Коммутируемые сети и VPN (cетевые подключения по требованию) автоматически меняют конфигурацию маршрутизации клиента. В зависимости от конфигурации подключения будет или изменен основной шлюз, чтобы весь трафик пересылался через подключение по требованию, или будут установлены временные маршруты, чтобы через подключение по требованию пересылался лишь трафик, предназначенный для частной сети. В любом случае маршрутизацию не нужно конфигурировать вручную.
    Route можно использовать для анализа и настройки статической маршрутизации из командной строки. Чтобы просмотреть таблицу маршрутизации, запустите команду route print. Далее приведен пример результатов выполнения этой команды.
    Список интерфейсов
    28 ….................ContosoVPN
    7 ...00 15 с5 08 82 f3 Broadcom NetXtreme 57xx Gigabit Controller
    8 ...00 13 02 1e е6 59 .. .. Intel(R) PRO/ Wireless 3945ABG Network Connetion
    1 …......................Software Loopback Interface 1
    16 ...00 00 00 00 00 00 00 e0 isatap.hsd1.nh.comcast.net.
    13 ...00 00 00 00 00 00 00 e0 6T04 Adapter
    18 ...00 00 00 00 00 00 00 e0 Microsoft 6to4 Adapter
    9 .. .02 00 54 55 4e 01 …. Teredo Tunneling Pseudo-Interface
    30 .. .00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
    19 ...00 00 00 00 00 00 00 e0 isatap.hsd1.nh.comcast.net.
    IPv4 таблица маршрута
    Активные маршруты:
    Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
    0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.198 25
    0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.199 10
    10.0.0.0 255.0.0.0 0n-link 192.168.2.102 21
    10.255.255.255 255.255.255.255 0n-link 192.168.2.102 266
    71.121.128.170 255.255.255.255 192.168.1.1 192.168.1.199 11
    127.0.0.0 255.0.0.0 0n-link 127.0.0.1 306
    127.0.0.1 255.255.255.255 0n-link 127.0.0.1 306
    127.255.255.255 255.255.255.255 0n-link 127.0.0.1 306
    192.168.1.0 255.255.255.0 0n-link 192.168.1.198 281
    192.168.1.0 255.255.255.0 On-link 192.168.1.199 266
    192.168.1.198 255.255.255.255 On-link 192.168.1.198 281
    192.168.1.199 255.255.255.255 On-link 192.168.1.199 266
    192.168.1.255 255.255.255.255 On-link 192.168.1.198 281
    192.168.1.255 255.255.255.255 On-link 192.168.1.199 266
    192.168.2.0 255.255.255.0 192.168.1.2 192.168.1.198 26
    192.168.2.0 255.255.255.0 192.168.1.2 192.168.1.199 11
    192.168.2.0 255.255.255.0 192.168.2.100 192.168.2.102 11
    192.168.2.102 255.255.255.255 On-link 192.168.2.102 266
    224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
    224.0.0.0 240.0.0.0 On-link 192.168.1.198 281
    224.0.0.0 240.0.0.0 On-link 192.168.1.199 266
    255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
    255.255.255.255 255.255.255.255 On-link 192.168.1.198 281
    255.255.255.255 255.255.255.255 On-link 192.168.1.199 266
    255.255.255.255 255.255.255.255 On-link 192.168.2.102 266
    В таблице маршрутизации перечислены конечные сети и интерфейс или маршрутизатор, используемый для получения доступа к ним. Windows поддерживает отдельные таблицы маршрутизации для IPv4 и IPv6. Далее описан раздел IPv4.
    Маршруты с маской сети 0.0.0.0 указывают основной шлюз.
    В разделе Постоянные маршруты ( Persistent Routes) указаны все статические маршруты к удаленным сетям.
    • Маршруты с маской сети 255.255.255.255 идентифицируют интерфейс и могут игнорироваться.
    • Конечные сетевые адреса 127.0.0.0 и 127.0.0.1 указывают интерфейс замыкания на себя (loopback), который можно игнорировать.
    • Конечный адрес 224.0.0.0 служит групповым адресом. Групповая адресация используется редко.

    Например, рассмотрим следующую строку данных Route Print:
    10.0.0.0 255.0.0.0 On-link 192.168.2.102 21
    Эта строка указывает, что компьютер настроен для отправки трафика, предназначенного для сети 10.0.0.0/8, на маршрутизатор 192.168.2.102, а не на основной шлюз.
    0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.198 25
    В cтроке результатов указано, что основному шлюзу назначен адрес 192.168.1.1 (для интерфейса с IP-адресом 192.168.1.198). Адрес представляет именно основной шлюз, поскольку задана маска сети 0.0.0.0, которая соответствует всем конечным сетям, а других особых маршрутов не существует.
    Проанализировав лишь два предыдущих статических маршрута, можно определить, что подключение к IP-адресу 10.12.55.32 будет выполняться через маршрутизатор 192.168.2.102. Однако подключение к IP-адресу 172.18.39.75 будет маршрутизироваться через 192.168.1.1 — адрес основного шлюза.
    К СВЕДЕНИЮ Маршрутизаторы в локальной сети
    Маршрутизаторы всегда должны располагаться в той же подсети, где размещен компьютер. Однако маршрутизатор с IP-адресом 192.168.2.1 будет недействителен, поскольку он расположен в другой подсети, а для подключения к удаленной сети компьютеру нужно пересылать пакеты на маршрутизатор в своей сети.
    Для добавления статических маршрутов из командной строки используется команда route add. Например, если соседний маршрутизатор с IP-адресом 192.168.1.2 обеспечивает доступ к сети 10.2.2.0/24 (с маской сети 255.255.255.0), вы можете запустить следующую команду для добавления статического маршрута в сеть:
    route -р add 10.2.2.0 MASK 255.255.255.0 192.168.1.2
    В команде Route Add параметр -р используется для назначения постоянного маршрута. Если маршрут не постоянный, он будет удален при следующем запуске компьютера.
    Удаление
    route DELETE 157.0.0.0
    Если интерфейс if не задан, система попытается определить наилучший интерфейс для добавляемого маршрута.
    Модификация маршрута производится по команде:
    route change ip mask gateway metric x if y
    где ip — адрес или сеть назначения, y — порядковый номер интерфейса. Модификация маршрута может производиться только в случае смены шлюза или/и метрики интерфейса.
    Если хотите убрать адрес шлюза, то нужно ввести вместо шлюза 0.0.0.0

    Настройка статической маршрутизации с помощью оснастки Маршрутизация и удаленный доступ


    После установки роли маршрутизатора таблица route продолжает действовать и в ней нужно прописывать шлюз (наш компьютер с ролью маршрутизатора) в случае если уже прописаны другие шлюзы в этой таблице (например, основной).
    Установив службы маршрутизации и удаленного доступа (Routing And Remote Access Services), просмотрите таблицу маршрутизации IP. Для этого:
    1. Последовательно откройте узел Роли-Службы политики сети и доступа (Network Policy And Access Services), папку Маршрутизация и удаленный доступ, а затем папку IPv4.
    2. ПКМ папку Статические маршруты и примените команду Отобразить таблицу IP-маршрутизации (Show IP Routing Table). Отобразится статическая таблица маршрутизации (не включающая динамические маршруты, добавленные из RIP).
    Чтобы добавить статические маршруты в диалоговом окне Статический маршрут IPv4 (IPv4 Static Route) выберите сетевой интерфейс, который будет использоваться для пересылки трафика в удаленную сеть. В поле Назначение (Destination) введите ID конечной сети. В поле Маска подсети (Network Mask) введите значение маски конечной сети. В поле Шлюз (Gateway) введите IP-адрес маршрутизатора, который должен пересылать пакеты для этой конечной сети. Значение Метрика изменяйте только тогда, если вы располагаете множеством путей к конечной сети и хотите, чтобы компьютер использовал предпочтительный шлюз. В таком случае отконфигурируйте более предпочтительные маршруты с помощью более низких значений метрики.
    Служба маршрутизации и удаленного доступа добавит этот статический маршрут, и он отобразится в панели сведений.
    Корневые DNS-серверы будут некоторое время использовать один IP-адрес.
    Задача
    Вы конфигурируете компьютер WServer с двумя сетевыми интерфейсами. Каждый из этих интерфейсов подключен к отдельной подсети.
    Одна из этих подсетей содержит четыре маршрутизатора, причем каждый маршрутизатор обеспечивает доступ к другим подсетям. Вам требуется, чтобы компьютер WServer автоматически идентифицировал маршрутизаторы и определял доступные удаленные подсети для каждого маршрутизатора. Что следует предпринять?
    A. Включить для интерфейса преобразование адресов NAT.
    Б. Добавить статический маршрут для интерфейса.
    Ответы
    A. Неправильный Преобразование адресов NAT позволяет клиентам с частными IP-адресами подключаться к компьютерам в Интернете. Преобразование NAT не обеспечивает автоматическую настройку маршрутизации.
    Б. Неправильный Хотя для всех удаленных сетей можно использовать статические маршруты, в сценарии требуется, чтобы компьютер WServer автоматически идентифицировал удаленные сети.

    Ping


    Эта утилита до сих пор присутствует на системах. Она позволяет определить наличие компьютера в сети, для чего посылает удаленному компьютеру эхо-ICMP-запросы. Если компьютер не блокирует входящие ICMP-пакеты, то утилита подсчитывает время отклика от компьютера, а в случае отправки нескольких пакетов выдает суммарную статистику. Большинство внутренних роутеров, конечно же, не блокируют ICMP-запросы, поэтому с помощью этой команды можно определить, какой из узлов сети доступен.
    По умолчанию команда ping отсылает 4 пакета к удаленному узлу и на основе данных, полученных в результате отправки, выдает статистическую информацию. Статистика наглядно показывает, сколько пакетов было потеряно и среднее время отправки (время отклика) в процентном соотношении, а также максимальные и минимальные величины. В тех случаях, когда происходят значительные потери пакетов в локальной сети, лучше всего использовать команду ping с ключом –t. При выполнении утилиты с этим ключом пакеты будут отсылаться постоянно, пока пользователь не прекратит ее работу. Остановить работу утилиты можно, одновременно нажав распространенную комбинацию клавиш Ctrl + C. Для вывода текущей статистики без прекращения работы утилиты используется сочетание клавиш Ctrl + Break. В таком случае пакеты будут продолжать отсылаться, а пользователь получит сводную статистику по уже отправленным пакетам.
    Утилита ping также дает возможность задать количество пакетов, отправляемых удаленному узлу. Для этого необходимо выполнить команду ping с ключом –n x, где x — количество отправляемых пакетов. В свою очередь, при наличии такой возможности ключ –a позволяет определить доменное имя удаленного компьютера, если известен лишь его IP-адрес.
    В некоторых случаях к узлу доходят пакеты маленького объема, а пакет большого объема теряется. По умолчанию утилита ping отсылает пакеты с размером буфера 32 байт. Этот объем можно изменять в пределах от 0 до 65 500. Для этого служит ключ –l x, где x — количество отправляемых узлу байт.
    Также утилита ping позволяет задать параметр поля TTL (time-to- live ) каждого пакета. Для этого служит ключ –i x, где x — время жизни пакета в диапазоне от 0 до 255. Команда ping дает возможность задать время ожидания отправленного пакета. Для этого необходимо запускать утилиту с параметром –w x, где x — время ожидания, которое задается в миллисекундах и может иметь практически неограниченную величину.
    Теперь перейдем к самому главному. Утилита ping выдает не только статистику по количеству отправленных/полученных пакетов, но и приблизительный маршрут каждого из пакетов. Для этого при запуске утилиты нужно задать ключ –r x, где x — количество прыжков для пакета. Это значение для данной команды лежит в пределах от 0 до 10. После выполнения этой команды статистика будет содержать информацию по прыжкам для каждого отправленного пакета. Утилита также может показать штамп времени для каждого прыжка. Для активации этой функции необходимо запускать утилиту с параметром –s x, где x может принимать значения от 1 до 4.
    Большинство функций отображения маршрута в утилите ping зависят от полученного ответа: если ответ от запрашиваемого компьютера не получен, пользователь не увидит никакой информации.
    ping6 — версия ping для протокола IPv6.

    Аrр


    Протокол ARP позволяет компьютеру физически осуществлять коммуникации с соседним компьютером или маршрутизатором, представленным IРv4-адресом. Утилита Аrр выполняет соответствующую функцию. Ее можно использовать для отображения ARP-кэша компьютера, в котором хранится топология преобразования IРv4-адресов в МАС-адреса других компьютеров в локальной сети, и для управления этим кэшем.
    Поскольку подключение к компьютеру в пределах широковещательного диапазона зависит от точного сопоставления IРv4-адресов в МАС-адреса этого компьютера в локальном кэше ARP, с помощью утилиты Аrр можно исправлять сетевые проблемы при неточном сопоставлении адресов.
    Например, отобразив кэш с помощью команды аrр -а, можно устранить проблему, связанную с тем, что соседние виртуальные машины назначили себе один и тот же виртуальный МАС-адрес (довольно распространенная ситуация).
    С помощью команды аrр /-d можно удалить запись в ARP-кэше компьютера или виртуальной машины с недействительным MAC-адресом.
    В редких случаях с помощью утилиты Аrр можно определить попытки локального хакера связать в ARP-кэше некоторые или все локальные IPv4-адреса (особенно IРv4-адрес локального маршрутизатора) с МАС-адресом самого хакера. Эта технология позволяет хакеру тайно выполнять маршрутизацию сетевых подключений через свой компьютер.
    Для разрешения преобразований IP и MAC в версии IPv6 используется протокол ND (Neighbor Discovery), а не протокол АRР. Потому у всех сетей IPv6 есть преимущество - невозможность инфицирования ARP-кеша.

    Настройка имен

    Стенд


    Два компьютера WServer с именами Dcsrvl и Boston. Компьютеру Dcsrvl должен быть назначен IPv4-aдpеc 192.168.0.1/24, а машине Boston - IPv4-адрес 192.168.0.2/24. На обоих компьютерах нужно включить общий доступ к файлам.

    Разрешение имен в сетях


    Сети WServer включают не меньше 3 систем разрешения имен: DNS, LLMNR и NetBIOS.
    Самой важной является DNS, поскольку этот метод разрешения имен используется для поддержки служб доменов AD и разрешения всех имен Интернета. Система DNS играет роль поставщика именования принципалов и разрешения имен в сетях Windows. Таким образом, DNS — наиболее предпочтительный метод разрешения имен в Windows, который по возможности используется во всех ситуациях. Инфраструктуры DNS нет в небольших и неофициальных сетях. Поэтому, к примеру, DNS нельзя использовать для разрешения имен компьютеров в рабочей группе, на которых система WServer установлена с параметрами по умолчанию. В таких рабочих группах используются другие службы разрешения имен — LLMNR и NetBIOS.
    Система Windows всегда будет вначале пытаться разрешить имя с помощью DNS, а в случае недоступности DNS попытается использовать LLMNR, а затем NetBIOS.

    LLMNR


    Метод разрешения имен Link Local Multicast Name Resolution (LLMNR) применяется только в системах WClient и WServer.
    LLMNR использует многоадресное вещание для разрешения IPv6-адресов компьютеров лишь в локальной подсети. Протокол LLMNR является более предпочтительным методом разрешения имен, чем NetBIOS. Если вы захотите подключиться к компьютеру ClientB, указав UNC-путь ( Universal Naming Convention ) в виде \\ClientB в сети без DNS, ваш компьютер для разрешения имени ClientB сначала использует LLMNR.
    Компьютер ClientA использует для разрешения этого имени метод LLMNR, проверив сначала в кэше LLMNR локального компьютера ранее разрешенные имена. Если соответствующая запись не найдена, ClientA через IPv6 отправит LLMNR-запрос имени (Name Query Request) на широковещательный адрес FF02::1:3. Все IPv6-yзлы в сети с включенным сетевым обнаружением прослушивают трафик, пересылаемый на этот широковещательный адрес. Если ClientB с включенным сетевым обнаружением расположен в той же подсети, компьютер отреагирует на запрос и перешлет на компьютер ClientA свой IPv6-адрес. После этого ClientA сможет установить соединение с машиной ClientB.
    Протокол LLMNR также отправляет запросы разрешения имен в IPv4 (в частности, по адресу 224.0.0.252), однако во время написания этой книги клиенты WServer и WClient по умолчанию не отвечали на эти запросы. Однако в сетях IPv4 Сетевое обнаружение позволяет компьютерам отображаться в окне Сеть. В окне Сеть может отобразится только 1 компьютер из двух. После обновления экрана отобразятся оба компьютера. Если при отключенных IPv6 и NetBIOS в окне Сеть дважды щелкните значок компа, вы получите сообщение о том, что Windows не может получить доступ к \\DCSRV1. Двойной щелчок значка компьютера в окне Сеть функционально эквивалентен попытке подключения с указанием имени компьютера в UNC-пути.
    Для разрешения имен компьютеров в локальной подсети не требуется конфигурация. LLMNR является единственным протоколом разрешения имен, который работает без конфигурации в IPv6-сетях Windows. По сравнению с NetBIOS метод LLMNR компактней и, следовательно, имеет меньший фронт атаки.
    Недостаток LLMNR заключается в том, что этот протокол нельзя использовать для разрешения имен компьютеров за пределами локальной подсети.
    Протокол LLMNR можно отключить сразу для большого числа компьютеров с помощью групповой политики. В объекте групповой политики откройте папку Конфигурация компьютера\Адмииистративиые шаблоны\Сеть\DNS-клиент и найдите параметр политики Отключить многоадресное разрешение имен ( Turn Off Multicast Name Resolution).

    NetBIOS


    Устаревший протокол и система именования NetBIOS, или NetBIOS через TCP/IP, (NetBT или NBT). Поскольку в NetBIOS каждый компьютер располагает лишь одной меткой идентификации крупномасштабными сетями сложно управлять. Эти имена включают 16 символов и не поддерживают такие знаки, как точки. Можно использовать только первые 15 знаков имени из одной метки, поскольку шестнадцатый символ зарезервирован системой для заполнения имени. По традиции управление этими именами осуществляет служба WINS. Служба WINS не отображается в Диспетчере сервера - нужно использовать консоль WINS в программной группе Администрирование.
    По умолчанию протокол NetBIOS включен для каждого подключения по локальной сети IPv4. Дело в том, что некоторые сетевые приложения по-прежнему используют имена NetBIOS. Многим сетевым администраторам система NetBIOS требовалась еще и потому, что до выхода WClient лишь она обеспечивала возможность простого обзора сетей. Многие пользователи годами подключаются к сетевым ресурсам с помощью опции Сетевое окружение (Network Neighborhood и My Network Places ) и не хотят менять свои привычки. Без NetBIOS эти действия выполнять нельзя. В сетях WServer компонент NetBIOS не используется для отображения компьютеров в окне Сеть. NetBIOS в определенных ситуациях можно отключить.
    Протокол NetBIOS по умолчанию обеспечивает разрешение имен в IPv4-сетях Windows без DNS. Например, в домашней беспроводной сети можно подключаться к другим компьютерам, указывая их имена UNC (\\Comp3), не включая Сетевое обнаружение (Network Discovery), даже если на машине Соmр3 установлена операционная система Windows XP. Протокол NetBIOS также позволяет проверить имя Соmр3 с помощью команды ping и получить ответ с IPv4-адреса этого компьютера.
    Ping Adm
    Обмен пакетами с Adm ...
    В данном случае понятно, что для разрешения имени система Windows использует NetBIOS, поскольку в имя компьютера не включен домен DNS (например, mydomain.com) и ответ на запрос пришел с IPv4-адреса. Ответ с IP-6-адреса означает использование LLMNR.
    Если отконфигурирован DNS-сервер на клиенте, то эти же компьютеры, отконфигурированиые как WINS-клиенты, не могут отображать подсеть рабочей группы в окне Мое сетевое окружение. Для этого компьютеры WClient нужно отконфигурировать с использованием адреса WINS-сервера.
    Конфигурировать и управлять NetBIOS легче, чем DNS. Компонент NetBIOS отсутствует в структуре IPv6.
    Если вы используете множество WINS-серверов в большой организации, на них нужно отконфигурировать репликацию, чтобы базы данных WINS все время обновлялись. В большинстве случаев на всех WINS-серверах настраивается репликация приема/передачи ( push / pull ) (особенно при звездообразной конфигурации), чтобы серверы могли эффективно обновлять друг друга.
    Система NetBIOS разглашает информацию о сетевых службах, которая может быть использована для взлома сети.
    Еще один недостаток NetBIOS — слишком высокая прозрачность в корпоративных сетях. Широковещательный трафик NetBIOS довольно заметен и недостаточно защищен.

    Методы разрешения имен NetBIOS


    Протокол NetBIOS включает 3 метода разрешения имен: широковещание, WINS и файл Lmhosts.
    1. Широковещание NetBIOS. Для подключений по локальной сети в Windows протокол NetBIOS включен по умолчанию. Таким образом, компьютер, которому требуется разрешить имя, выполняет широковещательный запрос IР-4-адреса собственника имени в локальной сети.
    2. WINS-сервер. По сути, WINS-сервер представляет каталог таких имен компьютеров, как ServerB, и связанные с ними IP-адреса. При настройке сетевого подключения с адресом WINS-сервера выполняются два действия. Во-первых, вы разрешаете компьютеру выполнять поиск компьютерных имен, которые нельзя разрешить с помощью DNS или LLMNR. Во-вторых, вы регистрируете имя локального компьютера в каталоге WINS-сервера. Главное преимущество WINS состоит в том, что WINS-сервер включает разрешение имен NetBIOS за пределами локальной подсети.
    3. Файл Lmhosts. Статический файл локальной базы данных, который хранится в папке %SystemRoot%\System32\ Drivers \Etc и сопоставляет конкретные имена NetBIOS адресам IP. Позволяет компьютеру разрешать IP-адрес для данного имени NetBIOS в случае сбоя другого метода разрешения имен. Файл Lmhosts требуется создать вручную. Поэтому он обычно используется с целью разрешения имен удаленных клиентов, для которых недоступны другие методы разрешения имен — например, когда в сети нет WINS-сервера.

    Включение и отключение NetBIOS и типы узлов


    Чтобы изменить параметры NetBIOS, откройте свойства подключения по локальной сети - Свойства протокола Интернета версии 4 (TCP/IPv4) и щелкните кнопку Дополнительно - вкладка Служба WINS. Служба WINS поддерживает лишь 1Рv4-адреса.
    Подключение по локальной сети по умолчанию разрешает WINS-серверу назначать параметры NetBIOS. Параметры NetBIOS, полученные с DHCP-cepвера, не просто включают или отключают NetBIOS: DHCP-сервер может конфигурировать клиента в качестве конкретного типа узла NetBIOS.
    Механизм, посредством которого имена NetBIOS разрешаются в IP-адреса, зависит от типа узла NetBIOS, отконфигурированного для компьютера.
    Существует 4 типа узлов.
    1. Широковещательный (b-узел). Этот тип узла использует широковещательные запросы имен NetBIOS для регистрации и разрешения имен. Принцип работы этого типа узлов больше других похож на LLMNR.
    2. Узел точка-точка (р-узел). Этот тип узла использует коммуникации точка- точка и WINS-сервер для разрешения имен. Р-узел не применяет широковещание, а напрямую запрашивает сервер имен.
    3. Комбинированный (m-узел) Данный тип узла вначале использует широковещание (b-узел), а затем, если имя не было разрешено с помощью широковещания, применяет запросы WINS-сервера (р-узел).
    4. Смешанный (h-узел) Этот тип узла вначале использует запросы WINS (р-узел), а затем — широковещание (b-узел), если сервер имен недоступен или имя не зарегистрировано в базе данных WINS. Однако до внедрения широковещания b-узла эти компьютеры также используют файл Lmhosts для поиска сопоставлений имени в IP-адрес.
    По умолчанию клиенты Windows конфигурируются h-узлом. Текущее состояние узла, назначенного компьютеру Windows, можно определить в результатах команды ipconfig /all.

    PNRP


    Благодаря полной поддержке IPv6 в WServer и WClient также включена дополнительная система разрешения имен PNRP (Peer Name Resolution Protocol). В отличие от системы DNS, которая использует иерархическую структуру именования, протокол разрешения одноранговых имен PNRP для разрешения имен системы задействует одноранговых участников сети. По сути, PNRP является ссылочной системой, которая выполняет замыкания на основе известных данных. Например, когда вы пытаетесь найти компьютер А, располагаясь по соседству с компьютерами Б и В, ваша система запросит у компьютера Б местоположение компьютера А. Если компьютер Б указывает местоположение, вы получаете ссылку на компьютер А. В противном случае ваша система запросит у компьютера В местоположение компьютера А, а затем использует точной такой же процесс, как и в случае с компьютером Б. Если компьютерам Б и В не известно местоположение компьютера А, ваша система будет посылать запрос другим компьютерам по соседству, пока не найдет систему, которой известно местоположение компьютера А.
    В PNRP включено несколько возможностей, которые отличаются от службы DNS.
    1. Для локализации объектов эта распределенная система именования не использует центральный сервер. Она практически не зависит от сервера, однако в некоторых ситуациях серверы необходимы для разработки процесса разрешения имен. В WServer компоненты PNRP-сервера включены в качестве надстройки.
    2. Систему PNRP можно расширить до миллиардов имен — в отличие от системы DNS, которая управляет лишь небольшим числом имен.
    3. Поскольку система PNRP является распределенной и полагается на таких клиентов, как серверы, она отказоустойчива. Одним именем могут управлять несколько компьютеров, обеспечивая множество путей к этому имени.
    4. Публикация имен выполняется мгновенно, бесплатно и не требует административного вмешательства, как в случае с DNS.
    5. Имена обновляются в реальном времени — в отличие от DNS, где для повышения производительности интенсивно используется кэширование. По этой причине PNRP не возвращает старые адреса, как в случае с DNS-сервером,
    в частности старым нединамическим DNS-сервером.
    6. Система PNRP также поддерживает именование служб и компьютеров,
    поскольку PNRP-имя содержит адрес, порт и потенциальную полезную нагрузку, такую, например, как функция службы.
    7. Имена PNRP можно защищать с помощью цифровых подписей. Защита имен таким способом гарантирует, что их нельзя подделать или заменить фальшивыми именами.
    Для разрешения имен PNRP использует концепцию облака. Существуют два отдельных облака. Первым является глобальное облако, содержащее всю глобальную область адресов IPv6, которая полностью охватывает Интернет.
    Второе — локальное облако канала, которое основано на области локальных 1Рv6-адресов последнего. Локальные каналы обычно представляют отдельные подсети. Допускается существование нескольких локальных облаков каналов и только одного глобального облака.
    Поскольку мировое сообщество еще не перешло к IPv6, переход к PNRP также пока не осуществлен и для разрешения имен используются системы DNS.
    Иерархии AD DS не поддерживаются в PNRP. Поэтому рекомендуется продолжать использование DNS.
    Система PNRP может содержать миллионы записей имен, а система DNS намного скромнее и использует для именования иерархию серверов.

    DNS


    DNS-сервер WServer полностью соответствует стандартам RFC, генерируемым специальной комиссией интернет-разработок IETF (Internet Engineering Task Force ) (www.ietf.org), а также содержит набор компонентов, предназначенных для поддержки функций сетевой операционной системы NOS (Network Operating System) в AD DS. В WServer реализация DNS была разработана в соответствии с ключевыми положениями документации RFC, в которой содержится описание основных требований к функционированию DNS. Это делает ее применение особенно выгодным в существующих сетевых реализациях, поскольку позволяет WServer взаимодействовать с другими типами DNS, которые тоже соответствуют тем же самым требованиям, описанным в документах RFC.
    DNS-сервер представляет собой компьютер с программой DNS-сервера (например, служба DNS-сервера в системе WServer или BIND в UNIX ). DNS-серверы содержат информацию базы данных DNS о некоторой части древовидной структуры доменов DNS и разрешают запросы разрешения имен, поступающие от DNS-клиентов. DNS-серверы могут обеспечивать указатель на еще один сервер, который может помочь разрешить запрос, либо сообщают, что информация недоступна или не существует.
    Сервер, использующий локально управляемую базу данных, является главным сервером домена, отвечающим на запросы об узлах в этом домене.
    Серверы могут быть главными на одном или нескольких уровнях иерархии доменов. В частности, корневые DNS-серверы в Интернете являются главными лишь для доменных имен верхнего уровня, например .com. В результате главные серверы доменов .com имеют приоритет лишь для имен в домене .com, например lucernepublishing.com.
    Смежные домены, например .соm, lucernepublishing.com и example.lucernepublishing.com, могут стать отдельными зонами в случае делегирования, посредством которого ответственность за субдомен в именном пространстве DNS назначается отдельной сущности. При управлении пространствами имен DNS в AD DS нужно делегировать зоны новых создаваемых доменов, поскольку в противном случае управление зоной будет осуществляться на уровне леса, а не на уровне домена. В WServer мастер установки доменных служб AD автоматически выполняет делегирование при создании дочернего домена.
    Делегированная зона — это дочерняя зона, управление которой осуществляется на собственном DNS-сервере. В случае делегирования родительская зона содержит запись NS для сервера, управляющего этой дочерней зоной. Таким образом, при получении запросов имен в дочерней зоне родительская перенаправляет их на сервер, указанный в записи NS. Делегирование можно выполнять только из родительской зоны в дочернюю.
    Файлы зон содержат данные зон, для которых сервер является главным. Во многих типах реализации DNS-серверов данные зон хранятся в текстовых файлах, однако DNS-серверы на контроллерах доменов AD могут также хранить информацию зон в AD.
    Распознаватель DNS - служба, использующая протокол DNS для запроса информации DNS-серверов. Распознаватели DNS осуществляют коммуникации с удаленными DNS-серверами или программой DNS-сервера на локальном компьютере. В WServer роль распознавателя DNS выполняет служба DNS-клиент. Помимо функций распознавателя DNS служба DNS-клиент обеспечивает дополнительные возможности кэширования сопоставлений DNS.
    Для мониторинга DNS-серверов используются 2 опции:
    1. Регистрация событий DNS-сервера в журнале событий DNS-сервер.
    2. Ведение журнала отладки DNS-сервера с записью в текстовый файл. Эта опция включается в диалоговом окне свойств DNS-сервера. По умолчанию она отключена; ее следует использовать только в сценариях отладки.
    Утилита Nslookup - выполняет тестирование запросов пространства имен DNS. Nslookup также является командным интерпретатором, вход в который выполняется с помощью команды nslookup (чтобы вернуться к командной строке, введите exit ). Однако указанную утилиту можно использовать и напрямую. Для этого введите команду nslookup с именем узла или IP-адресом компьютера.
    Dnslint - выполняет диагностику распространенных неполадок, связанных с разрешением имен. Далее приведен список переключателей команды:
    /d — для запроса тестов разрешения доменных имен;
    /ql — для проверки тестов запросов DNS из списка;
    /ad — для проверки записей, связанных с AD.
    Имена компьютеров нельзя вводить динамически.
    Иерархическая структура DNS позволяет поддерживать сети любых размеров, а поскольку DNS использует двухточечные коммуникации, физическая топология не играет особой роли.
    В WServer служба DNS улучшена с точки зрения поддержки фоновой загрузки зон. Когда DNS-сервер управляет значительным количеством зон и записей AD DS, для его запуска может потребоваться больше времени, поскольку перед обслуживанием запросов ему необходимо загрузить данные всех зон. Используя фоновую загрузку, служба DNS может быстрее отвечать на запросы, продолжая загрузку данных в фоновом режиме после запуска компьютера и входа в систему.
    Безопасность приёма DNS-ответов обеспечивается DNSSEC, который поддерживается только начиная с W7 и Wserver 2008 R2.
    Кроме того, поскольку технология DNS предназначена для управления именованием в Интернете, она включена в WServer и позволяет выйти за пределы своей сети. Cистема DNS интегрирована вместе с AD DS, однако ее также можно запускать независимо в периметре сети и за ее пределами. При этом система DNS позволяет другим организациям и отдельным лицам локализовать вас в любой точке земного шара, в результате чего они смогут взаимодействовать с вами или приложениями.
    Алгоритм Round - Robin - DNS-службы можно использовать для обеспечения высокой степени готовности. С этой целью для одного ресурса создается множество записей, в каждой из которых указан отдельный IP-адрес. При получении запроса DNS-сервер предоставит первый адрес, затем второй, третий и т.д., обеспечивая баланс нагрузки среди множества серверов, управляющих одной и той же службой.
    Например, серверы Edge Transport Server в Microsoft Exchange Server 2007, которые подключены к Интернету, а также принимают и пересылают внутреннюю электронную почту, используют алгоритм Round-Robin для балансировки нагрузки электронной почты.

    Этапы выполнения запроса DNS


    DNS-клиент:
    При наличии локально отконфигурированного файла WINDOWS\System32\Drivers\Etc\Hosts все сопоставления имен узлов в адреса загружаются из файла в кэш при запуске службы DNS-клиент и при каждом обновлении файла Hosts. В WServer записи динамически добавляются в кэш распознавателя, создавая файл Hosts. Записи ресурсов, полученные в ответах на предыдущие запросы DNS, добавляются в кэш и хранятся там некоторое время. При остановке службы DNS-клиент кэш очищается.
    Если служба DNS-клиент не может разрешить запрос с помощью локально кэшированной информации, клиент отправляет лишь один запрос на DNS-сервер. Каждое сообщение запроса, отправляемое клиентом, содержит следующие сведения.
  • Имя домена DNS, указанное в формате FQDN (Служба DNS-клиент добавляет необходимые суффиксы для генерирования имени FQDN, если оно не было указано исходной клиентской программой).
  • Указанный тип запроса, например запрос записи ресурса по типу или специализированный тип операции запроса.
  • Указанный класс доменного имени DNS (Для службы DNS-клиент всегда указывается класс Internet [IN]).
    Когда клиент выполняет запрос DNS, он вначале пересылает этот запрос по адресу предпочтительного DNS-сервера. Если предпочтительный DNS-сервер недоступен, DNS-клиент обращается к альтернативному DNS-серверу, если таковой указан. Если предпочтительный сервер доступен, но не может разрешить запрос, то клиент НЕ обращается к альтернативному DNS-серверу.
    DNS-сервер проверяет возможность приоритетного ответа на запрос на основе информации, содержащейся в локально сконфигурированной зоне на сервере. Иначе сервер проверяет возможность разрешения имени с помощью локально кэшированной информации предыдущих запросов.
    Как правило, клиент выполняет итерацию только в том случае, когда DNS-сервер не отконфигурирован для приёма рекурсии от клиента. Клиент сам выполняет итеративные запросы в соответствии с корневыми ссылками на DNS-сервере. Используются корневые ссылки с целью локализации серверов, уполномоченных для корневых имен в Интернете, таких, например, как .com, .org, .net и т. д.
    Для правильного выполнения рекурсии клиента DNS-серверу вначале требуется определить точку начала поиска имен в доменном пространстве DNS. Эта информация обеспечивается в виде корневых ссылок - предварительного списка ресурсов, используемого службой DNS с целью локализации главных серверов корня дерева пространства доменных имен DNS.
    По умолчанию DNS-серверы в WServer используют предварительно отконфигурированный файл корневых ссылок Cache .dns из папки WINDOWS\System32\Dns. Содержимое этого файла загружается в память сервера при запуске службы и включает указатели на корневые серверы пространства имен DNS. На рис. 2-8 показан файл корневых ссылок по умолчанию.
    В WServer файл корневых ссылок уже содержит адреса корневых серверов в пространстве имен DNS Интернета. Поэтому в случае использования службы DNS-сервер в WServer для разрешения DNS-имен Интернета файл корневых ссылок не нужно конфигурировать вручную. Более того, на компьютере, который управляет корневым DNS-сервером (с именем «.»), вообще не нужно использовать корневые ссылки. В этом сценарии WServer автоматически удаляет файл корневых ссылок Cache.dns.
    Каждые несколько лет список корневых серверов в Интернете модифицируется. Поскольку файл Cache.dns уже содержит множество возможных корневых серверов, в модификации файла корневых ссылок сразу после таких изменений нет необходимости. Если же вы хотите проанализировать доступность новых корневых серверов, обновите соответствующим образом корневые ссылки. На время написания этой книги последнее обновление списка корневых серверов было сделано 1 ноября 2007 года. Последнюю версию именованного файла кэша можно загрузить с InterNIC по адресу ftp://rs.internic.net/domain/ named .cache. Эти корневые подсказки регулярно обновляются в центре обновления Windows (Microsoft Windows Update ).
    В крупной организации этот список корневых ссылок можно заменить корневыми серверами в частном пространстве имен. В такой ситуации DNS-серверы в корпоративной сети больше не будут разрешать имена Интернета, однако пользователи смогут подключаться к Интернету с помощью прокси-серверов.
    На рис. 2-9 клиенту в Интернете требуется разрешить имя example.lucernepublishing.com в IP-адрес. Предполагается, что кэши DNS-клиента и всех DNS-серверов пусты.
    Ниже описан процесс обработки запроса службой DNS-клиент на клиентском компьютере.
    1. Клиент связывается с сервером NameServerl и запрашивает example.lucernepublishing.com.
    2. Сервер NameServerl обращается к главному серверу Интернета (т. е. корневому серверу) и запрашивает example.lucernepublishing.com.
    3. Корневой сервер Интернета не знает ответ и запрашивает направление на главный сервер домена .соm.
    4. Сервер NameServer1 обращается к главному серверу домена .com и запрашивает имя example.lucernepublishing.com.
    5. Главный сервер домена .com не знает точный ответ и направляет запрос на главный сервер домена lucernepublishing.com.
  • Сервер NameServer1 обращается к главному серверу домена lucernepublishing.com и запрашивает имя example.lucernepublishing.com.

    DNS-сервер


    При установке роли DNS-сервера отдельно от AD его придется отконфигурировать вручную, чтобы добавить и настроить одну или несколько зон прямого просмотра. Чтобы добавить зону прямого просмотра, в дереве консоли диспетчер DNS (DNS Manager) ПКМ папку Зоны прямого просмотра ( Forward Lookup Zones ) и примените команду Создать новую зону.
    Чтобы установить DNS-сервер на автономном сервере или члене домена с ядром сервера WServer, введите такую команду:
    start /w ocsetup DNS-Server- Core - Role
    Чтобы удалить роль, введите такую команду;
    start /w ocsetup DNS-Server-Core-Role /uninstall
    После установки DNS на компьютере с ядром WServer с использованием команды Dcpromo или Start /w ocsetup настройку и управление DNS-сервером можно выполнять, подключившись к нему через диспетчер DNS на другом компьютере. Чтобы в диспетчере DNS подключиться к еще одному серверу, ПКМ корень (имя сервера) в дереве консоли диспетчера DNS и примените команду Подключение к DNS-серверу.
    В окне свойств DNS-сервера можно конфигурировать параметры DNS-сервера и управляемых им зон. Чтобы открыть это диалоговое окно, в диспетчере DNS ПКМ значок DNS-сервера, который требуется отконфигурировать, и примените команду Свойства.
    Вкладка Интерфейсы позволяет указать IP-адреса локального компьютера, на которых сервер должен прослушивать запросы DNS. По-умолчанию — все.
    Вкладка Корневые ссылки ( Root Hints) содержит копию данных файла WINDOWS\System32\Dns\Cache.dns.
    Процедура развертывания DNS довольно проста, особенно при развертывании на контроллере домена. Однако служба DNS включает много компонентов. Для управления и устранения неполадок нужно знать принципы настройки зон DNS.
    Диспетчер DNS - основной инструмент управления DNS-серверами, однако администратор должен знать и другие инструменты DNS. Из всех доступных альтернативных средств самым мощным является инструмент командной строки dnscmd. Управляет всеми аспектами DNS-серверов. Набрав в командной строке команду dnscmd, вы увидите около 40 команд утилиты Dnscmd, в том числе команду dnscmd /enumdirectorypartitions, отображающую разделы каталога приложений на локальном сервере, а также команду dnscmd /info, которая отображает основные сведения конфигурации DNS-серверов.
    /config — для модификации параметров конфигурации сервера;
    /statistics — для получения данных статистики оперирования на сервере;
    /startscavenging — для инициирования очистки;
    /directotypartitioninfo — для получения сведении о разделах;
    /exportsettings — для создания резервного файла параметров сервера

    Настройка кэширования DNS-сервера


    Очистка кэша DNS-сервера выполняется каждый раз при остановке службы DNS-сервера. Очистку кэша DNS-сервера можно выполнить и вручную в консоли DNS, щелкнув правой кнопкой мыши значок сервера в дереве консоли и применив команду Очистить кэш или через dnscmd /clearcache.
    Обновив адрес клиентского компьютера, вы заметили, что локальный DNS-сервер некорректно разрешает имя компьютера из кэшированной информации. Как быстрей всего решить эту проблему?
    A. На DNS-сервере в командную строку ввести dnscmd /clearcache. Эта команда выполняет очистку кэша DNS-сервера. Если вы знаете, что DNS-сервер отвечает на запросы с использованием устаревших данных кэша, лучше всего очистить кэш сервера. Тогда при получении следующего запроса имени DNS-сервер попытается разрешить это имя, опрашивая другие компьютеры.
    Значения TTL. Время жизни датаграммы в секундах применяется ко всем кэшированным записям ресурсов в кэше клиента DNS и DNS-сервера. По умолчанию назначается значение 1 ч, однако этот параметр можно изменять на уровнях зоны и записи.
    Серверы кэширования не управляют зонами и не являются приоритетными для отдельных доменов. Например, если сеть содержит филиал с каналом медленной глобальной сети WAN ( Wide Area Network) между сайтами, сервер кэширования может ускорить запросы разрешения имен. Кроме того, сервер кэширования не выполняет трансфер зон, который требует немало сетевых ресурсов в средах WAN. Сервер кэширования DNS можно использовать на сайте, где требуется локальное функционирование DNS и нежелательно администрирование доменов или зон.
    По умолчанию служба DNS-сервер выполняет роль сервера кэширования. Для того чтобы установить сервер кэширования DNS, выполните следующие действия:
    1. Установите на компьютере роль DNS-сервер и не создавайте зоны.
  • Проверьте конфигурацию или корректность обновления корневых ссылок сервера.

    Динамические обновления на сервере


    DNS-служба в WServer может обеспечить много ролей. Доступны 3 типа DNS-серверов.
    1. Динамические DNS-серверы. Предназначены для регистрации имен множества различных устройств с помощью динамических обновлений, которые выполняются динамическими DNS-серверами (DDNS). Серверы DDNS позволяют устройствам (клиентам и серверам) самостоятельно регистрироваться на DNS-сервере.
    Когда DNS-служба запускается на контроллере домена и интегрируется со службой каталогов, она переключается в режим DDNS, позволяя компьютерам, использующим DHCP, автоматически регистрировать свои имена. На независимом же DNS-сервере режим нединамичен.
    Таким образом службы AD DS могут локализовать клиента для пересылки данных управления, например объектов групповой политики GPO. DDNS обеспечивают запись и чтение, однако принимают регистрацию только от известных сущностей.
    С настроенным динамическим обновлением DNS-серверы WServer могут принимать динамическую регистрацию и обновления записей. Саму регистрацию и обновления нужно выполнять с помощью DNS-клиента или DHCP-сервера (от лица DNS-клиента). Включение регистрации задаётся в "Свойствах" подключения через адаптер, в дополнительных настройках, на закладке DNS.
    Для успешного динамического обновления зона, в которой клиенты регистрируют или обновляют записи, должна быть отконфигурирована для приема динамических обновлений. Существует два типа такого обновления.
    а) Безопасное обновление. Позволяет выполнять регистрацию только с компьютеров домена AD и обновление лишь с того компьютера, который изначально выполнял регистрацию. Вы должны интегрировать зону в AD. В AD можно интегрировать только те зоны, которые создаются на контроллерах домена. Выбрать опцию сохранения зоны в AD.
    б) Небезопасные обновления. Позволяет выполнять обновление с любого компьютера.
    Для указания динамического обновления DNS-клиента вручную можно использовать команду ipconfig /registerdns.
    Такие смарт-устройства, как компьютеры с Windows 2000, ХР, 2003, WClient и WServer, могут регистрировать свои имена в DDNS, однако устройства с более ранними выпусками операционной системы, например Windows NT, не могут это делать. Старые устройства будут использовать DHCP для регистрации, однако такая реализация инфраструктуры DDNS менее безопасна.
  • DNS-серверы с правом чтения и записи. Предыдущие версии DNS-серверов, которые не работают в динамическом режиме, однако принимают записи от известных источников, например авторизованных операторов. Самым распространенным типом DNS-серверов с правом чтения и записи является основной (или предпочитаемый) DNS-сервер. Основные DNS-серверы обычно развертываются в периметре сети и не интегрируются с AD DS.
    На нединамических DNS-серверах записи зон обновляются вручную. В соответствии с документацией RFC, определяющей стандарты протокола DNS в Интернете, WServer может поддерживать старые DNS-серверы, а также динамическую DNS-службу для AD DS. Ранние DNS-серверы содержат основные или дополнительные зоны.
  • DNS-серверы только для чтения. Содержат копию данных DNS только для чтения. В WServer существует два типа DNS-серверов только для чтения. Первым является дополнительный (или альтернативный) DNS-сервер. Дополнительные DNS-серверы обеспечивают локальный доступ к данным, которые не могут модифицироваться, поскольку эти серверы поддерживают лишь одностороннюю репликацию от родительского сервера. Вторым типом является DNS-сервер только для чтения на контроллерах домена только для чтения RODC в WServer. Эти серверы, интегрированные вместе с RODC, запускают основные зоны лишь с правом чтения.
    С помощью этих трех типов DNS-серверов можно сконструировать стратегию разрешения имен, соответствующую всем требованиям именования (рис. 9-3).
    Например, вы можете установить в сети пару DNS-серверов вместе с каждым контроллером домена, так как данные DNS обычно интегрируются с хранилищем каталогов. Поскольку эти данные помещаются в хранилище каталогов, данные DNS реплицируются на каждый контроллер домена, а иногда и в лесу с помощью того же механизма, который реплицирует трафик каталогов. Это означает, что каждый контроллер домена содержит локальную копию данных DNS. Установленная DNS-служба на контроллере домена автоматически получает доступ к его данным и может обеспечить локальные, а не удаленные службы разрешения имен без нагрузки трафика глобальной сети WAN. Кроме того, DNS-службу контроллера RODC в режиме только для чтения можно использовать в незащищенных местах сети, где необходимы локальные службы и нет административного персонала. Независимую основную службу DNS также можно использовать в периметре сети. Эти серверы содержат несколько записей, однако поддерживают доступ к любому приложению или службе в периметре сети. И наконец, дополнительные DNS-серверы лишь с правом чтения можно использовать в небезопасных размещениях с подключением к Интернету.

    Пересылка


    Вкладка Пересылка (Forwarders) свойств сервера позволяет конфигурировать локальный DNS-сервер для пересылки запросов DNS на другие DNS-cepверы, которые называются серверами пересылки. С помощью этой вкладки можно указать IP-адреса вышестоящих DNS-серверов, на которые будут пересылаться запросы, если локальный DNS-сервер не может найти ответ в своем кэше или данных зоны. При ошибке подключения по пересылке DNS-сервер будет запрашивать свои корневые серверы.
    Например, если организация подключена к Интернету через медленное соединение, производительность разрешения имен можно оптимизировать, туннелируя все запросы DNS через один сервер пересылки. В этом случае кэш сервера пересылки DNS получает все возможности роста, что уменьшит количество внешних запросов.
    Еще одна причина пересылки состоит в том, чтобы позволить клиентам и серверам DNS в периметре брандмауэра безопасно разрешать внешние имена. Для того чтобы внутренний DNS-сервер или клиент мог связываться с внешними DNS-серверами, выполняя итеративные запросы, на уровне брандмауэра должны быть открыты порты, используемые для коммуникаций со всеми внешними серверами. Настроив DNS-сервер в периметре брандмауэра для пересылки внешних запросов на один DNS-сервер пересылки за пределами брандмауэра и открыв порты только для этого сервера пересылки, вы сможете разрешать имена, не отображая свою сеть для внешних серверов. Такая схема изображена на рис. 2-21.
    В структуре леса AD с множеством доменов делегирование DNS позволяет клиентским запросам в родительских доменах разрешать имена ресурсов дочерних доменов. Однако отсутствует встроенный механизм, который позволил бы клиентам в дочерних доменах разрешать запросы имен в родительских доменах. Для включения этой функции DNS-серверы дочерних доменов в структуре леса конфигурируют для пересылки неразрешенных запросов на DNS-сервер или серверы корневого домена леса (рис. 2-22).
    Условная пересылка - конфигурация DNS-сервера, где запросы конкретных доменов перенаправляются на конкретные DNS-серверы при соответствующих условиях.
    Например, ваша сеть охватывает два леса. Первым является производственный лес, который содержит учетные записи всех пользователей организации. Второй лес, особый, был создан для тестирования интеграции сторонних приложений со схемой леса AD DS перед развертыванием в производственном лесу. Поскольку схема леса меняется, вы не можете связать леса с помощью доверительной связи лесов. Поэтому вы создаете в каждом лесу условные пересылки, чтобы пользователи в производственном домене, по большей части являющиеся разработчиками и профессионалами IT, могли связываться с лабораторным доменом.
    Ещё один из сценариев условной пересылки состоит в объединении двух отдельных сетей. Предположим, компании Contoso и Fabrikam имеют отдельные сети с доменами AD. После объединения компаний для подключения к частным сетям используется арендованный канал 128 кбит/с. Чтобы клиенты в каждой компании могли разрешать друг другу запросы имен в сетях, на DNS-серверах обоих доменов настраивается условная пересылка. Запросы разрешения имен в домене компании-партнера будут пересылаться на DNS-сервер в этом домене. Все запросы Интернета пересылаются на вышестоящий DNS-сервер за пределами брандмауэра (рис. 2-23). Для достижения того же результата вы также можете отконфигурировать дополнительные зоны и зоны-заглушки. Однако условная пересылка сводит к минимуму трафик трансфера зон и обеспечивает постоянное обновление данных. Кроме того, ее легко конфигурировать и поддерживать.
    Чтобы настроить условную пересылку для домена, нужно использовать контейнер Серверы условной пересылки ( Conditional Forwarding) в дереве консоли диспетчера DNS. Затем в открывшемся диалоговом окне Создать сервер условной пересылки (New Conditional Forwarder) укажите имя домена, для которого должны пересылаться запросы DNS, а также адрес связанного DNS-сервера.
    Например, компания имеет штаб-квартиру в Нью-Йорке и филиал в Сакраменто. Эти офисы управляют доменами AD с именами, соответственно, ny.lucernepublishing.com и sac.lucernepublishing.com. Нужно, чтобы пользователи в каждом офисе могли разрешать имена и просматривать внутреннюю сеть в другом офисе. Кроме того требуется, чтобы пользователи в каждой сети могли выполнять разрешение имен в Интернете. Как отконфигурировать DNS-серверы в каждом офисе? Использовать условную пересылку и настроить родительские DNS-серверы в Нью-Йорке для пересылки запросов домена sac.lucernepublishing.com на DNS-серверы в Сакраменто. И наоборот - в Сакраменто.

    Клиентские параметры DNS


    Обычно в браузерах для FQDN замыкающая точка отбрасывается, однако служба DNS-клиент добавляет ее в запросах.
    В типичной сети настройка DNS-клиентов осуществляется через параметры, унаследованные из DHCP или членства в домене AD. Для компьютеров со статической конфигурацией IP, а также машин, не входящих в окружение AD, параметры DNS-клиента нужно задавать вручную.
    Автоматическое получение клиентом адреса DNS-сервера можно настроить в диалоговом окне Свойства: Протокол версии 4 (TCP/IPv4). Этот параметр назначается по умолчанию. Чтобы сконфигурировать более длинный список приоритетных DNS-серверов, щелкните кнопку Дополнительно (Advanced) и перейдите на вкладку DNS.

    Имя компьютера и DNS-суффиксы


    При установке WServer на компьютере имя компьютера генерируется автоматически, если оно не указано в файле ответов. После установки это имя можно изменить с помощью команды sysdm.cpl. В DNS это имя компьютера называется именем узла. Имя узла компьютера можно определить с помощью команды hostname.
    Но клиент также может использовать возможности служб разрешения имен DNS, если ему назначить не только имя узла, но и основной DNS-суффикс. Имя узла с DNS-суффиксом составляет так называемое полное имя компьютера. Компьютер ClientA с основным DNS-суффиксом contoso.com получает полное имя ClientA.contoso.com. Обычно основной DNS-суффикс соответствует имени основной зоны с правом чтения/записи, управляемой локально назначенным предпочтительным DNS-сервером.
    Клиент может задействовать все возможности служб разрешения имен DNS, если отконфигурировать для него основной DNS-суффикс.
    Основной DNS-суффикс выполняет две функции. Он позволяет клиенту автоматически регистрировать собственные записи узла в зоне DNS, имена которой соответствуют имени основного DNS-суффикса. Кроме того, DNS-клиент автоматически добавляет основной DNS-суффикс в запросы DNS. Команда ping server1 на компьютере с DNS-суффиксом nwtraders.msft преобразуется в команду ping SERVER1.nwtraders.msft.
    В процессе присоединения компьютера к домену AD имя домена автоматически конфигурируется вместе с основным DNS-суффиксом компьютера.
    Чтобы настроить основной DNS-суффикс вне домена AD, на вкладке Имя компьютера диалогового окна Свойства системы щелкните кнопку Изменить и в открывшемся диалоговом окне Изменение имени компьютера или домена щелкните кнопку Дополнительно. Откроется диалоговое окно DNS-суффикс и NetBIOS-имя компьютера.
    Помимо основного DNS-суффикса компьютеру можно назначить суффикс подключения; делается это с DHCP-сервера или вручную. Отличие от обычного суффикса в том, что этот тип суффикса связан лишь с отдельным сетевым подключением.
    Суффикс подключения удобно использовать на компьютере с двумя сетевыми адаптерами для распознавания по имени двух маршрутов к этому компьютеру. На рис. 2-31 компьютер Узел А подключен к двум подсетям через два отдельных адаптера. Первый адаптер с адресом 10.1.1.11 подключен к подсети 1 через медленное (10 Мбит/с) подключение Ethernet , которому назначен DNS-суффикс public.example.microsoft.com. Второй адаптер с адресом 10.2.2.22 подключен к подсети 2 через подключение Fast Ethernet (100 Мбит/с). Этому быстрому подключению назначен DNS-суффикс backup.example.microsoft.com. При этом основной суффикс - example.microsoft.com.

    Настройка поискового списка суффиксов


    По умолчанию служба DNS-клиент сначала прикрепляет к неквалифицированному имени локального компьютера основной DNS-суффикс. Если этот запрос не разрешает имя, служба DNS-клиент добавляет все суффиксы подключения, назначенные этому сетевому адаптеру. Если эти запросы также не разрешают имя, служба DNS-клиент добавляет лишь родительский суффикс от основного DNS-суффикса.
    Предположим, что полное имя многосетевого компьютера — computerl.domainl.microsoft.com. Сетевым адаптерам на компьютере Computerl назначены суффиксы подключения subnetl.domainl.microsoft.com и subnet2.domainl.microsoft.com. Если на этом компьютере ввести в текстовое поле Адрес Internet Explorer имя computer2 и нажать клавишу Enter, локальная служба DNS-клиент попытается разрешить имя Computer2, запросив имя computer2.domainl.microsoft.com. Если этот запрос не разрешит имя, служба DNS-клиент запросит имена computer2.subnetl.domainl.microsoft.com и computer2.subnet2.domainl.microsoft.com. Если и этот запрос не разрешит имя, служба DNS-клиент запросит имя computer2.microsoft.com.
    Для DNS-клиентов можно отконфигурировать поисковый список доменных DNS-суффиксов, чтобы расширить или изменить их поисковые способности DNS. В случае ошибки запроса DNS служба DNS-клиент может использовать этот список для прикрепления других суффиксов к исходному имени и многократной отправки запросов на DNS-сервер с целью поиска альтернативных имен FQDN.
    DNS-суффиксы поискового списка служба DNS-клиент добавляет в указанном порядке в первую очередь, не пытаясь использовать другие доменные имена.
    Соответствующий параметр объекта групповой политики Порядок просмотра DNS-суффиксов (DNS Suffix Search List) находится в папке Конфигурация компыотера\Административные шаблоны\Сеть\DNS-клиент.

    Обновление записей узлов


    Динамическое обновление отдельных клиентов выполняется только в том случае, если они отконфигурированы с помощью основного DNS-суффикса (вручную или через членство в домене AD) или суффикса подключения, соответствующего имени зоны, управляемой предпочтительным DNS-сервером. Например, для динамического обновления компьютера Clientl в зоне lucernepublishing.com именем FQDN этого компьютера должно быть client1.lucernepublishing.com, и клиент должен указать в качестве предпочтительного DNS-сервера IP-адрес DNS-сервера, управляющего основной зоной lucernepublishing.com.
    На рис. 2-33 показана вкладка диалогового окна Дополнительные параметры TCP/IP с параметрами регистрации DNS по умолчанию для DNS-клиента.
    Клиент с включенным параметром Зарегистрировать адреса этого подключения в DNS пытается регистрировать обе записи — А и АААА — с помощью предпочтительного DNS-сервера. DNS-клиенты никогда не пытаются регистрировать IРv4-адреса APIPA или локальные IРv6-адреса каналов с помощью DNS-сервера.
    Компьютер с включенным параметром Использовать DNS-суффикс подключения при регистрации в DNS пытается регистрировать записи А и АААА для всех DNS-суффиксов, назначенных сетевому подключению. Кроме того, если клиенту уже назначен основной DNS-суффикс, соответствующий DNS-суффиксу подключения, то при включении этого параметра дополнительные записи узлов не будут регистрироваться.
    Если в рабочей группе вы развернули DHCP-сервер, чтобы назначить компьютерам группы IP-адрес, основной шлюз, DNS-сервер и имя домена contoso.com и в качестве предпочтительного DNS-сервера клиентам назначается DNS-сервер, управляющий основной зоной домена contoso.com, то ни один из клиентов исследовательской рабочей группы не сможет успешно зарегистрировать записи DNS с помощью DNS-сервера. Необходимо применить параметр Использовать DNS-суффикс подключения при регистрации в DNS.
    Чтобы выполнять регистрацию всех записей узлов в DNS, в командную строку введите с привилегиями администратора команду ipconfig /registerdns.
    Обновление записей указателей Для клиентов со статическими адресами обновление записей PTR выполняется так же, как и обновление записей узлов (А и АААА). Можно зарегистрировать на DNS-сервере PTR-записи клиента со статическим адресом, запустив в командной строке с административными привилегиями на компьютере клиента команду ipconfig /registerdns. Для успешной регистрации требуется выполнение определенных условий. Во-первых, DNS-клиенту нужно назначить соответствующий основной DNS-суффикс. Во-вторых, предпочтительный DNS-сервер клиента должен управлять соответственно настроенными зонами прямого и обратного поиска.
    По умолчанию DNS-клиенты со статическими IP-адресами обновляют на сервере записи узлов (А или АААА) и указателей (PTR), a DNS-клиенты, являющиеся DHCP-клиентами, — лишь записи узлов. В среде рабочей группы DHCP-сервер обновляет записи указателя от лица DHCP-клиента при каждом обновлении конфигурации IP. Обновление PTR-записей DHCP-клиентов в рабочей группе отличается от обновления в среде AD. Далее описано обновление PTR-записей DHCP-клиентов в этих двух средах.
    В среде рабочей группы DHCP-клиенты имеют собственные PTR-записи, обновляемые DHCP-сервером. Обновление можно выполнять с помощью команды Ipconfig /renew. Для успешной регистрации требуется соблюдение определенных условий. Во-первых, DNS-клиенту и DNS-cepвepy нужно назначить этот DNS-сервер как предпочтительный. Во-вторых, на компьютере DNS-клиента нужно включить параметр Зарегистрировать адреса этого подключения в DNS. В-третьих, DNS-клиенту должен быть назначен соответствующий DNS-суффикс (вручную в качестве основного DNS-суффикса или автоматически с DHCP-сервера).
    В среде AD клиенты DHCP обновляют свои PTR-записи. Для запуска обновления можно использовать команды ipconfig /registerdns или ipconfig /renew. Для успешного обновления нужно включить параметр Использовать DNS-суффикс подключения при регистрации в DNS. Чтобы включить этот параметр, нужно вначале включить параметр Зарегистрировать адреса этого подключения в DNS.
    Чтобы компьютеры в сети регистрировали имена DNS подключений, можно использовать групповую политику. В объекте групповой политики откройте папку Конфигурация компыотера\Адмииистративные шаблоны\Сеть\DNS-клиент и включите параметр политики Регистрировать DNS-записи с DNS-суффиксом подключения ( Register DNS Records With Connection- specific DNS Suffix).
    По умолчанию клиент с доменным именем, назначенным DHCP-сервером не регистрирует свой адрес в DNS.
    Чтобы DNS-клиент выполнял динамическую регистрацию своих записей ресурсов, в командную строку введите команду ipconfig /registerdns.

    Кэш DNS-клиента


    Кэш DNS-клиента (или кэш распознавателя DNS) поддерживается всеми DNS-клиентами. DNS-клиенты проверяют свой кэш распознавателя перед запросом DNS-сервера. При получении DNS-клиентом ответа на запрос от DNS-сервера в кэш распознавателя добавляются новые записи.
    Для просмотра кэша DNS-клиента в командную строку введите команду ipconfig /displaydns. Будут показаны все записи, загруженные из локального Hosts, а также все недавно полученные записи запросов имен, выполненных системой.
    Для очистки кэша DNS-клиента в командную строку можно ввести команду ipconfig /flushdns. В качестве альтернативы можно перезагрузить службу DNS-клиент. Например, если клиент Windows внес в кэш отказ DNS-сервера на запрос, клиент может получать этот отказ даже в том случае, если в настоящее время DNS-сервер разрешил запрос. Чтобы устранить такую проблему, очистите кэш DNS-клиента.
    После очистки введите команду ipconfig /displaydns. Обратите внимание на то, что кэш не будет полностью пустым. По умолчанию он содержит четыре записи: PTR-запись для адреса ::1, PTR-запись 127.0.0.1, запись А, сопоставляющая имя локального узла с IP-адресом 127.0.0.1, и запись AAAA, сопоставляющая имя локального узла с 1Ру6-адресом ::1.
    С компа Boston введите команду ping dcsrvl. В командную строку введите команду ipconfig /displaydns. Под заголовком dcsrvl.nwtraders.msft в кэше появятся две новые записи: запись А и запись АААА.

    Зоны


    Зона - часть пространства имен DNS, за управление которой отвечает определенный сервер или группа серверов DNS. Она является в DNS основным механизмом для делегирования полномочий и применяется для установки границ, в пределах которых определенному серверу разрешено выполнять запросы. Любой сервер, который обслуживает какую-то определенную зону, считается полномочным; исключением являются разве что зоны-заглушки. Зона может состоять из нескольких домёнов разного уровня иерархии, связанных родительскими отношениями. Любой раздел или подраздел DNS может существовать внутри единой зоны. Например, организация может поместить все пространство имен домена, поддоменов и подподдоменов в единую зону или же разделить какие-то разделы этого пространства имен на отдельные зоны. На самом деле даже целое пространство имен Интернета может представляться в виде единого пространства имен с корнем .
    и множеством отдельных зон.
    Зона - база данных, содержащая полномочную информацию об области единственного пространства имен DNS. Единое требование для всех зон состоит в том, что данные должны быть согласованы в общем именном пространстве зон, для чего следует отконфигурировать репликацию зон или передачу зон.
    Если DNS-сервер был отдельно установлен на контроллере домена, сервере-члене домена или автономном сервере, зоны следует создавать и конфигурировать вручную. Создав на контроллере домена основную зону или зону-заглушку, вы сможете хранить данные зоны в AD.
    Зона содержит записи, которые связывают имена с адресами в описываемой области пространства имен DNS. Хотя для ответов на запросы имен DNS-сервер может использовать кэшированную информацию с других серверов, он уполномочен отвечать на запросы лишь в локально управляемой зоне. Для любой области пространства имен DNS, представленной именем домена, существует только 1 полномочный источник данных зоны.
    Служба DNS в WServer поддерживает 3 типа зон. Для запуска мастера ПКМ значок сервера в дереве консоли диспетчера DNS и примените команду Создать новую зону.

    Тип зоны


    Основная зона ( Primary zone) - Самый распространенный тип зон DNS. Локальный DNS-сервер, управляющий основной зоной, служит первичным источником данных об этой зоне. Сервер хранит главную копию данных зоны в локальном файле или в доменных службах AD. Если зона сохраняется в файле, этот файл но умолчанию получает имя имя_зоны.dns и хранится в папке %systemroot%\System32\Dns на сервере.
    Основные зоны - зоны, которые содержат информацию с правом чтения и записи (кроме RODC) для отдельного домена. Основные зоны хранятся на нединамических и динамических DNS-серверах. Те из них, которые хранятся на нединамических DNS-серверах, содержатся в текстовых файлах, вручную редактируемых администратором. Основные зоны на DDNS-серверах содержатся в AD и автоматически обновляются каждым хранителем записей или вручную администратором.
    Зоны, интегрированные в AD, в отличие от стандартных зон обеспечивают многоуровневую репликацию данных, упрощенную конфигурацию, а также повышенную безопасность и эффективность.
    Дополнительные зоны (Secondary zones) обеспечивают полномочную копию с правом только для чтения основной зоны или еще одной дополнительной зоны. Это - стандартный устаревший тип зон. Предоставляют возможность снизить объем трафика запросов DNS. Кроме того, в случае недоступности сервера, который управляет основной зоной, дополнительная зона может обеспечивать разрешение имен до тех пор, пока основной сервер снова не станет доступным.
    Исходные зоны, из которых дополнительные зоны получают информацию, называются мастер-зонами, а процедуры копирования данных, обеспечивающие регулярное обновление информации зоны, называются передачами зон. Поскольку дополнительная зона — это копия основной зоны, управляемая еще одним сервером, ее нельзя хранить в AD. Дополнительные DNS-серверы подчинены одному или нескольким основным серверам.

    Хранение зон в AD


    При создании основной зоны или зоны-заглушки на контроллере домена, на странице Тип зоны мастера можно выбрать опцию сохранения зоны в AD. Данные зон, интегрированных в AD, автоматически реплицируются в AD в соответствии с параметрами, выбранными на странице Область репликации зоны, интегрированной в AD (AD Zone Replication Scope ).
    Интеграция зоны DNS в AD дает несколько преимуществ. Во-первых, поскольку службы AD выполняют репликацию зон, нет необходимости в настройке отдельного механизма передачи зон DNS между основным и дополнительными серверами. Во-вторых, службы AD позволяют выполнять обновление и репликацию отдельных свойств записей ресурсов на DNS-серверах. Поскольку не передается множество полных записей ресурсов, снижается нагрузка на сетевые ресурсы во время передачи зон. Наконец, зоны, интегрированные в AD, обеспечивают также опциональные возможности внедрения требований безопасности динамических обновлений, настройка которых осуществляется на странице Динамическое обновление мастера создания зоны.
    На традиционных контроллерах доменов копии зоны предоставляется право чтения/записи. На контроллерах доменов с доступом лишь для чтения (Readonly Domain Controller, RODC) копии зоны назначается лишь право чтения.
    При создании зоны на контроллере домена опция сохранения зоны в AD на странице Тип зоны выбирается по умолчанию. Однако этот флажок можно снять и создать так называемую стандартную зону. На сервере, не являющемся контроллером домена, можно создавать лишь стандартные зоны, а флажок на этой странице неактивен.
    В отличие от зоны, интегрированной в AD, стандартная зона сохраняет свои данные в текстовом файле на локальном DNS-сервере. Кроме того, в случае использования стандартных зон можно конфигурировать только основную копию с правом чтения и записи данных зоны.
    Модель стандартной зоны подразумевает одну точку сбоя перезаписываемой версии зоны. В случае недоступности основной зоны в сети никакие изменения в зону внести нельзя. Однако запросы имен в зоне могут не прерываться, пока доступны дополнительные зоны.

    Создание зон прямого и обратного просмотра


    На странице Зона прямого или обратного просмотра (Forward or Reverse Lookup Zone) мастера создания новой зоны необходимо выбрать тип создаваемой зоны; зона прямого просмотра или зона обратного просмотра.
    В зонах прямого просмотра DNS-серверы сопоставляют полные доменные имена FQDN с IP-адресами. Отметим, что зоны прямого просмотра получают имя в соответствии с доменными именами DNS, для которых выполняется разрешение, например pmeeswate.com. В зоне прямого просмотра отдельная запись базы данных, сопоставляющая имя узла с адресом, называется запиисью узел(А).
    В зонах обратного просмотра DNS-серверы сопоставляют IP-адреса именам FQDN в отдельном домене. Зоны обратного просмотра именуются в обратном порядке первых трех октетов адресного пространства, для которого обеспечивается разрешение имен, плюс, дополнительный тег in-addr. arpa . Например, при разрешении имен для подсети 192.168.1.0/24 зона обратного просмотра получит имя 1.168.192.in-addr.arpa. В зоне обратного просмотра отдельная запись базы данных, называется указателем или РТR-записью.
    Принцип работы зон прямого и обратного просмотра продемонстрирован на рис. 3-5 и 3-6.
    Для одновременного создания зон прямого и обратного просмотра можно использовать мастер настройки DNS-сервера (Configure A DNS Server Wizard). Чтобы запустить мастер, в дереве консоли диспетчера DNS ПКМ значок сервера и примените команду Настроить DNS-сервер.
    Небольшим сетям, скажем до 500 компьютеров, могут и не требоваться зоны обратного просмотра RLZ (Reverse Lookup Zone). Такие зоны чаще всего используются приложениями. Например, защищенное веб-приложение применяет обратный просмотр, чтобы подтвердить подлинность подключившегося компьютера. Если в вашей сети нет таких приложений, зоны обратного просмотра вам не понадобятся.
    Однако клиенты, которые могут динамически обновлять свои записи DNS, также создают запись указателя PTR и пытается сохранить его в зоне обратного просмотра (RLZ), соответствующей зоне прямого просмотра (FLZ), где локализована запись. Если зоны обратного просмотра не существуют, эти записи никогда не генерируются.

    Выбор имени зоны


    Если зона создается для разрешения имен в домене AD, лучше всего указать имя зоны, соответствующее имени домена AD. Например, если организация содержит два домена AD, с именами proseware.com и east .proseware.com, инфраструктура разрешения имен должна включать две зоны с именами, соответствующими именам этих доменов.
    В случае создания зоны для пространства имен DNS не в среде AD, нужно указать имя Интернет-домена организации, например fabrikam.com.
    Чтобы добавить DNS-сервер на существующий контроллер домена, обычно добавляется копия основной зоны, обеспечивающая разрешение имен в локальном домене AD. Для этого нужно просто создать зону, имя которой соответствует имени существующей зоны в локальном домене AD. Новая зона будет заполнена данными с других DNS-серверов в домене.

    Зона GlobalNames и WINS


    На вкладке WINS окна свойств зоны можно указать WINS-сервер, к которому будет обращаться служба DNS-сервер для просмотра имен, не найденных с помощью запросов DNS. При указании WINS-сервера для зоны прямого просмотра в эту зону добавляется особая запись WINS, ссылающаяся на этот WINS-сервер. При указании WINS-сервера для зоны обратного просмотра в зону добавляется особая запись WINS-R, определяющая этот WINS-сервер.
    Например, если DNS-клиент запрашивает имя ClientZ.contoso.com и предпочитаемый DNS-сервер не может найти ответ в обычных источниках (кэше, данных локальной зоны и с помощью опроса других серверов), сервер запрашивает имя CLIENTZ. на WINS-сервере, указанном в записи WINS.
    Помните, что зоны GNZ позволяют заменить реализацию WINS только при управлении небольшим количеством имен из одной метки. Однако если организации нужно использовать много имен из одной метки, вместе с DNS следует реализовать службу WINS.
    По традиции именами NetBIOS управляет служба WINS. В DNS системы WServer вместо WINS можно использовать зону GNZ ( Global -Names Zone). Чтобы исключить эту старую службу из сети Windows, корпорация Microsoft реализовала зону GlobalNames, которая может содержать имена из одной метки. Например Mail, для подключения к ресурсам сервера почты. Этот компонент удобно использовать, если список просмотра DNS-суффиксов по умолчанию для DNS-клиентов не позволяет пользователям быстро подключаться (или подключаться вообще) к ресурсу с помощью такого имени из одной метки. По умолчанию зона GlobalNames не существует.
    На рис. 3-22 показана зона GlobalNames с записью для сервера с именем, состоящим из одной метки Почта.
    Зона GlobalNames совместима лишь с DNS-серверами WServer. Потому она не может реплицироваться на серверы с предыдущими версиями Windows Server.
    Развертывание зоны GlobalNames:
    1. Включение поддержки зоны GlobalNames. Этот шаг можно выполнить до или после создания зоны, однако его нужно повторить на каждом DNS-cepвере, куда будет реплицироваться зона GlobalNames. В командную строку с административными иривилегиями введите следующую команду:
    dnscmd . /config /enableglobalnamessupport 1
    Вы получите сообщение об успешном сбросе свойства реестра. После запуска команды нужно перезапустить службу DNS.
    В данном случае точка используется для указания локального сервера. Чтобы включить поддержку зоны GlobalNames на удаленном сервере, вместо точки введите имя удаленного сервера.
    2. Создание зоны GlobalNames для DNS-сервора, служащего контроллером домена WServer. Зона GlobalNames представляет собой не особый тип зоны, а всего лишь интегрированную в AD зону прямого просмотра с именем GlobalNames. При создании зоны выберите репликацию данных зоны для всех DNS-серверов в лесу. Эта опция находится на странице Область репликации зоны, интегрированной и AD (AD Zone Replication Scope) мастера создания новой зоны. Оставьте опцию по умолчанию Основная и установите флажок Сохранять зону в AD.
    3. Заполнение зоны GlobalNames. Для каждого сервера, которому требуется обеспечить возможность разрешения имен из одной метки, создайте в зоне GlobalNames запись псевдонима ( CNAME ) ресурса. Отметим, что каждая запись CNAME указывает запись узла в еще одной зоне.
    При развертывании зоны GlobalNames в лесу AD в производственной среде включить зону потребуется выполнить на каждом DNS-сервере и лесе.
    На странице Динамическое обновление выберите опцию Запретить динамическое обновление и щелкните кнопку Далее. Эту опцию нужно выбрать потому, что динамические обновления не поддержинаются в зоне GlobalNames.
    Если щелкнуть правой кнопкой мыши контейнер зоны и применить команду Обновить, будут созданы записи собранные с динамических клиентов.

    Записи

    Встроенные записи ресурсов


    Записи ресурсов - записи имен в базах данных DNS. Записи ресурсов обычно связываются с IP-адресами с использованием FQDN-имени.
    При создании новой зоны автоматически создается 2 типа записей. Во-первых, такая зона всегда включает начальную запись зоны SOA (Start Of Authority ), определяющую основные свойства зоны. Особая запись DNS с такой информацией домена, как схема обновления записей, интервал проверки обновлении на других DNS-серверах, а также время и дата первого обновления, вместе с другими сведениями, в том числе информация о контактах с доменом и т.д. В файле зоны может содержаться только одна запись SOA. Запись SOA должен содержать каждый файл зоны.
    Кроме того, новые зоны содержат хотя бы одну запись сервера имен NS (Name Server), указывающую имя полномочного сервера (серверов) зоны. На рис показана новая зона с двумя записями.
    При загрузке зоны DNS-сервер использует начальную запись зоны SOA для определения основных свойств и полномочий зоны. Эти параметры также характеризуют частоту передачи зон между основным и дополнительным сервером.
    Если дважды щелкнуть запись SOA, откроется вкладка Начальная запись зоны диалогового окна свойств зоны.
    Серийный номер - номер редакции файла зоны. Указанное здесь число увеличивается каждый раз при изменении записей ресурсов в зоне. Его также можно увеличить вручную с помощью кнопки Увеличить (Increment).
    Основной сервер (Primary Server) - полное имя компьютера основного DNS-сepвера зоны. Это имя должно завершаться символом точки.
    Ответственное лицо ( Responsible Person RP) В это поле вводится имя ответственного лица, соответствующее доменному почтовому ящику администратора зоны. Имя, введенное в это поле, всегда должно завершаться точкой. Указывает имя оператора этого сервера. Обычно для него используется стандартный термин, например Hostmaster или Operations. По умолчанию в WServer назначается имя hostmaster.имя_днс_зоны с FQDN-именем зоны. Записи Ответственное лицо основаны на записях RP, которые не создаются по умолчанию.
    Создайте соответствующую запись RP для каждой зоны или хотя бы для каждого мастер-сервера DNS и назначьте ей это значение. Помните, что для создания записи потребуются различные элементы, описанные далее.
    1. Общее имя группы. Будет отображаться в записи.
    2. Почтовый ящик группы в каталоге. Для своевременной доставки сообщений по этому адресу лучше всего использовать почтовый ящик.
    Для создания записи RP используйте следующую процедуру. Начните с записи Текст.
  • ПКМ имя зоны и примените команду Другие новые записи.
  • В списке Выбор типа записи ресурса ( Select A Resource Record Туре) найдите запись Текст (TXT) и щелкните кнопку Создать запись.
  • В диалоговом окне Новая запись ресурса (New Resource Record) введите имя записи, например Disclaimer, и перейдите к полю Текст.
  • Введите свое сообщение. Щелкните ОК, чтобы создать запись. После этого вы вернетесь к диалоговому окну Тип записи ресурса (Resource Record Type). Это окно должно содержать информацию о вас и вашем управлении DNS. Текст сначала набирается в текстовом редакторе, а затем вставляется в это диалоговое окно.
  • В списке Выбор типа записи ресурса (Select A Resource Record Туре) найдите тип записи Ответственное лицо (PR) (Responsible Person (PR)) и щелкните команду Создать запись (Create Record).
  • В диалоговом окне Новая запись ресурса (New Resource Record) введите имя записи в текстовое поле Узел или домен ( Host Or Domain), например Operations, и щелкните кнопку Обзор (Browse), чтобы локализовать почтовый ящик ответственного лица. Вы также можете ввести адрес.
  • Щелкните кнопку Обзор (Browse), чтобы локализовать новую созданную текстовую запись (необязательное примечание). Найдите зону, с которой работаете, локализуйте и выберите в ней запись. Щелкните ОК.
  • Щелкните О К, чтобы создать запись. Щелкните кнопку Готово ( Done ), чтобы закрыть диалоговое окно Типы записи ресурса (Resource Record Type).
  • Вернитесь к диалоговому окну Свойства или дважды щелкните запись Начальная запись зоны (Start Of Authority), чтобы назначить запись PR для начальной записи зоны SOA.
    Интервал обновления (Refresh Interval) Значение в этом поле определяет время ожидания дополнительного DNS-сервера перед запросом обновления зоны на главном сервере. По истечении интервала обновления дополнительный DNS-сервер запрашивает на главном сервере копию текущей записи SOA. После получения ответа дополнительный DNS-сервер сравнивает серийный номер текущей записи SOA главного сервера с серийным номером своей локальной записи SOA. Если эти значения отличаются, дополнительный DNS-сервер запрашивает передачу зоны с главного DNS-сервера. По умолчанию назначается интервал обновления 15 минут.
    Интервал повтора (Retry Interval) Значение в этом поле определяет время ожидания дополнительного сервера до повторной передачи зоны. Обычно этот интервал меньше интервала обновления. По умолчанию назначается 10 минут.
    Срок истекает после (Expires After) Значение в этом поле определяет интервал времени, в течение которого дополнительный сервер продолжает выполнение запросов DNS-клиентов, не обращаясь к главному серверу.
    По истечении этого времени данные считаются ненадежными. По умолчанию для этогo параметра назначается один день.
    Минимальный срок жизни TTL (Minimum (Default) TTL) Значение в этом поле определяет минимальный срок жизни, по умолчанию применяемый ко всем записям ресурсов в зоне. По умолчанию для этого параметра назначается 1 час.
    Значения TTL не относятся к записям ресурсов в полномочных зонах. В этих зонах для значений TTL используется время жизни кэша записи ресурсов на неполномочных серверах. DNS-сервер, который внес в кэш запись ресурса из предыдущего запроса, сбрасывает эту запись но истечении TTL записи.
    Срок жизни (TTL) записи. Значение, указанное в этом поле, определяет срок жизни текущей записи SOA. Это значение заменяет значение по умолчанию, указанное в предыдущем поле.
    Ниже приведен пример текстового представления созданной начальной записи зоны SOA в файле стандартной зоны.
    @ IN SOA computer1.domain1.local. hostmaster.domain1.local. (-5099 ;
    serial number-3600 : refresh (1 hour)-600 ; retry (10 mins)-86400 ;
    expire (1 day)-60 ) ; minimum TTL (1 min)
    Помимо записей SOA и NS автоматически создаются еще некоторые записи ресурсов. Например, во время установки нового DNS-сервера, когда сервер назначается контроллером домена, многие записи SRV доменных служб AD создаются автоматически в локально управляемой зоне.
    Несмотря на то что многие записи ресурсов создаются автоматически, в корпоративных средах обычно требуется создать некоторые записи ресурсов вручную, например почтовые обменники MX для почтовых серверов, псевдонимы (CNAME) для веб-серверов и серверов приложений, а также записи узлов для серверов и клиентов, которые не могут выполнять собственные обновления.
    Чтобы вручную добавить запись ресурса для зоны, в консоли Диспетчер DNS ПКМ значок зоны и в контекстном меню выберите тип создаваемой записи. После выбора записи в контекстном меню откроется диалоговое окно, где можно указать имя записи и связанный с ней компьютер.
    На рис. 3-13 показано диалоговое окно Новая запись ресурса для создания записи MX. Отметим, что имя компьютера с IP-адресом связывают только записи узла. Большинство типов записей связывают имя службы или псевдоним с исходной записью узла. Таким образом, запись MX полагается на присутствие в зоне записи узла SRV12.nwtraders.msft.
    Далее описаны наиболее распространенные типы записей.

    Типы записей


    Записи ресурсов представляют сущности базы данных DNS, которые используются для ответов на запросы клиентов DNS. Каждый DNS-сервер содержит записи ресурсов. Каждая запись ресурсов описана с конкретным типом ресурса, например адрес (А) IPv4-yзлa, адрес (АААА) IPv6-узла.
    Ниже приведены распространенные записи ресурсов, создаваемые вручную:
    • узел А и АААА;
    • псевдоним (CNAME);
    • почтовый обменник (MX);
    • указатель (PTR);
    • расположение службы (SRV).
    • ISDN . Отображает конкретное имя DNS на телефонный номер ISDN.
    • KEY. Хранит открытый ключ, используемый для шифрования в конкретном домене.
    • RP. Указывает на ответственное лицо (Responsible Person) домена.
    • WKS. Обозначает конкретную общеизвестную службу (Well Known Service).
    • MB. Указывает на хост, содержащий конкретный почтовый ящик.

    Для большинства сетей основную часть записей ресурсов в базе данных зоны составляют записи ресурсов узлов. Эти записи используются в зоне для связывания компьютерных имен (имен узлов) с IP-адресами.
    В диспетчере DNS запись А, где сопоставляется имя узла serverl.lucernepublishing.com с IРv4-адресом 192.168.0.99, и запись АААА, где сопоставляется то же имя с IРv6-адресом fd00:0:0:5::8, будут представлены в текстовом виде в файле стандартной зоны lucernepublishing.com.dns так:
    ;
    ; Zone records
    ;
    server1 А 192.168.0.99
    АААА fd00:0:0:5::8
    Даже при включении динамических обновлений для зон в некоторых сценариях записи узлов нужно будет добавлять записи в зону вручную. На рис. 3-14 компания Contoso использует доменное имя contoso.com в общедоступном пространстве имен и внутреннем домене AD. В этом случае публичный веб-сервер www.contoso.com расположен вне домена AD и выполняет обновления лишь на публичном полномочном DNS-сервере contoso.com.
    Но внутренние клиенты пересылают свои запросы DNS на внутренние DNS-серверы. Так как запись А сервера www.contoso.com не обновляется динамически на внутренних DNS-серверах, ее добавляют вручную, чтобы внутренние клиенты могли разрешать имена и подключаться к общественному веб-серверу.
    Записи узлов можно добавлять вручную, если в сети используется сервер UNIX. Например, компания Fabrikam Inc. имеет в своей частной сети один домен AD с именем fabrikam.com (рис. 3-15). Эта сеть также включает UNIX-сервер Appl.fabrikam.com, который запускает важное приложение для выполнения ежедневных операций компании. Так как UNIX-серверы не могут выполнять динамические обновления, придется вручную добавить запись узла сервера Арр1 на DNS-сервер, управляющий зоной fabrikam.com. В противном случае пользователи не смогут подключаться к серверу приложений, указывая его имя FQDN.
    Если вы можете связаться с компьютером по IP-адресу, но не можете связаться по имени, не исключено, что на компьютере в DNS отсутствует запись узла. Для решения этой проблемы на компьютере можно запустить команду ipconfig \registerdns (это сработает только на компьютере с версией операционной системы не ниже Windows 2000).

    NS


    При создании зоны в WServer каждый сервер, управляющий основной копией зоны, интегрированной в AD, получит собственную запись NS в новой зоне по умолчанию.
    При создании стандартной основной зоны по умолчанию будет добавлена запись NS локального сервера. Для серверов, управляющих дополнительными зонами, нужно вручную добавить записи NS в основную копию зоны.
    Чтобы добавить записи NS, в диспетчере DNS дважды щелкните любую существующую запись NS. Откроется вкладка Серверы имен диалогового окна свойств зоны. Щелкните кнопку Добавить, чтобы добавить имя FQDN и IP-адрес сервера, управляющего дополнительной зоной локальной основной зоны.
    Дополнительная зона не распознает эту запись (NS) как действительный сервер имен, пока содержит действительную копию данных зоны. Чтобы дополнительная зона получила эти данные, нужно включить передачу зон для этого сервера на вкладке Передача зон (Zone Transfers) диалогового окна свойства зоны.
    Ниже приведен пример записи, созданной в файле стандартной зоны:
    @ NS dns1.lucernepublishing.com.
    Символ @ представляет зону, определенную записью SOA в файле зоны. Затем полная запись сопоставляет домен lucernepublishing.com с DNS-сервером dnsl.lucernepublishing.com.
    Информацию об IP-адресе конкретного ресурса записи серверов имен на самом деле не содержат. В действительности в большинстве случаев такую информацию содержат лишь записи А. Записи NS и другие аналогичные записи просто указывают на запись А сервера. Например, запись NS может просто указывать на запись serverl.companyabc.com, а та затем уже направлять запрос к записи А сервера serverl в зоне companyabc. com.

    Псевдоним, или каноническое имя (CNAME)


    Позволяют использовать несколько имен для указания одного узла. Предназначена для создания альтернативной записи или псевдонима DNS для имени, уже указанного в еще одной записи конкретной зоны. Например, если вам нужно создать такую запись, как intranet .contoso.com, указывающую сервер или ферму серверов, вы можете создать псевдоним. В качестве псевдонима можно указать более функциональное имя, чем имя сервера.
    Например, известные имена серверов (ftp, www), как правило, регистрируются с помощью записей CNAME. Эти записи сопоставляют имена узлов, соответствующие их службам (например, ftp.lucernepublishing.com), с реальной записью А компьютера, управляющего службой (например, server-boston.lucernepublishing.com).
    Записи ресурсов CNAME также рекомендуется использовать в следующих случаях.
    1. Когда требуется переименовать узел, указанный в записи А той же зоны.
    2. Когда групповое имя известного сервера (например, www) требуется разрешить в группу отдельных компьютеров (каждый из которых содержит индивидуальные записи А), обеспечивающих одну и ту же службу (например, группа резервных веб-серверов).
    Созданная в диспетчере DNS запись CNAME, где сопоставляется псевдоним ftp.lucemepublishing.com с именем узла ftp1.lucernepublishing.com, будет представлена в текстовом виде в файле зоны lucernepublishing.com.dns таким образом:
    ftp CNAME ftp1.lucernepublishing.com.

    Почтовый обменник (MX)


    Используются приложениями электронной почты для локализации почтового сервера в зоне. Они позволяют сопоставлять доменное имя, например lucernepublishing.com, указанное в адресе электронной почты [email protected], с записью А компьютера, управляющего почтовым сервером в домене.
    Часто записи MX (Mail Exchanger) создаются для обеспечения отказоустойчивости еще одного почтового сервера на случай недоступности предпочтительного сервера.
    Множеству серверов назначаются значения предпочтений. Чем ниже это значение, тем выше порядок предпочтения сервера. Такие записи MX, созданные в диспетчере DNS, могут быть представлены в файле зоны lucernepublishing.com.dns следующим образом:
    @ MX 1 mailserver1.lucernepublishing.com.
    @ MX 10 mailserver2.lucernepublishing.com.
    @ MX 20 mailserver3.lucernepublishing.com.
    В данном примере символ @ представляет локальное доменное имя, содержащееся в адресе электронной почты.

    Указатель (PTR)


    Эта запись используется лишь в зонах обратного просмотра для поддержки обратного просмотра, который производится при разрешении IP-адресов в имена узлов или имена FQDN. Обратный просмотр выполняется в корневых зонах домена in-addr.arpa. Записи PTR можно добавлять в зоны вручную или автоматически.
    Ниже приведен пример текстового представления в файле зоны записи PTR, созданной в диспетчере DNS, которая сопоставляет IP-адрес 192.168.0.99 имени узла serverl.lucernepublishing.com:
    99 PTR server1.lucernepublishing.com.
    ПРИМЕЧАНИЕ Номер 99 записи PRT
    В зоне обратного просмотра последний октет IPv4-адреса эквивалентен имени узла. Поэтому число 99 представляет имя, назначенное узлу внутри зоны
    0.168.192.in-addr.arpa. Эта зона соответствует подсети 192.168.0.0.

    Расположение службы (SRV)


    Записи SRV (Service Location Record) применяют для указания расположения служб TCP/IP в домене. Клиентские приложения, использующие SRV, посредством DNS могут извлекать записи SRV серверов приложений.
    Служба сетевого входа в систему Netlogon использует записи SRV для локализации контроллеров домена, выполняя поиск домена Службы AD облегченного доступа к каталогам (LDAP).
    Хотя большинство записей SRV создаются автоматически, иногда необходимо создавать их вручную в диспетчере DNS, чтобы повысить отказоустойчивость или устранить неполадки сетевых служб. В следующем примере показано текстовое представление двух записей SRV, настроенных вручную в консоли Диспетчер DNS:
    _ldap._tcp SRV 0 0 389 dc1.lucernepublishing.com.
    SRV 10 0 389 dc2.lucernepublishing.com.
    В этом примере сервер LDAP (контроллер домена) с приоритетом 0 (самый высокий) сопоставлен с портом 389 узла dcl.lucernepublishing.com. И второй контроллер домена с более низким приоритетом, 10. Для обеих записей назначен приоритет 0, то есть среди серверов с равным приоритетом нагрузка не сбалансирована.
    Например, чтобы использовать Microsoft Office Communications Server, нужно создать запись о расположении службы протокола установления сеанса SIP (Session Initiation Protocol) и указать все устройства, которые используют данную службу в сети. Аналогичным образом службы AD DS создают несколько записей расположения служб для поддержки входа и процессов распространения групповой политики. Записи расположения служб обычно состоят из IP-адреса сервера и TCP/IP-порта, на котором доступна служба.

    Очистка и удаление устаревших записей


    Штампы времени TTL используются в DNS для отслеживания возраста динамически регистрируемых записей ресурсов. Очистка устаревших записей представляет собой процесс удаления устаревших записей со штампами времени. Очистка может выполняться только в случае использования штампов времени. Штампы времени и очистка в совокупности обеспечивают удаление старых записей, которые могут накапливаться со временем в зоне.
    По умолчанию штампы времени и очистка отключены. Чтобы включить очистку для отдельной зоны, нужно включить эту функцию на уровне сервера и уровне зоны.
    На уровне сервера: в дереве консоли Диспетчера DNS ПКМ значок сервера и примените команду Установить свойства очистки для всех зон (Set Aging/Scavenging For All Zones). Затем в открывшемся диалоговом окне Свойства очистки сервера (Server Aging/Scavenging Properties) установите флажок Удалять устаревшие записи ресурсов (Scavenge Stale Resource Records).
    Хотя этот параметр включает на уровне сервера штампы времени и очистку для всех новых зон, он не включает штампы времени и очистку существующих зон, интегрированных в AD. Поскольку вы задаете значения для существующих зон, DNS также позволяет задавать их для любой создаваемой зоны, включая интегрированные зоны AD. Установите флажок Применить эти параметры к существующим зонам, интегрированным в AD ( Apply These Settings To The Existing AD- Integrated Zones) и щелкните ОК.
    Очистка, применяемая к серверу, выполняется во всех активных зонах на сервере.
    На уровне зоны: откройте свойства зоны, а затем на вкладке Общие щелкните кнопку Очистка (Aging).
    Зоны, интегрированные в AD, устанавливают значения штампов времени для динамически регистрируемых записей по умолчанию еще до включения очистки. Однако основные стандартные зоны устанавливают штампы времени для динамически регистрируемых записей в зоне лишь после включения очистки. Записям ресурсов, создаваемым вручную для всех типов зон, назначается штамп 0; это означает, что их возраст определяться не будет. Очистка создаваемых вручную записей никогда не выполняется. Если вам требуется запретить очистку определенной записи в зоне, лучше всего удалить исходную запись и воссоздать ее вручную.
    В диалоговом окне Свойства очистки для зоны (Zone Aging/Scavenging Properties) можно модифицировать, два ключевых параметра штампов времени и очистки:
    1. Интервал блокирования — это время между последним обновлением штампа и его возможным следующим обновлением. Блокирование не позволяет серверу обрабатывать ненужные обновления и снижает объем трафика.
    2. Интервал обновления — это промежуток между самым ранним временем обновления штампа времени и самым ранним временем начала очистки записи. По истечении интервалов блокирования и обновления записи могут удаляться из зоны. По умолчанию интервал равен 7 дням. Поэтому при включении штампов времени динамически регистрируемые записи ресурсов могут быть удалены через 14 дней.
    Не забывайте, что интервал обновления должен быть больше интервала блокирования.
    Очистка выполняется в зоне автоматически или вручную. Для автоматического выполнения очистки нужно разрешить, автоматическое удаление устаревших записей ресурсов на вкладке Дополнительно (Advanced) диалогового окна свойств DNS-сервера.
    Если эта опция не включена, вы можете выполнить очистку в зонах вручную, щелкнув правой кнопкой мыши значок сервера в дереве консоли Диспетчер DNS и применив команду Удалить устаревшие записи (Scavenge Stale Resource Records).

    Репликации и передачи зон


    Репликации зоны, интегрированной в AD


    Репликация зон — это процесс синхронизации данных зон, интегрированных в AD. Передача зон — это синхронизация данных зон между главной и дополнительной стандартной зоной. Эти два механизма основаны на разных технологиях, поэтому настраиваются отдельно.
    На странице Область репликации зоны, интегрированной в AD Мастера создания новой зоны можно выбрать контроллеры домена в сети для сохранения данных зоны. Эта страница появляется только при выборе опции сохранения зоны и AD.
    На этой странице представлены такие опции:
    • сохранение зоны на всех контроллерах домена, которые также являются DNS-серверами но всём лесе AD;
    • сохранение зоны на всех контроллерах домена, которые также служат DNS-серверами в локальном домене AD;
    • сохранение зоны на всех контроллерах домена в локальном домене AD (используется для совместимости с Windows 2000);
    • сохранение зоны на всех контроллерах домена, указанных и области настраиваемого раздела каталога AD.

    Передача зон


    Если все DNS-серверы расположены на контроллерах доменов, для обеспечения согласованности данных зон среди всех DNS-серверов используется репликация AD. Однако эта возможность недоступна при установке DNS-cepвера на компьютере, не являющемся контроллером домена. В таком случае зону нельзя сохранять в AD, вместо этого нужно использовать стандартную зону, которая сохраняет данные в локальном текстовом файле на каждом DNS-сервере.
    При полной передаче зоны все ее содержимое пересылается на один или несколько других DNS-серверов, при инкрементной передаче пересылается лишь поднабор данных. По традиции полная передача выполняется в асинхронном режиме передачи AXFR (Asynchronous Full Transfer ), а инкрементные передачи выполняются в инкрементном режиме передачи IXFR (Incremental Zone Transfer). В WServer также поддерживаются безопасные передачи зон, которые выполняются посредством репликации с множеством равноправных участников (Multimaster).
    Если зоны отконфигурированы для выполнения передач зон на один или несколько дополнительных серверов, эти дополнительные серверы периодически запрашивают серийный номер зоны на главном сервере. Такие запросы называются запросами SOA. Если в запросе SOA получен серийный номер основной зоны, равный серийному номеру дополнительной зоны, передача не выполняется. Если же серийный номер зоны на главном сервере больше соответствующего значения на запрашивающем дополнительном сервере, последний инициирует передачу зоны.
    Щелчком кнопки Увеличить (на основном сервере) инициируется передача зоны.
    Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне. К примеру, у вас есть два сайта - один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит отдельному домену AD. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами. Такая структура показана на рис. 3-28.
    Передача данных для дополнительных зон может быть инициирована в любом из трех случаев.
  • По истечении интервала обновления начальной записи SOA основной зоны.
  • При загрузке дополнительной зоны сервером.
  • В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях (Сообщение DNS Notify). Традиционные или предыдущие DNS-серверы управляют данными в локальных файлах. Эти файлы локализованы на основном сервере. Они часто пересылаются с помощью механизма опроса и передачи зон для чтения лишь дополнительных серверов. Однако записи в больших зонах часто нужно обновлять, что может привести к появлению некорректных записей на дополнительном сервере. Для решения этой проблемы DNS использует особый процесс, уведомляющий подчиненные серверы о доступности обновления, которое затем предлагает передавать зону на серверы лишь с правом чтения.
    На вкладке Передача зон можно также настроить уведомление, которое будет отправлено дополнительным серверам в случае изменений в основной зоне. Поскольку передача зон представляет собой операции PULL, их нельзя конфигурировать для переноса новых данных на дополнительные серверы. Дополнительная зона, получившая уведомление, инициирует передачу зоны. Для настройки уведомлений на вкладке Передача зон щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере. По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен, автоматически уведомляются об обновлениях зоны.
    4. Обновление дополнительной зоны вручную. Если щелкнуть дополнительную зону ПКМ, откроется контекстное меню, в котором можно использовать следующие операции для обновления зоны:
    а) Перезагрузка ( Reload ). Перезагружается дополнительная зона из локального хранилища.
    б) Передать зону с основного сервера (Transfer From Master). Сервер, управляющий локальной дополнительной зоной, определяет истечение интервала обновления серийного номера дополнительной зоны в записи SOA и выполняет передачу зоны с главного сервера.
    в) Перезагрузить повторно зону с основного сервера (Reload From Master) Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.
    По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.
    а) На любой сервер (То Any Server). Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует использовать только в частных сетях с высоким уровнем безопасности.
    б) Только на серверы, перечисленные на странице серверов зон (Only To Servers Listed On The Name Servers Tab). Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.
    в) Только на серверы из этого списка (Only To The Following Servers). Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

    Зона-заглушка


    Зоны-заглушки аналогичны дополнительной зоне, однако содержат записи ресурсов, необходимые для идентификации полномочных DNS-серверов главной зоны. Зоны-заглушки часто применяются для того, чтобы родительская зона (например, proseware.com) могла использовать обновляемый список серверов имен, доступных в делегированной дочерней зоне (например east.proseware.com). Они также служат для улучшения разрешения имен и упрощения администрирования DNS. Эта зона может ускорить разрешение имен и снизить вероятность возникновения ошибок, поскольку зоны-заглушки используются как ссылки на другие DNS-серверы, уполномоченные для зоны.
    Зона-заглушка (stub) — это копия, которая содержит лишь основные записи главной зоны. Нужна, чтобы локальный DNS-сервер мог пересылать запросы на уполномоченные серверы имен в главной зоне. Таким образом, зона-заглушка функционально идентична делегированию зон. Тем не менее, поскольку зоны-заглушки могут инициировать и принимать передачу зон из главной (делегированной) зоны, они обеспечивают дополнительное информирование родительских зон об обновлениях в записях NS дочерних зон.
    Пример зоны-заглушки показан на рис. 3-31.
    Зоны-заглушки можно использовать в следующих целях:
    Разрешение имен. Зоны-заглушки позволяют DNS-серверу выполнять рекурсию, используя список серверов имен в зоне-заглушке и не запрашивая при этом Интернет или сервер в локальном пространстве имен DNS. В такой ситуации все зоны-заглушки развертываются не между родительской и дочерней зонами, а в доменах большого леса AD или пространстве имен DNS.
    Предположим, вы работаете администратором DNS-сервера Dns1.contoso.com, который уполномочен для зоны Contoso.com. Ваша компания имеет дочерний домен AD с именем India.contoso.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная в AD, содержит только два полномочных DNS-сервера - 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.contoso.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервере Dns1.contoso.com оказались не отконфигурироваными записи новых DNS-серверов.
    Эту проблему можно устранить, создав зону-заглушку на сервере Dnsl.contoso.com для домена India.contoso.com. С помощью новой зоны-заглушки компьютер Dnsl посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.contoso.com.
    Другие примеры использования зон-заглушек:
    Зоны-заглушки могут использоваться для разрешения имен между доменами, предотвращая поиск родительского сервера в пространстве имен DNS. Зоны-заглушки, таким образом, заменяют дополнительные зоны в ситуациях, когда требуется обмен данными DNS между доменами без избыточности данных для главной зоны. Кроме того, зоны-заглушки оптимизируют процесс разрешения имен и снижают нагрузку сетевых ресурсов при передаче данных зон.
    Следует знать, что зоны-заглушки можно использовать для расширения возможностей разрешения имен среди доменов.
    Как зона-заглушка, реализованная в доменах большого леса или другого пространства имен DNS, оптимизирует процесс разрешения имен?
    Ответы:
    Зона-заглушка обеспечивает DNS-серверы именами серверов, уполномоченных для данной зоны. В случае локального хранения такой ииформации DNS-серверу не требуется запрашивать другие серверы с целью определения полномочных серверов для этой зоны. Таким образом, процесс разрешения имен в этой зоне выполняется более эффективно.

    Пул сокетов


    Для пула сокетов WServer (можно поставить и на Wserver 2008, 2003 и 2000 www.microsoft.com/technet/ security /Bulletin/ms08-037.mspx) DNS вы можете позволить серверу DNS использовать перемешивание портов источников при выполнении DNS запросов. Зачем это делать? Затем, что перемешивание портов источника обеспечивает защиту от различных атак отравления кэша. Изначальное исправление включало некоторые стандартные параметры, но в WServer вы можете изменять параметры пула сокетов.
    Благодаря перемешиванию портов источников сервер DNS будет случайно выбирать порт источника из пула доступных сокетов, которые он открывает при запуске службы. Это не позволяет удаленным злоумышленникам, не прошедшим проверку подлинности, отправлять специально созданные ответы на DNS запросы, чтобы отравить кэш DNS и пересылать трафик в места, которые контролируются злоумышленником.
    Предыдущие версии Windows DNS сервера использовали весьма предсказуемый набор портов источника при издании запросов DNS. С помощью нового пула сокетов DNS сервер DNS будет использовать случайный номер порта, выбранный из пула сокетов. Это значительно усложняет злоумышленнику задачу определения порта источника DNS запроса. Для дополнительной защиты от злоумышленника, случайный ID транзакции добавляется в это сочетание, что делает отравление кэша еще более сложной задачей.
    Пул сокетов работает по умолчанию с 2500 сокетами (сокет — сочетание порта и адреса). Однако если вы хотите еще больше усложнить жизнь злоумышленникам, вы можете увеличивать это значение до 10000. Чем больше сокетов будет у вас в пуле, тем сложнее будет определить, какой сокет будет использоваться, а это сильно усложняет задачу отравления кэша. С другой стороны, вы можете настроить пул на ноль. В этом случае у вас будет только один сокет, используемый для DNS запросов, то, чего делать не стоит. Вы даже можете исключать определенные порты из пула.
    Как и компонент кэша DNS, пул сокетов настраивается с помощью инструмента dnscmd. Вы можете настроить размер пула портов, из которых случайным портом источника будет выбран.
    Dnscmd /Config /socketPoolSize
    в привилигированную командную строку, где это число до 10000 указывает размер пула. Можно выбрать больше, чем по-умолчанию (2500) для повышения безопасности и за счет увеличения использования памяти.
    Чтобы исключить порты (только для Wserver 2008)
    dnscmd /Config /socketPoolExcludedPortRanges

    Настройка блокировки DNS-кэша


    Преследует те же цели, что и Пул сокетов. Путем настройки блокировки кэша, вы можете установить процент от значения TTL для кэшированных записей в течение которого записи, хранящиеся в кэше DNS-сервера не могут быть перезаписаны.
    dnscmd /Config /CacheLockingPercent
    Рекомендуемые значения — 90% и выше.

    DNSSEC


    В WServer и WClient полностью поддерживаются все новейшие требования DNSSEC, которые перечислены в документах RFC-4033, RFC-4034 и RFC-4035.

    Компоненты DNSSEC


    Действие DNSSEC основано на использовании так называемых подписанных зон ( Signed Zones), под которыми подразумеваются зоны, чьи записи подписываются в соответствии с
    требованиями, изложенными в RFC-4035. В каждой подписанной зоне могут содержаться записи одного и более новых типов DNSEC, к числу которых относятся записи DNSKEY, NSEC, RRSIG и DS. Эти записи обеспечивают проверку данных DNS на предмет правильности преобразователями.
    Для подписания зоны применяется специальный ключ шифрования, который называется ключом ZSK (Zone Signing Key — ключ для подписания зоны) и, по сути, представляет собой состоящую из открытого и закрытого ключа комбинацию, хранимую в сертификате. Для подписания ключа ZSK и тем самым обеспечения проверки его правильности и, по сути, корректности комбинации из открытого и закрытого ключа, применяется еще один
    ключ, который называется ключом KSK (Key Signing Key — ключ для подписания ключа).
    Записи DNSKEY (DNS Public Key) применяются в DNSSEC для хранения открытых ключей. Хранение открытых ключей KSK и ZSK в этих записях обеспечивает возможность выполнения проверки на предмет правильности подписей зон.
    Записи NSEC (Next Secure) применяются в DNSSEC для подтверждения не существования того или иного имени в DNS и позволяют клиентам DNS в случае не извлечения записи при просмотре DNS иметь уверенность в том, что такой записи в зоне DNSSEC не существует.
    Записи RRSIG (Resource Record Signature) применяются для хранения подписей, принадлежащих записям в DNS. Например, для каждой записи А будет обязательно существовать соответствующая запись RRSIG. Для каждой записи NSEC тоже будет обязательно су-
    ществовать такая соответствующая ей запись.
    Записи DS (Delegation Signer) применяются для защиты делегируемых другим серверам DNS полномочий и подтверждения их правильности и не позволяют используемым для
    атак типа “человек посередине” серверам DNS разрывать цепочку защиты во время рекурсивных просмотров.
    Кроме того, в DNSSEC применяется понятие так называемых не проверяющих правильность защищенных оконечных преобразователей (Non-Validating Security- Aware Stub Resolver ). Под ними подразумеваются такие защищенные (security-aware) преобразователи, которые доверяют выполнять проверку на предмет правильности DNSSEC от их имени одному или более защищенным DNS-серверам. Все клиенты DNS, которые функционируют под управлением Windows, являются не проверяющими правильность защищенными оконечными преобразователями. Это означает, что они не проверяют, являются ли записи DNS защищенными, а вместо этого неявным образом доверяют это делать серверу DNS.
    Для этого они просто помечают запросы к DNS флагами в соответствии с требованиями, указанными в таблицы NRPT и затем ожидают, когда DNS-сервер выполнить проверку вместо них. Сервер DNS возвращает результаты в любом случае и указывает, прошла ли проверка DNSSEC успешно. В случае, если проверка прошла успешно, Windows-клиенты DNS передают результаты далее тому приложению, которое первоначально запрашивало поиск
    в DNS.
    Для обеспечения безопасности запросов к DNS нужно сделать так, чтобы клиенты DNS могли проверять действительность DNS-сервера. В системах Windows для этого можно
    использовать протокол IPSec. Для обеспечения максимальной защиты этот протокол должен быть также развернут и на самом сервере DNS.

    Требования


    Реализация DNSSEC, которая поставляется с WServer, предусматривает подписания зон в автономном режиме, т.е. требует, чтобы файл зоны DNS сначала подписывался и только потом загружался на DNS-сервер. Это означает, что создавать динамические зоны в WServer нельзя, все зоны должны быть статическими.
    Подписываемые зоны могут быть интегрированными в Active Directory, но тогда они должны подвергаться резервному копированию в файл. Все записи имеют текстовый вид,
    так что никаких проблем с интегрированными в Active Directory зонами из-за этого возникать не будет.
    Чтобы запрашивать DNSSEC-защиту при выполнении просмотра, клиент DNS должен иметь запись в таблице политик преобразования имен (Name Resolution Policy Table). Это
    будет вынуждать его помечать запрос флагом как защищенный запрос и тем самым заставлять DNS-сервер проверять безопасность операции поиска и возвращать записи с установленным флагом защиты. Если клиент не запрашивает DNSSEC-защиту, DNS-сервер будет просто возвращать записи.
    И, наконец, для обеспечения полной защиты выполняемых в DNS операций просмотра должен быть обязательно внедрен протокол IPSec.

    Настройка зоны DNSSEC


    В описанном ниже сценарии будет шифроваться зона secure.companyabc.соm. Первоначально эта зона никак не защищена и содержит несколько записей (рис. 10.31). Она
    представляет собой основанную на файлах зону, DNS-зона которой хранится в файле secure.companyabc.com.dns внутри стандартного каталога с:\windows\system32\dns\.
    Настройка и управление DNSSEC осуществляется с помощью утилиты dnscmd.exe.
    Первым шагом является генерирование для защищаемой зоны сертификатов подписи, т.е. сертификатов ZSK и KSK.
    Необходимые шаги перечислены ниже.
    1. На DNS-сервере щелкните ПКМ на пункте Command Prompt (Командная строка) в меню Start (Пуск) и выберите в контекстном меню пункт Run As Administrator .
    2. Введите команду cd \windows\system32\dns.
    3. Чтобы сгенерировать сертификат KSK, введите команду:
    dnscmd /OfflineSign /GenKey /Alg rsasha1 /Flags KSK /Length 1024 /Zone secure.companyabc.com /SSCert /FriendlyName KSK-secure.companyabc.com
    4. Чтобы сгенерировать сертификат ZSK, введите команду:
    dnscmd /OfflineSign /GenKey /Alg rsasha1 /Length 1024 /Zone secure.companyabc.com /SSCert /FriendlyName ZSK-secure.companyabc.com
    Генерируемые ключи сохраняются на DNS-сервере в хранилище сертификатов Local Computer внутри каталога MS-DNSSEC. На рис. 10.32 показано, как можно просматривать информацию о содержащихся в хранилище Local Computer сертификатах через ММС-оснастку Certificates. Срок действия сертификатов подписи по умолчанию составляет 5 лет.
    Следующим действием является подписание файла зоны и записей. Для этого потребуется взять существующий файл зоны (в рассматриваемом примере это secure.companyabc.com.dns), подписать зону и записи и сохранить результат в другом файле зоны (в данном примере это signed.secure.companyabc.com.dns). Для подписания нужно использовать ранее сгенерированные сертификаты. Ниже перечислены шаги, которые необходимо вы-
    полнить для подписания зоны.
    1. Диспетчер сервера/Roles, DNS Server, DNS, DC1
    и Forward Lookup Zones (Зоны обратного просмотра) и найдите узел с названием secure.companyabc.com.
    2. Щелкните на узле secure.companyabc.com ПКМ и выберите в контекстном меню пункт Update Server Data File (Обновить файл данных сервера). Это гарантирует сохранение в файле самых последних обновлений.
    3. Запуск от имени администратора
    cd \windows\system32\dns.
    4. Чтобы подписать файл зоны, введите команду
    DnsCmd /OfflineSign /SignZone /input secure.companyabc.com.dns /output signed.secure.companyabc.com.dns /zone secure.companyabc.com /signkey /cert /friendlyname KSK-secure.companyabc.com
    /signkey /cert /friendlyname ZSK-secure.companyabc.com
    После выполнения этих шагов файл зоны будет подписан и готов загрузке на DNS-сервер.
    Последним действием в процессе подписания зоны является повторная загрузка файла зоны на DNS-сервер. Сначала потребуется удалить неподписанную зону, после чего загрузить файл подписанной зоны (в рассматриваемом примере это signed.secure.companyabc.com.dns).
    Ниже перечислены необходимые шаги.
    1. Запуск от имени администратора cd \windows\system32\dns.
    3. Введите команду dnscmd /ZoneDelete secure.companyabc.com /f. Это приведет к удалению прежней неподписанной зоны с DNS-сервера.
    4. Введите команду
    dnscmd /ZoneAdd secure.companyabc.com /primary
    /file signed.secure.companyabc.com / load
    Это приведет к загрузке файла подписанной зоны.
    После этого зона secure.companyabc.com будет зашифрована. Кроме того, последующие обновления будут сохраняться в новом файле signed.secure.companyabc.com.dns. На рис. 10.33 показано, как выглядят записи зоны после шифрования.
    В этих записях исходной датой является 10/26/2009, а датой истечения срока действия — 11/25/2009. По умолчанию срок действия составляет 30 дней с момента подписания зоны. Это означает, что через 30 дней файл зоны потребуется подписывать снова.
    Если необходимо увеличить срок действия, в команде dnscmd.exe необходимо указать параметры /ValidFrom и /ValidTo.
    Теперь на каждую предыдущую запись приходится целых четыре новых:
    • стандартная запись А;
    • запись подписи RR (RR Signature — RRSIG) для стандартной записи;
    • следующая безопасная запись (Next Secure Record — NSEC);
    • запись подписи RR (RR Signature — RRSIG) для следующей безопасной записи.

    Без дополнительной конфигурации клиенты DNS будут игнорировать DNSSEC-настройки зоны. Чтобы они использовали DNSSEC-свойства зоны DNS, их нужно сконфигурировать так, чтобы они запрашивали безопасные записи DNS. Для этого потребуется настроить для них политику NRPT (Name Resolution Policy Table — таблица политик преобразований имен). Ниже перечислены шаги по созданию групповой политики NRPT для зоны secure.companyabc.com.
    1. На контроллере домена DC1 откройте консоль Диспетчер сервера/Features (Компоненты), Group Policy Management , Forest : companyabc.com (Лес: companyabc.com) и Domains и выделите узел с названием companyabc.com.
    2. Щелкните на узле companyabc.com ПКМ и выберите в контекстном меню пункт Create a GPO in This Domain, and Link It Here (Создать объект групповой политики и добавить на него ссылку здесь).
    3. Введите NRPT Group Policy Object . Edit.
    4. Раскройте последовательно папки Policies и Windows Settings и выберите папку Name Resolution Policy (Политика преобразования имен).
    5. В поле То which part of the namespace does this rule apply (К какой части пространства имен должно применяться данное правило) выберите вариант Suffix и введите secure.companyabc.com.
    6. На вкладке DNSSEC отметьте флажок Enable DNSSEC in This Rule (Включить DNSSEC в этом правиле).
    7. В разделе Validation (Проверка правильности) отметьте флажок Require DNS Clients to Check That Name and Address Data Has Been Validated (Требовать, чтобы клиенты DNS удостоверялись в том, что данные об имени и адресе были проверены на предмет правильности). Название этой опции сформулировано верно. В случае ее включения Windows-клиент DNS будет удостоверяться именно в том, проверил ли DNS-сервер данные на предмет
    правильности, а не производить такую проверку самостоятельно.
    8. Щелкните на кнопке Create (Создать), чтобы создать запись в поле Name Resolution Policy Table (Таблица политик преобразования имен). На рис. 10.34 показано, когда должна выглядеть эта запись.
    9. Закройте окно редактора GPMC, чтобы сохранить изменения.
    После выполнения этих шагов все клиенты DNS в домене будут запрашивать, чтобы DNS-серверы проверяли правильность запросов на выполнение поисков в домене secure,
    companyabc. com с помощью DNSSEC.
    К числу дополнительных шагов, которые может потребоваться выполнить для обслуживания защищенной зоны DNS, относятся:
    • создание резервных копий сертификатов KSK и ZSK;
    • создание резервных копий файлов защищенной и незащищенной зон;
    • создание графика выполнения обслуживания для обновления подписей зоны.

    DHCP


    Важным дополнением является DHCP Guard, который блоки-
    рует DHCP-сообщения от неавторизованных виртуальных машин,
    претендующих на звание серверов DHCP. Появились инструменты
    для работы с DHCP failover.

    Назначение адресов DHCP


    DHCP позволяет назначать IP-адреса, маски подсети и другие параметры конфигурации клиентским компьютерам в локальной сети. Если DHCP-сервер доступен, компьютеры, настроенные на автоматическое получение IP-адресов, запрашивают и получают с него конфигурацию IP во время загрузки.
    Серверы DHCP тоже могут назначать IPv6-aдpeca, однако эта методика нечасто используется, поскольку IPv6-узлы по умолчанию сами конфигурируют свои адреса.
    Автоматическая конфигурация включает как минимум IРv4-адрес, маску подсети, а также другие параметры (например, основной шлюз и DNS-сервер).
    1. На первой стадии клиент выполняет широковещание сообщения DHCP Discover в локальной сети для идентификации всех доступных DHCP-серверов.
    2. DHCP-сервер отправляет DHCP-клиенту одноадресное сообщение DHCP Offer . Сообщение содержит список параметров конфигурации DHCP и доступный IP-адрес из области DHCP. Если на DHCP-сервере зарезервирован IP-адрес, соответствующий МАС-адресу DHCP-клиента, сервер предлагает этот зарезервированный IP-адрес DHCP-клиенту.
    3. Ответ с запросом DHCPREQUEST. DHCP-клиент отвечает на сообщение DHCP Offer и запрашивает IP-адрес, содержащийся в сообщении DHCP Offer. В качестве альтернативы DHCP-клиент может запросить ранее назначенный IP-адрес.
    4. Если IP-адрес, запрашиваемый DHCP-клиентом, все еще действителен, DHCP-сервер отвечает сообщением подтверждения DHCP Ack. Теперь клиент может использовать этот IP-адрес.

    Области и опции DHCP


    Cерверу нужно назначить диапазон IP-адресов - область, которая определяет единую физическую подсеть в сети, в которой работают службы DHCP. Для каждой области можно назначить только один непрерывный диапазон.
    Например, если сеть состоит из двух подсетей с диапазонами адресов 10.0.1.0/24 и 192.168.10.0/24, DHCP-сервер должен быть напрямую подключен к каждой подсети и связанным диапазонам адресов. Области также обеспечивают для серверов метод управления распределением и назначением IP-адресов и опций среди клиентов в сети.
    Чтобы DHCP-сервер назначал адреса компьютерам в локальной подсети, самому серверу нужно назначить адрес из той же подсети.
    Опции DHCP обеспечивают для клиентов такие дополнительные параметры конфигурации, как адреса DNS или WINS-сервера со сроком аренды адресов. Доступно более 60 стандартных опций DHCP. В конфигурации IPv4 чаще всего используются следующие.
    003 Маршрутизатор. Предпочитаемый список 1Рv4-адресов маршрутизаторов в той же подсети, где расположены DHCP-клиенты.
    006 DNS-серверы. IP-адреса серверов имен DNS, к которым могут обращаться DHCP-клиенты.
    015 DNS-имя домена Эта опция указывает имя домена, которое должны использовать DHCP-клиенты при разрешении неквалифицированных имен в процессе разрешения доменных имен DNS. Данная опция также позволяет клиентам выполнять динамические обновления DNS.
    044 WINS/NBNS-серверы IРv4-адреса основного и дополнительного WINS-серверов, используемых DHCP-клиентом.
    046 Тип узла WINS/NBT (WINS/NBT Node Туре) Предпочитаемый метод разрешения имен NetBIOS для DHCP-клиента, например, 0 x 1=b - узел - для узла широковещания, или 0 х 8 = h - узел — для гибридного узла с подключением широковещания и «точка-точка».
    051 Аренда ( Lease ). Опция, назначающая особый срок аренды лишь для клиентов удаленного доступа. Зависит от данных пользовательского класса такого типа клиента.
    Опции DHCP обычно назначаются для всей области, но их можно назначать и на уровне сервера и применять ко всем арендам адресов во всех областях, определенных для DHCP-сервера. И, наконец, их также можно назначать на уровне резервирования.

    Добавление роли DHCP-сервер


    Процедура установки и настройки DHCP-сервера довольно проста, но для реализации и управления DHCP в сети нужно понимать концепции DHCP.
    На странице Выбор привязки сетевого подключения (Select Network Connection Bindings) мастера добавления ролей нужно указать сетевые адаптеры, которые DHCP-сервер будет использовать для обслуживания клиентов. Если DHCP-сервер установлен на многосетевом компьютере, на этой странице можно назначить службу DHCP только для одной сети. Кроме того, IP-адрес адаптера требуется назначить вручную, а адреса, назначаемые клиентам с сервера, должны располагаться в той же логической подсети, где находится назначенный статический адрес (если для обеспечения службы DHCP в удаленной сети не используется агент-ретранслятор DHCP).
    Хотя эта опция сама по себе не ограничивает количество адресов, на странице Указать параметры IPv4 DNS-сервера можно отконфигурировать лишь два адреса. Значение в поле IPv4-aдpec основного DNS-сервера (Preferred DNS Server IPv4 Address) соответствует первому адресу в списке DNS-серверов, а значение в поле IPv4адpec дополнительного DNS-сервера соответствует адресу второго DNS-сервера в списке, назначаемом каждому DHCP-клиенту.
    Добавление областей DHCP. Область представляет собой административное группирование IP-адресов компьютеров в подсети, использующей службу DHCP. Каждая подсеть может располагать лишь одной DHCP-областью с единым непрерывным диапазоном IP-адресов.
    Откроется диалоговое окно Добавление области (Add Scope).
    1. Имя области не играет роли для DHCP-клиентов, а лишь используется для области в консоли DHCP.
    2. Начальный и конечный IP-адреса (Starting/ Ending IP Address). Во время определения диапазона IP-адресов для области следует использовать последовательные адреса, составляющие подсеть, в которой будет включена служба DHCP. Из этого определенного диапазона также следует исключить все статические адреса для существующих или запланированных серверов в сети.
    3. Маска подсети, которая будет назначена DHCP-клиентам. Здесь следует указать ту же маску подсети, которая отконфигурирована для самого DHCP-сервера.
  • Тип подсети (Subnet Type) В этом поле можно указать один из двух сроков аренды для области. По умолчанию назначается тип подсети Проводной ( Wired ) со сроком аренды 6 дней.

    Настройка режима DHCPv6 без отслеживания состояния


    Режим DHCPv6 используется в сетях IPv6. Режим без отслеживания состояния служит режимом адресации IPv6-yзлoв по умолчанию. В этом режиме конфигурация адресов осуществляется без помощи DHCP-сервера, хотя параметры все еще можно получать с DHCP-сервера. При автоматическом назначении адреса IPv6-yзлy без DHCP-сервера узел в режиме без отслеживания состояния самостоятельно конфигурирует адрес, совместимый с локальной подсетью, обмениваясь запросами ( Router Solicitation) и объявлениями (Router Advertisement) с соседним маршрутизатором IPv6.
    На странице Настроить режим DHCPv6 без отслеживания состояния (Configure DHCPv6 Stateless Mode) можно отключить режим без отслеживания состояния на DHCP-сервере и позже настроить его для IPv6-узлов, выполняющих адресацию без отслеживания состояния. Затем IРу6-узлы с адресацией без отслеживания состояния будут запрашивать на DHCP-сервере адрес и потенциально иные параметры конфигурации (например, адреса DNS-серверов) с помощью протокола DHCPv6. Потребуется создать область диапазона IРу6-адресов. Для этого в дереве консоли DHCP ПКМ узел IPv6, примените команду Создать область.
    Чтобы включить адресацию без отслеживания на IРv6-узле, введите команду:
    netsh interface ipv6 set interface имя_интерфейса managedaddress=disabled
    Чтобы IРv6-узел получал опции DHCP с сервера DHCPv6, введите следующую команду:
    netsh interface ipv6 set interface имя_интерфейса otherstateful=enabled
    На странице Авторизация DHCP-сервера (Authorize DHCP Server) можно выбрать параметры авторизации DHCP-сервера в домене AD, указав имя пользователя. В доменных средах AD сервер DHCP не будет назначать адреса клиентам, пока не будет выполнена его авторизация. Это снижает вероятность случайного или намеренного создания пользователем DHCP-сервера, назначающего недействительную конфигурацию для DHCP-клиентов.
    Требование авторизации сервера обозначено красной стрелкой вниз на значке IPv4 или IPv6 в консоли DHCP, как показано на рис. 4-11.

    Исключаемые адреса и резервирование


    Диапазон исключения - это набор из одного или нескольких IP-адресов, включенных в диапазон определенной области, которые не будут выделяться в аренду DHCP-клиентам.
    Чтобы добавить диапазон исключений, в дереве консоли DHCP найдите папку DНСР\\IРv4\Область\Пул адресов. ПКМ папку Пул адресов и примените команду Диапазон исключения (New Exclusion Range).
    Резервирование используется для назначения DHCP-сервером постоянного (перманентного) адреса путем связывания IP-адреса с МАС-адресом. Для резервирования DHCP-сервер распознает DHCP-запросы, поступающие с аппаратного адреса, после чего назначает этому МАС-адресу IP-адрес.
    Недостаток резервирования в том, что такие адреса назначаются во время загрузки в зависимости от доступности DHCP-сервера, что неудобно для таких серверов инфраструктуры, как DNS-серверы. Но преимущество использования постоянного адреса для некоторых серверов, например серверов приложений, серверов печати и даже некоторых контроллеров домена, состоит в том, что эти адреса не нужно конфигурировать вручную.
    Чтобы создать резервирование, в дереве консоли DHCP найдите папку DНСР\\\Ру4\Область\Резервирование. ПКМ папку Резервирование (Reservations).
    Утилита командной строки Getmac, встроенная в WServer, позволяет без труда получать МАС-адреса удаленных компьютеров. С помощью этого инструмента область DHCP можно отконфигурировать с нуля не более чем за 30 с, даже не зная имя удаленного компьютера.
    Если вы не хотите вводить компьютерные имена для каждой области, убедитесь, что DNS-сервер управляет удаленной зоной просмотра с включенным динамическим обновлением. После перезагрузки всех клиентов запись PTR каждого клиента должна быть зарегистрирована в этой зоне обратного просмотра.
    Затем используйте команду Getmac с переключателем /s и укажите удаленный компьютер, после чего сохраните результаты в буфере обмена, чтобы не вводить МАС-адрес вручную.
    Например, чтобы создать область DHCP для компьютера с текущим адресом 192.168.0.99, в консоли DHCP откройте диалоговое окно Создать область (New Reservation), а затем введите в командную строку следующее:
    getmac /s 192.168.0.99 | clip
    Затем откройте Блокнот и нажмите клавиши Ctrl + V. Таким образом вы вставите результат предыдущей операции Getmac. После этого в окне программы Блокнот можно скопировать аппаратный адрес и вставить его в текстовое поле диалогового окна Создать область. В то же диалоговое окно введите IP-адрес, который хотите назначить имени области, и щелкните кнопку Добавить.
    Эта технология значительно упрощает миграцию со статической адресации в область DHCP. Практически во всех случаях дело того стоит.

    Изменение срока действия аренды


    Каждый DHCP-сервер поддерживает базу данных адресов, которые может назначать клиентам. DHCP-сервер назначает адрес под видом аренды; ее срок по умолчанию составляет 6 или 8 дней — в зависимости от метода, используемого для настройки сервера. DHCP-сервер отслеживает арендованные адреса, чтобы не назначать двум клиентам один адрес.
    Чтобы предотвратить назначение на неопределенный срок IP-адреса клиенту, отключенному от сети, DHCP-серверы изымают адреса по истечении срока их аренды.
    По истечении половины срока аренды клиент запрашивает обновление аренды адреса на DHCP-сервере. Если DCHP-сервер доступен в сети, он, как правило, принимает эти запросы и возобновляет период аренды адреса. В случае недоступности DHCP-сервера DHCP-клиент попытается вновь обновить аренду по истечении половины оставшегося срока. Если по прошествии 87,5% срока аренды DHCP-сервер остается недоступным, DHCP-клиент пытается найти новый DHCP-сервер, чтобы получить другой IP-адрес.
    При корректном завершении работы DHCP-клиента или запуске администратором команды ipconfig /release клиент отправляет сообщение DHCP Release на DHCP-сервер, назначивший IP-адрес. DHCP-сервер помечает этот IP-адрес как доступный и назначает его другому DHCP-клиенту. В случае внезапного отключения DHCP-клиента от сети без возможности отправить сообщение DHCP Release сервер DHCP не назначит IP-адрес другому клиенту, пока не истечет срок аренды DHCP. Поэтому в сети, к которой часто подключаются и от которой часто отключаются клиенты (например, в беспроводных сетях), важно использовать более короткий срок аренды DHCP (например, 6 ч вместо 6 дней).
    Срок действия аренды IP-адреса можно изменить. Для большинства локальных сетей LAN приемлемо значение по умолчанию 6 дней, но его можно увеличить, если компьютеры постоянно остаются в одном месте в сети. При использовании разбросанных адресов или коротких сеансов пользовательских подключений срок аренды адресов следует уменьшить. Особенную осторожность нужно проявлять при настройке неограниченных сроков аренды. Такие сроки можно конфигурировать в небольших сетях со множеством адресов, но этот параметр нужно использовать крайне осторожно.
    Чтобы изменить срок аренды адресов, откройте свойства области. Срок аренды можно изменить на вкладке Общие в области Срок действия аренды адреса для DHCP-клиентов (Lease Duration).
    Узел Арендованные адреса (Address Leases) и дереве консоли DHCP отображает текущие арендованные IP-адреса. Чтобы завершить аренду адреса клиентом, такой адрес можно просто удалить, щелкнув его правой кнопкой мыши и применив команду Удалить.
    С помощью консоли DHCP можно завершить аренду адресов сразу для нескольких клиентов. Это удобно, когда клиентам нужно назначить новые адреса (по причине новых исключений или резервирования, влияющих на этих клиентов). Удаление аренды множества адресов одновременно удобно при назначении новой опции DHCP множеству клиентов. После удаления аренды адресов DHCP-клиенты обновят аренду и получат новые адреса или опции.

    Настройка дополнительных опций DHCP


    Опции DHCP можно назначить на уровне сервера, области и резервирования.
    Опции, определяемые на уровне сервера, наследуются всеми областями, отконфигурированными на сервере. Опции, определяемые на уровне области, наследуются при аренде и резервировании всех адресов в области. Опции, определенные на уровне резервирования, применяются лишь к этому резервированию.
    Опции DHCP на всех трех уровнях идентичны.
    На уровне сервера: для этого ПКМ папку Параметры сервера в консоли DHCP и примените команду Настроить параметры (Configure Options).
    В то время как Мастер добавления ролей позволяет определить небольшое количество опций сервера и области, полный диапазон опций DHCP можно отконфигурировать в консоли DHCP. Чтобы просмотреть встроенные опции, которые можно конфигурировать, найдите и консоли DHCP папку DHСР\узел_сервера\IРv4\Область\Параметры области. ПКМ папку Параметры области (Scope Options) и примените команду Настроить параметры. Затем в открывшемся диалоговом окне Параметры: область выберите опцию для области.

    Классы опций DHCP


    Класс опций — клиентская категория, позволяющая DHCP-серверу назначать опции только отдельным клиентам в области. При добавлении класса опций на сервер клиенты этого класса могут получать такие опции.
    Существует 2 типа классов опций.
    1. Классы поставщика используются для назначения опций поставщика DHCP-клиентам, идентифицируемым но типу поставщика. Например, клиентов можно конфигурировать как клиентов Windows 2000, чтобы включать и отключать NetBIOS. Класс поставщика обычно не конфигурируется, поскольку идентификация класса встроена в программное обеспечение клиента. Администратору, как правило, не нужно заполнять класс, включая параметр на стороне клиента.
    2. Классы пользователя применяются для назначения опций любому набору клиентов, идентифицируемых как требующих аналогичной конфигурации опций DHCP. Эта классы можно конфигурировать. Администраторы могут создавать новые классы пользователей и заполнять их, конфигурируя параметр на стороне клиента.
    Класс пользователя по умолчанию (Default User) представляет собой класс, которому принадлежат все DHCP-клиенты и для которого по умолчанию создаются все опции. Чтобы применить опцию для всех DHCP-клиентов независимо от их классовой идентификации, оставьте эту опцию отконфигурированной для класса пользователя по умолчанию. Однако эта отдельная опция, назначаемая через класс пользователя по умолчанию, может быть заменена опциями, определяемыми в других классах. Например, если класс пользователя по умолчанию определяет адреса WINS-сервера и DNS-сервера, а настраиваемый класс пользователя определяет лишь WINS-сервер, клиент с настраиваемым классом пользователя получит адрес WINS-сервера из набора адресов WINS и DNS-серверов класса пользователя по умолчанию.
    Чтобы опции вступили в силу при уже назначенных адресах нужно удалить арендованные адреса. Тогда DHCP-клиенты обновят аренду и получат адрес основного шлюза.
    Можно запустить команды Ipconfig /release и Ipconfig /renew на каждом клиентском компьютере, чтобы все клиенты получили адреса с нового DHCP-сервера.

    Реализация классов пользователя


    Чтобы реализовать класс пользователя, нужно сначала определить этот класс на DHCP-сервере, назначив для него ID и набор опций. Когда эти клиенты осуществят коммуникации с помощью DHCP-серверов, они сообщат ID класса и унаследуют его опции с опциями класса пользователя по умолчанию. Если ID класса отсутствует, клиент наследует лишь опции класса пользователя по умолчанию.
    Для того чтобы создать настраиваемый или новый класс пользователя, в консоли DHCP ПКМ значок IPv4 и примените команду Определить классы пользователей. Откроется диалоговое окно Классы пользователей DHCP. В этом окне предварительно определены 3 класса пользователей.
    Помимо этих трех существует неявный Класс пользователя по умолчанию (Default User Class ), к которому по умолчанию принадлежат все клиенты.
    На экране отобразится диалоговое окно Новый класс, показанное на рис. 4-21. В этом диалоговом окне нужно лишь указать класс и ID-код для класса по своему усмотрению. (Для определения строки кода следует использовать поле ASCII .)
    И, наконец, класс нужно заполнить. Чтобы компьютеры наследовали опции нового класса, им нужно назначить код класса, соответствующий коду, определенному для нового класса на DHCP-сервере. Это можно сделать с помощью команды Ipconfig /setclassid на каждом компьютере.
    Например, чтобы отконфигурировать подключение по локальной сети с кодом класса SamplelD, в командную строку введите:
    ipconfig /setclassid "local area connection" SamplelD
    После запуска этой команды на клиентском компьютере DHCP клиент наследует опции, определенные для этого класса, помимо опций, определенных для класса пользователя по умолчанию. При конфликте двух опций, например при определении основного шлюза, опция, указанная для более специфического класса, имеет приоритет по сравнению с опцией для класса пользователя по умолчанию.

    DHCP на компьютере с ядром сервера WServer


    Установите роль DHCP-сервера:
    start /w ocsetup DHCPServerCore
    Она не запускает автоматически службу DHCP-сервер и не конфигурирует эту службу для автоматического запуска по умолчанию. Чтобы в первый раз запустить эту службу, введите следующую команду:
    net start dhcpserver
    Чтобы настроить автоматический запуск службы DHCP (не забудьте поставить пробел после знака равенства):
    sc config dhcpserver start= auto
    Добавить области и настроить сервер можно, подключившись к серверу с консоли DHCP компьютера, на котором установлена полная версия WServer.
    В качестве альтернативы можно также создать и настроить области на самом компьютере с ядром сервера, используя утилиту Netsh командной строки.
    Чтобы отконфигурировать компьютер с ядром сервера как DHCP-клиента для IPv4, введите следующую команду, где local area connection — это имя сетевого подключения:
    netsh interface ipv4 set address "local area connection" dhcp
    Чтобы сервер получал адрес DNS-сервера посредством службы DHCP, введите следующую команду:
    netsh interface ipv4 set dnsserver "local area connection" dhcp
    Отметим, что две последние команды нужно выполнять только в том случае, если был изменен параметр по умолчанию. В установку ядра сервера WServer, как и во все версии Windows, по умолчанию включена полная версия DHCP-клиента.
    servermanagercmd - install dhсp
    Эту команду используют на компьютере с полной установкой WServer для добавления роли DHCP-сервер. Ее нельзя использовать на машине с ядром WServer.

    Подключение к сетям


    Слияние компаний


    В случае слияния двух компаний нужно объединять их сети. Если эти компании используют один и тот же диапазон частных IP-адресов, одна из них должна сменить адреса в сети. Смена сетевых адресов — очень кропотливая задача: понадобится обновлять DHCP-серверы, записи DNS, серверы со статическими адресами и клиентские параметры IP. Хуже всего то, что эту работу нужно выполнять в нерабочее время — то есть вам придется в течение нескольких ночей менять параметры IP и проводить полное тестирование.
    Чтобы свести к минимуму вероятность конфликта IP-адресов, создайте случайные сети из диапазонов частных адресов. Например, вероятность использования сети 10.252.83.0/24 меньше, чем сети 192.168.1.0/24.

    Настройка NAT


    В WServer включены две службы NAT.
    1. Общий доступ к подключению к Интернету (Internet Connection Sharing, ICS) Изначально предназначена для домашних и небольших офисных сетей. Конфигурацию ISC можно настроить несколькими щелчками мыши, однако опции конфигурации чрезвычайно ограничены.
    2. Службы маршрутизации и удаленного доступа.
    После включения ICS автоматически будет включена служба DHCP, которая назначает клиентам IP-адреса в диапазоне 192.168.0.0/24. Эта служба DHCP несовместима ни с ролью DHCP-сервер, ни с агентом-ретранслятором DHCP (DHCP relay agent) служб маршрутизации и удаленного доступа.
    ПКМ сетевой интерфейс, который подключен к Интернету, и примените команду Свойства. Если вы хотите разрешить пользователям в Интернете доступ ко всем серверам интрасети (например, к веб-серверу или серверу электронной почты с частным IP-адресом), щелкните кнопку Настройка. Для каждой внутренней службы выполните следующие действия.
    1. Если служба имеется в списке Службы, установите флажок напротив нее в списке. В диалоговом окне Параметры службы введите внутреннее имя или IP-адрес сервера и щелкните ОК.
    2. Если службы нет в списке или используется нестандартный номер порта, щелкните кнопку Добавить, Введите описание службы и внутреннее имя или IP-адрес сервера. Затем в поля Номер внешнего порта службы ( External Port Number For This Service) и Номер внутреннего порта службы ( Internal Port Number For This Service) введите номер порта, используемый сервером. Выберите порт TCP или UDP и щелкните ОК.
    Разные номера внешнего и внутреннего портов нужно указывать только в том случае, если пользователи в Интернете задействуют для подключения к серверу другой номер порта. Например, веб-серверы, как правило, используют порт по умолчанию 80. Если ваш внутренний веб-сервер использует ТСР-порт 81, вы можете указать номер внешнего порта 80 и номер внутреннего порта 81.
    После этого пользователи в Интернете смогут получать доступ к серверу через порт 80 по умолчанию. Если в интрасети размещены два веб-сервера, каждый из которых использует ТСР-порт 80, вы можете назначить номер внешнего ТСР-порта 80 только одному из серверов. Для второго сервера нужно назначить другой номер внешнего порта, например 8080 , но оставить номер внутреннего порта 80.
    При включении ICS конфигурация сетевого интерфейса с доступом в Интернет не будет изменена, однако сетевому интерфейсу интрасети будет назначен IP-адрес 192.168.0.1. Кроме того, теперь компьютер будет отвечать на DHCP-запросы лишь на интерфейсе интрасети и назначать клиентам IP-адреса в диапазоне 192.168.0.0/24. Все клиенты получат адрес 192.168.0.1 (частный IP-адрес компьютера с общим доступом в Интернет) в качестве адреса основного шлюза и адреса основного DNS-сервера.
    Общий доступ можно также назначить для VPN или коммутируемого подключения. Таким образом, отдельный компьютер сможет подключаться к удаленной сети и пересылать трафик с других компьютеров в интрасети.

    NAT с помощью маршрутизации и удаленного доступа


    Использование RRAS вместо общего доступа в Интернет (ICS) обусловлено следующими причинами:
    • выполнение маршрутизации для множества внутренних сетей;
    • возможность использования другого DHCP-сервера, включая роль DHCP-сервер;
    • на компьютере с включенным компонентом Маршрутизация и удаленный доступ, включая агент-ретранслятор DHCP, нельзя использовать ICS.

    Для настройки NAT с помощью Служб маршрутизации и удаленного доступа на компьютере WServer выполните следующие действия.
    1. Отконфигурируйте NAT-сервер с такими двумя интерфейсами:
    a) интерфейс с публичным IP-адресом Интернета, подключенный к Интернету;
    б) интерфейс со статическим частным IP-адресом, подключенный к частной интрасети.
  • Добавьте роль Службы политики сети и доступа со службой ролей Службы маршрутизации и удаленного доступа (Routing And Remote Access Services, RRAS).
  • В Диспетчере сервера\Роли\Службы политики сети и доступа, ПКМ Маршрутизация и удаленный доступ и примените команду Отключить маршрутизацию и удаленный доступ (Disable Routing And Remote Access). (необязательно), а потом примените команду Настроить и включить маршрутизацию и удаленный доступ.
    4. На странице Конфигурация выберите опцию Преобразование сетевых адресов NAT.
    5. На странице Подключение к Интернету на основе NAT (NAT Internet Connection) выберите интерфейс, который подключает сервер к Интернету.
    Сервер готов пересылать пакеты из внутренней сети в Интернет.
    Во время включения NAT можно использовать любой DHCP-сервер. Как правило, в случае использования компьютера WServer в качестве DHCP-сервера нужно добавить роль DHCP-сервер. Такая роль обеспечивает полнофункциональный DHCP-сервер.
    Преобразование NAT включает весьма ограниченный, но вполне функциональный DHCP-сервер, способный обеспечивать конфигурацию IP-адресов для DHCP-клиентов в отдельной подсети. Для настройки DHCP-сервера NAT выполните следующие действия.
    1. В диспетчере сервера откройте последовательно контейнеры Роли\Службы политики сети и доступа\Маршрутизация и удаленный дocтyп\IPv4, ПКМ папку Преобразование сетевых адресов (NAT) и примените команду Свойства.
    2. На вкладке Назначение адресов (Address Assignment) установите флажок Назначать IP-адреса с помощью DHCP-распределителя (Automatically Assign IP Addresses By Using The DHCP Allocator).
    3. Введите адрес частной сети и маску подсети.
    4. Чтобы исключить конкретные адреса, статически назначенные существующим серверам (не частные IP-адреса, назначаемые NAT), щелкните кнопку Исключить и в открывшемся диалоговом окне Исключение зарезервированных адресов ( Exclude Reserved Addresses) перечислите адреса, которые не будут назначаться DHCP-клиентам.
    Статистические данные DHCP-сервера можно просмотреть, открыв последовательно контейнеры Роли\Службы политики сети и доступа\Маршрутизация и удаленный дocтyп, щелкнув правой кнопкой мыши папку Преобразование сетевых адресов (NAT) и применив команду Отобразить сведения DHCP-распределителя (Show DHCP Allocator Information).
    Чтобы подключаться к Интернету, клиентам NAT нужно разрешать запросы DNS. Эту функцию можно обеспечить с помощью роли DNS-сервер.
    Для небольших сетей, не требующих DNS-сервера, NAT можно конфигурировать для пересылки запросов DNS на DNS-сервер, настроенный на NAT-cepвере. Как правило, им является DNS-сервер провайдера Интернета. Для настройки пересылки запросов DNS выполните следующие действия.
    1. Роли\Службы политики сети и доступа\Маршрутизация и удаленный доступ\IРv4, ПКМ папку Преобразование сетевых адресов (NAT) и примените команду Свойства.
    2. На вкладке Разрешение имен в адреса установите флажок Для клиентов, использующих службу DNS (Clients Using DNS).
    3. Если для сетевого доступа NAT-сервер должен использовать VPN или телефонное подключение, установите флажок Подключаться при этом к публичной сети (Connect To The Public Network When A Name Needs To Be Resolved), а затем выберите соответствующий интерфейс вызова по требованию.
    Статистические данные DNS-сервера можно просмотреть, открыв Роли\Службы политики сети и доступа\Маршрутизация и удаленный доступ\IPv4, ПКМ папку Преобразование сетевых адресов и применив команду Отобразить сведения о DNS-прокси (Show DHCP Allocator Information).
    Сервер NAT часто конфигурируется как DNS-сервер.
    Для компьютеров в той же локальной сети LAN, к которой подключен интерфейс интрасети NAT-сервера, назначьте основному шлюзу IP-адрес интрасети NAT-сервера (и DNS, если DHCP не работает).
    По умолчанию компонент NAT Служб маршрутизации и удаленного доступа записывает ошибки NAT в журнал событий Система. Для всех событий NAT указан источник SharedAccess_NAT.
    Потоковое видео часто использует протокол UDP, который подвержен ошибкам при работе с NAT-устройством. Но подключения потокового видео, использующие TCP, должны работать всегда. По этой причине большинство протоколов потокового мультимедиа поддерживают UDP (для обеспечения производительности) и TCP (для совместимости с NAT).
    В условиях AD может возникнет проблема разрешения локального домена, т.к. запрос на его разрешение будет уходить в Интернет.

    Беспроводные сети


    Добавление беспроводных сетей — дело рискованное. Однако, следуя приведенным рекомендациям, этот риск можно минимизировать.
    1) Создание универсальной глобальной группы пользователей и компьютеров с беспроводным доступом в Active Directory. Вы можете назначить доступ для универсальной глобальной группы и предоставить компьютерам и пользователям доступ к беспроводной сети, добавив их в эту группу.
    2) Раньше в беспроводных сетях многие пользователи отключали широковещание SSID , думая, что таким образом смогут обеспечить защиту сети. При отключении широковещания SSID пользователи не смогут подключаться к беспроводной сети без настройки вручную. Однако хакеры могут без всякого труда подключаться к беспроводным сетям, в которых не выполняется широковещание SSID. Кроме того, при настройке XP и более ранних версий Windows для подключения к беспроводным сетям, выполняющим широковещание SSID, эти компьютеры могут транслировать личные данные, перехватываемые хакерами.
    3) Требование строгих паролей при использовании метода проверки подлинности Microsoft: Защищенный пароль (Microsoft: Secured Password) В этой технологии проверка подлинности выполняется с использованием стандартных учетных данных, поэтому пользователи должны применять строгий пароль.
    4) Проверка подлинности компьютеров и пользователей Если вы не можете поддерживать проверку подлинности компьютера, включите Единую регистрацию входа для проверки подлинности пользователей.
    Беспроводные клиенты Windows поддерживают все распространенные стандарты беспроводных сетей.

    WPA-EAP


    Компьютер WServer можно использовать для проверки подлинности беспроводных пользователей, настроив его как RADIUS -сервер и отконфигурировав точки беспроводного доступа (RADIUS-клиенты) для пересылки запросов проверки подлинности на RADIUS-сервер.
    Служба NPS обеспечивает проверку подлинности RADIUS на серверах Windows. NPS-сервер может передавать запросы проверки подлинности на контроллер домена, позволяя защищенным беспроводным сетям WPA-EAP выполнять проверку подлинности контроллеров домена без ввода ключа пользователями. Режим WPA-EAP обеспечивает очень гибкую проверку подлинности. WClient и WServer позволяют пользователям подключаться к защищенной производственной сети WPA-Enterprise с помощью смарт-карты.
    Самый простой способ развертывания WPA-EAP состоит в использовании PKI для развертывания сертификатов на RADUIS-сервере и всех беспроводных клиентских компьютерах.
    Чтобы создать инфраструктуру открытых ключей PKI и включить автоматическую подачу заявок, чтобы клиентские компьютеры располагали необходимыми сертификатами для поддержки проверки подлинности WPA-EAP, выполните следующие действия:
  • Установите роль CS AD. Параметры по умолчанию предназначены для тестовой среды.
  • GPO\Конфигурация компьютера\Политика\Конфигурация Windows\Пapaмeтpы безопасности\Политика открытого ключа.
  • В панели сведений ПКМ Клиент служб сертификации: автоматическая подача заявок ( Certificate Services Client - Auto-Enrollment)\Свойства.
  • Выберите в раскрывающемся списке Модель конфигурации опцию Включено. При желании вы можете установить флажки других опций, связанных с автоматической подачей заявок.
  • В диалоговом окне Свойства: Certificate Services Client - Auto-Enrollment Properties щелкните раскрывающийся список Модель конфигурации и выберите параметр Включено. Установите оба флажка и щелкните ОК.
  • В панели сведений ПКМ объект Параметры подтверждения пути сертификата (Certificate Path Validation Settings) и примените команду Свойства.
  • В диалоговом окне Свойства: Параметры подтверждения пути сертификата (Certificate Path Validation Properties) установите флажок Определить параметры политики ( Define These Policy Settings) и щелкните ОК.

    Проверка подлинности беспроводных сетей с помощью WServer


    Беспроводные клиенты Windows могут выполнять проверку подлинности с помощью следующих режимов:
    Только компьютер. Windows выполняет проверку подлинности беспроводных подключений перед отображением окна входа в систему. Система Windows может затем подключиться к контроллерам домена AD и другим сетевым ресурсам перед входом пользователя.
    Только пользователь. Windows выполняет проверку подлинности беспроводных подключений после входа пользователя в систему.
    Системы WClient и WServer поддерживают технологию единого входа Singe Sign On (SSO) (технология, при использовании которой пользователь переходит из одного раздела портала в другой без повторной аутентификации), которая позволяет администраторам конфигурировать проверку подлинности пользователей в беспроводной сети перед входом пользователя в систему. Таким образом, устранены недостатки проверки подлинности только для пользователя. Чтобы включить SSO, используйте расширение групповой политики Политики беспроводной сети IEEE 802.11 или команду netsh wlan с соответствующими параметрами.
    Если не применяется технология SSO, проверка подлинности пользователей не будет выполняться на домене до подключения к беспроводной сети. Поэтому пользователи могут выполнить вход только в случае локального кэширования учетных данных домена. Кроме того, операции входа в домен (включая обработку обновлений групповой политики и сценарии входа) не будут выполняться, а в журналы событий Windows будут записываться сообщения об ошибках.
    Компьютер и пользователь. Windows выполняет проверку подлинности перед регистрацией учетных данных компьютера. После регистрации учетных данных система Windows запрашивает учетные данные пользователя.
    В средах, использующих виртуальные локальные сети, доступ компьютера к сетевым ресурсам может быть ограничен, пока пользователь не предоставит учетные данные (например, компьютер может получать доступ лишь к контроллерам домена Active Directory).

    RADIUS-сервер для беспроводных сетей


    Разверните точки беспроводного доступа и настройте на них перенаправление запросов проверки подлинности на RADIUS-сервер.
    Сообщения проверки подлинности RADIUS используют UDP-порт 1812, а учетные сообщения RADIUS используют UDP-порт 1813.
    Установите службу ролей NPS и Службы маршрутизации и удаленного доступа (флажки Служба удаленного доступа (Remote Access Service) и Маршутизация (Routing) будут установлены автоматически).
    1. Роли\Службы политики сети и доступа\NPS
    2. В панели сведений в области Стандартная конфигурация выберите RADIUS-сервер для беспроводных или кабельных подключений 802.1X (RADIUS Server For 802.1X Wireless Or Wired Connections). Затем щелкните ссылку Настройка 802.1X
    3. На странице Введите тип подключений 802.1X выберите опцию Безопасные беспроводные подключения
    4. На странице Укажите коммутаторы 802.1X ( Specify 802.1X Switches) отконфигурируйте точки беспроводного доступа в качестве действительных клиентов RADIUS. Выполните следующие действия для каждой точки беспроводного доступа:
    а) В диалоговом окне Новый RADIUS-клиент введите в поле Понятное имя имя для идентификации точки беспроводного доступа. В поле Адрес введите имя узла или IP-адрес, идентифицирующий точку беспроводного доступа.
    б) В области Общий секрет (Shared Secret) выберите опцию Вручную и введите общий секрет. При желании вы можете автоматически создать сложный секрет, выбрав опцию Создать ( Generate ), а затем щелкнув еще одну появившуюся кнопку Создать. Запишите общий секрет на бумаге для дальнейшего использования.
    5. На странице Настройка метода проверки подлинности выберите в раскрывающемся списке Тип один из таких методов проверки подлинности.
    а) Microsoft: Защищенные ЕАР ( PEAP ). Чтобы можно было использовать данный метод проверки подлинности на RADUIS-сервере, нужно установить компьютерный сертификат, а также компьютерный или пользовательский сертификат на всех клиентских компьютерах беспроводной сети. Проверка подлинности РЕАР совместима с защитой сетевого доступа NAP сетей 802.1X.
    б) Microsoft: Смарт-карта или иной сертификат. По сути, эта технология проверки подлинности аналогична РЕАР. При выборе этого метода проверки подлинности беспроводные клиенты Windows предлагают пользователям подключить смарт-карту для установления связи с беспроводной сетью.
    в) Microsoft: Защищенный пароль (EAP-MSCHAP v2) (Microsoft: Secured Password). Этот метод проверки подлинности требует установки компьютерных сертификатов на всех RADIUS-серверах и доверия клиентских компьютеров центру сертификации, издавшему компьютерный сертификат для RADIUS-сервера. Клиенты проходят проверку подлинности с использованием доменных учетных данных.
    6. Укажите группу, которой хотите предоставить беспроводной доступ.
    7. На странице Настройка VLAN можно щелкнуть кнопку Настроить и указать параметры VLAN. Это требуется только в том случае, если нужно ограничить доступ беспроводных пользователей к конкретным сетевым ресурсам и сеть VLAN создается с использованием сетевой инфраструктуры.
    8. Роли\Службы политики сети и доступа\ПКМ объект NPC и примените команду Зарегистрировать сервер в Active Directory.
    Теперь с помощью диспетчера сервера проанализируйте конфигурацию новой политики.
    9. Разверните узел Службы политики сети и доступа\NPS\Политики\Сетевые политики. В панели сведений должно быть указано, что политика Безопасные беспроводные подключения включена, а ее параметру Права доступа (Access Type) назначено значение Разрешение доступа к узлу ( Grant Access).

    RADIUS-прокси


    Если вы используете RADIUS-серверы и нужно обеспечить уровень абстрагирования между точками доступа и RADIUS-серверами или пересылать запросы на разные RADIUS-серверы на основе конкретного критерия, вы можете отконфигурировать WServer как RADIUS-прокси (рис. 7-5).
    Рисунок 7-5. Пример архитектуры RADIUS-прокси
    Чаще всего RADIUS-прокси используется для пересылки запросов на конкретные RADIUS-серверы организации на основе области, идентифицируемой в запросе RADIUS. Таким образом, различные организации могут управлять своими RADIUS-серверами (и, соответственно, пользовательскими учетными записями, проверка подлинности которых выполняется на каждом RADIUS-сервере). Например, если организация содержит два домена, которые не доверяют друг другу, вы можете отконфигурировать точки беспроводного доступа (или VPN-серверы) для пересылки запросов на RADIUS-прокси. Затем RADIUS-прокси сможет определить домен, в который следует переслать запрос. RADIUS-прокси можно также использовать для распределения нагрузки среди RADIUS-серверов, чтобы в случае неспособности одного RADIUS-сервера обработать запрос он пересылался на другой сервер.
    Группы RADIUS-серверов могут состоять как из 1, так и из множества RADIUS-серверов (выполняющих проверку подлинности одних и тех же пользователей).
    Чтобы создать группу прокси-серверов RADIUS:
  • Добавьте роль Службы политики сети и доступа
  • Роли\Службы политики сети и доступа\NРS\Клиенты и серверы RADIUS, ПКМ объект Группы внешних RADIUS-серверов (Remote RADIUS Server Groups) и примените команду Новый документ. Откроется диалоговое окно Создать группу внешних RADIUS-серверов. Добавить. Откроется диалоговое окно Добавление RADIUS-сервера. На вкладке Адрес введите имя узла или IP-адрес RADIUS-сервера.
    3. На вкладке Проверка подлинности и учетные данные (Authentication/ Accounting ) введите общий секрет.
    4. На вкладке Балансировка нагрузки (Load Balancing) оставьте параметры по умолчанию, если вы распределяете нагрузку или все серверы получают одинаковое число запросов. Если же вы распределяете нагрузку среди серверов с различными мощностями, укажите соответствующие параметры в полях Приоритет ( Priority ) и Вес ( Weight ).
    Повторите шаги для каждой группы RADIUS-серверов.
    Затем создайте политику запросов подключений:
    1. Роли\Службы политики сети и доступа\NPS\Политики, ПКМ Политики запросов на подключения (Connection Request Policies) и примените команду Новый документ. Укажите имя политики запросов на подключение и тип подключения
    2. В списке выберите Тип сервера доступа к сети. Если ваш сервер доступа обеспечивает номер типа, выберите опцию Зависящие от поставщика (Vendor Specific) и введите этот номер.
    3. На странице Укажите условия (Specify Conditions) щелкните кнопку Добавить. Выберите условие, которое хотите использовать для определения группы RADIUS-серверов, принимающих запросы проверки подлинности.
    Чтобы определять группы на основе имени сферы, выберите условие Имя пользователя. Щелкните кнопку Добавить.
    4. Укажите дополнительные сведения, требуемые для выбранного условия, и щелкните кнопку ОК.
    5. На странице Укажите перенаправление запроса на подключение (Specify Connection Request Forwarding) установите флажок Направлять запросы учетных данных на группу внешних RADIUS-серверов. Затем выберите группу RADIUS-серверов в раскрывающемся списке.
    6. На странице Настройка параметров можно добавить правила переназначения существующих атрибутов или добавить атрибуты, которые могут отсутствовать в исходном запросе. Например, перед пересылкой запроса проверки подлинности на RADIUS-сервер можно изменить имя сферы запроса. Такой параметр является опциональным и требуется только в том случае, если исходный запрос RADIUS не соответствует требованиям конечного RADIUS-сервера.
    7. В Диспетчере сервера ПКМ новую политику и примените команду Вверх, чтобы поместить политику над политиками с более низким приоритетом (при необходимости).
    Повторите шаги 1-7, чтобы определить уникальный критерий, в соответствии с которым будет выполняться пересылка запросов в каждую группу RADIUS, после чего RADIUS-прокси будет готов к работе.

    Наблюдение за учетными данными RADIUS-серверов


  • Проще всего просматривать журнал событий Безопасность в оснастке Просмотр событий. Пример такого события продемонстрирован на рис. 7-6. В столбце Категория задачи для таких событий указана категория Сервер политики сети. Успешная проверка подлинности помечается ключевыми словами Проверка выполнена успешно ( Audit Success), а ошибка проверки подлинности помечается словами Сбой проверки (Audit Failure).
    Беспроводной клиент не может регистрировать подробные сведения об ошибках проверки подлинности, поскольку RADIUS не обеспечивает детальную информацию о причинах отказа в полномочиях.
    Рис. 7-6. Сбой проверки подлинности, записанный в журнал событий Безопасность
    2. Анализ файла журнала RADIUS. Файл журнала RADIUS можно редактировать, поскольку его формат совместим с программным обеспечением отчетности. Стандартный механизм проверки подлинности RADIUS обеспечивает стандартный файл журнала. По умолчанию журнал RADIUS (он также называется журналом IAS) хранится в папке %SystemRoot%\system32\LogFiles с именем файла IN.log. Выберите узел Службы политики сети и доступа\NPS\Учетные данные. По умолчанию WServer сохраняет файл журнала в папку %SystemRoot%\system32\LogFiles\.
    Как правило, непосредственный анализ файла журнала RADIUS не выполняется. Для анализа журналов RADIUS используется соответствующее программное обеспечение, включающее программы проверки безопасности и программное обеспечение учета данных проверки подлинности. Далее показаны первые несколько полей в формате файла журнала RADIUS (остальные поля зависят от используемой точки беспроводного доступа):
    Поле Описание
    Server name Имя компьютера, зарегистрированное на RADIUS-сервере
    Service Всегда содержит значение IAS
    Date Дата в формате MM/DD/YYYY
    Time Время в формате hh.mnv.ss
    3. Ведение журнала на сервере. Вы также можете подробно отслеживать учетные данные, в частности, для работы с группой поддержки Microsoft. Чтобы включить ведение журнала, запустите следующую команду:
    netsh ras set tr * en
    Сервер политики сети будет генерировать файл журнала %SystemRoot%\Tracing\IASNAP.log. Затем этот журнал можно переслать группе поддержки Microsoft для детального анализа.
    К СВЕДЕНИЮ Ведение журнала NAP
    Рио. 8-17. Сбой проверки работоспособности NAP
    Файлы журналов обеспечивают практически всю информацию, требуемую для проверки и устранения неполадок. Если нужна еще более подробная информация, прочитайте руководство «The Definitive Guide to NAP Logging», которое находится по адресу blogs.technet.com/wincat/ archive /2007/10/29/the-definitive-guide-to-nap-logging. aspx .

    Подключение к беспроводным сетям


    С WClient или WServer можно вручную подключаться к беспроводным сетям:
    1. Пуск\Подключение (Connect To).
    2. На странице мастера Подключиться к сети щелкните беспроводную сеть, к которой хотите подключиться, а затем — кнопку Подключиться.
    Если сеть не выполняет широковещание идентификатора SSID, щелкните ссылку Установка подключения или сети и следуйте инструкциям указания скрытого SSID.
    3. Щелкните Выбор дополнительной информации регистрации (Select Additional Log On Information). В диалоговом окне ввода учетных данных введите имя пользователя WirelessUser. Затем введите пароль для пользователя.
    4. После подключения клиентского компьютера к беспроводной сети щелкните кнопку Закрыть.
    5. В диалоговом окне Выберите сетевое размещение (Set Network Location) укажите тип сетевого профиля. В доменных средах лучше всего выбрать тип Работа. При необходимости укажите учетные данные администратора.
    Для автоматического подключения компьютеров к защищенным беспроводным сетям можно использовать параметры групповой политики.
    1. GPO\Конфигурация компьютера\Политика\Конфигурация Windows\Параметры безопасности, ПКМ Политики беспроводной сети (IEEE 802.11) и примените команду Создание новой политики WClient. В беспроводных сетях можно использовать политики XP и WClient.
    Политики WClient автоматически применяются к беспроводным клиентам WServer. Политики XP применяются к клиентам XP SP2 и WServer 2003. Если политики WClient нет, компьютеры WClient и WServer будут применять политику Windows XP.
    2. На вкладке Общие щелкните кнопку Добавить и выберите тип Инфраструктура. В этом диалоговом окне также можно конфигурировать нерегламентированные сети без точки доступа, хотя на предприятиях редко используются предварительно отконфигурированные сети без точки доступа.
    3. В диалоговом окне Свойства Нового профиля/вкладке Подключение введите в поле Имя профиля имя беспроводной сети. Затем в поле Сетевые имена (Network Name) введите код SSID и щелкните кнопку Добавить. Вы можете удалить Новый код SSID (NEWSSID SSID), созданный по умолчанию.
    4. В окне Свойства Новый профиль перейдите на вкладку Безопасность. Щелкните раскрывающийся список Проверка подлинности и выберите технологию беспроводного подключения и метод проверки подлинности для этого кода SSID (рис. 7-7).
    Рис. 7-7. Настройка параметров безопасности беспроводной сети
    с помощью групповой политики
    Щелкните кнопку Дополнительно. При желании установите флажок Включить единую регистрацию для сети.
    5. Вновь щелкните OK, чтобы вернуться к диалоговому окну Свойства: Новая политика беспроводной сети WClient (New WClient Wireless Network Policy Properties).

    Настройка точки беспроводного доступа


    Вы отконфигурируете точку беспроводного доступа для проверки подлинности WPA-EAP. Поскольку для настройки точек беспроводного доступа используются разные инструменты, приведенные далее инструкции могут изменяться в зависимости от используемого оборудования.
    1. Откройте административное средство, используемое для управления точкой беспроводного доступа. Часто таким инструментом служит веб-страница, которую можно открыть, набрав IP-адрес точки беспроводного доступа в адресной строке браузера.
    2. Отконфигурируйте точку беспроводного доступа с использованием SSID-кода сети Contoso.
    3. Укажите тип безопасности WPA-EAP (он может быть указан как WPA-предприятие) или WPA2-EAP
    4. Для RADIUS-сервера назначьте IP-адрес компьютера WServer.
    5. Укажите общий секрет, сгенерированный мастером Настройка 802.1X
    С помощью точек беспроводного доступа можно конфигурировать множество RADIUS-серверов.

    Настройка параметров групповой политики беспроводных сетей


    Настройте SSO, Microsoft: Защищенные ЕАР
    Перезагрузите компьютер и войдите в систему с помощью учетной записи WirelessUser2 (не входит в группу пользователей домёна, но входит в универсальную группу беспроводных пользователей). Компьютер автоматически подключится к беспроводной сети, используя проверку подлинности компьютера. Этот сетевой доступ позволил компьютеру подключиться к контроллеру домена и пройти проверку подлинности с помощью учетной записи даже несмотря на то, что эти учетные данные не были ранее кешированы.
    1. На машине Dcsrvl откройте Server Manager и объект Диагностика\Проомотр событий\Журналы Windows\Бeзоnacnocть
    2. Просмотрите последние события успешной проверки подлинности клиентского компьютера и пользовательской учетной записи.

    Подключение к удаленным сетям


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

    Коммутируемые подключения


    В случае коммутируемого подключения клиентский компьютер использует модем для соединения с сервером удаленного доступа по телефонной линии. Каждому клиенту требуется отдельная физическая линия связи с сервером.
    Ниже описаны преимущества коммутируемых подключений.
    1. Не требуется подключение к Интернету При коммутируемом соединении стандартная аналоговая телефонная линия служит для установления сетевого подключения непосредственно к внутренней сети. Это означает, что при использовании телефонных соединений внутренней сети не нужно отвечать на запросы проверки подлинности из Интернета. Внутреннюю сеть вообще ненужно подключать к Интернету - распространенное требование для сетей
    с высоким уровнем безопасности.
    2. Минимальные угрозы конфиденциальности. Хотя в коммутируемых подключениях отсутствует шифрование и трафик проходит через общественную телефонную сеть, многие специалисты по безопасности считают, что эта сеть обеспечивает более высокий уровень конфиденциальности, чем Интернет.
    3. Прогнозируемая производительность Коммутируемые подключения обеспечивают постоянный и прогнозируемый уровень быстродействия, поскольку подключение предназначено для одного клиента.
    4. Низкая пропускная способность Модемы для традиционных аналоговых телефонных линий технически обеспечивают полосу пропускания 56 Кбит/с, но реальное значение, как правило, составляет 20-25 Кбит/с. Эта полоса пропускания позволяет решать простые задачи, например просматривать Веб, но не обеспечивает потоковое аудио и видео. Цифровые телефонные линии, например цифровая сеть с интегрированными услугами ISDN (Integrated Services Digital Network), может обеспечить пропускную способность 128 Кбит/с, однако стоимость ее намного выше.

    VPN-подключения


    В Server 2000 появились следующие дополнительные возможности VPN:
    • Маршрутизация по запросу с возможностью маршрутизации протоколов IP и IPX по запрашиваемым или постоянным каналам глобальной сети (WAN), таким как аналоговые телефонные линии, сети ISDN или VPN-соединения, использующие РРТР или L2TP с IPSec.
    • Интеграция RRAS, обеспечивающая возможность интеграции брандмауэра с функциями RRAS и NAT.

    Эволюция RRAS в Server 2003 продолжилась за счет добавления улучшенных средств администрирования и управления, использующие утилиту командной строки Netsh.
    Двухточечный протокол (РРР) теперь поддерживает усиленную защиту с помощью защищенного расширяемого протокола аутентификации ( Protected Extensible Authentication Protocol — PEAP) с PEAP-MS- CHAP v2 и PEAP-TLS.
    Полная поддержка IPv6 наряду с поддержкой IPv4, причем они могут сосуществовать, совершенно не мешая друг другу.
    Существует пакет администратора диспетчера подключений (Connection Manager Administration Kit — СМАК).
    Выполнение подключений с помощью клиентов среды для диагностики сетевых соединений (Network Diagnostics Framework ), которая поддерживает базовые возможности диагностики Network Diagnostics Framework.
    Новые шифруемые VPN-соединения на основе L2TP/IPSec, которые теперь поддерживают стандарт AES (Advanced Encryption Standard — расширенный стандарт шифрования) с 128- и 256-битными ключами.
    Средство VPN Reconnect (Восстановление соединений VPN) позволяет пользователям прозрачно повторно подключаться к традиционным соединениям VPN, даже в условиях перемещения и изменяющихся сетей, что стало возможным благодаря реализации функции мобильности IKEv2 — MOBIKE.
    Для WServer переходная сеть — это всегда сеть, работающая по протоколу IP, куда входит и Интернет, и частная внутренняя IP-сеть компании.
    VPN-клиент — это компьютер, инициирующий VPN-подключение к VPN-серверу. Создавать VPN-соединение для удаленного доступа к Wserver могут клиенты Microsoft, функционирующие под управлением Windows NT 4.0, 9х,
    2000, XP, WClient.
    VPN-клиентами могут также быть любые клиенты РРТР или L2TP, разработанные не Microsoft и использующие IPSec.
    Сервер RRAS — это сервер WServer с установленной ролью NPAS (Network Policy and Access Services — службы сетевых политик и доступа) и службами роли RRAS. Такой сервер принимает VPN-подключения от VPN-клиентов. Имя или IP-адрес сервера RRAS должно быть преобразуемым и доступным через корпоративные брандмауэры. Это можно сделать либо подключив сетевой интерфейс к демилитаризованной зоне (DMZ),
    либо добавив в брандмауэр нужное правило доступа.
    Сервер сетевых политик (Network Policy Server — NPS) выполняет аутентификацию, авторизацию, аудит и учет VPN-клиентов. В системе NPS устанавливаются роли NPAS, а также служба роли NPS. Сервер NPS применяется для выполнения политик сетевого доступа, обеспечивающих работоспособность, аутентификацию и авторизацию клиентов. NPS работает в сочетании с технологией защиты сетевого доступа (Network Access Protection — NAP), которая обеспечивает управление, контроль и работоспособность клиентов. Система NPS предоставляет
    NAP политики, на основе которых производятся проверки. NPS также имеет множество шаблонов для крупномасштабного развертывания или идентичного конфигурирования множества серверов NPS.
    Должен быть сервер с установленной ролью AD CS и службами роли CA и Certification Authority Web Enrollment (Веб-развертывание центра сертификации). Для работы этих ролей необходимо, чтобы был установлен и ряд других ролей, например, Web Server (IIS) и File Services. WServer позволяет администраторам выпускать сертификаты для инфраструктуры VPN и управлять ими. То же самое можно сделать и с помощью сторонних СА
    наподобие VeriSign — тогда сервер не понадобится, но придется ежегодно вносить плату.
    Сертификаты совсем не обязательны для всех конфигураций инфраструктуры VPN, но они считаются лучшим способом защиты инфраструктуры VPN. Сервер сертификатов AD обязателен для развертывания DirectAccess.
    Сервер AD предоставляет полномочия доступа для пользователей VPN-клиентов.
    Системы WServer и WClient поддерживают 3 технологии VPN: PPTP , L2TP и SSTP. По умолчанию VPN-серверы WServer поддерживают все 3 технологии VPN одновременно, хотя их можно отключать по отдельности.
    Для протокола L2TP требуется, чтобы клиенты и серверы VPN использовали компьютерные сертификаты.
    В WServer события VPN-подключения записываются в журнал событий System. Источником этих событий является RemoteAccess. В журнале регистрируются все ошибки проверки подлинности.

    Настройка VPN-сервера


    Во-первых, отконфигурируйте VPN-сервер хотя бы с двумя сетевыми адаптерами. Подключите один сетевой адаптер к общественному Интернету. Ему следует назначить статический IP-адрес. Второй сетевой адаптер подключите к интрасети. Этот интерфейс будет пересылать трафик между VPN и сетевыми ресурсами. Потребуется включить на сервере маршрутизацию удаленного доступа по запросу, выполнив следующие действия:
    1. Роли\Службы политики сети и доступа, ПКМ Маршрутизация и удаленный доступ и примените команду Настроить и включить маршрутизацию и удаленный доступ
    2. На странице Конфигурация выберите опцию Удаленный доступ
    3. На странице Удаленный доступ установите флажок Доступ к VPN
    4. На странице VPN Connection выберите сетевой адаптер, который подключает сервер к Интернету
    5. На странице Выбор сетевого соединения (Network Selection ) выберите интерфейс, подключающий сервер к внутренней сети.
    6. На странице Назначение IP-адресов (IP Address Assignment) выберите опцию Автоматически, если в сети уже есть DHCP-сервер. Если же вы хотите, чтобы сервер удаленного доступа распределял IP-адреса из диапазона, еще не назначенного DHCP-серверу, выберите опцию Из диапазона заданных адресов. Если откроется страница Назначение диапазонов IP-адресов, щелкните кнопку Создать, введите диапазон IP-адресов и щелкните ОК. Добавьте необходимые диапазоны адресов.
    7. На странице Управление несколькими серверами удаленного доступа (Managing Multiple Remote Access Servers) следует выбрать метод проверки подлинности пользователей удаленного доступа. Если вы используете отдельный RADIUS-сервер, выберите опцию Да, настроить данный сервер для работы с RADIUS-сервером. Если же для проверки подлинности вы используете службу Маршрутизация и удаленный доступ, в частности для проверки подлинности в домене AD, выберите опцию Нет использовать службу маршрутизации и удаленного доступа для проверки подлинности запросов на подключение (No, Use Routing And Remote Access To Authenticate Connection Requests).
    Теперь можете открыть узел Роли\Службы политики сети и доступа\Маршрутизация и удаленный доступ\Порты и просмотреть список VPN-портов, которые принимают входящие VPN-подключения. По умолчанию WServer создает 128 портов для каждой из трех технологий VPN. Каждому VPN-подключению требуется отдельный порт. Для добавления и удаления портов ПКМ узел Порты и примените команду Свойства. В диалоговом окне Свойства: Порты выберите тип порта, который хотите изменить, а затем щелкните кнопку Настроить.
    При настройке компьютера в качестве VPN-сервера WServer автоматически конфигурирует агент-ретранслятор DHCP. Если во время работы мастера установки сервера маршрутизации и удаленного доступа VPN-сервер был DHCP-клиентом, мастер автоматически отконфигурирует агент-ретранслятор DHCP с IPv4-адресом DHCP-сервера. Чтобы потом изменить IP-адрес, выберите узел Роли\Службы политики сети и доступа\Маршрутизация и удаленный Доступ\IPv4\Агент DHCP-ретрансляции (DHCP Relay Agent) и отредактируйте его свойства.

    Настройка пакетных фильтров VPN


    Настроив VPN-сервер для приема входящих VPN-подключений, вы не сможете проверить связь с VPN-сервером с помощью команды ping на интерфейсе подключения к Интернету, поскольку мастер установки сервера маршрутизации и удаленного доступа создает фильтры, блокирующие весь входящий трафик, за исключением входящих VPN-подключений. Если вы используете на компьютере с VPN-сервером веб-сервер, сервер электронной почты или другие службы, придется вручную добавить пакетные фильтры и исключения для брандмауэра Windows, чтобы разрешить трафик для других служб. Для изменения фильтров входа выполните следующие действия:
    1. Роли\Службы политики сети и доступа\Маршрутизация и удаленный дocтyп\IPv4\Oбщиe для IРv4-трафика или соответствующий узел в папке IPv6 для IРv6-трафика.
    2. В панели сведений ПКМ интерфейс подключения к Интернету и примените команду Свойства.
    3. На вкладке Общие щелкните кнопку Фильтры входа (Inbound Filters )/Фильтры выхода (Outbound Filters) и отконфигурируйте фильтрацию исходящих пакетов.

    Настройка VPN-клиента


    В среде AD для этого нужно открыть свойства пользователя, перейти на вкладку Входящие звонки ( Dial -Up) и установить флажок Разрешить доступ. Чтобы подключить клиентский компьютер к VPN-серверу, выполните следующие действия.
    1. На клиентском компьютере щелкните кнопку Пуск\Connect To. Запустится мастер подключения к сети.
    2. На странице Подключение к сети щелкните ссылку Установка подключения или сети (Set Up A Connection Or Network).
    3. На странице Выберите вариант подключения ( Choose A Connection Option ) выберите вариант Подключение к рабочему месту (Connect To A Workspace) и щелкните кнопку Далее.
    4. Если откроется страница Использовать имеющееся подключение выберите опцию Нет, создать новое подключение и щелкните кнопку Далее.
    5. На странице Как выполнить подключение (How Do You Want To Connect) выберите опцию Использовать мое подключение к Интернету (VPN).
    6. На странице Введите адрес Интернета для подключения (Type The Internet Address To Connect To) введите IP-адрес сетевого адаптера VPN-сервера, который подключен к внутренней сети. Затем щелкните кнопку Next.
    7. На странице Введите имя пользователя и пароль (Type Your User Name And Password) введите имя пользователя, пароль и имя домена. Установите флажок Запомнить этот пароль. Затем щелкните кнопку Подключить (Connect).
    8. После подключения щелкните кнопку Close .
    9. На странице Выберите сетевое размещение (Set Network Location) укажите тип сетевого профиля для VPN. Обычно назначают тип Work .
    10. В окне подтверждения щелкните кнопку Close.
    Теперь для подключения к VPN щелкните кнопку Пуск\Подключение (Connect To) — откроется мастер подключения к сети. Выберите созданное VPN-подключение и щелкните кнопку Подключиться.

    Аутентификация для системы RRAS


    WServer может аутентифицировать пользователя, подключающегося через удаленный доступ, с помощью
    различных РРР-протоколов аутентификации:
    1. протокол аутентификации с помощью паролей (Password Authentication Protocol — PAP);
    2. протокол аутентификации с предварительным согласованием вызова CHAP;
    3. протокол аутентификации с предварительным согласованием вызова Microsoft (Microsoft Challenge Handshake Authentication Protocol — MS-CHAP); MS-CHAP v2;
    4. расширяемый протокол аутентификации (Extensible Authentication Protocol — EAP);
    5. PEAP.
    ЕАР и РЕАР созданы для применения с инфраструктурой сертификатов, использующей сертификаты пользователей или смарт-карты.
    С помощью ЕАР клиент VPN отправляет на аутентификацию свой сертификат пользователя, а сервер VPN посылает на аутентификацию сертификат компьютера. Это наиболее надежный метод аутентификации, поскольку в нем не задействованы пароли. Могут использоваться и сторонние СА, если сертификат в справочнике компьютеров сервера IAS
    (Internet Authentication Service — служба Интернет-аутентификации) содержит назначение сертификата аутентификации сервера (Server Authentication certificate purpose ), известное также как использование сертификата (certificate usage ) или политика выпуска сертификатов (certificate issuance policy). Назначение сертификата определяется с помощью идентификатора объекта (Object Identifier — OID). Если OID для аутентификации сервера выглядит как 1.3.6.1.5.5.7.3.1, то сертификат пользователя, установленный на клиенте удаленного доступа Windows, должен содержать назначение сертификата аутентификации клиента (OID 1.3.6.1.5.5.7.3.2).
    Протокол РЕАР сам по себе не определяет метод аутентификации, а лишь обеспечивает защиту ЕАР, создавая шифруемый канал между клиентом и сервером. То есть он просто
    усиливает защиту поверх ЕАР. Протокол РЕАР можно даже использовать с MS-CHAP v2 для повышения безопасности протокола аутентификации с помощью паролей.

    Протоколы аутентификации для соединений РРТР


    Для соединений РРТР только 4 протокола аутентификации (MS-CHAP, MS-CHAP v2, ЕАР и РЕАР) обеспечивают механизм генерации одинаковых ключей шифрования и на VPN-клиенте, и на VPN-сервере. Сквозное шифрование Microsoft (Microsoft Point-to-Point Encryption — MPPE) использует этот ключ для шифрования всех данных РРТР, передаваемых по VPN-соединению.
    MS-CHAP и MS-CHAP v2 являются протоколами аутентификации,
    использующими пароли. В отсутствие сервера центра сертификации или смарт-карт настоятельно рекомендуется использовать MS-CHAP v2, так как он предоставляет более надежный протокол аутентификации, чем MS-CHAP. Протокол MS-CHAP v2 может также выполнять взаимную аутентификацию, позволяющую VPN-серверу аутентифицировать VPN-клиент, а VPN-клиенту аутентифицировать VPN-сервер.
    Если нужно применять протокол аутентификации, использующий пароли, то лучше устанавливать надежные пароли (длиннее восьми символов), содержащие случайное сочетание букв верхнего и нижнего регистра, цифр и знаков пунктуации.

    Протоколы аутентификации для соединений L2TP/IPSec


    Для соединений L2TP/IPSec можно применять любой прокол аутентификации, поскольку аутентификация производится после установления безопасного соединения между VPN-клиентом и VPN-сервером, называемого сопоставлением безопасности (Security
    Association — SA) IPSec. Для обеспечения надежной аутентификации пользователей рекомендуется использовать строгий протокол наподобие MS-CHAP v2, ЕАР или РЕАР.
    В WServer соединения L2TP не шифруют РРР с помощью сквозного шифрования Microsoft (Microsoft Point-to-Point Encryption — MPPE). Вместо этого шифрование обеспечивается с помощью заголовка и хвоста ESP средства IPSec.

    Выбор наилучшего протокола аутентификации


    Применение протокола аутентификации ЕАР или РЕАР для соединений РРТР, L2TP и SSTP настоятельно рекомендуется при выполнении следующих условий в организации. Если используются смарт-карты или существует инфраструктура сертификатов, выпускающая сертификаты пользователей, то наиболее безопасным выбором является ЕАР. Обратите внимание, что ЕАР поддерживается только VPN-клиентами, работающими под управлением Windows ХР, Windows 2000 client, WClient, Windows 7, Windows 2000 Server, Server 2003, Server 2008 и R2.
    Протокол РЕАР с EAP-MS-CHAP v2 применяется для облегчения развертывания.
    В такой конфигурации сертификаты нужны только для инфраструктуры VPN-сервера, но не для клиентов. Однако для усиления защиты ключи генерируются с помощью протокола защиты транспортного уровня (Transport Level Security — TLS) с
    взаимной аутентификацией.
    Если нужно применять протокол аутентификации, использующий пароли, используйте MS-CHAP v2 и групповую политику надежных паролей. Хотя MS-CHAP v2 не является столь же надежным протоколом безопасности, как РЕАР или ЕАР, он поддерживается компьютерами, работающими под управлением Server 2008, Server 2008 R2, Server 2003, 2000 Server, WClient, XP, 2000 client.

    Протоколы VPN


    Для установления туннеля и клиент, и сервер этого туннеля должны использовать одинаковый протокол туннелирования.
    Рабочие станции, которые являются VPN-клиентами и функционируют под управлением WClient, XP и 2000, и серверные компьютеры по умолчанию поддерживают L2TP/IPSec и РРТР.
    При использовании РРТР шифрование данных начинается после завершения процесса подключения РРР, что означает использование аутентификации РРР. При L2TP/IPSec шифрование данных начинается до процесса соединения РРР посредством согласования сопоставлений безопасности IPSec. В SSTP сеанс шифруется посредством SSL, перед началом аутентификации. В DirectAccess коммуникации шифруются прозрачно перед началом пересылки данных пользователем.
    Во-вторых, соединения РРТР используют МРРЕ — потоковый шифр, основанный на алгоритме шифрования Rivest-Shamir-Adleman (RSA) RC-4, и 40-, 56- и 128-битные ключи шифрования. Потоковые шифры кодируют данные в виде потока битов. Соединения L2TP/IPSec применяют Data Encryption Standard (DES) — блочный шифр, кодирующий данные дискретными блоками (64-битными блоками в случае DES). SSTP использует SSL с RC4 или AES. DirectAccess применяет 3DES или AES.
    И, наконец, соединения РРТР требуют только аутентификации уровня пользователя через протокол аутентификации, основанный на РРР. Соединения L2TP/IPSec требуют той же аутентификации уровня пользователя, что и аутентификация уровня компьютера, с использованием сертификатов компьютера. В отличие от этого, SSTP и DirectAccess требуют только сертификатов уровня компьютера для серверов VPN.
    В табл. 24.2 приведено сравнение некоторых характеристик трех протоколов туннелирования:
    Характеристика
    РРТР
    L2TP/IPSec
    SSTP
    Инкапсуляция
    GRE
    L2TP поверх UDP
    SSTP поверх TCP
    Шифрование
    Двухточечное шифрование
    Microsoft (MPPE с RC4
    IPSec ESP с тройным DES
    (3DES) или улучшенным стандартом шифрования (AES)
    SSL с RC4 или AES
    Протокол поддержки туннеля
    PPTP
    L2TP
    SSTP
    Когда выполняется аутентификация пользователя
    Перед началом шифрования
    После создания сеанса IPSec
    Требуемые сертификаты
    Никакие
    Сертификаты компьютеров на
    VPN-клиенте и VPN-сервере
    Сертификат ком-
    пьютера на VPN-
    сервере и сертифи-
    кат корневого СА на VPN-клиенте
    Клиент
    Windows 9х и выше
    Windows 2000 и выше
    Server 2008,
    ХР SP3 и
    WClient SP1

    Туннелирование внутри сетевой среды WServer


    Для технологии туннелирования уровня 2 (РРТР, L2TP и SSTP) туннель похож на сеанс; оба конца туннеля должны принять туннель и обменяться переменными конфигурации наподобие назначения адресов или параметров шифрования и сжатия. В большинстве случаев данные, пересылаемые по туннелям, посылаются с помощью протокола передачи дейтаграмм. В качестве механизма управления туннелем используется протокол поддержки туннеля.
    Технологии туннелирования уровня 3 обычно предполагают, что все конфигурационные параметры определены заранее, часто вручную. Для этих протоколов этап поддержки туннеля может отсутствовать. Однако для протоколов уровня 2 (РРТР, L2TP и SSTP)
    туннель нужно создавать, сопровождать и затем отключать. После установления туннеля можно передавать туннелируемые данные. Клиент или сервер туннеля использует для подготовки данных к передаче протокол пересылки данных по туннелю. Например, как показано на рис. 24.4, если туннельный клиент посылает информацию туннельному серверу, то туннельный клиент вначале добавляет к полезной загрузки заголовок протокола передачи данных по туннелю. Туннельный сервер принимает пакеты, удаляет заголовок протокола передачи данных по туннелю и ретранслирует содержащуюся в пакетах информацию в сеть назначения. Информация, посылаемая от туннельного сервера туннельному клиенту, обрабатывается аналогично.

    SSTP


    Впервые представленный в WServer 2008, новый протокол туннелирования защищенных сокетов (Secure Socket Tunneling Protocol — SSTP) был специально разработан для обхода всех сложностей, связанных с установкой VPN-туннелей через корпоративные брандмауэры, которые блокируют многие порты и протоколы, применяемые РРТР и L2TP.
    Туннель SSTP использует протокол HTTP по SSL (HTTPS), который широко поддерживается для защиты веб-трафика. Для соединений в SSTP применяется порт 443.
    SSTP для обеспечения прозрачной связи через брандмауэры, NAT и прокси-серверы.
    Заголовок SSTP, заголовок РРР и исходный пакет, шифруется с помощью сеанса SSL. И, наконец, пакет с добавленным заголовком IP маршрутизируется в пункт назначения. Структура пакета показана на рис. 24.8.
    Хотя SSTP основан на веб-протоколе HTTPS, сервер VPN не обязательно должен быть сконфигурирован с применением IIS. VPN-сервер RRAS прослушивает SSTP-соединения с унифицированным индикатором ресурса (Uniform Resource Identifier — URI) вида <. Это не конфликтует с IIS и не требует ее наличия, хотя служба IIS может быть установлена для других целей.
    К сожалению, SSTP не поддерживает туннелирование через прокси-серверы, требующие аутентификации. Еще одним ограничением SSTP является то, что в отличие от РРР и L2TP, он не поддерживает межсайтовые соединения в WServer 2008 R2.
    Использует методы проверки подлинности РРР для аутентификации на уровне пользователя и инкапсуляцию HTTP через канал SSL для проверки подлинности и целостности данных, а также их шифрования. Благодаря инкапсуляции HTTP, протокол SSTP может пересылать данные через множество брандмауэров, NAT-преобразователей и прокси-серверов, где не работают протоколы РРТР и L2TP. Протокол SSTP поддерживается только в WServer (как VPN-сервер или клиент) и WClient (как VPN-клиент). Для протокола SSTP требуется, чтобы на VPN-сервере был установлен компьютерный сертификат и клиенты доверяли центру сертификации, издавшему этот сертификат. В большинстве организаций для этого используются службы сертификации AD, за исключением того, что автоматическая подача заявок от клиентских компьютеров не требуется.

    DirectAccess


    В Microsoft позиционируют DirectAccess как нечто отличное от традиционных сетей VPN. Такое позиционирование основано главным образом на автоматизированной природе DirectAccess, а не на технических или архитектурных отличиях. Формально DirectAccess является сетью VPN, но с рядом отличий.
    DirectAccess — новый протокол удаленного доступа в Server 2008 R2, предоставляющий подключения сетевого узла к удаленным системам без каких-либо требований регистрации пользователя. DirectAccess позволяет преодолеть ряд ограничений традиционного VPN, включая перечисленные ниже:
    • необходимость для пользователя вручную устанавливать соединение с VPN;
    • заметная для пользователя задержка при установке соединения, связанная с проверкой работоспособности удаленной системы;
    • необходимость вручную переустанавливать соединение, если VPN-соединение теряется;
    • низкая производительность, когда весь трафик (интрасети и Интернет) маршрутизируется через соединение VPN.

    DirectAccess скрывает все процессы соединений от пользователей и интеллектуально маршрутизирует трафик интрасети и Интернета, тем самым преодолевая сложности традиционного VPN. Он подключается сразу после того, как компьютер загружен, и тут же проводит проверки работоспособности, вместо того, чтобы делать это при входе пользователя. Процесс подключения прозрачен для пользователя, и пользователю никогда не требуется явно подключаться к DirectAccess. И, наконец, протокол DirectAccess имеет встроенные опции контроля обработки запросов DNS, эффективно балансируя трафик Интернета и интрасети, снижая накладные расходы соединений удаленного доступа и повышая производительность.
    DirectAccess создает шифрованный сквозной туннель от удаленного пользователя — в данном случае удаленного пользователя на системе Windows 7 — к интрасети предприятия. Будучи однажды сконфигурированным, компьютер будет автоматически подключаться к офису с любого доступного Интернет-соединения. Вдобавок, за счет использования сервера NPS на базе Server 2008 R2 удаленно подключенные клиенты могут безопасно управляться, подобно внутренним клиентским системам.
    Хотя DirectAccess позиционируется как альтернатива VPN, технология DirectAccess имеет в себе все элементы VPN. Она устанавливает защищенный частный туннель через публичные сети, используя для этого IPSec и сертификаты, и полученная в результате функциональность не слишком отличается от L2TP. Существующие отличия имеют скорее административный характер, нежели технический.
    Протокол DirectAccess использует IPv6, IPSec и сертификаты для установки безопасных соединений клиентов DirectAccess с ресурсами интрасети через сервер DirectAccess. Чтобы проходить через публичные сети IPv4, в DirectAccess используются ISATAP, Teredo и 6to4.
    DirectAccess предъявляет некоторые специфические требования.
    1. Сервер, функционирующий под управлением Server 2008 R2, должен иметь 2 сетевые карты: одну, подключенную к интрасети, и другую — к Интернету.
    2. Сетевая карта, подключенная к Интернету, должна иметь 2 последовательных публичных адреса IPv4.
    3. Ресурсы и приложения интрасети должны поддерживать IPv6. (you no longer need IPv6 in the datacenter or Forefront User Access Gateway)
    4. Клиенты DirectAccess должны работать под управлением Windows 7; более старые клиенты не поддерживаются.
    5. Контроллер домена и сервер DNS, к которым подключены системы, должны функционировать под управлением Server 2008 SP2 или Server 2008 R2.
    6. Должна существовать инфраструктура PKI для выпуска сертификатов с публично доступным в Интернете списком отмененных сертификатов (certificate revocation list - CRL).
    Протокол DirectAccess построен поверх IPv6 и требует, чтобы все устройства в конечных точках поддерживали IPv6. Даже когда клиенты DirectAccess используют переходные технологии IPv6 вроде Teredo или 6to4, в конечном итоге они соединяют клиентов IPv6 с хостами IPv6.
    Внутренне DirectAccess может использовать устройства Network Address Translation -Protocol Translation (NAT-PT), которые могут обеспечить доступ к ресурсам IPv4. Ресурсы, которые не поддерживают IPv6 естественным образом, могут быть доступны через устройство NAT-PT. Server 2008 R2 в настоящее время не включает такой возможности, поэтому для данной функциональности понадобится устройство от стороннего поставщика. Механизм NAT-PT описан в документе RFC-2766 ( tools .ietf.org/html/rfc2766), но был переклассифицирован с предлагаемого стандарта (Proposed Standard) в исторический (Historic) из-за присущих ему проблем. Детали этих проблем описаны в документе RFC-4966 (tools.ietf.org/html/rfc4966). К ним относятся: трудности применения механизмов обеспечения целостности; невозможность перенаправления протоколов, которым не хватает возможностей демультиплексирования; превалирующее состояние таймаутов; утеря информации из-за несовместимости заголовков IPv4 и IPv6; проблемы с фрагментацией пакетов; невозможность обработки широковещательного трафика. По причине наличия этих проблем использовать устройства NAT-PT рекомендуется лишь в качестве крайней меры.

    2 туннеля


    Клиент DirectAccess устанавливает 2 туннеля, которые являются ключом к разносторонности этого метода удаленного доступа. Это туннели IPSec ESP, которые аутентифицируются сертификатами и шифруются для обеспечения конфиденциальности.
    1. Туннель компьютера устанавливается первым, когда запускается клиент DirectAccess. Этот туннель аутентифицируется только сертификатом компьютера и обеспечивает доступ к DNS интрасети и контроллерам доменов. Этот туннель также используется для загрузки групповой политики компьютера и запроса аутентификации пользователя.
    2. Туннель пользователя аутентифицируется сертификатом компьютера и регистрационными данными пользователя и обеспечивает доступ к ресурсам интрасети. Этот туннель также используется для загрузки групповой политики пользователей.
    Оба эти туннеля (рис. 24.11) устанавливаются прозрачно для пользователя. Для установки удаленного доступа пользователю не нужно вводить регистрационную информацию помимо той, что он вводит при входе в Windows.
    Эти туннели позволяют прозрачным образом устанавливать удаленный доступ, по сути, позволяя компьютеру подключаться к интрасети, даже когда пользователь еще не вошел в систему. Это позволяет клиенту DirectAccess принимать групповую политику удаленно и управляться со специальных серверов в интрасети. Когда пользователь входит в систему, он аутентифицируется в интрасети и, как следствие, становится субъектом последних требований, изменений пароля и политик. В отличие от этого, традиционные решения VPN обычно используют аутентификацию пользователей на основе кэшированных учетных данных на локальной машине и затем устанавливают соединение удаленного доступа.

    Модель доступа DirectAccess


    Модель полного доступа (end-to-edge) DirectAccess предполагает, что клиент DirectAccess установит туннель IPSec к серверу DirectAccess. Сервер DirectAccess затем переадресует незащищенный трафик к ресурсам интрасети. Это наиболее общая форма DirectAccess, которая строго следует стандартной методологии удаленного доступа.
    На рис. 24.12 показана модель полного доступа. Обратите внимание, что имеется одиночное защищенное соединение (сплошная линия) через туннель с сервером DirectAccess, которое затем пересылается на каждый из серверов приложений в трех незащищенных (пунктирная линия) соединениях.
    Модель полного доступа требует поддержки IPSec внутри интрасети, хотя ресурсы интрасети по-прежнему нуждаются в поддержке IPv6.
    Модель ограниченного доступа (end-to-end) DirectAccess предполагает наличие клиента DirectAccess, устанавливающего туннель IPSec с каждым сервером приложений, с которым он соединяется. Это гарантирует защиту трафика от начала до конца с помощью шифрования IPSec, включая передачу по интрасети. Здесь присутствует защищенное соединение через туннель сервера DirectAccess с каждым из серверов приложений. Это указывает на то, что существуют отдельные соединения IPSec с каждым сервером, защищенные шифрованием.
    Модель ограниченного доступа требует, чтобы каждый сервер приложений функционировал под управлением Server 2008 или Server 2008 R2, а также использовал IPv6 и IPSec. Соединения IPSec также приводят к возникновению некоторых накладных расходов.

    Трафик Интернет по сравнению с трафиком интрасети с DirectAccess


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

    Компоненты DirectAccess


    DirectAccess полагается на технологию IPv6 с инфраструктурой PKI для предоставления невидимого безопасного соединения с сетью предприятия. Пользователю не понадобится конфигурировать клиент VPN или входить в систему. С точки зрения администратора эта технология позволяет управлять и выполнять мониторинг удаленных систем с помощью таких инструментов, как SCCM (Microsoft System Center Configuration Manager — Диспетчер конфигурации системного центра Microsoft) и Group Policy. DirectAccess наконец-то уравнял удаленных сотрудников с традиционным офисным персоналом.
    Компоненты развернутой среды DirectAccess:
    1. Сервер DirectAccess подключается к внутренней сети и Интернету. Он должен работать под управлением Server 2008 R2 с двумя физическими сетевыми интерфейсами: один — для публичной сети Интернет, другой — для внутренней корпоративной сети. Публичный интерфейс должен иметь 2 последовательных 1Р-адреса.
    2. Клиент DirectAccess Windows 7. Должен быть членом домена с сертификатом.
    3. Корпоративная сеть IPv6. Сеть IPv6, к которой будут удаленно подключаться клиенты DirectAccess.
    4. Сервер сертификатов. Этот сервер выпускает сертификаты, поддерживающие создание туннелей, аутентификацию и безопасность. Сервер сертификатов должен иметь публичный список устаревших сертификатов (CRL), который доступен внутренне и внешне.
    5. Сервер NLS (Network Location Server — сервер сетевого расположения). Это сайт HTTPS, который служит индикатором для клиента DirectAccess — подключен он к Интернету или интрасети.
    6. Сервер DNS и Active Directory. Этот сервер должен работать под управлением Server 2008 SP2 или R2. Роли AD и DNS могут располагаться на разных физических серверах, но большинство организаций обычно устанавливают их на одном.
    Для усиления безопасности также могут быть реализованы смарт-карты или защита NAP. В наиболее простой конфигурации DirectAccess требует, чтобы каждый клиент имел действительный сертификат компьютера для аутентификации во внутренней сети. Это заменяет применение традиционного имени пользователя и пароля.
    Для подключения к IPv6 удаленных клиентов, работающих с IPv4, применяются переходные технологии вроде Teredo, 6to4, а также новой технологии IP-HTTPS.
    Teredo является наиболее распространенным методом работы с DirectAccess.
    6to4 непосредственно транслирует адреса IPv6 в адреса IPv4. Если удаленные клиенты напрямую подключены к Интернету и имеют только публичные адреса IPv4, то 6to4 будет предпочтительным методом подключения.
    IP-HTTPS — новый протокол в Windows 7 и Windows Server 2008 R2. Он передает трафик IPv6 по туннелю IPv4 HTTPS между клиентом DirectAccess и сервером DirectAccess. Хотя это может показаться самым простым выбором, за него приходится платить производительностью из-за высоких сетевых накладных расходов, а потому данный способ следует применять в последнюю очередь.
    Протокол DirectAccess очень устойчив и прозрачно принимает множество методов доступа для установки соединения.

    Служба NLS


    Служба NLS (Network Location Service — служба сетевого расположения) является важным компонентом архитектуры DirectAccess. Это веб-сайт, к которому клиент пытается подключиться, чтобы определить, соединен ли он в данный момент с Интернетом или интрасетью. Это URL-адрес высокодоступного веб-сайта в интрасети.
    Ниже описаны два поведения клиентской системы DirectAccess.
    Если клиент DirectAccess может добраться до URL-адреса службы NLS, предполагается, что он подключен к корпоративной сети, поэтому никаких дополнительных действий не требуется.
    Если клиент DirectAccess не имеет доступа к URL-адресу службы NLS, предполагается, что он не подключен к корпоративной сети, поэтому запускается процесс соединения с DirectAccess.
    Служба NLS — это обычно высокодоступный веб-сайт, такой как службы в кластере NLB или кластере Windows.
    Если веб-сайт NLS не работает, это может привести к катастрофической ситуации, потому что все клиенты DirectAccess вдруг решат, что они в Интернете, даже несмотря на то, что на самом деле они подключены к интрасети. И тогда все они начнут процесс
    подключения DirectAccess. Вот почему веб-сайт NLS должен быть постоянно доступен.

    Процесс подключения DirectAccess


    Клиент DirectAccess характеризуется высокой надежностью. Он будет пробовать разнообразные методы подключения к корпоративной сети. Процесс подключения начинается, когда клиент обнаруживает, что он подключен к сети, т.е., когда становится активным соединение с локальной сетью, точкой беспроводного доступа и т.п.
    Клиент DirectAccess проходит следующий процесс подключения, когда обнаруживает, что соединен с сетью.
    Клиент DirectAccess пытается соединиться с веб-сайтом NLS. Если он может достичь сайта, то решает, что подключен к интрасети и прекращает процесс DirectAccess. Если же не может, то решает, что подключен к Интернету, и процесс DirectAccess продолжается.
    • Клиент DirectAccess устанавливает туннель на сервер DirectAccess, используя IPv6. Если между ними находится сеть IPv4, то клиент использует протокол Teredo или 6to4 для туннелирования IPv6 через IPv4.
    • Если клиент DirectAccess не может подключиться, используя протоколы Teredo или 6to4, то клиент попытается подключиться с помощью протокола IP-HTTPS.
    • Клиент DirectAccess устанавливает туннель IPSec на сервер DirectAccess, используя IPv6. Клиент DirectAccess и сервер DirectAccess выполняют взаимную аутентификацию в процессе установки туннеля компьютера IPSec.
    • Клиент DirectAccess подключается к контроллеру домена и получает групповую политику компьютера.
    Чтобы этот процесс дошел до этой точки, пользователю не обязательно входить на компьютер.
    • Пользователь DirectAccess входит в систему либо применяет регистрационные данные уже вошедшего пользователя в сочетании с сертификатами, чтобы установить
    туннель пользователя IPSec. Групповая политика пользователя применяется к клиенту DirectAccess.
    • Сервер DirectAccess начинает пересылать трафик от клиента DirectAccess на авторизованные ресурсы интрасети.
    Этот процесс полностью прозрачен для пользователя и не требует от него какого-либо взаимодействия. В случае разрыва сетевого соединения клиент DirectAccess переустановит соединение с помощью этого процесса, когда вновь обнаружит сетевое подключение.

    Выбор между традиционными технологиями VPN и DirectAccess


    Внутри технологий VPN также имеется ряд вариантов для выбора — прежде всего, между L2TP/IPSec и РРТР.
    Теперь для удаленного доступа к внутренним ресурсам вместо
    нескольких ролей ( Direct Access и VPN) предлагается единая
    Unified Remote Access. Технология Direct Access представляет собой предпочтительное решение для создания такого
    подключения. Сервер больше не требуется размещать в DMZ, он может находиться и за NAT'om. Настройка сервера и соединений
    упрощена, за всё отвечает мастер.

    Преимущества L2TP/lPSec


    Более высокий уровень безопасности, а также ряду других преимуществ. Преимущества L2TP/IPSec перед РРТР перечислены ниже.
    • IPSec предлагает аутентификацию данных на уровне пакетов (т.е. требуя доказательства, что данные были отправлены авторизованным пользователем), целостности данных (доказательства, что данные не были модифицированы в пути), защиты ответа (предотвращения повторной отправки потока захваченных пакетов) и конфиденциальности данных (предотвращения интерпретации захваченных пакетов без ключа шифрования). Протокол РРТР обеспечивает только конфиденциальность данных на уровне пакета.
    • Соединения L2TP/IPSec обеспечивают более строгую аутентификацию, требуя как аутентификации уровня компьютера через сертификаты, так и аутентификации уровня пользователя — через протокол аутентификации РРР.
    Пакеты РРР, передаваемые в процессе аутентификации уровня пользователя, никогда не пересылаются незашифрованными, потому что процесс соединения РРР для L2TP/IPSec происходит после настройки сопоставлений безопасности IPSec. В случае перехвата обмен аутентификацией РРР для некоторых типов протоколов аутентификации может использоваться для проведения автономных атак с помощью словаря и определения пользовательских паролей. Если обмен аутентификацией РРР зашифрован, автономные атаки с помощью словаря возможны только после успешного взлома зашифрованных пакетов.

    Преимущества РРТР


    Имеются существенные аргументы в пользу выбора организациями РРТР, а не L2TP/IPSec.
    Ниже перечислены преимущества РРТР:
    РРТР не требует наличия инфраструктуры сертификатов. L2TP/IPSec, SSTP и DirectAccess требуют такой инфраструктуры, чтобы использовать сертификаты компьютеров для серверов VPN (или любого другого аутентифицируемого сервера) и
    всех клиентских компьютеров VPN.
    РРТР может использоваться всеми платформами Windows. VPN-клиенты Windows Server 2008 R2, Server 2008, 2000 Server, Windows 7, WClient, XP и 2000 Workstation — это единственные клиенты, поддерживающие L2TP/IPSec и использующие сертификаты. Windows 7 — единственный клиент, поддерживающий DirectAccess.
    IPSec работает на уровне ниже стека TCP/IP. Этот уровень контролируется политикой безопасности на каждом компьютере и согласовывает сопоставления безопасности между отправителем и получателем. Политика состоит из набора фильтров и ассоциированного поведения безопасности. Если IP-адрес, протокол и номер порта пакета соответствует фильтру, пакет является субъектом ассоциированного поведения безопасности.

    Преимущества SSTP


    Протокол SSTP в Server 2008 R2 дает администраторам возможность устанавливать туннели между основными корпоративными сетями, минуя многие технические
    препятствия, которые останавливают внедрение РРТР и L2TP.
    Ниже описаны преимущества SSTP.
    Протокол SSTP помогает сократить затраты на администрирование, сокращая количество действий, необходимых для установки туннеля между организациями.
    Поскольку HTTPS пропускается через большинство брандмауэров и прокси-серверов, для поддержки SSTP никакой дополнительной инфраструктуры не требуется.
    Протокол SSTP обеспечивает безопасность на основе сертификатов, будучи реализованным через SSL. Однако сертификаты должны быть выпущены только для серверов, а не для клиентов. Это обеспечивает преимущества безопасности, характерные для L2TP, почти сохраняя легкость конфигурации РРТР.
    Преимущества несколько ослабляются требованием к центру сертификации у клиента и требованиями к операционной системе. Клиент должен доверять центру сертификации,
    выпустившему сертификат, и иметь доступ к списку отмененных сертификатов.
    Поддержка SSTP на клиентах доступна в Server 2008, Windows Server 2008 R2, Windows 7, XP с пакетом обновлений SP3 или выше, а также WClient с пакетом обновлений SP1 или выше.

    Преимущества DirectAccess


    Позволяет администраторам управлять удаленными
    системами как локальными посредством таких инструментов, как Групповые политики и SCCM. С точки зрения пользователя это самое простое решение удаленного доступа. Выполнив первоначальную конфигурацию, ему больше не нужно предпринимать никаких дополнительных действий; все просто работает. Однако с точки зрения админист-
    ратора это решение является самым сложным — из-за IPv6 и требований к сертификатам.
    Ниже перечислены преимущества DirectAccess.
    предлагает прозрачные соединения везде, где удаленная система может подключиться к Интернету. Никакого участия пользователя при этом не требуется.
    позволяет переадресовывать папки, так что критичные данные остаются внутри корпоративной сети и централизованно резервируются средствами предприятия.
    использует новую технологию NRPT (Name Resolution Policy Table — таблица политик преобразования имен) для определения соответствующего DNS-сервера для запросов соединения. В сочетании с разделенным туннелированием это действительно прозрачное решение.
    Несмотря на эти преимущества, DirectAccess может оказаться сложным в реализации. Если большинство частей, таких как IPv6, PKI и Windows 7, на рабочей станции уже присут-
    ствуют, то DirectAccess может быть наилучшим решением удаленного доступа для Server 2008 R2.
    Для организаций, которые хотят развернуть IPv6 и получить опыт работы с этой новой схемой
    адресации, технология DirectAccess предлагает хорошую учебную платформу IPv6 — са-
    модостаточную и хорошо интегрированную с существующими технологиями IPv4.

    Порты, используемые соединениями VPN


    Нередко серверы RRAS, служащие серверами VPN, имеют две сетевые карты, из которых одна подключена к внешней сети или к DMZ. Это проще, поскольку обычно накладывает минимум ограничений на коммуникации с интерфейсом, направленным вовне. Сервер RRAS — защищенный брандмауэром и направленный наружу интерфейс, использование которого рекомендуется для сокращения потенциального риска. Фактически, это требования для серверов DirectAccess.
    Однако, несмотря на шаги по сокращению опасности, этот направленный наружу интерфейс может представлять неприемлемый уровень риска для некоторых организаций.
    В подобных случаях инфраструктура VPN должна оставаться полностью в пределах внутренней сети. В такой конфигурации брандмауэр должен быть сконфигурирован так, чтобы
    разрешать прохождение соответствующего трафика через сервер RRAS.
    В табл. 24.3 и 24.4 приведен список важнейших правил брандмауэра, которые необходимы для протоколов РРТР и L2TP. IP-адрес для каждого из правил — это адрес сервера RRAS, который является целевым, если речь идет о входном потоке данных, и исходным в случае выходного потока.
    Таблица 24.3. Правила брандмауэра для сервера RRAS для РРТР
    Направление
    Протокол
    Порт или идентификатор
    Назначение
    Входящие
    TCP
    1723
    Разрешает трафик поддержки туннеля РРТР от
    клиента РРТР на сервер РРТР
    IP
    47
    Разрешает передачу туннелированных РРТР-
    данных от клиента РРТР на сервер РРТР
    Исходящие
    TCP
    1723
    Разрешает трафик поддержки туннеля РРТР от
    сервера РРТР на клиент РРТР
    IP
    47
    Разрешает передачу туннелированных РРТР-
    данных от сервера РРТР на клиент РРТР
    Таблица 24.4. Правила брандмауэра для сервера RRAS для L2TP
    Входящие
    UDP
    500
    Разрешает трафик IKE на сервер VPN
    UDP
    4500
    Разрешает трафик IPSec NAT-T на сервер VPN
    IP
    50
    Разрешает трафик ESP на сервер VPN
    Исходящие
    UDP
    500
    Разрешает трафик IKE от сервера VPN
    UDP
    4500
    Разрешает трафик IPSec NAT-T от сервера VPN
    IP
    50
    Разрешает трафик ESP от сервера VPN
    Интересно, что поскольку сервер DirectAccess должен быть двухканальным (dual-homed) с сетевым интерфейсом, подключенным к публичной сети, какие-то порты на брандмауэре для DirectAccess не нужны. Фактически, он полностью минует брандмауэр.
    Протокол SSTP прост и только требует, чтобы был открыт ТСР-порт 443 для исходящего потока на сервере RRAS.

    Традиционный сценарий создания VPN-сети


    Рис. 24.15. Диаграмма для сценария развертывания VPN
    Базовые конфигурации систем, используемых в рассматриваемом примере, приведены в табл. 24.5. Предполагается, что уже создан домен AD companyabc.com с контроллером домена DC1.
    Для настройки архитектуры VPN необходимо выполнить перечисленные ниже шаги:
    • Создание сервера сертификации
    • Создание и настройка сервера сетевых политик
    • Создание RRAS
    • Создание VPN-клиента
    • Проверка VPN-соединения
    • Контроль неработоспособных VPN-клиентов.

    Таблица 24.5. Серверы в примере развертывания VPN
    Сервер
    Роли
    Операционная система
    IP-адрес
    DC1
    Сервер каталога
    WServer
    172.16.1.100
    NPS1
    Сервер сетевых политик
    Сервер сертификации
    172.16.1.151
    VPN1
    Сервер RRAS
    172.16.1.152 (внутренний)
    WClient1
    VPN-клиент
    WClient
    192.168.1.201 (внешний)
    В WServer AD доступ пользователей должен включаться на
    вкладке Dial-in (Доступ по дозвону) диалогового окна свойств учетной записи. Как показано на рис. 24.16 выбранной опцией по умолчанию является Control Access Through NPS Network Policy (Управление доступом с помощью сетевой политики NPS).
    Рис. 24.16. Вкладка Dial-in в WServer AD

    QoS


    Протокол QoS должен присутствовать в сетевом подключении. Планировщик пакетов QoS обеспечивает контроль сетевого трафика, включая службы управления пропускной способностью и назначения приоритетов потокам данных.
    Для настройки качества обслуживания в групповой политике в Windows используется мастер QoS на основе политики.
    Чтобы создать политику QoS, необходимо изменить параметры объекта групповой политики. Имя политики QoS должно быть уникальным. Конфигурация пользователя(компьютера)\Параметры Windows\QoS на основе политики.

    Распределение приоритета для трафика с помощью DSCP


    Чтобы определить приоритет для исходящего сетевого трафика, задайте для политики QoS значение DSCP с помощью параметра Укажите значение DSCP. Согласно RFC 2474, для DSCP можно указать значения от 0 до 63 в поле "Тип обслуживания (TOS)" пакета IPv4. Сетевые маршрутизаторы используют значение DSCP для классификации сетевых пакетов и определения соответствующей очереди. Более высокое значение определяет более высокий приоритет данного пакета. По умолчанию флажок Укажите значение DSCP установлен, значение равно 0.
    В рамках стратегии обеспечения качества обслуживания вашей организации необходимо предусмотреть количество очередей и поведение для пакетов с разными приоритетами. Например, можно создать политики QoS, в соответствии с которыми пакеты с определенными значениями DSCP будут распределяться по 5 очередям: трафик, чувствительный к задержкам, управляющий трафик, критически важный для бизнеса трафик, рекомендованный трафик и трафик массовой передачи данных.

    Регулируемый трафик


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

    Создание политики QoS


  • Выбранное имя должно однозначно идентифицировать политику в иерархии узла объекта групповой политики, в котором она создается.
  • Также при желании можно установить флажок Укажите частоту глушителя для включения регулировки трафика и настройки ограничения скорости. Ограничение скорости должно быть больше 1.
    Путь к приложению не должен включать символическую ссылку.
    Чтобы применить параметры политики QoS к пользователям или компьютерам, свяжите объект групповой политики, в котором размещены политики QoS, с контейнером Active Directory (доменом, сайтом или подразделением).
    QoS – целая пачка технологий, без которых современная сеть работает крайне плохо, а ряд задач не может выполнить вообще. Это и логики классификации трафика, и схема marking’а, когда данные помечаются путём помещения в заголовок канального или сетевого уровня соответствующих пометок, и управление логикой работы очередей, когда надо отправить несколько потоков данных через ограниченный по пропускной способности интерфейс, и шейпинг, и многие другие дисциплины, без которых целостная картина просто не получится. Фундаментально это изучается разве что на курсе Cisco QoS, да и то – в пять дней не всегда влезаем, материала там много.
    Однако, сетевые настройки Windows в плане “глубже, чем просто айпишник назначить”, обычно являют собой что-то мистическое для администратора (да и для большинства тренеров Microsoft тоже, т.к. сетевые вопросы в авторизованных курсах Microsoft рассказываются крайне минималистично). Хотя ничего ужасного в сетевых технологиях нет, скорее, наоборот – зачастую бытует мнение, что “в Windows этого нет”, базирующееся на глубоком выводе о том, что говорящий это не нашёл за 10 секунд.
    Попробуем разобраться. Предположим, что Вы уже знаете сетевые технологии на базовом уровне, хотя бы слышали про ethernet, 802.1Q и формат IP-пакета. Если не слышали – имеет смысл послушать курс Cisco ICND1, это бесплатно. Конечно, лучше изучить QoS основательно, но это, в принципе, не строго необходимо для восприятия данного материала.

    Включаем поддержку QoS в сетевой подсистеме Windows


    Для того, чтобы маркировать и CoS и ToS, у Windows есть специальный сетевой компонент, который так и называется – QoS Packet Scheduler. Установите его и включите на всех сетевых интерфейсах, на которых планируется управление QoS. Если посмотреть внимательно, то этот компонент по сути и есть NDIS-драйвер:
    Далее. Для того, чтобы мы могли указывать не только L3-параметры QoS (которые в IP-заголовке в поле ToS), а ещё и L2-параметры (которые в 802.1Q заголовке, в части, называемой 802.1p), нам надо включить на сетевом адаптере поддержку 802.1Q. Это будет выглядеть по разному в разных сетевых адаптерах – но примерно так:
    Если такого пункта нет, то ставить метки CoS в кадре 802.3 некуда. Это уменьшит практическую пользу от настроек QoS, но, в общем-то, не уберёт её. Суть в том, что обычный хост не добавляет этот заголовок в 802.3-кадр, и эта настройка, в зависимости от сетевого адаптера, может обозначать разное – или “принимать кадры с 802.1Q-заголовком и анализировать его, в том числе и 802.1p”, или “делать это только в случае, когда мы отправляем кадр с меткой 802.1Q”. Смотрите детальнее специфику своего сетевого адаптера, общий совет тут выдать можно только один – если заголовка 802.1Q нет, то данные о качестве обслуживания можно добавить лишь в L3-заголовок.
    Если Вы проделали всё вышеуказанное – система готова к тому, чтобы реализовывать заданные Вами параметры QoS. Теперь надо их задать.

    Глобальные настройки QoS


    Глобальные настройки QoS коснутся двух моментов – того, как будет обрабатываться входящий TCP-трафик, и того, как будут взаимодействовать политики QoS и установки QoS на уровне отдельных приложений. Находятся они в объекте групповой политики, точнее – в Computer Configuration/Windows Settings/ Policy- based QoS, в контекстном меню Advanced QoS Settings..., вызываемом ПКМ. Рассмотрим их по отдельности.

    Настройки Inbound TCP Traffic


    Это, по сути, никакой не QoS, а управление окном TCP для трафика в сторону данного хоста. Идея в том, что данная настройка напрямую влияет на то, какое максимальное значение receive window будет предлагаться при работе TCP-соединений. Начиная с NT 6.0, в Windows появилась человеческая поддержка окна TCP размером более 64К, вот данная политика и позволяет задать это максимальное значение окна централизованно. При задании уровня 0 окно будет ограничено 64КБ, при 1 – 256КБ, при 2 – 1МБ, а при 3 – 16МБ. Учтите, что чем больше окно, тем реже TCP отправляет подтверждения о приёме, и тем менее “динамично” он реагирует на форс-мажорные ситуации, когда сегмент TCP задерживается или теряется. Чем меньше – тем быстрее реакция, но больше служебного трафика. В общем и целом в надёжных сетях при передаче больших объёмов данных (например, файл-сервер в локальной сети офиса) целесообразно устанавливать значение выше, а при сценарии “По tcp-сессии идёт не очень много данных, но у канала варьируется латентность и качество” – меньшее значение.

    Настройки DSCP Marking Override


    Это достаточно простая настройка, некий аналог mls qos trust cos в Cisco IOS. Суть – разрешать или нет приложениям, которые умеют метить трафик, делать это. Если выберете, что в явном виде можно – то когда приложение будет устанавливать поле ToS, то политики QoS будут игнорироваться, если нет – то наоборот; приложения на данном хосте будут безрезультатно вызывать функции API по маркировке трафика, а вся маркировка будет идти по явно указанной в политиках логике.
    Давайте теперь посмотрим, как эти политики формируются.

    Настраиваем политики QoS


    Находятся они там же – Computer Configuration / Windows Settings / Policy-based QoS. Рассмотрим создание политики.
    Первое, что надо учесть – ограничения политик. Под них может подпадать только трафик TCP и UDP. Другие IP-протоколы ограничить не получится. Плюс есть дополнительные настройки для HTTP-сессий, что улучшает ситуацию. Поэтому штатное решение по управлению качеством обслуживания затрагивает не весь возможный трафик, но в подавляющем большинстве случаев является достаточным. Приоритет исходящего IPSec или PPTP-трафика, например, задать не получится.
    При создании политики первым делом надо будет указать её название (произвольное, технического назначения не имеет), значение DSCP и ограничение на полосу. Давайте чуток вспомним, что это и зачем.
    QoS – это большая пачка технологий. Это и то, как помечать пакеты и кадры (Marking), и то, как формировать очереди для отправки нескольких потоков с разными метками через один интерфейс (Queuing), и то, как сбрасывать из этих очередей лишний трафик (Shaping). Когда речь идёт о сегменте сети, в котором эта логика единообразна и продумана (трафик X помечается на всех устройствах однотипно и однотипно же добавляется в очереди), говорят о том, что это – домен QoS. Мы будем рассчитывать на то, что установки, которые мы сейчас делаем через групповую политику, будут аналогично восприниматься сетевыми устройствами – это уже out of scope для этой статьи, но для полноценной поддержки QoS в организации это сделать нужно. Иначе нет никакого особого смысла тщательно классифицировать трафик, потом помечать, а потом на первом же коммутаторе в процессе отправки в uplink валить всё в одну кучу с логикой FIFO.
    Когда деревья были большими – 31 год назад, в 1981 году – в заголовке IP-пакета тоже, как и сейчас, было одинокое поле размером с байт и с названием ToS – Type of Service. То, что делать с этим полем, написали в RFC 791 и назвали IP Precedence. Делать предлагалось многое – помечать каждый пакет “уровнем важности” от 0 до 7, используя 3 бита этого поля, и добавлять пожелания вида “если есть возможность, отправь трафик по каналу с меньшей латентностью / большей надёжностью / большей номинальной полосой пропускания”, используя ещё 3 бита. Два бита отложили до лучших времён. Как-то так:
    [
    Бит приоритета N0 |
    Бит приоритета N1 |
    Бит приоритета N2 |
    Бит задержки |
    Бит толщины |
    Бит надёжности |
    Unused |
    Unused
    ]
    Потом ещё чуток подумали и задействовали дополнительный бит, добавив 4е пожелание – “чтобы через тот канал, который подешевле в плане денег” – RFC 1349. Итого остался один незадействованный бит, получилось 8 уровней приоритета трафика плюс 4 бита и их комбинации влияли на выбор “при прочих равных условиях”. Предполагалось, что этого хватит. Стало так:
    [
    Бит приоритета N0
    Бит приоритета N1
    Бит приоритета N2
    Бит нежелательной задержки
    Бит толщины (канала)
    Бит надёжности
    По любви или за деньги
    Unused
    ]
    Хорошо заметно, что логическую модель пожеланий разрабатывала женщина.
    Модель IP Precedence была простой и предполагала, что весь трафик можно разбить на 8 классов, между которыми будет простое логическое соотношение вида “5 всегда важнее, чем 4″, плюс добавить некоторые пожелания. Все задачи по реализации этой схемы (чтобы одинаковый трафик метили одинаковыми IP Precedence, и обрабатывали схожим способом, плюс учитывали пожелания в виде 4х дополнительных бит) ложились на администратора. Впоследствии 4 бита “пожеланий” практически перестали использовать, и схема IP Precedence превратилась в минималистичную “8 глобальных типов трафика, выстроеных по важности”. Их можно трактовать и называть по-разному, логики работы это не поменяет, например так:
    • 0 – То, что называется Best Effort – трафик, который будет доставляться по остаточному принципу, когда будет возможность. Best Effort – это не “наилучшим способом”, это “хотели, как лучше, а как получится – посмотрим”. Обычно 0 – это весь неклассифицированный трафик.
    • 1 – Распознаный трафик. Например, HTTP, SMB, FTP. Это не значит, что этот трафик какой-то особенный. Он хотя бы “понятно какой”.
    • 2 – Приоритетный трафик. Например, RDP – при перекачке файла будет не очень хорошо, если начнёт тормозить работа с терминальным сервером.

    Но 14 лет назад, в 1998 году, парни из EMC и Cisco решили, что не хватит, и придумали ощутимо более гибкую систему, притом сразу и для ToS в IPv4, и для его потомка – Traffic Class в IPv6. Назвали её Differentiated Services. Система задействовала уже все 8 бит поля ToS – 6 на идентификатор класса (DSCP), и 2 на сигнализацию в случае заторов в сети (ECN). Как раз этот, более современный способ, и используется в политиках Windows. Метки, заданные по DSCP, более многочисленные, поэтому разбиваются на несколько групп.

    DSCP-метки группы CS – Class Selector’ы


    Этот механизм, который описан в RFC 2474, нужен для совместимости с предыдущей реализацией. В этом случае используется только 3 первые бита из 6, остальные устанавливаются в нули, поэтому с точки зрения расположения данных внутри байта ToS, CS’ы задают те же самые биты, что и IP Precedence. Соответственно, CS’ов будет 8 штук – от CS0 до CS7, и выглядеть они будут предсказуемо:
    • CS0 = 000 000
    • CS1 = 001 000
    • CS2 = 010 000
    • CS3 = 011 000
    • CS4 = 100 000
    • CS5 = 101 000
    • CS6 = 110 000
    • CS7 = 111 000

    DSCP-метки группы AF – Assured Forwarding


    Эти метки, логика которых есть в RFC 2597, уже интереснее – они содержат по 2 значения, x и y, поэтому записываются в читаемом варианте как AFxy.
    Первое значение – x – будет обозначать класс трафика. Классов определено 4 – от единицы до четвёрки. Их иногда называют словами – единица = бронзовый, двойка = серебряный, тройка = золотой, четвёрка = платиновый. Это значение будет записано в первые 3 бита. Во вторые будет записан y – он будет обозначать приоритет при необходимости сброса трафика. Будет определено три значения – единица будет обозначать low drop priority, двойка – medium , тройка – high. Это будет обозначать, что трафик одного и того же класса, но с разными приоритетами, будет при возникновении ситуации удаляться исходя из этого приоритета – вначале low, потом medium, потом high. Не запутайтесь – пакет с high drop priority сбрасывается последним, а с low – первым.
    Если сеть не поддерживает 3 приоритета, то она должна поддерживать хотя бы 2 – тогда они выглядят как AFx1 в роли “менее важного” и AFx2-AFx3 в роли “более важного”.
    Определены следующие значения
    • AF11 = 001 010 (в десятичном варианте DSCP = 10)
    • AF12 = 001 100 (в десятичном варианте DSCP = 12)
    • AF13 = 001 110 (в десятичном варианте DSCP = 14)
    • AF21 = 010 010 (в десятичном варианте DSCP = 18)
    • AF22 = 010 100 (в десятичном варианте DSCP = 20)
    • AF23 = 010 110 (в десятичном варианте DSCP = 22)
    • AF31 = 011 010 (в десятичном варианте DSCP = 26)
    • AF32 = 011 100 (в десятичном варианте DSCP = 28)
    • AF33 = 011 110 (в десятичном варианте DSCP = 30)
    • AF41 = 100 010 (в десятичном варианте DSCP = 34)
    • AF42 = 100 100 (в десятичном варианте DSCP = 36)
    • AF43 = 100 110 (в десятичном варианте DSCP = 38)

    DSCP-метка EF – Expedited Forwarding


    Это – высший, “premium” класс обслуживания. Значение этой метки – 46, она обозначает трафик, который надо отправить самым лучшим по всем параметрам способом.
    Вкратце всё. Как понятно, значение DSCP равное нулю будет обозначать Best-Effort доставку.

    Специфика 802.11-сетей


    У WiFi будет своя классификация типов трафика. Она будет называться WMM_AC (Wireless MultiMedia Access Categories) и будет достаточно несложной.
  • Весь трафик с DSCP от 48 и выше относится к Voice-классу (обозначается как VO)
  • Весь трафик с DSCP от 32 до 47 относится к Video-классу (обозначается как VI)
  • Весь трафик с DSCP от 24 до 31 относится к BestEffort-классу (обозначается как BE)
  • Весь трафик с DSCP от 8 до 23 относится к Background-классу (обозначается как BK)
  • Весь трафик с DSCP от 0 до 7 относится (опять, да?) к BestEffort-классу (обозначается тоже как BE)
    Соответственно, если Ваш WiFi-адаптер поддерживает WMM, то Вы можете включить это на уровне драйвера WiFi-адаптера, и он будет классифицировать свой исходящий трафик по 4м очередям в соответствии с “VO самый главный, VI второй, BE обычный, а BK – фоновый”. Если в Вашей сети политики QoS будут действовать на хосты с WiFi-адаптерами – учитывайте эти моменты при планировании политик.

    Создаём политику


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

    Применение политики на указанные приложения


    Здесь есть три варианта – политика будет действовать на трафик от любого приложения, от указанного (указывается исполняемый модуль), или только на HTTP-ответы от наших приложений, подпадающих под нужные критерии. Третий вариант будет интересен, когда надо будет через политику ограничить полосу отдаваемого трафика для указанных HTTP-ресурсов – допустим, если мы хотим ограничить “отдаваемые с нас” видеофайлы, подпадающие под критерий вида “ http://www.atraining.ru/video/*” .

    Применение политики на указанные source/destination IPv4/IPv6-адреса


    Достаточно тривиальные настройки – можно дополнительно ограничить применение политик QoS на трафик по L3-критерию. Замечу, что если в предыдущей настройке было выбрано “ограничить отдаваемый от нас в ответ на специфичный HTTP-запрос трафик”, то будет доступна только фильтрафия по destination, т.к. откуда исходит трафик и так понятно – от нас.

    Взаимодействие политик QoS


    В случае, когда трафик будет подпадать под несколько политик, будет определяться “выигравшая”, приоритеты будут выставляться так:
    • Политики QoS уровня пользователя перекрывают политики QoS уровня компьютера
    • Если определена политика, влияющая на конкретное приложение, и есть политика, под которую тот же трафик подпадает, но уже по сетевым критериям (адреса, номера портов), то выигрывает политика приложения
    • Политика, действующая на настройку более конкретно, перекроет общую. Это отнесётся и к подпадению сразу под две политики сетевого плана (подпасть под 192.168.1.0/24 важнее, чем под 192.168.0.0/16), и под “указанный явно порт лучше чем диапазон портов”, и под “более конкретный URL вида http://host/video/ * лучше, чем http://host/*”

    Зафиксируйте также интересную штуку – на серверных ОС Microsoft настройки QoS применяются всегда, а на клиентских – только в случае, когда сетевой интерфейс для исходящего трафика распознан как Domain Network. Это сделано специально, чтобы ограничения, действующие на ноутбук сотрудника при работе в корп.сети, не ограничивали бы по скорости и качеству его работу во внешних сетях. Это не влияет на безопасность, поэтому не является ослаблением оной; это лишь ограничения исходящего трафика.
    Теперь – о глобальных настройках “движка QoS” – сетевого компонента QoS Packet Scheduler.

    Настройки QoS Packet Scheduler


    Данные параметры будут указывать общесистемные (не относящиеся к конкретному типу трафика и сетевому интерфейсу) настройки этого механизма. Располагаться они будут в соответствующей ветке групповых политик:

    Параметр QoS Packet Scheduler – Limit Outstanding Packets


    Данная настройка указывает максимальный размер системной очереди исходящих пакетов. Т.е. если пакет назначен для отправки через конкретный интерфейс (найден next-hop и назначен egress interface), он считается “отправляемым” по данному критерию, и увеличивает этот счётчик на единицу. Как только пакет будет успешно отправлен (заметьте – именно пакет, этот счётчик работает только для L3-пакетов), счётчик уменьшится. Технически в Windows L3-очереди для конкретного интерфейса нет, есть только L2 (т.е. из кадров), поэтому если суммарное количество таких вот “ожидающих” пакетов будет больше указанного числа, то новый пакет не будет отправлен вообще, пока очередь не будет разгружена. От размера пакета это не зависит, считаются “головы” ожидающих пакетов. Пакеты всех сетевых протоколов (и IPv4, и IPv6) считаются вместе, т.е. при значении по умолчанию – 65536 – поставить “в очередь” по, допустим, 35 тысяч пакетов IPv4 и IPv6 не получится – 65537й пакет любого протокола будет отброшен по логике tail drop (т.е. не помещён в очередь).
    Я бы рекомендовал помнить, что исходящий пакет лимитируется кадровым MTU, которое в случае включения поддержки Jumbo Frames на сетевых интерфейсах будет 9КБ, поэтому даже дефолтная настройка, по сути, выделяет буфер для ожидающих пакетов суммарным размером до 589.824.000 байт, т.е. более полугигабайта (в случае обычного сетевого интерфейса 10/100Мбит – поменьше, 98.304.000 байт). Этого более чем достаточно на все случаи жизни (просто подумайте, что это за приложение такое, которое будет пытаться впихнуть в исходящую очередь интерфейса столько пакетов), поэтому зачастую целесообразно это значение уменьшать – уменьшается объём RAM, занимаемый служебными структурами драйвера QoS Packet Scheduler. Я ставлю на хосты, у которых виртуальные сетевые интерфейсы и не-интенсивная нагрузка (например, DC/GC) значение в 4096, и footprint драйвера QoS проседает.
    Для узлов, к которым подключается много внешних сессий, плюс настроен QoS, плюс отдаваемые данные состоят из мелких пакетов (голос, торренты) это значение может быть увеличено. Общая логика, думается, понятна – есть память и потребность отдавать очень много мелких пакетов – вполне можно и в ограничение в 65536 упереться.

    Параметр QoS Packet Scheduler – Set Timer Resolution


    В случае, когда настроено ограничение какого-либо типа исходящего трафика по полосе (“шейпинг”), данный параметр указывает то, какой минимальный квант времени используется для расчётов. Логика проста – допустим, используется стандартное значение в 10ms. Это значит, что секунда делится на 100 равных частей. Допустим, есть правило, которое ограничивает сервис X по отправке до 5МБайт в секунду. Следовательно, 100 раз в секунду будет запускаться счётчик, который будет измерять трафик, фактически отправленный подпадающим под правило сервисом. Если этот трафик за учётный период в 10ms наберёт 50КБ, то больше он отправляться не будет и начнёт уходить в “ожидающую” очередь, про которую рассказано в предыдущем пункте. Ну а когда начнётся новый период в 10ms, опять сможет быть отправлено 50КБ.
    Соответственно, чем это число больше, тем шейпинг будет “грубее”, но меньше будет тратиться процессорных ресурсов. А чем число меньше, тем более “гладко” будет уходить трафик – заметьте, это всё относится только к трафику, подпадающему под правила QoS, трафик без маркировки это затрагивать не будет. Имеет смысл увеличить разрешение таймера (до 2ms например) в случае, когда есть правило по отправке голосового трафика – это положительно повлияет на качество исходящего потока.

    Параметр QoS Packet Scheduler – Limit Reservable Bandwidth


    Самая страшная настройка – сколько про неё сказок рассказывается уже лет 10, просто ппц. Легенды о том, что “венда по дефолту 20% сетевой полосы пропускания просто так зажимает”, я слышал в десятках вариантов – от безобидного “потому что они тупые там и не могут нормально сетевуху полностью нагрузить” до шизоидного “это чтобы данные с винта пользователя в Пентагон отправлять”.
    На самом деле всё просто. Это – суммарное количество резервируемой всеми правилами QoS, работающими на данной системе, полосы пропускания. Т.е. если оно 20%, а у Вас сетевой интерфейс в 100 Мбит, то как бы Вы не старались, и не создавали, например, 3 правила, каждое из которых резервирует под приложение по 15 мегабит (3*15=45), то Вы никак больше 20 мегабит не займёте в результате своим приоритезированным трафиком. Грубо говоря, это значение показывает, сколько “QoS’овского классифицированного” трафика в процентах от номинальной полосы пропускания интерфейса может быть. Целесообразно, если Вы пишете политики QoS, увеличить это число например до 90%. Почему не до 100? Потому что в случае, когда по каким-то причинам весь трафик некоего приложения станет супер-приоритетным, и полоса резервирования будет 100%, другой трафик будет вечно проигрывать соревнование за очерёдность отправки, и система не сможет делать свои задачи – грубо говоря, например, отвалятся всякие служебные протоколы типа IKE, который ходит по 500му порту UDP, NTP, DNS, и прочие. Вот от этого идёт страховка, когда делают не 100, а не от того, что “винда просто так берёт и часть сети не использует”.

    Quality Windows Audio Video Experience ( qWave ) – что такое и нужен ли


    Данный компонент, появившийся со времен NT 6.0, представляет из себя клиент-серверный сервис, технически работающий по портам 2177TCP/UDP, и нужный для того, чтобы две службы на разных хостах могли “договориться” о том, какому потоку данных какой приоритет предоставить. Сервер, инициирующий передачу данных, имеет роль initiator, принимающая сторона имеет роль sink. Суть в том, что приложение, которое сможет “заказать” у qWave уровень качества для своих данных, должно быть соответствующим способом разработано (например, использовать для установки сессии функционал .NET). qWave, по сути, будет перекрывать своими настройками, если они есть, системные. Плюсов у интегрированного подхода много – qWave автоматически определяет, поддерживается ли 802.1p не только на конечных хостах, но и на промежуточном сетевом оборудовании, позволяет гибко и на ходу переопределять резервируемую полосу для нужного трафика, а также постоянно отслеживать такие параметры, как latency канала (QoS Packet Scheduler этого делать не может), периодически отправляя тестовые пакеты и “промеряя” качество линии между двумя хостами.
    Напомню – “просто так” установить этот компонент можно, но нужен софт, который будет уметь запросить у него функционал. По умолчанию qWave не работает, т.к. если бы он работал, то он тратил бы ресурсы сети на тестовые измерения качества канала.

    Безопасность


    IPSec


    По умолчанию IPSec оперирует в режиме транспорта. Режим транспорта также применяется в VPN-ах на основе IPSec, где задействуется L2TP для туннелирования подключения IPSec через общественную сеть. Режим туннелирования IPSec используется редко и поддерживается как дополнительная функция. Туннели IPSec не поддерживаются в сценариях удаленного доступа к VPN.
    Управлять протоколом IPSec можно с помощью локальной или групповой политики безопасности или инструментов командной строки. С помощью групповой политики можно также контролировать приложения, которым разрешено обмениваться данными по сети. В сетях WServer протокол IPSec, как правило, реализуют через один из способов:
  • политики IPSec
  • правила безопасности подключений (ПБП).
    В системе WServer в IPSec внесены несколько скромных, но заслуживающих внимания улучшений. Самое важное — ПБП позволяют реализовать IPSec для сетевых коммуникаций с проверкой подлинности. ПБП реализованы в виде опции для отдельных компьютеров WClient, но в WServer их можно внедрять с помощью групповой политики в Брандмауэре Windows в режиме повышенной безопасности.
    По умолчанию ПБП не выполняют шифрование данных, а лишь обеспечивают защиту против их искажения и атак повторного воспроизведения (replay-атаки). Я бы порекомендовал предоставить ПБП выполнять свои функции по умолчанию, а для шифрования использовать политики IPSec. Главное преимущество ПБП — упрощение администрирования, а при создании настраиваемых правил с расширенной функциональностью это преимущество будет сведено на нет.
    По умолчанию политики IPSec пытаются выполнить согласование служб проверки подлинности шифрования. Однако политики IPSec и ПБП можно конфигурировать для обеспечения любой комбинации служб защиты данных. После согласования подключения IPSec двумя компьютерами с использованием политик IPSec или ПБП безопасность обмена данными между этими компьютерами обеспечивается в Сопоставлении безопасности.
    Методы проверки подлинности IPSec:
    1. Протокол Kerberos (Active Directory) - протокол проверки подлинности по умолчанию в средах AD, поэтому самый простой способ настроить проверку подлинности IPSec состоит в реализации IPSec в отдельном лесу AD. Для безопасности IPSec не потребуется никакой настройки конфигурации, кроме присоединения узлов к домену. Отметим, что область Kerberos, размещенную в сетевой среде вне AD, можно также использовать для проверки подлинности коммуникаций IPSec.
    2. Сертификаты. В этом сценарии каждый узел должен получить и установить сертификат компьютера публичного или частного центра сертификации.
    3. Предварительный ключ - пароль, совместно используемый участниками для шифрования и расшифровки данных. В IPSec предварительный ключ также можно указать в конечных точках, чтобы включить шифрование между узлами. Хотя этот метод проверки подлинности позволяет устанавливать сопоставления безопасности IPSec, предварительные ключи не обеспечивают такой уровень проверки подлинности, как сертификаты и Kerberos. Кроме того, предварительные ключи IPSec хранятся в открытом виде на каждом компьютере или в Active Directory, что снижает уровень безопасности, обеспечиваемый таким решением. По этим причинам предварительные ключи рекомендуется использовать лишь в непроизводственных средах.

    Политики IPSec


    Политики IPSec определяют, каким образом компьютер или группа компьютеров управляет коммуникациями IPSec. Политику IPSec можно назначить для отдельного компьютера с помощью оснастки Локальная политика безопасности, или для группы компьютеров — с помощью групповой политики. Хотя для компьютера в сети можно определить много политик IPSec, применяться к компьютеру будет не более одной политики. При назначении второй политики IP-безопасности первая автоматически отменяется. Если компьютеру назначена политика IP-безопасности групповой политикой, он игнорирует политику IP-безопасности, назначенную в консоли Локальная политика безопасности.
    Каждая политика IP-безопасности состоит из одного или нескольких правил политики, определяющих защиту трафика IP. Каждое правило политики связано с одним списком фильтров IP и одним действием фильтра. Списки фильтров IP захватывают трафик IP для политики.
    Если трафик, доставляемый на компьютер с назначенной политикой, соответствует фильтру в одном из заданных правил политики, выполняется действие фильтра, назначенное для этого правила (блокирование, разрешение или согласование безопасности). Отметим, что при совпадении начального и конечного адресов приоритет всегда имеет самый специфичный фильтр IP-безопасности.
    В групповой политике предусмотрено 3 предопределенных политики IP-безопасности.
    Client (Respond Only) При назначении этой политики компьютеру он никогда не будет инициировать запрос установления канала коммуникаций IPSec с другим компьютером. Но любой компьютер с политикой Client, запрашиваемый еще одним компьютером, будет выполнять согласование и установление коммуникаций IPSec. Как правило, эту политику назначают компьютерам в интрасети, которым требуется обмениваться данными с защищенными серверами без необходимости в защите всего трафика.
    Server (Request Security) Эту политику следует назначать компьютерам, для которых шифрование не требуется, хотя рекомендуется. При этой политике компьютер принимает незащищенный трафик, но всегда пытается обеспечивать безопасность дополнительных подключений, запрашивая безопасное подключение от исходного отправителя. Эта политика позволяет оставить незащищенным все подключение, если на другом компьютере не включена IP-безопасность.
    Secure Server (Require Security) Эту политику следует назначать серверам интрасети, для которых обязательны защищенные подключения.
    Чтобы назначить политику IPSec в объекте групповой политики, выберите узел ...\Конфигурация Windows\Параметры безопасности\Политики IP-безопасности, ПКМ нужную политику в панели сведений и примените команду Назначить (Assign).

    Создание новой политики IP-безопасности


    ПКМ узел Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Политики IP-безопасности и примените команду Создать политику IP-безопасности. Он просто дает возможность создать «пустую» политику. Правило ответа по умолчанию совместимо только с предыдущими операционными системами и обеспечивает действие по умолчанию для политики IP-безопасности, если не применяются другие фильтры IPSec.
    Созданную политику IP-безопасности можно конфигурировать и окне свойств.
    Далее описаны основные страницы Мастера создания новых правил IP-безопасности.
    1. Конечная точка туннеля (Tunnel Endpoint). Параметры на этой странице нужно конфигурировать только при использовании IPSec в режиме туннелирования.
    2. Тип сети. На этой странице можно выбрать тип сети, к которому будет применено правило: все подключения, локальная сеть или подключение удаленного доступа.
    3. Список IP-фильтров. В групповой политике для политики IP-безопасности предварительно определены два списка IP-фильтров: All ICMP Traffic и All IP Traffic. Трафик ICMP, как правило, связан с командой Ping или Tracert.
    С помощью мастера IP-фильтра определите IP-трафик, соответствующий исходной и конечной точке. Для определения источника и назначения пакетов можно указать IP-адреса источника и назначения пакетов, DNS-имена, функцию сервера (например, DHCP-сервер, DNS-сервер, WINS-сервер или основной шлюз) и тип IP-протокола (включая номер TCP/UDP-порта). Отраженный фильтр распространяется на пакеты, которые имеют противоположные адреса источника и назначения.
    В групповой политике для правил IP-безопасности предварительно определены 3 действия IР-фильтра:
    • Permit (Разрешить). Это действие фильтра разрешает передавать незащищенные IP-пакеты
    • Request Security (Optional). (Запрашивать безопасность (опционально)) Разрешает передачу незащищенных IP-пакетов, однако запрашивает согласование безопасности клиента (предпочтительно шифрование)
    • Require Security (Требовать безопасность). Переключает локальный компьютер в режим запроса безопасной передачи IP-пакетов. Если методы безопасности (включая шифрование) установить невозможно, локальный компьютер прекратит обмен данными с таким клиентом

    Страница Метод проверки подлинности. Согласование безопасности можно выполнить только после проверки подлинности клиентов IPSec. По умолчанию проверка подлинности производится с помощью службы каталогов Active Directory или протокола Kerberos. Отметим, что эта страница не открывается при выборе действия Permit на странице Действие фильтра.
    IP-фильтры, списки IP-фильтра и действия фильтра, создаваемые для правила IP-безопасности, могут использоваться совместно с другими правилами IP-безопасности. Эти компоненты можно также конфигурировать и без помощи мастера правил безопасности. Для этого в консоли Локальная политика безопасности или объекте групповой политики ПКМ узел Политики IP-безопасности и примените команду Управление списками IP-фильтра и действиями фильтра.

    Правила безопасности подключений (ПБП)


    ПБП не включают фильтры и действия фильтров. Функции, обеспечиваемые фильтрами и действиями фильтров, встроены в каждое ПБП, однако возможности фильтрации ПБП не настолько обширны, как в политиках IP-безопасности. Правила безопасности подключений не применяются к отдельным типам трафика IP, например через порт 23. Эти правила применяются ко всему трафику IP определенных IP-адресов, подсетей или серверов в сети.
    Вначале правило безопасности подключения выполняет проверку подлинности указанных в правиле компьютеров перед подключением. Затем это правило обеспечивает безопасность обмена данными. Если правило безопасности подключения требует безопасности подключения и два компьютера не могут выполнить проверку подлинности друг друга, подключение блокируется.
    По умолчанию ПБП обеспечивают лишь безопасность данных проверки подлинности (информация для установления подлинности, целостность данных и защита от повторного воспроизведения (replay)). По этой причине можно сказать, что ПБП выполняют лишь проверку подлинности подключений. Тем не менее, для ПБП можно также отконфигурировать шифрование данных.
    ПБП можно отконфигурировать для любого компьютера в консоли Брандмауэр Windows в режиме повышенной безопасности (Windows Firewall with Advanced Security, WFAS). Параметры WFAS можно также настроить для множества клиентов в сети с помощью групповой политики.
    С помощью функций экспорта и импорта политики можно создать один набор правил безопасности подключений и экспортировать его на другие компьютеры или объекты групповой политики.

    Создание и настройка ПБП


    GPO\Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\WFAS\WFAS — LDAP://aдpec. ПКМ ПБП - Новое правило.
    1. Страница Тип правила:
    1.1 Изоляция. Основное правило, которое используется для проверки подлинности всего трафика выбранных сетевых профилей (Домен, Личный и Общий).
    1.2 Освобождение от проверки подлинности (Authentication Exemption). Этот тип правила можно использовать для освобождения конкретных компьютеров, группы или диапазона IP-адресов (компьютеров) от проверки подлинности самих себя независимо от других ПБП.
    Обычно такие правила служат для подтверждения доступа к компьютерам инфраструктуры, с которыми должен обмениваться данными локальный компьютер перед возможной проверкой подлинности. Эти правила также пригодны для компьютеров, которые не могут применять метод проверки подлинности, отконфигурироваииый для данной политики и профиля.
    1.3 Сервер-сервер (Server-To-Server). Позволяет выполнять проверку подлинности коммуникаций между IP-адресами или наборами адресов, включая конкретные компьютеры и подсети.
    1.4 Туннельный (Tunnel). Этот тип правила используется для настройки режима туннелирования IPSec шлюзов VPN.
    1.5 Настраиваемый (Custom). Служит для создания правила с особыми параметрами или комбинацией функций предыдущих типов правил.
    2. Страница Конечные точки (Endpoints). На этой странице мастера можно указать удаленные компьютеры, с которыми требуется выполнять согласование безопасности подключения IPSec.
    3. Страница Требования (Requirements). На этой странице можно указать обязательное требование или только запрос проверки подлинности подключения для определенных конечных точек.
  • Страница Метод проверки подлинности конечных точек. При выборе первой опции, По умолчанию, используется один из методов проверки подлинности, указанный на вкладках профилей окна свойств узла WFAS. Среди других методов проверки можно выбрать проверку подлинности Kerberos (Active Directory) для компьютеров и пользователей, проверку подлинности Kerberos лишь для компьютеров, сертификат или применить опцию Дополнительно. С ее помощью эти методы проверки можно также настроить как опциональные.
    Параметры IP-безопасности можно определить в свойствах узла WFAS объекта групповой политики или соответствующей консоли. В открывшемся диалоговом окне свойств перейдите на вкладку Параметры IPSec. Параметры IPSec по умолчанию (IPSec defaults) - Настроить.
    Например, для того чтобы настроить шифрование данных для ПБП, вначале выберите опцию Дополнительно в области Защита данных, а затем щелкните кнопку Настроить. Откроется диалоговое окно Настройка параметров защиты данных (Customize Data Protection Settings). В этом окне установите флажок Обязательное шифрование для всех ПБП, использующих эти параметры (Require Encryption For All Connection Security Rules That Use These Settings).
    Исключить ICMP из IPSec (Exempt ICMP from IPSec) Этот параметр на вкладке Параметры IPSec используется для освобождения сообщений ICMP (Ping и Tracert) от проверки подлинности и шифрования. С помощью незашифрованных сообщений ICMP можно устранять неполадки при безуспешном согласовании IP-безопасности.

    Авторизация подключений в брандмауэре Windows


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

    Антивирус


    Начнём со штатных средств Windows 8 и Server 2012:
    Средство удаления вредоносных программ - предназначено для удаления только наиболее распространённых троянов и вирусов и, по официальным данным, ни в коем случае целиком не заменяет антивирусное ПО, т.к. не обеспечивает защиту (не предотвращает заражение), а осуществляет всего лишь проверку и удаление. На самом деле оно сканирует только активные процессы.
    Защитник Windows - полноценный антивирус (бывший Security Essentials). Идёт с клиентскими ситемами по-умолчанию. На Server его нет и не рекомендуется его туда ставить. Для серверов подразумевается использование других решений. Не делает автопроверку системы в случае пропуска запланируемой.
    Windows Live OneCare – онлайновый сервис, обеспечивающий поиск и удаление троянов, вирусов, программ-шпионов и -реклам.
    System Center 2012 Endpoint Protection (ранее Forefront Endpoint Protection, Forefront Client Security и Client Protection) — нужен для централизованного управления клиенскими антивирусами. Весит более 5 Гбайт. Платен.

    System Center Endpoint Protection


    Клиент, устанавливаемый на конечных компьютерах, обеспечивает защиту от известных и неизвестных угроз, вирусов, шпионского ПО
    и руткитов. Чтобы удовлетворить всем требованиям, SCEP содержит несколько компонентов, работающих на разном уровне — приложения, файловая система и сеть. Для выполнения своих задач он интегрируется с Центром безопасности Windows, Windows Firewall,
    AppLocker, управляя их настройками и отслеживая изменения в
    конфигурационных файлах системы. Во время установки клиента добавляются специальные компоненты, позволяющие строить защиту на уровне ядра, в том числе — и обнаруживать руткиты. Согласись,
    только у разработчиков ОС могут быть все необходимые инструменты,
    работающие на очень низком уровне, остальным вендорам приходит-
    ся как-то выкручиваться. Для защиты от многих типов сетевых атак
    SCEP содержит IPS (систему предотвращения вторжения) — Network Inspection System (NIS). Напомню, что NIS используется в том числе
    и на TMG 2010, только в случае с SCEP она защищает от атаки
    отдельный хост, а не сеть. Для решения своих задач клиент взаимо-
    действует и с NAP.
    Антивирус наряду с традиционным сигнатурным анализом ис-
    пользует и модуль динамической трансляции ( Dynamic translation and Emulation), когда программа прогоняется в режиме эмуляции
    и анализируется, что она делает. Таким образом, увеличивается
    вероятность обнаружения новых вирусов. На этом этапе может включиться в работу еще один интересный компонент, известный тем, кто
    юзает Microsoft Security Essentials - служба динамических сигнатур
    DSS (Dynamic Signature Service). Если во входе анализа файл будет
    расценен как подозрительный, (например, пытается сразу изме-
    нить защищенные части ОС), но сигнатуры этого вируса в базе нет.
    то генерируется профиль файла, который отсылается для анализа
    в специальные сервисы Microsoft — DSS, SpyNet и MRS (Microsoft Reputation Services). В случае, когда в базе обновлений сигнатура уже есть, но она не скачана, автоматически обновляются базы. В
    сигнатурах содержится не только часть «тела» вируса, но и некоторые
    типичные сценарии поведения, позволяющие однозначно опреде-
    лить зловредность программы.
    Одна из задач, которые ставилась при разработке SCEP — «не мешать», поэтому конфигурация поумолчанию рассчитана на высокий уровень
    производительности. Управление функциями SCEP производится на
    основе политик, и администратор может гибко настроить функции
    системы защиты в зависимости от их назначения — рабочая станция,
    файловый или почтовый сервер и так далее. В поставке доступен ряд
    предустановок, представляемых компаниями-разработчиками для
    своих продуктов. Также изначально минимизировано взаимодей-
    ствие с пользователем, который в настройках поумолчанию получает
    только действительно важные сообщения. Еще один интересный
    момент. Кстандартным сканированиям (потребованию и распи-
    санию) добавлен интеллектуальный режим, когда SCEP
    оценивает состояние системы и применяет решение об
    уровне проверки. В том случае, когда вирус или руткит
    нельзя удалить на рабочей системе, будет произведена
    попытка удаления в процессе перезагрузки. В качестве
    клиентских компьютеров поддерживаются WinXP3/ Vista /7
    и серверные версии Win2k3/2k8/2k8R2. Управление из
    центральной консоли версиями на Win7 Starter, Win7
    Home и Vista Basic не предусмотрено и установить кли-
    ентскую часть на такие компьютеры можно лишь вручную.
    В принципе почти все это мы втой или иной мере встре-
    чали у разработчиков других антивирусных продуктов
    корпоративного уровня. Еще одна фишка SCEP состоит в
    том, что для централизованного управления используется
    System Center Configuration Manager. Последний предна-
    значен для управления группами компьютеров, установки
    и обновления ПО на них, это упрощает установку SCEPHa
    конечных компьютерах. Это позволяет снизить стоимость
    владения, особенно в тех случаях, если организация
    уже использует SCCM.
    Нет необходимости в развертывании дополнительной
    инфраструктуры, все настройки производятся в едином
    интерфейсе, администратор сразу видит состояние всех
    компонентов сети. Опять же необходимости в переучива-
    нии персонала. Соответственно, уже готово все для сбора
    данных, последующий апдейт ядер и антивирусных баз.
    Но это же является и недостатком FEP, ведь если нет. то
    SCCM придется его развернуть — со всеми вытекающими из этого шага последствиями. Если корпоративную
    версию Касперского или «Др. Веб» можно установить «на
    посмотреть» за полчасика, то в случае с SCEP тебя, воз-
    можно, ждет пара «веселых» дней :).

    Установка SCCM

    Для работы SCEP понадобится и SCCM+SQL Server.
    Во время
    установки базы данных, необходимо активировать на SQL
    Analysis Services, Integration Services и Reporting Services.
    Последний нужен только для сервера отчетов, который
    может быть один на всех в сети. Причем здесь тех, кто
    хочет установить «на посмотреть» ожидает неприятный
    сюрприз — триальная версия MSSQL не поддержива-
    ется, годится только лицензионная Standart/Enterprise.
    Об этом напрямую нигде в доках не сказано, просто в
    процессе проверки совместимости с SQL-сервером
    мастер установки SCEP не обнаруживает сервисы Analysis
    и Reporting. Все сервисы MSSQL, в частности SQL Server
    Agent следует перевести в режим автозапуска.
    В зависимости от конфигурации может понадобиться
    создать SPN (Service Principle Name) для сервиса MSSQL.
    Для этого в консоли вводим команду вида:
    >setspn -A MSSQLSvc/srv01.example.org: 1433
    example\mssqlserver
    Registering ServicePrincipalNames for
    CN=Mssqlserver,CN= Users ,DC=example,DC=org
    MSSQLSvc/srv01.example.org:1433
    Updated object
    Как видишь, процесс несложен, нужно только разобрать-
    ся в данных, которые следует ввести, ведь если SPN для учетной записи будет дублироваться, получим ошибку. В этом случае
    лучше удалить при помощи ключа «-d» все записи и добавить одну
    действительно необходимую.
    Обычно все данные можно получить, проанализировав логи. В моем
    случае это выглядело так:
    [Verbose] Retrieved SQL server account : Internal:
    'EXAMPLE\ mssqlserver'; External: 'EXAMPLE\mssql'
    [Verbose] Retrieved SQL SPN: MSSQLSvc/SRV01
    [Verbose] Validating SPN. Account: EXAMPLE\mssqlserver.
    SPN: mssqlsvc/srv01
    Ставим компоненты на Win2k8R2:
    PS> Import - Module servermanager
    PS> Add-WindowsFeature BITS,RDC,Web-WMI,Web-Dav-Publishing
    Далее ставим SCCM.

    Установка SCEP

    Теперь все готово для установки серверной части SCEP. Непосред-
    ственно перед развертыванием SCEP лучше всего воспользоваться
    анализатором соответствия рекомендациям Microsoft SCEP (cick.ru/G-1V), который покажет, насколько
    система готова к установке SCEP. Соответствующий функционал есть и в программе установки, но запускается он почти в самом конце.
    При установке клиентской части, будет проверено наличие антиви-
    русных программ других производителей, и если таковые найдут-
    ся, они будут автоматически деинсталлированы. Архив, который
    содержит клиента и расширения для SCCM под соответствующую
    платформу, и язык можно скачать с сайта MS. Просто запускаем мастер и следуем его указаниям. По ходу следует определиться с типом установки. Предлагается четыре
    варианта:
    • Basic topology — устанавливается база данных, расширение сервера и консоли SCCM, компоненты сервера отчетов;
    • Basic topology with remote reporting database — то же, что и пред-
    ыдущий, только мастер позволяет указать альтернативный сервер
    отчетов;
    • Advanced topology — полностью настраиваемая установка, в ходе
    которой выбираются компоненты и задается произвольное раз-
    мещение базы отчетов, имена базы данных и т.д.
    • Install only Configuration Manager Console Extension for EP —
    ставим только расширение консоли для SCCM.
    Если нужно поставить вручную клиентскую часть, то выбираем
    Advanced topology и снимаем все флажки.
    Теперь переходим к настройкам Reporting Services. Здесь потребуется ввести URL сервиса и учетную запись с правами администратора
    домена. Причем мастер подставит URL, но в формате рабочей груп-
    пы, нужно просто дополнить его полным FQDN сервиса.
    Как и прочие, продукт SCEP может обновляться через Windows
    Update. Это лучший вариант, поэтому на следующем шаге масте-
    ра обязательно устанавливаем соответствующий флажок. Далее
    определяемся с участием в Microsoft SpyNet. Отказываться здесь
    не стоит. По умолчанию предлагается вариант Basic, когда в MS отсылается минимум информации о файле. Его обычно предпочитают
    большинство пользователей, беспокоящихся о конфиденциально-
    сти, ведь в случае активации Advanced отправляются дополнительные данные. Далее все стандартно. Указываем, куда ставить и ждем,
    пока отработает проверка зависимостей. В случае ошибки подсказку
    можно узнать, нажав ссылку рядом или просмотрев логи. Базы внутри пакета уже устарели, все равно придется потом активировать апдейт вручную. По окончании в панели появится значок клиента SCEP, некоторое время он будет
    «приходить в себя» пока обновится и проверит систему, затем
    значок сменит цвет на зеленый, означающий, что все в порядке. Во
    время установки клиента будет применена дефолтовая политика,
    в некоторых случаях работа компонентов SCCM будет блокирована
    (как правило, подключение или процессы MSSQL) и потребуется в
    дальнейшем переопределить политику. Удобнее это сделать, создав
    коллекцию, в которой сервер SCCM будет единственной системой.
    В консоли SCCM в разделе Computer Management появится меню SCEP, перейдя в которую мы увидим сводную
    информацию о статусе клиентов, систем защиты и политик. Все
    установки собраны в трех вкладках — Policies (управление политиками), Alerts (настройка 4 групп уведомлений) и Reports (отчеты).
    Плюс несколько подпунктов, начинающихся с SCEP-*, будут доступны в Computer Management — Desired Configuration Management —
    Configuration Baselines. Следующим шагом необходимо развернуть клиенты на удаленных системах. Способов существует много,
    в том числе несколько вариантов предлагает и SCCM. Разберем
    «штатный». Для начала следует создать коллекции. Далее про-
    сто выбираем коллекцию и в контекстном меню пункт Distribute
    — Software. Запустится мастер, на втором шаге которого отмечаем
    Select an existing package и выбираем Microsoft Corporation SCEP — Deployment 1.0. Далее следуем указаниям, хотя в большинстве
    случаев ничего, за исключением выбора применяемой политики,
    изменять не нужно. По умолчанию доступно две политики — для
    клиента и сервера, просто отмечаем наиболее подходящую. Все,
    клиентская часть будетустановлена на удаленных системах. Про-
    цесс будет показан на панели мониторинга, также можно сформиро-
    вать отчет, выбрав пункт Deployment Overview .

    Настройка политик

    Конфигурация клиентов задается при помощи политик. Создать,
    изменить, копировать которые можно в подменю Policies. Новая
    политика создается при помощи пошагового мастера, появляю-
    щегося при выборе ссылки New Policy. На втором шаге следует
    определиться с типом политики. Доступны три варианта (стан-
    дартная для десктопов, повышенная защищенность и увеличен-
    ная производительность). Если политика создается для сервера,
    обращаемся к списку Policy Template , где предлагается еще с
    десяток шаблонов. Далее дополнительно задаются тип и время
    сканирования, каталоги которых следует исключить при скани-
    ровании, ресурс с которого получает обновления (UNC, WSUS и
    Windows Update). В настройках клиента флажками активируется реалтайм-защита, сканирование и предупреждения. Все, политика
    создана. Чтобы изменить установки Windows Firewall для выбранной политики, следует открыть окно ее свойств и перейти в соответствующее окно. Новые политики получают больший приоритет, чтобы их изменить следует выбрать ссылку Edit Policy Precedence и
    расставить их как нужно.
    Ряд проверок вроде принудительного сканирования дисков можно
    выполнить, выбрав компьютер в окне SCCM и вызвав его свойства.
    В качестве дополнительных инструментов для работы SCEP можно
    рекомендовать:
    • Пакет управления безопасностью SC Endpoint Protection
    Security Management Pack .
    • Пакет управления наблюдением за работоспособностью сервера
    SC Endpoint Protection Server Health Monitorinq Manaqement Pack.
    • Средства SC Endpoint Protection.
    Названия первых двух говорят сами за себя. Последний содержит
    ряд инструментов, позволяющих применять GPO для централизованного управления, предоставления оптимизированных параметров для каждой роли сервера и диагностики проблем.
    Клиентская часть
    достаточно функциональна, чтобы доверить ей защиту своих систем.
    И несомненно, что появление такого продукта, как SCEP добавит конкуренции в этом сегменте, от которой мы по-любому выиграем.

    Брандмауэр Windows


    Главные особенности: способность выявлять некоторые типы сетевых атак. Чтобы при последующем подключении к сети был установлен тот же профиль, в системе запущена специальная служба Network Location Awareness (NLA).
    В настройках шаблонов Private и Public пользователь может заблокировать все входящие соединения для программ, не включенных в список разрешенных (Block all incoming connections, including those in the list of allowed programs), – обеспечивая максимальную защиту.
    Ранее все изменения сохранялись в активном профиле, и при применении другого профиля их приходилось повторять. Теперь можно задать профили, для которых производится изменение.
    Кроме того, сторонние разработчики получили обновленный API, позволяющий легко задействовать возможности WF или добавить свои функции.
    Параметры брандмауэра Windows по умолчанию прекрасно работают с компонентами, встроенными в Windows. Правила брандмауэра можно применять по отдельности к профилям:
  • Домен. В случае доступности контроллера домена задействуется этот профиль. И его нельзя поменять.
  • Личный (Private) Применяется при подключении компьютера к частной сети. По умолчанию сети не рассматриваются как частные.
  • Общий (Public) Этот профиль по умолчанию применяется ко всем сетям, если контроллер домена недоступен. По умолчанию блокирует весь входящий трафик, не связанный с текущим подключением.
    Настройка области действия с использованием локальных IP-адресов выполняется, только когда компьютер отконфигурирован со множеством IP-адресов и принимать подключения по всем IP-адресам не требуется. В диалоговом окне IP-адрес Свойств правила выберите одну из опций.

    Фильтрация входящего трафика


    Брандмауэр Windows включен по умолчанию для блокирования большинства нежелательных входящих подключений.
    При установке компонента Windows, которому требуются входящие подключения, система Windows автоматически включает нужные правила брандмауэра. При установке приложения, не создающего автоматически правила требуемые для брандмауэра, вам придется создать эти правила вручную.
    Правила брандмауэра можно создать с помощью стандартной консоли Брандмауэр Windows в режиме повышенной безопасности или групповой политики — посредством аналогичного интерфейса, расположенного по адресу Конфигурация компьютера\Политики\КонфигурацияWindows\Параметры безопасности\Брандмауэр Windows в режиме повышенной безопасности\Брандмауэр Windows в режиме повышенной безопасности.
    Для создания входящего фильтра:
    На странице Тип правила Для программы. Правило, разрешающее или блокирующее подключения конкретного исполняемого файла независимо от используемых номеров портов.
    На странице Действия Разрешить безопасное подключение ( Allow The Connection If It Is Secure) Разрешает подключения, если они защищены протоколом IPSec. При желании вы можете установить флажок Обязательное шифрование подключений (Require The Connections To Be Encrypted). При установке флажка Переопределить правила блокировки (Override Block Rules) создаваемое правило будет переопределять другие правила, запрещающие клиенту подключаться к сети. При выборе такого типа правила мастер также предложит указать пользователей и компьютеры, авторизованные для установления этого типа подключения.
    Перейдите на вкладку Программы и службы. Обратите внимание на то, что для исполняемого файла %SystemRoot%\system32\TlntSvr.exe службы Telnet по умолчанию отконфигурировано правило разрешения коммуникаций. Щелкните кнопку Параметры и убедитесь, что выбрана служба Telnet.
    Монитор ресурсов/раздел Порты прослушивания отображает все порты, которые прослушивают приложения перед брадмауэром. Здесь есть столбец Состояние порта брадмауэра - признак Ограниченности означает степень открытости порта для профилей сетей (Частная/Приватная/Домен). Исключение составляет петлевой адрес. Кроме того, эти статусы оперативно не обновляются.
    Приложение может иметь TCP-подключение, но не иметь прослушиваемых портов.

    Фильтрация исходящего трафика


    По умолчанию Брандмауэр Windows разрешает весь исходящий трафик. Разрешение исходящего трафика подвергает компьютер меньшей угрозе взлома, чем разрешение входящего.
    Чтобы блокировать исходящие подключения ПО УМОЛЧАНИЮ, в свойствах Брадмауэра перейдите на вкладку Профиля и в раскрывающемся списке Исходящие подключения (Outbound Connections) выберите опцию Блокировать. WServer содержит фильтры исходящего трафика для основных сетевых служб, которые нужны, например если вы запретите все исходящие.

    Настройка с помощью групповой политики


    1. Конфигурация компьютера\Политики\Конфигурация Windows\Пapaмeтры безопасности\Брандмауэр Windows в режиме повышенной безопасности\Брандмауэр Windows в режиме повышенной безопасности. Этот узел применяет параметры только к компьютерам WClient и WServer и имеет точно такой же интерфейс, как и соответствующий узел в Диспетчере сервера. Этот узел всегда следует использовать при настройке компьютеров WClient и WServer, поскольку он обеспечивает более детальную конфигурацию правил брандмауэра.
    2. Конфигурация компьютера\Политики\Административные шаблоны\Сеть\Сетевые подключения\Брандмауэр Windows. Этот узел применяет параметры к компьютерам Windows XP, Windows Server 2003, WClient и WServer. Он обеспечивает меньше гибкости. Если вы не используете новые возможности IP-безопасности в WClient, то с помощью этого узла можете отконфигурировать параметры для всех своих клиентов.
    Чтобы достичь наилучших результатов, создайте отдельные объекты GPO
    для WClient/WServer и Windows XP/Windows Server 2003.
    Затем используйте запросы WMI для применения GPO к компьютерам с соответствующей версией Windows. Более подробные сведения можно найти в статье 555253 «HOWTO: Leverage Group Policies with WMI Filters» в базе знаний Microsoft по адресу support .microsoft.com/kb/555253.
    ПКМ объект Брандмауэр Windows в режиме повышенной безопасности. Перейдите на вкладку профиля. В области Ведение журнала щелкните кнопку Настроить. Чтобы записывать пакеты, сбрасываемые брандмауэром Windows, выберите в раскрывающемся списке Записывать пропущенные пакеты (Log Dropped Packets) опцию Да.
    В компаниях, где такой журнал ведут практически постоянно, это может влиять на производительность. Поэтому ведение журнала следует включать только при активном устранении неполадок, а потом отключать.

    Идентификация сетевых коммуникаций


    В документации сетевых приложений часто отсутствуют четкие сведения о протоколах, используемых приложением. Но посредством правил брандмауэра можно разрешить все коммуникации, требуемые для работы отдельной программы.
    Если вы предпочитаете использовать правила брандмауэра для портов или вам нужно отконфигурировать сетевой брандмауэр, который может идентифицировать коммуникации лишь на основе номера порта, а в документации приложения не указаны требования брандмауэра, можно проанализировать поведение приложения и определить используемые им порты. Самый простой способ — воспользоваться утилитой netstat. На сервере запустите приложение, а затем запустите следующую команду, чтобы определить порты, прослушиваемые для активных подключений:
    netstat -a -b
    Все строки в результатах команды, где в столбце Состояние (State) указано LISTENING , пытаются принимать входящие подключения на номере порта, указанном в столбце Локальный адрес. Исполняемое имя файла приведено после строки. Например, в следующих результатах показано, что служба RpcSs, запускаемая в процессе SvcHost.exe (который запускает много служб), прослушивает подключения на ТСР-порте 135:
    Активные подключения
    Имя Локальный адрес Внешний адрес Состояние
    TCP 0.0.0.0:135 Dcsrv1:0 LISTENING
    RpcSs
    [svchost.exe]
    Аналогичным образом в следующих результатах показано, что служба DNS прослушивает подключения на ТСР-порте 53:
    Активные подключения
    Имя Локальный адрес Внешний адрес Состояние
    TCP 0.0.0.0:53 Dcsrv1:0 LISTENING
    [dns.exe]

    NAP


    Сценарий: Из командировки в офис возвращается сотрудник с мобильным компьютером. В разъездах он подключал свой компьютер к беспроводной сети, куда компьютер еще одного гостя занес червя. При подключении компьютера к частной сети червь немедленно начал распространяться на уязвимые компьютеры, миновав систему безопасности на периметре.
    При подключении к локальной сети с использованием NAP (Network Access Protection) компьютеры должны соответствовать конкретным требованиям состояния, таким как установка самых последних обновлений. Если компьютеры не соответствуют этим требованиям, они могут быть помещены в сетевой карантин, где могут загрузить обновления, установить антивирусное ПО и получить дополнительные сведения о требованиях LAN (рис. 8-3).
    Например, во время настройки контроллера домена AD в сети восстановления работоспособности контроллеру следует назначить лишь доступ чтения. Аналогичным образом необходимо использовать отдельные серверы DHCP и DNS, для того чтобы снизить угрозу распространения вредоносного программного обеспечения с компьютера на производственный сервер.
    Безопасность — не абсолютное понятие и измеряется лишь степенью угрозы. NAP не может помешать опытному хакеру подключиться к вашей сети. Оценивая NAP как метод защиты от атак, помните, что NAP доверяет агенту работоспособности системы SHA (System Health Agent), который отчитывается о состоянии системы. Агент SHA также запускается на клиентском компьютере. Он играет роль, аналогичную роли сотрудника безопасности в аэропорту, который просто предупреждает пассажиров, чтобы они случайно не пронесли на самолет запрещенные вещества. Злоумышленник солжет и не скажет, что у него в чемодане. Но солгать не так-то просто: агент SHA представляет заявку о работоспособности SoH, подтверждающую подлинность отчета. Помочь в борьбе со злоумышленниками могут также дополнительные меры безопасности, например требование IP-безопасности подключений. Тем не менее, всегда существует вероятность, что кто-нибудь создаст вредоносный агент SHA под видом настоящего.
    Сетевой компонент должен внедрить NAP, разрешая и запрещая доступ к сети. Методы внедрения NAP (внедрение NAP с помощью шлюза служб терминалов не описано в этой книге):
    • Безопасные подключения IPSec
    • Точка доступа 802.1X. Точки доступа 802.1X обеспечивают мощную поддержку NAP, однако для этого потребуется сетевая инфраструктура, поддерживающая 802.1X.
    • VPN-cеpвеp
    • DHCP-cepвep

    Их (кроме 802.1X) можно реализовать лишь с помощью системы WServer.
    Проверка NAP выполняется с помощью 2 компонентов:
    1. Агенты SHA - клиентские компоненты, создающие свои заявления о работоспособности SoH ( Statement of Health) с описанием работоспособности клиентского компьютера. Клиент NAP комбинирует заявления SoH от множества агентов SHA в пакет состояния работоспособности системы SSoH (System Statement of Health), включающий данные версии для клиента NAP.
  • Средствами проверки работоспособности системы (SHV (System Health Validator)), на основании которых проводят анализ агенты, называются серверные компоненты, которые анализируют заявление SoH и создают отклик SoH (SoH Response, SoHR). Каждое средство SHV генерирует отклик SoHR, который может содержать инструкции по восстановлению работоспособности (например, номер версии файла сигнатур вирусов). Сервер политики работоспособности NAP (СПР NAP) использует SoHR для определения уровня доступа, который следует назначить клиентскому компьютеру, а также всех действий, необходимых для восстановления работоспособности. СПР NAP комбинирует отклики SoHR множества SHV в пакет SSoHR (System Statement of Health Response).
    Системы WClient, WServer и XP SP3 включают агент SHA и SHV, которые отслеживает параметры Центра обеспечения безопасности (Windows Security Center). Корпорация Microsoft и сторонние разработчики могут создавать SHA и SHV, обеспечивающие комплексную отчетность и обращающиеся к API-интерфейсу NAP.
    Например, агент работоспособности защиты Windows — это SHA в WClient, а средство проверки работоспособности защиты Windows — это SHA в WServer. Они характеризуются следующими проверками в своих SHV:
    • установлена и активизирована программа-брандмауэр;
    • установлено и работает антивирусное ПО;
    • установлены актуальные обновления антивирусного ПО;
    • установлено и работает антишпионское ПО;
    • установлены актуальные обновления антишпионского ПО;
    • активизирована служба обновления Microsoft Update Service.

    Все это сконфигурировано в политиках работоспособности клиентов или в SHV систем NPS.
  • Агент карантина (Quarantine Agent, QA) создает отчеты о состоянии работоспособности SHA. И, наконец, клиент принуждения (Enforcement Client, EC) обеспечивает доступ к Сети, основываясь на состоянии системы.
    Имеющийся API позволяет третьим сторонам создавать реализации EC для своих решений, а использование сетевого протокола идентификации IEEE 802.1X гарантирует совместимость с различными видами устройств. В настоящее время разработан протокол авторизации учетных данных узла (Host Credential Authorization Protocol, HCAP), обеспечивающий интеграцию Microsoft NAP с подобной разработкой Cisco NAC (Network Admission Control). Активировать поддержку HCAP можно на этапе установки сервера NPS. Имеются данные о разработках агента Anyclick for NAP для Mac и Linux в UNETsystem (www.unetsystem.co.kr). Компания Avenda (www.avendasys.com) уже представила готовое (правда, не бесплатное) решение Avenda Linux NAP Agent для использования в Linux.
    Подключение NAP устанавливается следующим образом:
    1. Клиент NAP подключается к сети с NAP и отправляет пакет SSoH на сервер NAP через точку NAP.
    2. СПР NAP использует установленные средства проверки работоспособности SHV и политики работоспособности, определяющей соответствие клиента NAP требованиям. После сравнения SoH с политикой работоспособности выдается разрешение или отказ в подключении. На основании такого результата NPS выполняет одно из 4 действий. В случае разрешения (работоспособность клиента удовлетворительна) для клиента просто выполняется процедура подключения. Если сравнение SoH с политикой дает неудовлетворительный результат (т.е. работоспособность клиента неудовлетворительна), NPS может запретить клиенту подключение, подключить клиент к ограниченной сети или даже разрешить подключение клиента, несмотря на его неудовлетворительную работоспособность.
    3. NAP отправляет пакет SSoHR клиенту NAP через точку NAP. После этого точка NAP подключит соответствующий требованиям компьютер ко внутренней сети, а компьютер, не удовлетворяющий этим требованиям, подключит к сети восстановления работоспособности.
    4. Каждый агент SHA обрабатывает ответ SoHR. SHA, не удовлетворяющие требованиям работоспособности, могут попытаться обеспечить соответствие.
    5. Если все SHA не соответствуют требованиям работоспособности, весь процесс повторится, пока не будет получен успешный результат.
    Компьютер можно привести в соответствие с требованиями работоспособности вручную и автоматизированно с помощью таких инструментов, как Microsoft Systems Management Server 2003 и Microsoft System Center Configuration Manager 2007.
    Сервер NAP оценивает работоспособность клиентских компьютеров как RADIUS-сервер. Если у вас в сети есть RADIUS-серверы WS2003 или WS2000 и используется Служба проверки подлинности в Интернете (Internet Authentication Service, IAS), вы можете обновить их до WServer и настроить как серверы политики работоспособности NAP. Если RADIUS-серверы установлены на других ОС, вам придется отконфигурировать новые серверы политики работоспособности WServer, настроить политику работоспособности и выполнить миграцию существующих клиентов RADIUS на серверы политики работоспособности NAP. С помощью политик проверки подлинности подключения отдельному RADIUS-серверу можно разрешить выполнять роль сервера политики работоспособности NAP и проверять подлинность запросов от других клиентов RADIUS. Политики требований работоспособности определяют клиентов, соответствующих требованиям работоспособности, сами эти требования, и действия для клиентов, им не соответствующих. Политика требования работоспособности представляет собой комбинацию из следующих компонентов. 1. Политика запроса на подключение (CRP). Определяет обработку запроса NPS-сервером. 2. SHV3. Группы серверов обновлений, к которой получают доступ клиенты, не соответствующие требованиям работоспособности. 4. Политика работоспособности. Определяет требования работоспособности с помощью параметров SHV. Для клиентов, соответствующих и не соответствующих требованиям работоспособности, следует предусмотреть отдельные политики работоспособности. 5. Сетевая политикаСервер NAP Диспетчер сервера/Роли/Службы политики сети и доступа/Службы роли - Сервер политики сети (NPS). Этого вполне достаточно для использования компьютера WServer в качестве RADIUS-сервера для внедрения защиты доступа к сети 802.1X, VPN или DHCP. Службы роли HRA и HCAP потребуют наличия IIS и Windows Process Activation Service. Служба роли RRAS необходима для клиентов, подключающихся удаленно (Dial-up & VPN, NAT). 1.\Роли\Службы политики сети и доступа\NPS (если роль Службы политики сети и доступа была установлена недавно, может потребоваться закрыть и вновь открыть Диспетчер сервера).
    2. Консоль управления позволяет настроить NPS-сервер несколькими способами. Самый простой — выбрать нужную конфигурацию в раскрывающемся списке «Стандартная конфигурация» на заглавной странице. Отсюда можно быстро настроить сервер NAP, а также RADIUS-сервер для удаленного доступа (Dial-up & VPN) и IEEE 802.1x-подключения. К примеру, в панели сведений выберите в раскрывающемся списке опцию Защита доступа к сети и щелкните ссылку Настроить NAP
  • На странице Выберите метод подключения к сети для использования с NAP выберите способ сетевых подключений для принудительной защиты NAP (IPSec, IEEE 802.1x Wired и Wireless, DHCP или VPN)
  • На следующей странице (ее название зависит от выбранного способа сетевых подключений) нужно добавить все серверы принудительной защиты доступа к сети под управлением HRA (Health Registration Authority) (служба ролей Центр регистрации работоспособности), кроме локального компьютера, и клиентов RADIUS (в смысле не клиентские компьютеры, а сервера сетевого доступа). Например, при внедрении принудительной защиты доступа к сети 802.1X может потребоваться добавить IP-адрес каждого коммутатора (каждого VPN-сервера, каждого DHCP-сервера с поддержкой NAP).
    5. На странице Настроить группы пользователей и группы компьютеров можно принять параметры по умолчанию и разрешить подключения всем пользователям. Чтобы предоставить или запретить доступ для группы, щелкните кнопку Добавить компьютер (Add Machine ).
    6. При выборе 802.1X и VPN откроется страница Настроить метод проверки подлинности. Здесь можно указать сертификат сервера NPS и типы проверки подлинности ЕАР, которые будут применяться на уровне компьютера или пользователя. При выборе сетевых подключений 802.1X на странице Настройка виртуальных локальных сетей можно настроить неограниченную и ограниченную сеть VLAN.
    7. На странице Определите политику работоспособности NAP (Define NAP Health Policy) можно выбрать установленные средства SHV. Установите флажок Разрешить полный доступ к сети для неподходящих для NAP клиентских компьютеров (Allow Full Network Access To NAP-Ineligible Client Computers ) (мониторинг).
    На основе имени, указанном на странице Выберите метод подключения к сети для использования с NAP Мастер настройки NAP создает в ветке NPS\Политики следующее:
    1. политику запросов подключений;
    2. необязательные и принудительные политики работоспособности;
  • необязательные и принудительные сетевые политики

    SHV и Политики работоспособности


    В \Роли\Службы политики сети и доступа\NPS\Защита доступа к сети\Средства проверки работоспособности системы\в панели сведений ПКМ средство SHV и примените команду Свойства. Сначала отконфигурируйте параметры Разрешение кода ошибки ( Error Code Resolution), показанные на рис. 8-12. Для каждого из 6-ти параметров можно определить совместимость или несовместимость клиентов. Как правило, нужно задавать параметр Несовместимый (Noncompliant). Если же совместимые клиенты получают код ошибки (например, если SHV или SHA пытается обратиться к внешним службам, но не может сделать это из-за неполадок подключений), для разрешения кода ошибки можно назначить параметр Совместимый (Compliant).
    Политики работоспособности применяются лишь к компьютерам с возможностями NAP.
    Рис. 8-12. Настройка разрешения кода ошибки SHV

    Штатное SHV


    Средство проверки работоспособности системы безопасности Windows позволяет выполнять многие проверки, аналогичные проверкам Центра обеспечения безопасности.
    1. Проверяет включение брандмауэра для всех сетевых подключений (например, брандмауэра Windows). Система ХР и WClient включает Брандмауэр Windows, соответствующий требованиям.
    2. Для компьютеров WClient проверяет установку антивирусного программного обеспечения с обновлением сигнатур вирусов. Поскольку Windows не содержит антивирусное ПО, компьютеры Windows по умолчанию не пройдут эту проверку. WClient содержит Защитник Windows, который соответствует этому требованию. Вы также можете установить Защитник Windows на компьютерах XP, но Средство проверки работоспособности системы безопасности Windows не поддерживает проверку антивирусного ПО для компьютеров XP.
    3. Проверяет автоматическое обновление.
    Кроме того, вы можете ограничить доступ для клиентов, на которых не установлены все последние обновления системы безопасности, а также указать требуемый уровень обновлений системы безопасности: Только критическая (Critical Only), Важная и выше (Important And Above ), Средняя и выше (Moderate And Above), Низкая и выше (Low And Above) или Все. На рис. 8-13 показано окно свойств Средства проверки работоспособности системы безопасности Windows с параметрами по умолчанию. Параметры на вкладке Windows XP применяются только к клиентам XP SP3.
    Рис. 8-13. Настройка свойств SHV Windows

    Сетевые политики и CRP


    Сетевые политики определяют соответствие подключения конкретным условиям (таким как политика работоспособности, операционная система клиента или поддержка компьютером защиты NAP). Затем они могут предоставлять клиенту полный или ограниченный сетевой доступ.
    Чтобы добавить сетевую политику:
    1. ПКМ Роли\Службы политики сети и доступа\NPS\Политики\Сетевые политики и примените команду Новый документ
    2. В раскрывающемся списке выберите тип сервера доступа к сети. Для принудительной защиты IPsec выберите HRA. Для принудительной защиты доступа 802.1X или VPN выберите Сервер удаленного доступа. Если вы планируете использовать протокол НСАР для интеграции с Cisco Network Access Control, выберите HCAP-сервер.
    3. Для защиты NAP чаще всего используются следующие условия:
    а) Политики работоспособности (Health Policies). Указывает, что клиент должен соответствовать условиям политики работоспособности.
    б) Компьютеры с поддержкой NAP (NAP-Capable Computers)
    в) Операционная система. Позволяет применять сетевую политику к компьютерам с поддержкой NAP и конкретными версиями операционной системы или архитектурой компьютера (как, например, 32-разрядные и 64-разрядные компьютеры). Это условие используется реже, чем два предыдущих.
    г) Срок действия политики (Policy Expiration). Это условие служит для применения различных параметров принудительной защиты на основе текущей даты и времени. Например, при создании временной политики, рассчитанной только на следующую неделю, можно добавить срок действия политики. Кроме того, нужно создать вторую сетевую политику, которая будет применена после истечения срока действия предыдущей политики.
    д) Группы размещения (Location Groups) и Группы пользователей НСАР (НСАР User Groups) Эти два условия удобны при применении защиты NAP в Cisco Network Access Control.
    4. На странице Укажите разрешение доступа (Specify Access Permission ). Выберите опцию Доступ разрешен (Access Granted ). Для политик NPS никогда не следует применять опцию Доступ запрещен, поскольку не будет проверяться работоспособность.
    5. Cтраницe Настройка методов проверки подлинности пропустите. Для защиты NAP методы проверки подлинности выбираются в Политике запросов на подключение (Connection Request Policy).
    6. На странице Настройка ограничений (Configure Constraints ) щелкните кнопку Далее. В защите NAP ограничения используются редко, хотя вы можете включить Ограничения по дням недели и времени суток (Day And Time Restrictions), чтобы применять сетевую политику лишь в определенные дни и время суток. При использовании времени ожидания сеанса подключение удаленного доступа разъединяется по истечении этого времени. Нельзя задать время ожидания 0.
    7. На странице Настройка параметров (Configure Settings) выберите параметр Принудительное использование NAP (NAP Enforcement). Затем выберите одну из следующих опций и щелкните кнопку Далее:
    а) Разрешить полный доступ к сети.
    б) Разрешить полный доступ к сети в ограниченное время (Allow Full Network Access For A Limited Time) Предоставляет полный доступ в определенное время, а в другое время ограничивает доступ лишь выбранной группой серверов обновлений. Используйте эту опцию при исходном развертывании NAP, если хотите предоставить льготный период для несовместимых компьютеров. Выбрав эту опцию, щелкните кнопку Настроить, чтобы выбрать группу серверов обновлений и указать URL-адрес устранения неполадок. Если использовать эту опцию в принудительной защите доступа VPN, клиенты VPN будут отключены по истечении времени разрешения доступа.
    в) Разрешает доступ лишь к серверам в выбранной группе серверов обновлений. Выбрав эту опцию, щелкните кнопку Настроить, чтобы выбрать группу серверов обновлений и указать URL-адрес устранения неполадок (здесь для пользователя написано что нужно зделать). Группа серверов обновлений используется только для принудительной защиты доступа DHCP и VPN. В принудительной защите доступа 802.1X и IPsec используются другие технологии ограничения сетевого доступа.
    Хотя ваши серверы обновлений могут зависеть от требований средств SHV, обычно серверы обновлений включают компонент Серверы HRA, чтобы несовместимые клиенты HRA могли получать сертификаты работоспособности принудительной защиты доступа IPsec.
    В диалоговом окне Серверы обновления и URL-адрес устранения неполадок (для информирования пользователя) (Remediation Servers And Troubleshooting URL) настройте следующие параметры.
    а) Укажите имя для группы и щелкните кнопку Добавить, чтобы добавить все серверы, к которым должны получать доступ клиенты, не прошедшие проверку на совместимость. Позже эту группу серверов можно будет обновить в Роли\Службы политики сети и доступа\Защита доступа к сети\Группы серверов обновлений
    б) В области URL-адрес устранения неполадок введите внутренний URL-адрес веб-страницы, где предоставлена дополнительная информация о причинах невозможности подключения к сети, способах обеспечения соответствия компьютеров, а также список контактных лиц группы поддержки. Несовместимый компьютер посещает этот URL, когда пользователь щелкает ссылку Дополнительные сведения в диалоговом окне Защита доступа к сети, которое открывается при попытке устранить неполадки подключения, как показано на рис. 8-14. Этот URL также отображается для пользователя при запуске команды
    netsh nар client show state
    Веб-сервер, указанный в URL-адресе, должен входить в список Группа серверов обновлений, иначе клиентский компьютер не сможет получить к нему доступ.
    8. На этой же странице также есть параметр Расширенное состояние ( Extended State). Он применяется только при использовании НСАР вместе с Cisco Network Admission Control. В ином случае оставьте для этого параметра опции по умолчанию.
    Теперь ПКМ эту сетевую политику и примените команду Вверх ( Move Up) или Вниз (Move Down) для назначения приоритета. Политики с более высоким приоритетом оцениваются первыми. К клиенту будет применена первая в списке политика с соответствующим клиенту критерием.
    Как отконфигурировать свойства сетевой политики?
    О. На вкладке Параметры создать IP-фильтр, сбрасывающий весь трафик. Это неправильный ответ. IP-фильтры следует использовать для подключений удаленного доступа. Они не применяются к сетевым политикам NAP.
    Более тонко политики задаются в отдельных меню. Так, в «RADIUS Server и Clients» настраиваются клиенты и удаленные группы серверов RADIUS (Remote RADIUS Server Groups).
    Если узел NPS будет настроен как RADIUS прокси, то на удаленные сервера будут пересылаться запросы на подключение.
    Для CRP всё аналогично. В CRP-политиках определяется обработчик запроса при подключении клиента. Это может быть как локальный узел, так и удаленный (в случае с RADIUS). Так как ранее мы уже создали политики, используя шаблон, то в списке присутствуют две записи: NAP DHCP и проверка подлинности Windows. В колонке «Статус» показано, активна эта политика или нет, а цифра в соседней колонке указывает на порядок ее обработки. На вкладке «Обзор» (Overview) можно изменить имя политики; сняв флажок Policy enabled, отключить проверку этой политики сервером. Раскрывающийся список чуть ниже позволяет изменить тип NPS-сервера (сейчас установлен DHCP-сервер). Активная политика будет применяться без каких-либо ограничений.

    Настройка NAP в режиме мониторинга


    Для тестирования разверните NAP в режиме мониторинга. В этом режиме в случае несоответствия компьютера требованиям работоспособности сетевое подключение пользователя блокируется, а администратор получает уведомление. Для этого модифицируйте политику несоответствия работоспособности, чтобы разрешить полный доступ к сети:
    1. Роли\Службы политики сети и доступа\NPS\Политики\Сетевые политики. В панели сведений дважды щелкните политику несовместимости. Например, если на странице Выберите метод подключения к сети для использования с NAP (Select Network Connection Method For Use With NAP) мастера настройки NAP вы выбрали имя NAP IPsec c HRA, то сетевая политика для несовместимых клиентов NAP получит имя NAP IPsec с HRA Несовместимый.
    2. Перейдите на вкладку Параметры и выберите параметр Принудительное использование NAP (NAP Enforcement).
    3. В диалоговом окне свойств сетевой политики выберите в панели сведений опцию Разрешить полный доступ к сети.
    Чтобы заново включить принудительную защиту доступа NAP, выберите опцию Разрешить ограниченный доступ.
    Ведение журнала NAP позволяет идентифицировать несовместимые компьютеры. В частности, это играет важную роль в исходных стадиях развертывания NAP, когда защита NAP служит лишь для сбора информации об уровне совместимости компьютеров в сети. С помощью журнала NAP можно идентифицировать несовместимые компьютеры и решить проблему перед включением принудительного использования NAP и ограничением доступа к сети. Ведение журнала NAP также позволяет идентифицировать компьютеры, которые не смогут подключаться к сети с принудительной защитой доступа NAP.
    Чтобы настроить ведение журнала NAP, ПКМ Роли\Службы политики сети и доступа\NPS и примените команду Свойства. На вкладке Общие установите или снимите флажки Отклонять запросы на проверку подлинности (Rejected Authentication Requests) и Обрабатывать запросы на проверку подлинности (Successful Authentication Requests), как показано на рис. 8-16.
    На NAP-сервере для просмотра клиентов NAP можно использовать журнал событий Безопасность в папке Журналы Windows, который находится в диспетчере сервера, в узле Диагностика\Просмотр событий\Журналы Windows\Бeзoпaсность. Эти события будут идентифицировать несовместимых клиентов NAP. На рис. 8-17 показано событие, идентифицирующее компьютер, который не прошел проверку работоспособности NAP.
    На NAP-клиентах WClient и WServer в консоли Просмотр событий нужно анализировать журнал Operational в панке Журналы приложений и служб\Microsoft\Windows\Network Access Protection. Нa NAP-клиентах XP SP3 нужно анализировать журнал событий Система в консоли Просмотр событий.
    Кроме того, вы можете включить отслеживание для службы Агент защиты сетевого доступа с целью сбора очень подробной информации, которая, как правило, требуется только при устранении сложных сетевых неполадок. Чтобы включить отслеживание, в командной строке выполните следующую команду:
    netsh nар client set tracing enable level=vorbose
    Файлы журнала наблюдения хранятся в папке %SystemRoot%\Tracing.
    NAP ведет журнал точно так же, как и RADIUS-cepвep.

    Клиент NAP


    1. GPO\Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Network Access Рrotection\Конфигурация клиента NAP. Клиентские параметры NAP можно настроить в трех папках этого узла.
    а) EC. Нужно включить одну политику, предписывающую использование клиентами этого типа принудительной защиты NAP. Например, в панели сведений дважды щелкните объект Клиент принудительного карантина для DHCP (DHCP Quarantine EC). Установите флажок Включить этот клиент системы ограничений.
    б) Параметры интерфейса пользователя. С помощью этой политики укажите настраиваемый текст (и, при желании, рисунок), который будут видеть пользователи в клиентском интерфейсе NAP.
    в) Параметры регистрации работоспособности (Health Registration Settings) В папке Политика запроса (Request Policy) настройте параметры шифрования для клиентов NAP (или используйте параметры по умолчанию). В папке Группы доверенных серверов (Trusted Server Group) настройте группу HRA-серверов, к которой будут обращаться клиенты IPsec NAP.
    2. Нужно запустить службу Агент защиты сетевого доступа. GPO\Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Системные службы.
    3. Чтобы разрешить клиентам использовать средство проверки работоспособности (SHV) Windows по умолчанию, нужно включить Центр обеспечения безопасности с помощью политики Конфигурация компьютера\Политики\Административные шаблоны\Компоненты Windows\Центр обеспечения безопасности.
    На клиенте откройте командную строку с административными полномочиями и запустите команду gpupdate /force. Она извлекает обновленные параметры групповой политики на контроллере домена и проверяет корректное применение изменений к клиентам NAP. Убедитесь, что запущена служба Агент защиты сетевого доступа.
    Конфигурацию клиента можно быстро проверить, запустив в командной строке следующую команду:
    netsh nap client show state
    Далее в примере выполнения этой команды показана конфигурация клиента с запущенной службой Агент защиты сетевого доступа и принудительной защитой доступа IPsec.
    Состояние клиента:
    Имя = Клиент защиты сетевого доступа (NAP)
    Описание = Клиент защиты сетевого доступа (NAP) Microsoft
    Версия протокола =1.0
    Статус = Разрешен
    Состояние ограничения = Не ограничено
    URL-адрес для устранения неполадок =
    Время начала ограничения =
    Расширенное состояние =
    Enforcement client state:
    Код = 79617
    Имя = Клиент принудительного карантина для DHCP
    Описание = Предоставляет принудительную защиту доступа к сети на основе NAP
    Версия =1.0
    Имя поставщика = Microsoft Corporation
    Дата регистрации =
    Инициализирован = Нет
    Код = 79618
    Имя = Клиент принудительного карантина для удаленного доступа
    Описание = Обеспечивает принудительный карантин для клиента RAS
    Версия =1.0
    Имя поставщика = Microsoft Corporation
    Дата регистрации =
    Инициализирован = Нет
    Код = 79619
    Имя = Сторона, использующая IPSec
    Описание = Предоставляет принудительную защиту доступа к сети на основе IPSec
    Версия = 1.0
    Имя поставщика = Microsoft Corporation
    Дата регистрации =
    Инициализирован = Да
    Код = 79621
    Имя = Клиент принудительного карантина шлюза сервера терминалов
    Описание = Обеспечивает применение карантина шлюза сервера терминалов
    Версия = 1.0
    Имя поставщика = Microsoft Corporation
    Дата регистрации =
    Инициализирован = Нет
    Код = 79623
    Имя = Клиент принудительного карантина для ЕАР
    Описание = Предоставляет принудительную защиту доступа к сети на основе ЕАР
    Версия = 1.0
    Имя поставщика = Microsoft Corporation
    Дата регистрации =
    Инициализирован = Нет
    System health agent (SHA) state:
    Код = 79744
    Имя = Агент работоспособности системы безопасности Windows
    Описание = Проверяет соответствие компьютера требованиям
    работоспособности с использованием политики, определенной администратором
    Версия =1.0
    Имя поставщика = Microsoft Corporation
    Дата регистрации =
    Инициализирован = Да
    Failure category = Нет
    Remediation state = Success
    Remediation percentage = 0
    Fixup Message = (3237937214) - The Windows Security Health Agent has
    finished updating its security state.
    Compliance results =
    Remediation results =
    Ok.
    Если применять параметры групповой политики неудобно, можно с помощью ID-кода SHA включить клиент NAP из командной строки (или с помощью сценария). Например, чтобы включить клиент принудительного карантина DHCP (с кодом 79617), запустите следующую команду:
    netsh nap client set enforcement 79617 enable

    Принудительная защита доступа DHCP


    В этом типе включения защиты NAP используется компьютер WServer и служба DHCP Server. IP-адрес, предоставляющий полный сетевой доступ, получают лишь компьютеры, соответствующие требованиям безопасности. Компьютеры, не удовлетворяющие требованиям, получают IP-адреса с маской подсети 255.255.255.255 без основного шлюза. Кроме того, не соответствующие требованиям узлы получают список маршрутов узла (маршруты в таблице маршрутизации, направляющие трафик на один IP-адрес) для сетевых ресурсов в группе серверов восстановления работоспособности. Эта конфигурация IP запрещает не соответствующим требованиям компьютерам подключаться к другим сетевым ресурсам. Хакер, вручную отконфигурировавший IP-адрес, может обойти защиту DHCP-сервера.
    При изменении состояния NAP-клиента (например, при отключении брандмауэра Windows) этот клиент заново оценивает состояние работоспособности путем обновления DHСР. Изменения, внесенные в политику работоспособности на NAP-серверах, вступят в силу только после обновления аренды DHCP. При ручном обновлении:
    ipconfig /release
    ipconfig /renew
    1. Установите службу роли Сервер политики сети. Настрока NAP
    2. Если DHCP и основные NPS-серверы установлены на разных компьютерах, на удаленном сервере DHCP/NPS отконфигурируйте NPS как RADIUS-прокси для перенаправления запросов подключений на основной NPS-сервер. Если на компьютере, на котором производится установка NPS, выполняется служба DHCP, то этот шаг с выбором сервера NPS можно пропустить.
    3. Чтобы включить NAP для всех областей на DHCP-сервере, ПКМ Роли\DНСР-сервер\\IРv4 и примените команду Свойства\вкладка Защита доступа к сети щелкните кнопку Включить во всех областях. Затем выберите одну из следующих опций:
    а) Полный доступ.
    б) Ограниченный доступ (Restricted Access) Включает принудительную защиту доступа NAP. Клиентам, не соответствующим требованиям работоспособности, будут назначаться конфигурация IP-адреса, предоставляющая доступ лишь к серверам, перечисленным в группе серверов восстановления работоспособности.
    в) Отбросить клиентский пакет (Drop Client Packet). Игнорирует запросы DHCP от клиентов, не соответствующих требованиям работоспособности. Клиенты Windows будут автоматически назначать себе адреса APIPA в сети 169.254.0.0/16, где они смогут обмениваться данными только с другими компьютерами АР1РА.
    Включение NAP для отдельной области действия:
    ПКМ Poли\DHCP-cepвep\\IPv4\ и примените команду Свойства. На вкладке Защита доступа к сети выберите опцию Включить во всех областях
  • Включите Клиент принудительного карантина для ЕAР (NAP EAP Quarantine EC) и запустите службу NAP на клиентских компьютерах.
  • На странице Настроить группы пользователей и группы компьютеров щелкните кнопку Далее, чтобы применить политику ко всем пользователям.
    6. В Диспетчере сервера выберите узел Роли\Службы политики сети и доступа\NPS\Политики\Политики запросов на подключение. Убедитесь, что политика NAP DHCP существует и стоит первой в списке. Если существуют другие политики запросов на подключение, удалите их. Аналогично удалите другие сетевые политики.
    Переходим к определению политики работоспособности NAP. Установленный флажок «Включить автообновление клиентских компьютеров» (Enable auto-remediation of client computers) разрешает получение обновлений клиентским системам, не удовлетворяющим политикам. Если этот параметр не выбран, клиенты, не поддерживающие NAP, не обновятся автоматически и не смогут получить полный доступ, пока не будут обновлены вручную. Переключатель внизу позволяет выбрать ограничения доступа к Сети клиентам, не поддерживающим NAP. По умолчанию разрешен только ограниченный доступ ( Deny full network access …). Если по какой-то причине для таких систем ограничений не предусмотрено, то переключаем в полный доступ (Allow full network access …). После нажатия кнопки «Далее» создаются политики и выводится отчет.

    Защита сетевых подключений IPSec


    Этот метод включения защиты требует, чтобы клиенты проверяли работоспособность системы безопасности перед получением сертификата работоспособности. В свою очередь, этот сертификат необходим для обеспечения безопасности IPSec перед подключением к узлам с защитой IPSec. Реализация IPSec позволяет требовать соответствие работоспособности для IP-адреса или номера TCP/UDP-порта. Например, вы можете разрешить несоответствующим требованиям компьютерам подключаться к веб-серверу, но разрешать только соответствующим требованиям компьютерам подключаться к файловому серверу, даже если обе службы запущены на одном компьютере.
    С помощью безопасных подключений IPSec компьютерам, соответствующим требованиям работоспособности, можно разрешать подключаться лишь к таким же компьютерам, прошедшим проверку работоспособности системы безопасности. Для реализации IPSec следует обеспечить CA с помощью служб сертификации WServer, а также реализовать Защиту доступа к сети (NAP) для поддержки сертификатов работоспособности.
  • Установите службу ролей Центр регистрации работоспособности (Health Registration Authority, HRA) и роль Службы сертификации. Если вы планируете использовать защиту доступа к сети 802.1X, вам также потребуется установить эту службу ролей.
    Для CA на основе WServer 2003 создают шаблон сертификата Проверка работоспособности системы (System Health Authentication), чтобы члены группы, освобожденной от защиты IPSec, могли автоматически подавать заявки на получение долговременного сертификата работоспособности.
    Установка службы ролей HRA:
    Мастер добавления служб ролей создает в IIS веб-приложение DomainHRA на сайте Default Web Site.
    а) На странице Выбор требований проверки подлинности для HRA выберите опцию Да, если все компьютеры являются членами доверенного домена. Если же некоторые компьютеры — не члены доверенного домена, вы можете выбрать опцию Нет, однако тогда уровень безопасности будет несколько понижен.
    б) Сертификат SSL можно установить позднее с помощью Диспетчера IIS. В папке Узлы ( Sites ) ПКМ Default Web Site и примените команду Изменить привязки (Edit Bindings). В диалоговом окне Привязки узла (Site Bindings) щелкните кнопку Добавить и создайте привязку HTTPS с сертификатом SSL
  • Мастер Настройка NAP обеспечит следующую конфигурацию в узле Роли\Службы политики сети и доступа\NРS\Политики\Политики (Хотя эти элементы можно конфигурировать по отдельности, намного проще использовать мастер):
    а) Политика запросов на подключение с именем NAP IPsec с HRA
    б) Политика работоспособности NAP IPsec с HRA Совместимый. Эта политика применяется ко всем компьютерам, прошедшим все проверки SHV.
    в) Сетевая политика NAP IPsec с HRA Совместимый (NAP IPsec With HRA Compliant). Эта политика предоставляет доступ для компьютеров, соответствующих требованиям системы безопасности.
    г) Политика работоспособности NAP IPsec с HRA Несовместимый (NAP IPsec With HRA Noncompliant). Эта политика применяется ко всем компьютерам, которые не прошли проверки SHV.
    д) Сетевая политика NAP IPsec с HRA Несовместимый. Эта политика предоставляет ограниченный доступ для компьютеров, не соответствующих требованиям системы безопасности.
  • Настройте HRA:
    ПКМ Роли\Службы политики сети и доступа\NPS\Центр регистрации работоспособности\Центр сертификации и примените команду Добавить центр сертификации (рис. 8-6). ПКМ Центр сертификации и примените команду Свойства. Если вы используете CA предприятия, выберите опцию Использовать центр сертификации предприятия. Если же вы располагаете одним автономным CA, клиенты не смогут проходить проверку работоспособности NAP. Если у вас включена принудительная защита доступа NAP, клиенты не смогут подключаться к сети.
    В узле Роли\Службы политики сети и доступа\NPS\Центр регистрации работоспособности\Центр сертификации можно также настроить механизмы, используемые для принудительной защиты доступа NAP. Но как правило используются параметры по умолчанию.
  • Запустите службу NAP на клиентских компьютерах. Включите IPsec на клиентских компьютерах. ПКМ GPO\Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Network Access Рrоtесtiоn\Конфигурация клиента\NAP\Параметры регистрации работоспособности\Группы доверенных HRA-серверов (Trusted Server Groups) и щелкните кнопку Создать. На странице Добавление серверов введите URL каждого сервера HRA. Если на сервере установлен сертификат SSL (которому доверяют клиенты), введите URL-адрес https://имя_cepвepa . Если сертификат SSL не установлен, снимите флажок Требуется проверка серверов (Require Server Verification ) и введите URL-адрес в формате https://имя_cepвepa . Клиенты NAP всегда начинают с первого сервера HRA и проверяют все серверы в списке, пока не будет найден сервер HRA, к которому можно обратиться.
    Включите принудительную защиту доступа IPSec: Конфигурация компьютера\Политики\Конфигурация Windows\Параметры бeзonacнocти\Network Access Рrotection\Конфигурация клиента NAP\Пapaмeтpы регистрации работоспособности\Клиенты системы ограничений (Enforcement Clients). В панели сведений дважды щелкните Сторона, использующая IPSec (IPsec Relying Party ). В диалоговом окне Сторона, использующая IPSec Свойства установите флажок Включить этот клиент системы ограничений.
  • Требуйте безопасные подключения IPSec с использованием сертификатов работоспособности, чтобы компьютеры могли подключаться к другим компьютерам, как описано далее.

    Правила безопасности подключений (ПБП) IPSec


    Далее, отконфигурируйте все серверы, доступ к которым должны получать лишь прошедшие проверку компьютеры, чтобы они требовали IPsec для входящих подключений (но не исходящих). После этого к серверам не смогут подключаться все компьютеры, которые не соответствуют требованиям NAP или не поддерживают NAP. В оснастке Брандмауэр Windows в режиме повышенной безопасности выполните следующие действия:
    1. ПКМ объект ПБП и примените команду Новое правило/Тип Изоляция
    2. На странице Требования (Requirements) выберите опцию Требовать проверку подлинности для входящих подключений и запрашивать проверку подлинности для исходящих подключений (Require Authentication For Inbound Connections And Request Authentication For Outbound Connections).
    3. На странице Метод проверки подлинности выберите опцию Сертификат компьютера. Затем щелкните кнопку Обзор и выберите CA, используемый для генерирования сертификата сервера HRA. Щелкните ОК. Установите флажок Принимать только сертификаты работоспособности (Only Accept Health Certificates).
    После применения политики к компьютерам связь смогут устанавливать лишь клиенты с действительным сертификатом работоспособности. По этой причине вам не следует требовать сертификаты работоспособности для сервера HRA, иначе клиенты не смогут получать свои сертификаты работоспособности.
    Для сервера HRA, серверов восстановления работоспособности и других компьютеров, доступ к которым должны получать не соответствующие требованиям и не поддерживающие NAP компьютеры, отконфигурируйте правило безопасности подключения IPsec для запрашивания, а не требования безопасных входящих подключений.
    Для клиентов NAP с XP SP3 понадобится с помощью оснастки Политики IP-безопасности настроить аналогичные политики, которые находятся в узле Конфигурация компьютера\Политики\Конфигурация Windows\Политики IP-безопасности. Чтобы настроить NAP-клиент Windows XP SP3 для использования сертификата проверки подлинности IPSec, надо установить для параметра реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley\IKEFlags значение 0х1с.

    Принудительная защита доступа 802.1Х


    В этом методе внедрения NAP используются коммутаторы Ethernet или точки беспроводного доступа, поддерживающие проверку подлинности 802.1Х. Если компьютер перестал соответствовать требованиям после подключения к сети 802.1X, устройство доступа 802.1X может изменить его доступ к сети.
    Для управления уровнями доступа, назначаемыми компьютерам, соответствующим и не соответствующим требованиям и не прошедшим проверку подлинности, в технологии 802.1X используется один из таких 2-ух методов:
    а) Список контроля доступа (Access Control List, ACL) - набор пакетных фильтров IPv4 или IPv6, отконфигурированных на точке доступа 802.1X. Точка доступа 802.1X применяет ACL к подключению и сбрасывает все пакеты, не разрешенные в ACL. Как правило, списки ACL применяются к подключениям не удовлетворяющих требованиям компьютеров и позволяют соответствующим требованиям компьютерам выполнять подключения без ACL (обеспечивая этим неограниченный сетевой доступ). Списки ACL позволяют предотвратить подключения не соответствующих требованиям компьютеров друг к другу, ограничивая этим распространение червя даже среди компьютеров, не удовлетворяющих требованиям системы безопасности.
    б) Виртуальная локальная сеть (VLAN) - группа портов на коммутаторе, образующая отдельную сеть. Сети VLAN не могут обмениваться данными друг с другом, если не использовать маршрутизатор. Для идентификации VLAN служит VLAN-идентификатор, который нужно сконфигурировать на самом коммутаторе. Затем с помощью NAP можно указать, в какие сети VLAN помещать компьютеры, удовлетворяющие требованиям, не соответствующие требованиям, а также не прошедшие проверку подлинности. Не соответствующие требованиям компьютеры, помещенные в сеть VLAN, могут обмениваться данными друг с другом. Таким образом, не соответствующий требованиям компьютер, инфицированный червем, может атаковать и инфицировать другие компьютеры, не соответствующие требованиям. Еще один недостаток VLAN в том, что сетевая конфигурация клиента должна меняться при переводе не соответствующего требованиям клиента NAP в категорию компьютеров, удовлетворяющих требованиям системы безопасности. Изменение сетевой конфигурации во время запуска системы и входа пользователя может привести к ошибкам обновления групповой политики или других загрузочных процессов.
    Точки доступа 802.1X могут поддерживать и списки ACL, и сети VLAN как по отдельности, так и одновременно. Если вы используете списки ACL и сети VLAN для других целей, примените эти же технологии для реализации системы безопасности 802.1X. Если точка доступа 802.1X поддерживает ACL и VLAN, используйте списки ACL для реализации системы безопасности 802.1X, чтобы ограничивать доступ несоответствующих требованиям клиентов к сети.
    Настройка принудительной защиты доступа 802.1X состоит из пяти комплексных этапов.
    1. Во время Настройки NAP на странице Конфигурация виртуальных локальных сетей нужно указать списки ACL или сети VLAN как для клиентов с ограниченным доступом, так и для клиентов с полным доступом (рис. 8-8). В документации коммутаторов поищите сведения об атрибутах, используемых RADIUS-серверами для указания VLAN и ACL.
    2. Настройте коммутаторы с проверкой подлинности 802.1X для проверки подлинности на основе протокола PEAP (Protected Extensible Authentication Protocol), например PEAP-MS-CHAP v2 или PEAP-TLS, и пересылки запросов RADIUS на NAP-сервер. Кроме того, отконфигурируйте интервал повторной проверки подлинности, чтобы регулярно проверять подлинность уже проверенных компьютеров, которые долгое время остаются подключенными к сети. Корпорация Microsoft рекомендует использовать интервал повторной проверки подлинности 4 часа. Инструкции ищите в документации коммутаторов.
    3. Если вы планируете использовать сертификаты для проверки подлинности (с помощью методов PEAP-TLS или EAP-TLS), разверните инфраструктуру PKI и распространяйте сертификаты на клиентские компьютеры с помощью такого механизма, как автоматическая подача заявок Active Directory.
    Если вы планируете применять проверку подлинности домена PEAP-MS-СHАР v2, используйте PKI для выдачи сертификатов NAP-серверу.
    4. Создайте исключения NAP для компьютеров, которые не могут поддерживать оценку работоспособности NAP. Для этого создайте сетевую политику, которая предоставляет беспроводной или проводной доступ и использует набор условий Группы Windows для группы безопасности компьютеров, которые не применяют условие Политика работоспособности (Health Policy).
    5. Включите Клиент принудительного карантина для ЕАР (NAP ЕАР Quarantine Enforcement Client) и запустите службу NAP на клиентских компьютерах, поддерживающих NAP.

    Принудительная защита доступа IPv4 (VPN)


    В этом типе включения защиты, NAP выполняется для подключений удаленного доступа с использованием VPN-сервера WServer и компонента Маршрутизация и удаленный доступ (другие VPN-серверы не поддерживают NAP). VPN-сервер может применять набор фильтров к подключениям не соответствующих требованиям компьютеров, разрешая им получать доступ только к определенной группе серверов восстановления работоспособности. Вы также можете определить пакетные фильтры IPv4 и IPv6 точно таким же образом, как при настройке стандартного VPN-подключения.
    1. Настройка NAP
    2. Отконфигурируйте серверы восстановления работоспособности.
    3. Отконфигурируйте VPN-серверы для выполнения проверки подлинности РЕAР (PEAP-MSCHAP v2 или РЕAР-TLS) и пересылки запросов RADIUS на NAP-сервер.
    4. Если вы планируете использовать сертификаты для проверки подлинности (с помощью методов PEAP-TLS или ЕAР-TLS), разверните инфраструктуру PKI и распространяйте сертификаты на клиентские компьютеры с помощью такого механизма, как автоматическая подача заявок Active Directory. Если вы планируете применять проверку подлинности домена PEAP-MS-CHAP v2, используйте PKI для выдачи сертификатов NAP-серверу.
    5. Включите Клиент принудительного карантина для EАР (NAP ЕАР Quarantine Enforcement Client) и запустите службу NAP на клиентских компьютерах, поддерживающих NAP.

    Обновление ПО


    Чтобы быстро распространять обновления в организации, корпорация Microsoft предлагает использовать сервер обновлений операционных систем и продуктов Microsoft WSUS (Windows Server Update Services). WSUS-сервер позволяет загружать, утверждать (после тестирования) и распространять обновления в организации независимо от количества клиентских компьютеров.
    Вам понадобится следующее оборудование, подключенное к тестовым сетям: Компьютер Dcsrvl, который служит контроллером домена Nwtraders.msfl. Компьютер с именем Boston - член домена Nwtradcrs.msft.
    Развертывание обновлений занимает много времеии. При развертывании обновлений часто приходится перезагружать клиентские компьютеры, что мешает работе пользователей. Кроме того, любое обновление может вызвать проблемы совместимости, даже несмотря на тщательное тестирование. Таким образом, развёртывание обновлений требует значительных затрат и не обеспечивает новых функций.
    Если Microsoft выпустила новое обновление, о котором вы ничего не знаете, еще не всё потеряно. Прежде всего, многими брешами можно воспользоваться лишь после прохождения множества уровней защиты. Кроме того, даже достигнув бреши, хакер не всегда сможет сделать на взломанном компьютере что-то серьезное.
    Добавление защиты доступа к сети (NAP) обеспечивает еще один уровень защиты для компьютеров без установленных обновлений.

    Принципы работы WSUS


    Перед развертыванием сервера WSUS нужно знать принципы настройки компонентов клиента и сервера в различных средах. Без соответствующего планирования обновления могут распространиться очень медленно, занимая пропускную способность подключений к Интернету и глобальной сети (WAN), или некорректно устанавливаться.
    Есть консоль управления WSUS, так что вам больше не потребуется веб-браузер.
    WSUS — это отдельная версия службы Центр обновления (Microsoft Update), посредством которой компьютеры Windows автоматически загружают обновления. Поскольку WSUS можно запускать во внутренней сети и применять для распространения обновлений на компьютеры, благодаря ей можно контролировать установку обновлений на клиентские компьютеры с минимальным использованием полосы пропускания.
    При запуске служба WSUS подключается к сайту Microsoft Update, загружает информацию о доступных обновлениях и добавляет их в список обновлений, требующих подтверждения администратора. После утверждения администратором и назначения приоритета для этих обновлений (процесс, который можно полностью автоматизировать) служба WSUS автоматически предоставляет компьютерам Windows доступ к обновлениям. Соответствующим образом отконфигурированный клиент Windows Update проверяет WSUS-сервер и автоматически загружает и опционально устанавливает утвержденные обновления. При расширении организации до уровня предприятия службу WSUS можно распространить на множестве серверов.

    Клиент Windows Update


    Клиент Windows Update представляет собой компонент WSUS; он извлекает программное обеспечение с WSUS-сервера, проверяет цифровую подпись и хэш SHA1 (Secure Hash Algorithm), уведомляет пользователя о доступности обновления и устанавливает программное обеспечение (если настроена соответствующая конфигурация). Клиент Windows Update устанавливает обновления в соответствии с графиком и может автоматически перезагрузить компьютер. Если во время обновления согласно графику компьютер был отключен, обновления могут быть установлены сразу после его запуска. Если оборудование компьютера обеспечивает соответствующую поддержку, клиент Windows Update может вывести компьютер из режима сна и установить обновления в указанное время.
    В Windows ХР и 2000 клиентский компонент WSUS называется клиентом автоматического обновления (Automatic Updates).
    Поскольку параметры обновления Windows должны применяться ко всем компьютерам в организации, для распространения этих параметров лучше всего использовать групповую политику. Параметры обновления Windows находятся в контейнере Конфигурация компьютера\Политики\Административные шаблоны\Компоненты Windows\Центp обновления Windows (Computer Configuration\Policies\Administrative Templates\Windows Components \Windows Update). В этом контейнере есть следующие параметры групповой политики.
    1. Размещение WSUS в интрасети (Specify Intranet Microsoft Update Service Location). Выберите опцию Enabled. В поля Укажите службу обновлений а интрасети для поиска обновлений (Set The Intranet Update Service For Detecting Updates) и Укажите сервер статистики в интрасети (Set The Intranet Statistics Server) введите адрес http://Имя_компьютера_WSUS
    2. Настройка автоматического обновления (Configure Automatic Updates) указывает, будет ли компьютер получать обновления безопасности и загружать другие важные файлы через службу автоматического обновления Windows. Здесь также можно определить, будет ли клиенту предлагаться установить обновления, или они будут устанавливаться автоматически в назначенное время суток. Этот параметр групповой политики позволяет конфигурировать автоматическую установку обновлений и время установки. Тем не менее, по умолчанию клиенты обновления Windows уведомляют пользователей о новых обновлениях и предлагают их установить.
    Выберите опцию Enabled. (Сконфигурируйте параметры автоматического обновления. Например, для автоматической установки обновлений в раскрывающемся списке Настройка автоматического обновления (Configure Automatic Updates) выберите опцию 4 Автоматическая загрузка и установка по расписанию (4 — Auto Download And Schedule The Install).
    3. Частота поиска автоматических обновлений (Automatic Updates Detection Frequency ) Указывает промежуток времени в часах между поисками доступных обновлений. Истинное время ожидания определяется путем вычитания от 0 до 20 процентов от указанного времени. Например, если в политике задается обнаружение с периодом 20 часов, то все клиенты, к которым применяется эта политика, будут проверять наличие обновлений с интервалом 16-20 часов.
    4. Разрешать пользователям, не являющимся администраторами, получать уведомления об обновлениях (Allow Non-Administrators To Receive Update Notifications) Указывает, будут ли пользователи - не администраторы получать при входе в систему уведомления об обновлениях, согласно настройке конфигурации программы автоматического обновления. Не администраторы могут устанавливать обновления с помощью клиента обновления Windows.
    5. Разрешить немедленную установку автоматических обновлений (Allow Automatic Updates Immediate Installation). Указывает, будет ли служба автоматического обновления устанавливать некоторые обновления без прерывания работы служб Windows и без перезагрузки Windows. При включении этого параметра клиент обновления Windows немедленно установит обновления, не требующие перезагрузки компьютера.
    6 Не выполнять автоматическую перезагрузку для автоматических установок обновлений (No Auto-Restart For Scheduled Automatic Updates Installations) Указывает, что для завершения установки по расписанию служба автоматического обновления будет ожидать перезагрузки компьютера любым вошедшим пользователем, а не перезагружать компьютер автоматически. По умолчанию этот параметр отключен, и клиенты автоматически перезагружают компьютер.
    7 Повторный запрос для перезагрузки при запланированных установках (Re-Prompt For Restart With Scheduled Installations) Задает для службы автоматического обновления период ожидания перед выводом нового приглашения на перезагрузку по расписанию. В зависимости от других параметров конфигурации пользователи могут отложить запланированную перезагрузку. Клиент обновления Windows будет автоматически напоминать о необходимости перезагрузки через интервал, указанный в этом параметре политики.
    8 Перенос запланированных автоматических установок обновлений (Reschedule Automatic Updates Scheduled Installations) Задает для службы автоматического обновления период ожидания от запуска компьютера до выполнения пропущенной ранее установки по расписанию. Если этот параметр не задан, пропущенная установка по расписанию будет выполняться через минуту после следующего запуска компьютера.
    9 Разрешить клиенту присоединение к целевой группе (Enable Client-Side Targeting). Этот параметр можно использовать для настройки клиентских компьютеров как членов группы компьютеров. Он никак не влияет на установку обновлений. Указывает имя целевой группы или групп, которые будут использоваться для получения обновлений из службы обновления Microsoft в интрасети. Эту опцию можно использовать только вместе с WSUS. Ее нельзя использовать вместе со службами обновления программного обеспечения Software Update Services (SUS) — предшественником WSUS.
    10 Разрешить управлению электропитанием центра обновления Windows выводить системы из спящего режима для установки запланированных обновлений (Enabling Windows Update Power Management To Automatically Wake Up The System To Install Scheduled Updates) Определяет, будет ли Цейтр обновления Windows использовать возможности управления электропитанием Windows для автоматического вывода системы из гибернации, если есть обновления, запланированные для установки. Центр обновления Windows также переведет систему в обычный режим и установит обновление, если наступил крайний срок его установки. Система не будет выводиться из гибернации, если нет обновлений для установки. Если система работает от батарей, когда Центр обновления Windows выводит ее из гибернации, обновления не будут установлены, а система автоматически вернется в режим гибернации через две минуты.
    11. Разрешить прием обновлений с подписью из службы обновления Майкрософт в интрасети (Allow Signed Updates From An Intranet Microsoft Update Service Location) Этот параметр политики позволяет управлять тем, будет ли программа автоматического обновления принимать обновления, подписанные другими компаниями, отличными от Microsoft, если такие обновления найдены в папке службы обновления Microsoft в интрасети. Этот параметр политики применим к версиям не ниже Windows XP с SP1 и используется редко.
    Кроме того, в контейнере Конфигурация пользователя, в таком же узле групповой политики есть дополнительные параметры, применяемые к пользователям.
    1. Не отображать параметр «Устанавливать обновления и завершить работу» в диалоговом окне «Завершение работы Windows» (Do Not Display 'Install Updates And Shut Down' Option In Shut Down Windows Dialog Box) Данный параметр применим к версиям не ниже Windows XP с SP2.
    2. Не задавать по умолчанию параметр «Установить обновления и завершить работу» в диалоговом окне «Завершение работы Windows» (Do Not Adjust Default Option To Install Updates And Shut Down' In Shut Down Windows Dialog Box) Этот параметр позволяет указать, можно ли параметр Установить обновления и завершить работу (Install Updates And Shut Down) выбрать по умолчанию в диалоговом окне Завершение работы (Windows Shut Down) Windows. Данный параметр поддерживают версии не ниже Windows XP с SP2.
    И наконец, последний пользовательский параметр доступен лишь в контейнере Конфигурация пользователя\Политики\Административные шаблоны\Компоненты Windows\Цeнтp обновления Windows .
    Запретить использование любых средств Центра обновления Windows ( Remove Access To Use All Windows Update Features) Этот параметр позволяет запретить доступ к Центру обновления Windows.

    Архитектура WSUS


    В принципе, отдельный WSUS-сервер требуется для каждого регионального офиса, где есть более 10 компьютеров, а также каждого отдела IT, которому необходимо управлять утверждением обновлений.
    Как правило, для WSUS-серверов избыточность не нужна. Тем не менее, вы должны архивировать базу данных WSUS и быть готовыми к замене сервера в течение недели. Сбой WSUS-сервера не оказывает непосредственного влияния на пользователей, а обновления редко бывают настолько критичны, чтобы в течение нескольких дней, необходимых на восстановление WSUS-сервера, случилась трагедия.
    Если организация располагается в одном офисе, одного WSUS-сервера вполне хватит — независимо от количества клиентских компьютеров. Клиент обновления Windows предназначен для совместного использования полосы пропускания, и при большой сетевой нагрузке переходит в режим ожидания, оказывая минимальное влияние на производительность сети.

    Мониторинг компьютеров


    Стенд:
    Dcsrvl, служащий контроллером домена Nwtraders.msft. Этот компьютер должен располагать как минимум одним интерфейсом, подключенным к Интернету. Boston - член домена Nwtraders.msft.
    Для устранения неполадок в приложениях используется программа Process Monitor (доступная по адресу www.microsoft.com/technet/sysinternals/FileAndDisk/processmonitor.mspx), а для устранения сетевых неполадок - программа Network Monitor.
    Зашифрованные пакеты отображаются в Network Monitor как «мусор», поскольку программа может перехватывать лишь заголовки.

    Мониторинг журналов событий


    Система Windows всегда хранит много важной информации в журналах событий. К сожалению, в версиях до WClient доступ к информации такого рода был затруднен. Журналы событий всегда хранились на локальном компьютере, и найти важные события среди огромного количества информации было очень сложно.
    В WClient, WServer и Server 2003 R2 можно собирать события с удаленных компьютеров (в том числе и с компьютеров Windows XP) и идентифицировать такие проблемы, как нехватка дискового пространства, еще до того как они приведут к сбоям в сети. Кроме того, в Windows теперь включено намного больше журналов событий, упрощающих устранение неполадок компонентов и приложений Windows.

    Концепции пересылки событий


    События, соответствующие определенному критерию, можно пересылать на компьютер администратора, что позволяет централизованно управлять ими.
    Для пересылки событий используется протокол HTTP или HTTPS. Поскольку эти же протоколы применяются для обзора веб-сайтов, пересылка событий работает через брандмауэры и прокси-серверы. Пересылаемые события шифруются при использовании любого из протоколов — как HTTP, так и HTTPS.
    Для пересылки событий требуется отконфигурировать пересылающий и принимающий компьютеры. Вначале на обоих компьютерах нужно запустить следующие службы:
    1. службу удаленного управления Windows (Windows Remote Management, WS-Management);
    2. сборщик событий Windows (Windows Event Collector ).
    В зависимости от используемой технологии доставки может также потребоваться включить исключение брандмауэра Windows и на компьютере сбора событий.
    Компьютерами-коллекторами событий могут являться лишь машины WClient, WServer и Server 2003 R2.
    Пересылать события могут лишь компьютеры XP SP2, Server 2003 с SP1 или 2, Server 2003 R2, WClient и WServer.
    Чтобы пересылать события с компьютеров XP и Server 2003, нужно установить компонент WS-Management 1.1. Более подробные сведения находятся по адресу go.microsoft.com/fwlink/YUnhid 100895.

    Настройка пересылающего компьютера


    Чтобы сконфигурировать компьютер WClient или WServer для пересылки событий, выполните следующие действия.
    1. В окне командной строки запустите с административными привилегиями команду для настройки WS-Management:
    winrm quickconfig
    Появится следующее сообщение:
    Служба WinRM не настроена на разрешение удаленного управления компьютером.
    Необходимо внести следующие изменения:
    Создайте прослушиватоль WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.
    Разрешите исключение брандмауэра WinRM.
    Выполнить изменения [у/n]?
    2. Введите Y и нажмите клавишу Enter. Инструмент командной строки WinRM (Windows Remote Management) (сконфигурирует компьютер на прием запросов WS-Management с других компьютеров. В зависимости от текущей конфигурации может потребоваться внести следующие изменения.
    • На компьютерах WClient назначить тип запуска Автоматически (отложенный запуск) (Automatic (Delayed Start)) и запустить WS-Management. Нa компьютерах WServer эта служба запущена по умолчанию.
    • Настроить прослушиватель Windows Remote Management на HTTP.
    • Создать исключение брандмауэра Windows, разрешающее входящие подключения к службе удаленного управления Windows через HTTP. Это исключение применяется только к профилям Домен и Личный.

    Затем нужно добавить учетную запись компьютера-коллектора в локальную группу Читатели журнала событий (Event Log Readers) на каждом пересылающем компьютере. Это можно выполнить вручную или автоматически с помощью сценария или в окне командной строки, запустив следующую команду:
    net localgroup "Event Log Readers" $@ /add
    Так, чтобы добавить компьютер SERVER1 в домен contoso.com, запустите следующую команду:
    net localgroup "Event Log Readers" [email protected] /add

    Настройка компьютера-коллектора


    Чтобы отконфигурировать компьютер WClient или WServer для сбора событий, откройте командную строку от имени администратора.
    Для настройки сборщика событий Windows Event Collector:
    wecutil qc
    В WServer можно просто выбрать узел Подписки (Subscriptions) в дереве консоли Просмотр событий (Event Viewer).

    Создание подписки на события


    Для того чтобы создать подписку на компьютере-коллекторе WServer, (компьютер WClient настраивают точно так же):
    1. В оснастке Просмотр событий, значок которой находится в узле Диагностика (Diagnostics) консоли Диспетчер сервера, ПКМ узел Подписки и примените команду Создать подписку.
    2. В диалоговом окне Просмотр событий щелкните кнопку Да, чтобы подтвердить настройку Windows Event Collector. Откроется диалоговое окно Свойства подписки.
    3. Создайте один из двух типов подписки:
    а) Инициировано сборщиком (Collector Initiated) Компьютер-сборщик связывается с исходными компьютерами для извлечения событий.
    Щелкните кнопку Выбрать компьютеры. В диалоговом окне Компьютеры щелкните кнопку Добавить доменный компьютер, выберите компьютеры, за которыми хотите наблюдать, и щелкните ОК. Щелкните кнопку Проверить (Test), чтобы протестировать настройку исходного компьютера, а затем - ОК. Если на исходном компьютере не выполнялась команда winrm quickconfig, при проверке подключения будет выдано сообщение об ошибке.
    б) Инициировано исходным компьютером (Source Computer Initiated)
    Щелкните этот тип, а затем щелкните кнопку Выбрать группы компьютеров. Для добавления компьютеров по типам используйте кнопки Добавить доменный компьютер (Add Domain Computers) и Добавить недоменный компьютер (Add Non-Domain Computers).
    На недоменных компьютерах требуется установить сертификат. Щелкните кнопку Добавить сертификаты, чтобы выбрать центр сертификации, который будет использоваться для проверки подлинности недоменного компьютера.
    5. Щелкните кнопку Выбрать события, чтобы открыть диалоговое окно Фильтр запроса (Query Filter ). В этом диалоговом окне можно определить критерий, которому должны соответствовать пересылаемые события.
    6. При желании щелкните кнопку Дополнительно (Advanced), чтобы открыть диалоговое окно Дополнительные параметры подписки (Advanced Subscription Settings). В нем можно конфигурировать три типа подписки.
    a) Обычная (Normal) Эта подписка гарантирует стабильную доставку событий без попыток резервирования полосы пропускания. Такой тип выбирается в большинстве случаев, если не требуется более жесткий контроль полосы пропускания или максимально быстрая доставка событий. В этой подписке используется режим доставки Pull (компьютер-сборщик связывается с пересылающим компьютером) с загрузкой по пять событий, если в течение 15 мин появились события для загрузки.
    б) Уменьшенная пропускная способность (Minimize Bandwidth) При использовании такой подписки снижается пропускная способность. Эту подписку удобно использовать в случае пересылки событий через глобальную сеть (WAN) или на большом количестве компьютеров в локальной сети (LAN). При этом используется режим доставки Push (пересылающий компьютер связывается с компьютером-сборщиком) с пересылкой событий каждые 6 ч.
    в) Уменьшенная задержка (Minimize Latency). При выборе этого типа подписки события доставляются с минимальной задержкой. Его следует использовать для сбора предупреждений или критических событий.
    В данном типе используется режим доставки Push с периодом отправки пакетов, равным 30 с.
    Кроме того, используя подписку, инициированную сборщиком, в этом диалоговом окне можно настроить пользовательскую учетную запись, применяемую подпиской. При выборе параметра Учетная запись компьютера (Machine Account) или определенного пользователя в любом случае потребуется добавить эту учетную запись в группу Читатели журнала событий (Event Log Readers) на каждом пересылающем компьютере.
    По умолчанию стандартные подписки событий выполняют проверку новых событий каждые 15 мин. Этот интервал можно уменьшить, чтобы получать события чаще. Но для настройки задержки дополнительного графического интерфейса нет, так что придется использовать утилиту командной строки Wecutil, предназначенную для конфигурирования компьютера-сборщика.
    Чтобы изменить значение задержки подписки событий, вначале создайте подписку в консоли Просмотр событий (Event Viewer). Затем в командной строке с административными привилегиями запустите следующие две команды:
    wecutil ss /cm:custom
    wecutil ss /hi:
    Например, чтобы для созданной подписки с именем Disk Events установить задержку в 2 мин, запустите следующие команды:
    wecutil ss "Disk Events"' /cm.custom
    wecutil ss "Disk Events" /hi:12000
    Чтобы проверить интервал, запустите команду:
    wecutil gs ""
    Например, чтобы проверить интервал подписки Disk Events, запустите такую
    команду и найдите значение HeartbeatInterval:
    wecutil gs "Disk Events"
    Типы подписки с уменьшенной пропускной способностью и уменьшенной задержкой по умолчанию отправляют в пакете определенное количество элементов. Это значение по умолчанию можно определить, запустив в командной строке следующую команду:
    winrm get winrm/config

    Настройка пересылки событий для использования HTTPS


    Помимо действий, описанных в подразделе «Настройка пересылающего компьютера», нужно выполнить следующее.
    1. Настроить компьютер с помощью компьютерного сертификата. В средах AD это можно выполнить автоматически с помощью центра сертификации предприятия.
    2. Создать исключение брандмауэра Windows для ТСР-порта 443. Если подписка отконфигурирована с использованием параметра оптимизации доставки Уменьшенная пропускная способность (Minimize Bandwidth) или Уменьшенная задержка (Minimize Latency), нужно также настроить компьютерный сертификат и исключение HTTPS брандмауэра Windows на компьютере-сборщике.
    3. В командной строке запустите от имени администратора такую команду:
    winrm quickconfig -transport:https
    На компьютере-сборщике нужно просмотреть параметры подписки в окне Дополнительные параметры подписки (Advanced Subscription Settings) и в поле Протокол выбрать HTTPS. Кроме того,
    компьютер-сборщик должен доверять центру сертификации, создавшему компьютерный сертификат (это происходит автоматически, если сертификат создан центром сертификации предприятия, а пересылающий компьютер и компьютер-сборщик являются членами одного домена AD).

    Занятие 2. Мониторинг производительности и стабильности


    Средство Монитор производительности и стабильности удобно использовать например при корреляции событий, например ошибок установки приложений.
    Системный монитор ( Performance Monitor) в режиме реального времени отображает в графическом виде данные производительности. Диалоговое окно Свойства Системного монитора:
    1. Источник. Здесь можно выбрать отображение текущей активности в реальном времени или сведений файлов журналов, сохраненных с помощью группы сборщиков данных. При отображении файла журнала на этой вкладке можно также указать диапазон времени, который будет отображаться в окне системного монитора.
    2. Линейчатая гистограмма ( Histogram Bar) Отображает гистограмму с последними значениями каждого счетчика. Если в гистограмме отображаются данные большого количества счетчиков и вас интересуют лишь текущие значения (а не изменение значения каждого счетчика со временем), такие данные удобней отображать в виде линейного графика.
    3. Отчет ( Report ) Отображает текстовый отчет с перечислением всех текущих значений.
    Монитор стабильности ( Reliability Monitor) отслеживает стабильность системы. Компьютеры, на которых не устанавливается новое программное обеспечение и не возникают ошибки, считаются стабильными и могут получить максимальный индекс стабильности системы 10.
    Монитор стабильности удобно использовать для диагностики случайных и долговременных неполадок. С помощью монитора стабильности можно быстро просмотреть сбои. Монитор стабильности (Reliability Monitor) отслеживает
    установку приложений (если для них используется Установщик Windows
    (Windows Installer)).
    Чтобы открыть монитор стабильности, в диспетчере сервера выберите узел Диагностика\Стабильность и производительность\Средства наблюдения\Монитор стабильности.
    Диаграмма в окне монитора стабильности отображает одну точку данных за каждый день. Под диаграммой находятся строки, в которых отображаются значки удачной и неудачной установки программного обеспечения, отказов приложений, неполадок оборудования, ошибок Windows и разных других неполадок. Щелкните определенный день в диаграмме, чтобы просмотреть данные стабильности за этот день.
    Монитор стабильности отображает данные, собираемые компонентом Reliability Analysis Component (RAC), который реализован как RACAgent.exe. Этот исполняемый файл запускается ежечасно в качестве скрытого запланированного задания. Чтобы просмотреть это задание, выберите узел Конфигурация\Планировщик заданий\Библиотека планировщика заданий\Microsoft\Windows\RAC. Затем щелкните меню Вид и установите флажок Отобразить скрытые задачи.

    Группы сборщиков данных


    Группы сборщиков данных собирают системную информацию, в том числе параметры конфигурации и данные производительности, и сохраняют их в файле данных. Позже этот файл можно использовать для просмотра отчета.
    В WServer включено несколько предварительно заданных групп сборщиков данных (Data Collector Set). Они находятся в узле Группы сборщиков данных\Системный (Data Collector Sets \System).
    1. Диагностика AD. Эта группа сборщиков данных включена лишь на контроллерах домена и регистрирует данные трассировки ядра, данные трассировки AD, данные счетчиков производительности и параметры конфигурации реестра AD.
    2. LAN Diagnostics (Диагностика локальной сети) Регистрирует данные счетчиков производительности сети, параметры сетевой конфигурации и трассировку диагностики. Эта группа сборщиков данных применяется при устранении комплексных сетевых неполадок, например проблем, связанных со временем ожидания сети, ее низким быстродействием или неполадок подключения виртуальной частной сети (VPN).
    3. System Performance (Производительность системы) Регистрирует данные счетчиков производительности процессора, диска, памяти и сети, а также трассировку ядра. Эта группа сборщиков данных используется для устранения случайных неполадок быстродействия, а также проблем на медленных компьютерах.
    4. Диагностика системы (System Diagnostics). Регистрирует все сведения, включенные в группу сборщиков данных System Performance, а также подробные системные данные. Эта группа сборщиков данных используется при устранении неполадок стабильности, например отказов оборудования, неполадок драйверов или ошибок Stop (синий экран). Отчет, генерируемый этой
    группой сборщиков данных, содержит сведения об ошибках системы, то есть
    их не понадобится просматривать в консоли Просмотр событий (Event Viewer) в диспетчере устройств ( Device Manager).
    5. Wireless Diagnostics (Диагностика беспроводной сети) Эта группа включена лишь на компьютерах с возможностью беспроводного подключения и регистрирует те же сведения, что и группа LAN Diagnostics, а также данные
    для устранения неполадок беспроводных сетей.
    Чтобы использовать группу сборщиков данных (Data Collector Set), щелкните ее правой кнопкой мыши и примените команду Пуск (Start). Работа групп сборщиков данных System Performance и System Diagnostics прекращается автоматически через 1 мин, работа группы AD Diagnostics — через
    5 мин, а сбор данных группой LAN и Wireless Diagnostics нужно останавливать вручную. При устранении сетевой неполадки после запуска группы сборщика данных следует попытаться воспроизвести проблему. Чтобы вручную остановить работу группы сборщика данных, щелкните ее правой кнопкой мыши и примените команду Стоп (Stop).
    Чтобы просмотреть последний отчет группы сборщиков данных, щелкните в узле Стабильность и производительность\Отчеты (Reliability And Performance\eports) правой кнопкой мыши и примените команду Последний отчет (Latest Report). Отчеты именуются автоматически в формате yyyymmdd-####.
    Чтобы свести к минимуму влияние процесса сбора данных на производительность, регистрируйте как можно меньше данных. Например, вместо группы System Diagnostics по возможности используйте группу System Performance, поскольку в ней меньше счетчиков.

    Занятие 3. Использование сетевого монитора


    Чтобы устранять комплексные неполадки, необходимо изучить внутреннюю работу приложения. Во время устранения сетевых проблем лучше всего проанализировать сетевые коммуникации с помощью анализатора протоколов.
    В качестве анализатора протоколов можно использовать бесплатный инструмент Microsoft Network Monitor. Позволяет даже останавливать захват трафика на основе записи в журнале событий в средстве просмотра событий. Ниже перечислены характеристики предшествующих версий ин-
    струмента Network Monitor.
    • Оптимизированный интерфейс, который включал сетевые переговоры, и расширяемое древовидное представление фреймов для переговоров.
    • Отображение и обновление захватов в режиме реального времени.
    • Возможность захватывать трафик одновременно на множестве сетевых карт.
    • Возможность запускать одновременно множество сеансов захвата.
    • Язык синтаксического анализатора протоколов на основе сценариев.
    • Возможность захватывать трафик в беспроводных сетях, сканировать один или все каналы беспроводной связи, поддерживаемые сетевой картой, и просматривать интенсивность сигнала и скорость передачи данных в соединении.
    • Возможность трассировать трафик внутри туннеля виртуальной частной сети посредством захвата трафика от сервера удаленного доступа (Remote Access Server — RAS).
    • Возможность использовать контекстное меню, вызываемое щелчком правой кнопкой мыши, в панели Frame Summary (Резюме фрейма), и наличие кнопки Добавить в фильтр.
    Переделанная система поддержки дополнительных схем протоколов.
    Новые публичные анализаторы синтаксиса, такие как ip1394, ipcp, РРРоЕ и т.д.
    К некоторым новым средствам Network Monitor 3.3 относятся следующие.
    • Поддержка Windows Server 2008 R2, Hyper -V и Windows 7.
    • Способность захватывать WWAN и туннельный трафик на компьютерах Windows 7.
    • Поддержка протоколов IPv4 и IPv6.
    В процессе установки для каждого сетевого адаптера добавляется драйвер Network Monitor 3 Driver (рис. 10-12), в том числе VPN и адаптеры удаленного доступа. Этот драйвер нужно установить и включить, чтобы программа Network Monitor могла собирать данные сетевого адаптера.
    Щелкните значок Microsoft Network Monitor.
    1. На вкладке Start Page выберите в панели Select Networks (Выбор сетей) сетевые адаптеры, которые хотите отслеживать. После этого в панели Select Networks можно настроить различные опции, выбрав сетевой адаптер и щелкнув кнопку Properties. Для проводных сетевых подключений можно включить смешанный режим Р-Mode (Promiscuous-Mode) для захвата кадров, пересылаемых на другие компьютеры (этот режим не работает в средах с коммутаторами Layer 2 - концентраторами). Поэтому в случае подключения компьютера к концентратору, к которому уже подключен один из отслеживаемых компьютеров, не придется включать порт мониторинга. Для беспроводных сетевых подключений можно использовать режим Monitor Mode, который аналогичен P-Mode.
    3. Щелкнув меню Tools и применив команду Options, можно настроить размер временного файла захвата данных и место его хранения. На вкладке Capture установите флажок Enable Conversations и щелкните кнопку Create A New Capture. Сетевой монитор создаст вкладку с новым захватом данных.
    4. Чтобы захватить сетевой трафик щелкните на кнопке Create a New Capture Tab (Создать новую вкладку захвата), которая расположена слева. Щелкните на кнопке Play или нажмите клавишу , чтобы начать захват трафика. Сетевой монитор начнет захватывать сетевой трафик и отображать его в панели Frame Summary (Итоги кадра).
    Подробные сведения о захвате сетевых данных с помощью утилиты NMCap вы найдете в статье «NMCap: the Easy Way to Automate Capturing» (blogs.technet.com/netmon/archive/2006/10/24/nmcap-the-easy-way-toautom). Так как для работы сетевого монитора и утилиты NMCap нужен драйвер Network Monitor, вы не сможете захватывать данные с компьютера, на который скопируете файл NMCap.exe.
    Быстро захватить трафик на таком компьютере можно, запустив инструмент Network Monitor OneClick, который легко скачать по адресу www.microsoft.com/downloads/ details .aspx7FarnilylD=9f37302e-d491-4c69-b7ce-410c8784fd0c. После захвата данных утилита OneClick автоматически удаляет себя с компьютера.
    Кадр (или фрейм) — это не совсем пакет, хотя и очень похож на него. Кадр содержит данные Layer 2, например заголовок Ethernet; пакеты же представляют собой информационные единицы Layer 3 и начинаются с IP-заголовка.
    Намного удобней использовать панель Frame Details, а не Hex Details, поскольку в первой панели отображаемые данные распределены по уровням.
    Чтобы отобразить более обширную область обзора, можно щелкнуть ПКМ любой кадр в панели Frame Summary и применить команду View Selected Frame(s) In A New Window (Открыть выделенные кадры в новом окне).
    Блог TechNet, посвященный сетевому монитору (blogs.technet.com/netmon), содержит массу полезной информации, посвященной сетевому монитору, перехвату трафика и анализу данных.

    Командная строка


    При необходимости захватить сетевой трафик в окне командной строки перейдите в папку установки Network Monitor и запустите следующую команду:
    NMCap /network * /capture /file имя_файла.cap
    Весь трафик на всех сетевых интерфейсах будет захвачен и сохранен в файле с расширением .cap. Захватив трафик достаточной продолжительности, нажмите клавиши Ctrl+C. Затем этот файл захвата можно проанализировать с помощью Network Monitor, щелкнув кнопку Open A Capture File (Открыть
    файл захвата данных) на вкладке Start Page.
    Для фильтрации захватываемых данных введите фильтр захвата в кавычках
    после параметра /capture. Например, благодаря следующей команде будет
    захватываться только трафик DNS:
    NMCap /network * /capture "DNS" /file имя_файла.cap
    Для захвата всего трафика в режиме P-Mode (захватывается весь трафик в области видимости компьютера, а не только широковещательный трафик и трафик обмена данными между компьютерами), используйте параметр /DisableLocalOnly, как показано в следующем примере:
    NMCap /network * /DisableLocalOnly /capture /file имя_файла. cap

    Фильтрация сетевых данных


    Для ограничения захвата данных можно использовать фильтр захвата (фильтрует кадры перед захватом) и фильтр отображения (фильтрует уже захваченные кадры).
    При выполняющемся захвате и выбранной вкладке, откройте меню Filter в панели меню в верхней части окна системного монитора.
  • Создание фильтра захвата. Выберите в меню пункт Фильтр захвата-Загрузить фильтр-Стандартные фильтры), чтобы выбрать заранее сконфигурированный фильтр, который будет захватывать трафик, относящийся к определенному элементу, такому как DNS.
  • Создание фильтра отображения. Выберите в меню пункт Display Filters Load Filter^Standard Filters (Фильтр отображения^Загрузить фильтр^Стандартные фильтры).
  • Создание фильтра цветового фильтра. Выберите в меню пункт Color Filters Load Filter->Standard Filters (Цветовой фильтр-Загрузить фильтр-Стандартные фильтры), чтобы применить цветовой эффект к определенным элементам, таким как DNS.
    4. После того как фильтр будет добавлен, его необходимо применить. Это можно сделать, щелкнув на кнопке Применить, которая находится в панели Capture Filter (Фильтр захвата), нажав комбинацию клавиш или выбрав пункт Применить в меню Filter для добавленного фильтра.
    5. Примените фильтр (фильтры), щелкнув на меню Filter в верхней части окна сетевого монитора.
    • Чтобы применить фильтр захвата, выделите Capture Filter и щелкните на кнопке Apply.
    • Чтобы применить фильтр отображения, выделите Display Filter и щелкните на кнопке Apply.
    • Чтобы добавить цветовой фильтр, щелкните на кнопке Color Filter, далее на кнопке Add, добавьте выражение (например, RDP или 192.168.1.5) и отфор-
    матируйте шрифт так, как вы этого хотите. Щелкните на кнопке ОК, а затем снова щелкните на кнопке ОК, чтобы применить фильтр, и закройте окно Color Filter.
    Как вариант, фильтр захвата или фильтр отображения можно применить, если щелкнуть ПКМ на элементе в панели Frame Summary и выбрать в контекстном меню пункт Добавить ячейку в фильтр отображения.
    Чтобы удалить фильтр, просто выделите его в меню Filter, выберите пункт
    Удалить фильтр, щелкните на кнопке Remove (Удалить) в панели Capture Filter или нажми-
    те комбинацию клавиш .

    Захват сетевого трафика между компьютерами


    Network Monitor 3.3 включает возможность захвата трафика беспроводных подключений, удаленных подключений, а также подключений к локальной (Local Area Network — LAN) и глобальной сети (Wide Area Network — WAN) посредством удаленного агента. В некоторых случаях сетевым администраторам приходится диагностировать или наблюдать за переговорами между двумя компьютерами. Действия, которые необходимо выполнить, чтобы наблюдать за трафиком между двумя разными компьютерами, перечислены ниже.
    Чтобы захватить трафик между двумя разными компьютерами, использующими адреса IPv4 источника и назначения, как показано на рис. 34.7, выполните описанные далее шаги.
    1. Создать новую вкладку захвата.
    2. В меню Filter выберите пункт Фильтр захвата “^Загрузить фильтр^Стандартные фильтры).
    3. Выберите Addresses, а затем IPv4 Addresses.
    4. Отредактируйте фильтр, чтобы определить IP-адреса, которые необходимо отфильтровать, в окне Capture Filter (например, 192.168.0.100 и Any).
    5. Щелкните на кнопке Apply в панели Capture Filter (Фильтр захвата).
    6. Щелкните на кнопке Play, которая находится на главной панели
    меню сетевого монитора, или нажмите клавишу , чтобы начать захват.
    Фильтры захвата нужно создать перед захватом данных. Для фильтрации уже захваченных данных также требуется создать фильтр. Чтобы создать фильтр с помощью стандартных шаблонов, в панели Capture Filter (Фильтр захвата) или Display Filter (Фильтр отображения) щелкните кнопку Load Filter (Загрузить фильтр). Затем выберите опцию Standard Filters (Стандартные фильтры) и укажите один из встроенных фильтров. Далее описаны самые полезные фильтры.
    • BascNetworkTShoot Отображает только те кадры, которые могут быть связаны с низкоуровневыми сетевыми проблемами, включая отказы подключений ICMP, ARP и TCP. Этот фильтр следует использовать при устранении распространенных сетевых неполадок для идентификации узла, вызвавшего проблему.
    • Broadcast отображает лишь кадры широковещания. Фильтр No-Broadcasts удаляет все кадры широковещания.
    • DNS Отображает только трафик DNS.
    • NameResolution Отображает весь трафик разрешения имен, включая
    • разрешение имен DNS, NetBIOS и ARP.
    • HttpWebpageSearch Отображает запросы конкретных веб-страниц. Этот
    • фильтр удобно использовать для определения компьютеров в сети, запрашивающие конкретную страницу, в частности для поиска искаженного пути, который может быть задействован для атаки веб-сервера (то есть может не сохраниться в файлах журналов).
    • MyIPv4Address и MyIPv6Address Отображает лишь входящие и исходящие запросы компьютера.
    • IPv4Address, IPv4DestinationAddress, IPv4Source Address, IPv4SourceAndDestination Отображает лишь входящие и исходящие запросы конкретных IPv4-адресов.
    • IPv6Address, IPv6DestinationAddress, IPv6SourceAddress Отображает лишь входящие и исходящие запросы конкретных 1Рv6-адресов.
    • IPv4SubNet Отображает лишь входящие и исходящие запросы конкретной подсети.

    С помощью двоичных операций можно комбинировать множество стандартных фильтров, создавая более сложные фильтры. Если разделить два фильтра оператором &&, то будут фильтроваться кадры, соответствующие обоим фильтрам. При разделении фильтров оператором || будут отображаться кадры, соответствующие любому фильтру. С помощью круглых скобок можно группировать множество параметров. Чтобы захватывать трафик, не соответствующий параметру, поставьте перед параметром восклицательный знак. Например, фильтр !(tcp.port == 3389) захватывает весь трафик, за исключением трафика удаленного рабочего стола (Remote Desktop ), который использует ТСР-порт 3389. Этот фильтр удобно использовать для захвата трафика при удаленном входе в компьютер.
    Вместо операторов && и || может также использовать операторы AND и OR.
    Например, если вы захватили трафик на DNS-сервере, приведенный ниже фильтр отобразит весь трафик DNS с узла 192.168.10.123:
    DNS && IPv4. SourceAddress == 192.168.10.123
    Следующий фильтр захватывает все веб-запросы страницы с именем Page 1.htm или Page2.htm:
    contains(Http. Request. URI, "Page1.htm") || contains(Http.Request.URI, "Page2.htm")
    Для фильтрации уже захваченных данных можно создать фильтр на основе существующего кадра, щелкнув его ПКМ в окне Frame Summary и применив команду Add Cell To Display Filter (Добавить ячейку в фильтр отображения). Затем щелкните кнопку Apply (Применить). Сетевой монитор отобразит лишь те кадры, которые в точности соответствуют этому описанию.
    При создании настраиваемых фильтров используйте кнопку Verify (Проверить), чтобы проверить корректность синтаксиса. Панель Display Filter выделит все ошибки и позволит их корректировать. Более подробные сведения о создании настраиваемых фильтров есть в разделе «Using Filters» справки Network Monitor Help.

    Синтаксический анализ захваченных данных сетевого трафика


    Синтаксический анализ захваченных данных позволяет преобразовать информацию в формат, который будет понятным для нас с вами.
    Чтобы модифицировать анализ захваченных данных в Network Monitor 3.3, выполните следующие шаги.
    1. При выполняющемся захвате или загрузке из сохраненного файла выберите вкладку Parsers (Анализаторы) в окне сетевого монитора, как показано на рис. 34.8.
    2. Разверните соответствующую категорию синтаксического анализа и дважды щелкните на выбранном анализаторе для загрузки его кода в редактор. Анализаторы используют простой в применении язык Network Monitor Parser Language (NPL).

    Управление файлами


    Стенд
    Компьютер с именем Dcsrvl, служащий контроллером домена Nwtraders.msft. Этот компьютер должен располагать как минимум одним интерфейсом, подключенным к Интернету.
    Компьютер с именем Boston — член домена Nwtraders.msft.

    Управление безопасностью файлов


    Отображение файлов на экране практически не влияет на производительность. При выводе файлов на экран их расширения проверяются только в случае создания новых файлов или переименования существующих.
    WServer, а также последние версии Windows уровня Enterprise обеспечивают 2 технологии управления доступом к файлам и папкам — файловые разрешения NTFS и шифрующую файловую систему EFS.
    Файловые разрешения NTFS определяют пользователей, которые могут просматривать или обновлять файлы. Файловые разрешения NTFS действуют как при локальном входе пользователей, так и при получении доступа к папкам по сети. Для различных типов файлов назначаются отдельные разрешения.
    Системные файлы. Пользователи могут читать папку %SystemRoot% и ее подпапки, но не могут записывать данные в них. Администраторы могут добавлять и обновлять файлы. Таким образом, лишь администраторы могут устанавливать обновления и приложения.
    Программные файлы. Аналогично разрешениям для системных файлов, разрешения для папки %ProgramFiles% позволяют пользователям запускать приложения, а администраторам они позволяют устанавливать программы. Пользователи в этом случае получают право чтения, а администраторы - полный доступ.
    Кроме того, все новые папки, создаваемые в корне диска, предоставят администраторам полный доступ, а пользователям — право чтения.
    Разрешения, назначаемые файлам и папкам по умолчанию, соответствуют требованиям настольных сред. Администраторы могут назначать пользователям и группам следующие разрешения доступа к файлам и папкам.
    Запись Пользователи могут создавать файлы в папке, но не обязательно могут читать их. Это разрешение пригодно для создания папки, в которую несколько пользователей могут записывать файлы, однако они не могут читать файлы друг друга или даже видеть другие файлы.
    Изменение Пользователи могут читать, редактировать, а также удалять файлы и папки.
    Полный доступ (Full Control) Пользователи могут выполнять любые действия с файлом или папкой, включая ее создание и удаление, а также изменение разрешений.
    ЗАПРЕТ доступа всегда отменяет разрешение доступа. Если 2 группы для одного и того же их пользователя-члена имеют например разрешения на Изменение и Чтение соответственно, то пользователь получит суммарное право (Изменение).
    Если пользователю не назначены файловые разрешения NTFS, он не имеет права доступа.
    Разрешения общего доступа применяются только при получении пользователями доступа NTFS к папке. При одинаковых правах NTFS, две общие папки одного и того же ресурса могут давать разный доступ. При этом более лояльные права на дочернюю папку не перекрываются запретом родительской.
    Чтобы отконфигурировать файловые разрешения NTFS с помощью командной строки или сценария, используйте команду icacls.
    Вы создаете папку Маркетинг и конфигурируете разрешения NTFS, чтобы предоставить группе Пользователи домена разрешение Чтение, а группе Маркетинг разрешение Изменение ( Modify ). Вы назначаете общий доступ к этой папке и предоставляете группе Все (Everyone) разрешение общего доступа Чтение. Учетная запись Мэри входит в обе группы — Маркетинг и Пользователи домена. Ей требуется получать доступ к файлам в этой папке из любой точки сети. Какие разрешения будут действовать для Мэри?
    A. Нет доступа (No Access).
    Б. Чтение (Read).
    B. Запись (Write).
    Г. Полный доступ (Full Control).
    А. Неправильный Разрешение Нет доступа (No Access) будут иметь пользователи, к которым не применяются записи контроля доступа. В данном случае Мэри получит разрешение Чтение (Read), поскольку ей назначено файловое NTFS-разрешение и разрешения общего доступа.
    Б. Правильный При подключении к общей папке пользователи всегда получают минимальный уровень прав доступа, обеспечиваемый разрешениями общего доступа и NTFS. В данном случае разрешения общего доступа предоставляют группе Все право Чтение, так что Мэри получит лишь право чтения.
    В. Неправильный Если Мэри вошла на локальный компьютер и получает доступ к файлам на локальном жестком диске, разрешения общего доступа не будут играть роли, и Мэри сможет обновить файлы. Но поскольку Мэри получает доступ к папке, используя общий ресурс, которому назначено лишь разрешение Read, она сможет лишь читать файлы.
    Г. Неправильный Разрешение Полный доступ (Full Control) позволяет пользователям менять права доступа. Для получения этого уровня доступа Мэри должна располагать NTFS-разрешением Полный доступ (Full Control) и разрешением общего доступа Совладелец (Coowner).

    Домен


    После добавления компьютера в домен локальные учётные записи продолжают действовать как обычно. Естественно, они не имеют никаких прав в домене, кроме того, что администраторская локальная учётка имеет полные права на компьютере. При входе на компьютер с доменной учёткой с таким же именем, что и локальная, создаётся отдельная папка для этого пользователя с приставкой (обычно имя домена или имя домена.000).
    Назначить доменные права или общий доступ для объекта на члене домена можно только от имени администратора домена. Пользователь домена из доменных прав может назначить только себя, хотя видеть может всю структуру пользователей и групп.

    Общий доступ к папкам


    Самый простой способ назначить общий доступ к папке — ПКМ в Проводнике Windows и применить команду Общий доступ (Share). С помощью этого интерфейса можно выбрать 4 уровня прав доступа:
    Читатель - только чтение.
    Соавтор (Contributor) Обеспечивает доступ чтения и записи. Аналогичен разрешению общего доступа Изменение.
    Совладелец (Coowner) Позволяет пользователю изменять файловые разрешения, а также предоставляет полный доступ чтения и записи. Аналогичен разрешению общего доступа Полный доступ.
    Владелец ( Owner ) Назначается пользователю, который создает общий ресурс и позволяет изменять файловые разрешения, а также читать и записывать файлы. Аналогичен разрешению общего доступа Полный доступ.
    Общий доступ с парольной защитой включен по умолчанию для компьютеров в рабочих группах. Пользователи других компьютеров вашей сети не могут получить доступ к папкам и принтерам для общего доступа, если они не имеют учетной записи на соответствующем компьютере.
    Не забудь про Диспетчер учётных данных. Чтобы учётные записи в хранилище или те, которые сохранились во время первого логина на ресурс перестали действовать придётся перезалогиниться.
    С помощью Мастера подготовки общих папок ( Provision A Shared Folder Wizard) можно назначать общий доступ к папкам, конфигурировать квоты и параметры безопасности.
    1. ПКМ Роли\Файловые службы\Управление общими ресурсами и хранилищами и примените команду Подготовить общий ресурс (Provision Share). Запустится Мастер подготовки общих папок.
    2. На странице Разрешения NTFS (NTFS Permissions) щелкните опцию Да, изменить разрешения NTFS и, если необходимо, щелкните ОК. Щелкните кнопку Далее.
    3. На странице Протоколы общего доступа (Share Protocols) можно выбрать общий доступ к папке с использованием протокола Windows (протокол SMB — Server Message Block) или протокола UNIX (протокол NFS - Network File System). Как правило, протокола SMB достаточно даже для обеспечения работы клиентов UNIX.
    4. На странице Параметры SMB щелкните кнопку Дополнительно, если вам нужно изменить назначенное по умолчанию число пользователей, одновременно получающих доступ к ресурсу, или параметры автономных файлов (Offline Files).
    5. На странице Разрешения SMB, показанной на рис. 11-11, выберите разрешения, которые хотите назначить. Чтобы определить настраиваемые разрешения, щелкните опцию Пользователи и группы имеют особые разрешения для общего ресурса (Users And Groups Have Custom Share Permissions), а затем щелкните кнопку Разрешения (Permissions). Щелкните кнопку Далее.
    7. На странице Политика квот (Quota Policy) установите флажок Применить квоту (Apply Quota), если хотите определить квоту. Затем выберите шаблон квоты.
    8. На странице Политика фильтра блокировки файлов (File Screen Policy) установите флажок Применить фильтры блокировки файлов (Apply File Screen), если хотите, чтобы в папке отображались лишь конкретные типы файлов. Затем выберите фильтр блокировки, который хотите использовать.

    Профиль сети


    Общий доступ к файлам и принтерам (File Sharing). При включении этого компонента брандмауэр позволяет обычным пользователям назначать общий доступ к файлам и папкам в своих профилях, то есть в папках каталога %systemroot%\Users\% username %. Администраторы могут назначать общий доступ к любому файлу и папке на компьютере.
    При включении общего доступа к файлам брандмауэр создает исключения для протокола ICMP, который используют утилиты Ping, Pathping и Tracert. Если оставить общий доступ к файлам отключенным, то локальный компьютер по умолчанию не станет реагировать на запросы ping.
    Общий доступ к общим папкам (Public Folder Sharing). При включении этого компонента будет автоматически назначен общий доступ к папке %systemroot%\Users\Public и разрешен общий доступ к файлам.
    Использование общих принтеров (Printer Sharing). При включении этого компонента разрешается общий доступ к принтерам, установленным на локальном компьютере. При выборе данного компонента автоматически включается общий доступ к файлам.
    Общий доступ с парольной защитой (Password Protected Sharing). Этот компонент доступен лишь на компьютерах, не присоединенных к домену. При его включении доступ к общим ресурсам могут получать только пользователи с действительными учетными записями на локальном компьютере.

    Подключение к общим папкам


    Клиентские компьютеры подключаются к общим папкам по сети с использовапием формата UNC (Universal Naming Convention) \\\.
    В формате UNC можно указать имя любой папки. Содержимое общей папки можно просмотреть в командной строке с помощью такой команды:
    dir \\MySorvor\MyDoc
    Болыпипство пользователей предпочитают получать доступ к общим папкам с помощью сетевого диска. Сетевые диски сопоставляют букву диска общей папке. Пользователи клиентских компьютеров могут подключаться к общим папкам, щелкнув меню Сервис (Tools) и выбрав команду Подключить сетевой диск. Сетевой диск можно также подключить с помощью команды Net в командной строке:
    net use : \\\\

    Шифрующая файловая система EFS


    Система безопасности NTFS не защищает от перестановки носителя под управление другой ОС. Файловая система EFS защищает файлы и папки, выполняя их шифрование на диске. EFS поддерживается во всех версиях Windows, начиная с Windows 2000.
    EFS влияет на производительность, поскольку для расшифровки файлов требуется время. В среднем производительность снижается на 10-60 %.
    В случае, если зашифровывается папка, система Windows будет автоматически шифровать все новые файлы в этой папке. Шифрованные файлы отображаются в проводнике Windows зеленым цветом.
    При первом шифровании файла или папки система Windows может предложить архивировать ключ шифрования. При выборе опции архивации ключа запустится Мастер экспорта сертификата. В средах AD для восстановления файлов следует использовать агент восстановлении данных (Data Recovery Agent, DRA).

    Общий доступ к файлам с защитой EFS


    Для совместного использования файлов с защитой EPS на локальном компьютере нужно добавить к файлу пользовательские сертификаты шифрования. Для совместного использования файлов по сети делать это не нужно, поскольку EFS предназначена для защиты доступа к файлам на локальном компьютере, и система Windows автоматически выполняет расшифровку файлов перед назначением общего доступа.
    Чтобы назначить общий доступ к файлу с защитой EFS, выполните следующее. Свойства зашифрованного файла/Общие/Другие-Дополнительные атрибуты/Подробно-Пользовательский доступ/Добавить-Шифрующая файловая система. Выберите пользователя, которому хотите предоставить доступ, и щелкните кнопку ОК. Выбранный вами пользователь, локально вошедший в систему, сможет открывать этот файл.

    Настройка EFS с помощью параметров групповой политики


    ПКМ Конфигурация компьютера\Политики\Коифигурация Windows\Параметры безопасности\Политики открытого ключа\Шифрующая файловая система, и применив команду Свойства, чтобы открыть диалоговое окно Свойства: Шифрующая файловая система.
    1. Шифрование файлов с помощью EFS. По умолчанию шифрование EFS разрешено. Если выбрать опцию Запретить, пользователи не смогут шифровать файлы с помощью системы EFS.
    2. Требовать смарт-карту для EFS (Require A Smart Card For EFS). Если установить этот флажок, нельзя использовать сертификаты программного обеспечения для EFS.
    3. Создать кешируемый пользовательский ключ из смарт-карты (Create Caching-Capable User Key From Smart Card). Если установить этот и предыдущий флажки, пользователям потребуется вставить смарт-карту лишь при первом получении доступа к зашифрованному файлу в сеансе.
    4. Включить шифрование файла подкачки (Enable Pagefile Encryption). Windows использует файл подкачки для хранения копии данных, которые помещаются в памяти, поэтому файл подкачки может содержать незашифрованные копии файлов с защитой EFS. В случае отключения этого параметра злоумышленник может найти незашифрованные данные в файле подкачки, но шифрование этого файла может повлиять на производительность.
    5. Отображать уведомления об архивации ключа при создании или изменении пользовательского ключа (Display Key Backup Notifications When User Key Is Created or Changed) Если установить этот флажок, система Windows предложит пользователю выполнить архивацию ключей EFS при создании и изменении ключей шифрования.
    6. Разрешить EFS создавать самозаверяющие сертификаты, когда центр сертификации недоступен (Allow EFS To Generate Self-Signed Certificates When A Certification Authority Is Not Available ). Если отключить этот параметр, клиентским компьютерам при первом шифровании файла с помощью EFS потребуется обращаться в центр сертификации. Таким образом, пользователи, отключенные от сети, не смогут включить применение EFS. Чтобы разрешить системе EFS получать сертификат из центра сертификации вместо создания самозаверяющего сертификата, нужно отконфигурировать центр сертификации и включить автоматическую подачу заявок.
    7. Конфигурация компьютера\Политики\Административные шаблоны\Сеть\Автономные файлы\Шифрование кэша автономных файлов (Computer Configuration\PoIicies\Administrative Templates\Network\Offline Files\Encrypt The Offline Files Cache) Включите этого параметр, чтобы шифровать автономные файлы.
    8. Конфигурация компьютера\Политики\Административные шаблоны\Компоненты Windows\Найти\Paзрешить индексирование шифрованных файлов (Computer Configuration\Policies\Administrative Templates\Windows Components\Search\Allow Indexing Of Encrypted Files) В случае индексирования зашифрованных файлов злоумышленник может определить содержимое зашифрованного файла, проанализировав индекс. Отключение индексирования шифрованных файлов повышает уровень безопасности, но пользователи не смогут выполнять поиск этих файлов.

    Настройка агента восстановления данных


    Если ключ расшифровки утерян, зашифрованный файл недоступен для всех, включая системных администраторов. Чтобы включить восстановление зашифрованных файлов, система EFS поддерживает агент восстановления данных (Data Recovery Agent, DRA). Агенты DRA могут выполнять расшифровку зашифрованных файлов. В производственных средах AD для настройки учетных записей пользователей в качестве агентов DRA уровня организации могут служить параметры групповой политики. Чтобы отконфигурировать агентов DRA на предприятии, выполните следующее.
    1. Отконфигурируйте центр сертификации предприятия. Например, вы можете установить роль сервера Службы сертификации AD с параметрами по умолчанию.
    2. Создайте пользовательскую учетную запись, которая будет играть роль агента восстановления данных, но вы можете задействовать и существующую пользовательскую учетную запись. Агент DRA может получать доступ к любому зашифрованному файлу — то есть имеет практически неограниченные полномочия, которые следует жестко контролировать. Войдите в систему с использованием учетных данных агента DRA.
    Для учетной записи агента восстановления данных DRA или любой учетной записи с высоким уровнем привилегий лучше, чтобы два лица вводили по половине пароля. Таким образом, для доступа к учетной записи агента DRA потребуется участие двух лиц. Эта концепция безопасности называется групповой безопасностью (collusion).
    3. ПКМ Конфигурация компьютера\Политики\Конфигурация Windows\Пapaмeтpы безопасности\Политики открытого ключа\Шифрующая файловая система и примените команду Создать агент восстановления данных. Редактор управления групповыми политиками создаст сертификат восстановления файлов для учетной записи агента DRA.
    Агенты восстановления данных могут открывать зашифрованные файлы аналогично другим файлам, как если бы они были зашифрованы с применением собственного сертификата пользователя. На предприятии можно создать множество агентов восстановления данных.

    Роль Файловые службы


    В системе WServer общий доступ можно назначить без добавления ролей сервера. Но при добавлении роли сервера Файловые службы предоставляются удобные инструменты управления и возможность участвовать в именных пространствах DFS, настраивать квоты, генерировать отчеты хранения, и многое другое.
    В процессе установки роли:
    1. Добавив Файловый сервер, вы сможете использовать оснастку Управление общими ресурсами и хранилищами (Share And Storage Management).
    2. Диспетчер ресурсов файлового сервера устанавливает инструменты для генерирования отчетов хранилища, настройки квот и определения политики отображения файлов. Если выбрать эту службу ролей, мастер предложит включить наблюдение за хранилищем на локальных дисках.
    3. Службы для NFS (Services for Network File System) Обеспечивает возможности коммуникаций для клиентских компьютеров UNIX, используемых для общего доступа к файлам сетевую файловую систему NFS (Network File System). Отметим, что большинство современных операционных систем UNIX могут подключаться к стандартным общим файловым хранилищам Windows, так что эта служба обычно не требуется.
    4. Служба поиска Windows. Индексирует файлы для ускорения поиска при подключении клиентов к общей папке. Эта служба ролей не предназначена для предприятий. Если выбрать ее, мастер предложит включить индексирование на локальных дисках.
  • Файловые службы Windows Server 2003. Обеспечивает службы, совместимые с компьютерами Windows Server 2003.

    Квоты


    С помощью квот можно запретить пользователям занимать дисковое пространство больше, чем им выделено (хотя это часто приводит к отказам приложений и, как правило, не рекомендуется).
    Влияние квот на производительность дисков не достигает и 10 %.
    После установки Диспетчера ресурсов файлового сервера (File Server Resources Manager) дисковыми квотами можно управлять с помощью консоли Диспетчере сервера\Роли\Файловые службы\Управление общими ресурсами и хранилищами\Диспетчер ресурсов файлового сервера\Управление квотами. Консоль Управление квотами обеспечивает более гибкий контроль, оповещая пользователей или администраторов о превышении пользователями порогового значения квоты или запуская исполняемый файл, автоматически выполняющий очистку дискового пространства.
    Создание шаблонов квот С помощью такого шаблона можно установить параметры квот и отклик. Например, в систему WServer включены следующие стандартные шаблоны:
    Предел 200 МБ с расширением 50 МБ. При достижении этого значения компьютер отправляет электронное сообщение пользователю и администраторам, а затем применяет квоту Расширенный предел 250 МБ, чтобы предоставить пользователю дополнительное дисковое пространство.
    Расширенный предел 250 МБ. Изначально применяется с предыдущим шаблоном квоты для предоставления пользователю дополнительного дискового пространства 250 Мбайт.
    Диалоговое окно Добавление порога (Add Threshold) содержит четыре вкладки.
    1. Сообщение электронной почты Отправляет сообщение электронной почты администраторам или пользователю. Чтобы определить переменную [ Admin Email ] и другие параметры электронной почты, ПКМ значок Диспетчер ресурсов файлового сервера (File Server Resource Manager) и примените команду Настроить параметры (Configure Options).
    2. Журнал событий (Event Log) Регистрирует в журнале событие, которое можно обрабатывать с помощью средств управления.
    3. Команда При достижении порогового значения запускает
    команду или сценарий: На этой вкладке можно назначить сценарий, автоматически сжимающий файлы, удаляющий временные файлы или выделяющий пользователю больше дискового пространства.
    4. Отчет (Report) Генерирует отчет, который можно пересылать по электронной почте администраторам или пользователю. На этой вкладке можно выбрать множество отчетов.
    Создание квоты:
    1. Щелкните кнопку Обзор, чтобы выбрать папку, к которой будет применена квота.
    2. При желании выберите опцию Автоматически применять шаблон и создавать квоты на существующих и новых вложенных папках. Тогда шаблон будет применяться ко всем новым папкам, создаваемым в выбранной родительской папке.
    Оснастка Квоты (Quotas) отобразит созданную квоту, которая будет немедленно применена.

    Настройка дисковых квот с помощью командной строки или сценария


    Для настройки дисковых квот с помощью командной строки или сценария можно использовать команду DirQuota. Например, следующая команда применяет стандартный шаблон Предел 200 МБ с уведомлением пользователя к папке C:\Shared.
    dirquota quota add /Path:C:\Shared /SourceTemplate:"200 MB Limit Reports To User"
    Чтобы создать жесткий предел 100 Мбайт, запустите следующую команду:
    dirquota quota add /Path:C:\Shared /Limit:100MB /Type: Hard
    Хотя с помощью команды DirQuota можно создать множество пороговых значений и предупреждений, как правило, проще использовать шаблоны и применять к ним команду DirQuota. Чтобы получить полную информацию об утилите DirQuota, введите команду DirQuota /?.

    DFS


    Система DFS обеспечивает отдельное именное пространство, позволяющее пользователям подключаться к любой общей папке в организации (например, используя одну букву сетевого диска в Проводнике). Например, для домена AD с именем contoso.com создается именное пространство \\contoso.com\dfs. Затем можно создать папку \\contoso.com\dfs\ marketing и сопоставить ее с общими папками на двух серверах \\server1\marketing и \\server2\marketing. Можно создать и несколько таких пространств имён.
    DFS может обеспечить избыточность для общих файлов с помощью репликации. Репликация также позволяет управлять общей папкой на множестве серверов, чтобы клиентские компьютеры автоматически подключались к ближайшему доступному серверу.
    Конечный объект папки (folder target ). Общая папка, обслуживаемая на сервере Windows. Папка DFS – папка, соответствующая конечному объекту, которая будет отображаться под корнем при подключении клиента DFS. Имя папки DFS и имя общего ресурса вовсе необязательно должны выглядеть одинаково, но для упрощения процесса устранения неполадок настоятельно рекомендуется, чтобы это было именно так. Для обеспечения отказоустойчивости одной папке DFS может назначаться несколько конечных объектов папки. Тогда в случае недоступности одного конечного объекта папки клиенты будут подключаться к другому доступному конечному объекту. Конечные объекты папок могут иметь вид как имени общего ресурса, так и папки под общим ресурсом. Например, и \\serverl\userdata, и \\serverl\usedata\ Finance будут являться действительными конечными объектами папки.
    Диалоговое окно свойств именного пространства содержит вкладки: Ссылки (Referrals). При доступе к корню именного пространства или папкам клиент получает ссылку с контроллера домена. Клиенты всегда пытаются получить доступ к первому целевому компьютеру в списке ссылок, а если компьютер не отвечает, переходят к следующему в списке. На этой вкладке можно управлять сортировкой конечных ресурсов в списке. В раскрывающемся списке Метод сортировки (Ordering Method) выберите Случайный порядок ( Random Order), чтобы распределять ссылки среди всех конечных объектов. Минимальные затраты (Lowest Cost ), чтобы направлять клиентов на ближайший конечный компьютер с помощью ссылок сайта. Чтобы клиенты не могли получать доступ к конечному объекту на другом сайте AD, выберите метод Исключить конечные объекты вне сайта клиента. По умолчанию папки наследуют метод сортировки корня именного пространства, но вы можете редактировать также свойства отдельных папок. Ссылки - конфигурационный параметр пространства имен и/или папки DFS, который определяет, как клиенты DFS будут подключаться к серверу пространства имен, папке в пространстве имен или отдельному серверу конечных объектов папки. Свойства ссылки позволяют ограничивать количество клиентских подключений к серверам на локальном сайте AD и указывать частоту проверки доступности сервера DFS. Отключение ссылки конечного объекта делает невозможным его использование клиентами, что может быть удобно при необходимости проведения на сервере процедур обслуживания.
    Параметр Продолжительность кэширования (Cache Duration) определяет время ожидания клиентов перед запросом новой ссылки.
    Дополнительно (Advanced). Оптимизировать для согласованности (Optimize For Consistenсу) конфигурирует серверы именного пространства для запросов основного контроллера домена PDC при каждом изменении именного пространства.
    ПКМ именное пространство - Создать папку. Введите имя для папки. Если она будет использоваться лишь в организационных целях (например, будет только содержать другие папки), щелкните ОК. Если же папка должна содержать файлы, щелкните кнопку Добавить, чтобы связать ее с общей папкой. Если добавить множество папок с конечными объектами, для этих папок можно отконфигурировать автоматическую репликацию.
    Access-based Enumeration (ABE) – пользователям разрешено видеть только те файлы и папки, которые разрешено. Активизировать ABE можно когда создается пространство имен на основе домена. Здесь нужно иметь в виду один момент: изменение применяется к всему пространству имен и всем исходным и целевым папкам, определенным в пространстве имен. По умолчанию данная функция отключена.
    Дерево DFS начинается с корня пространства имен DFS.
    Подключение репликации. Объект каталога, который определяет и отвечает за проведение репликации между отправляющим и принимающим сервером-членом репликации. При создании подключения репликации задаются такие параметры, как график репликации, служба, которая будет выполнять репликацию данных, отправляющие и принимающие члены и любые необходимые ограничения по пропускной способности. Для каждого подключения репликации может указываться только один отправляющий и принимающий член.
    Член репликации - cервер с общим подключением репликации.
    Содержать папки реплик, предназначенные только для чтения, могут лишь члены репликации, которые не определены как первичный источник. Это может пригодиться для проведения аудита, централизованного резервного копирования или управления наборами данных. RODC обслуживают том SYSVOL как папку репликации, доступную только для чтения.
    Группа репликации - все серверы, папки и подключения, которые определяют подлежащий репликации набор данных.
    Репликация нескольких главных копий (multimaster replication) - двусторонний процесс репликации между несколькими серверами в группе репликации.
    DFS позволяет создавать общий файловый ресурс для корней пространства имен, папок или конечных объектов папок и настраивать для него разрешения, но не конфигурировать для него во время этого процесса разрешения NTFS и дополнительные функциональные возможности. Администраторы DFS должны создавать и определять общие ресурсы, права доступа к ним и права NTFS на общую папку, еще до определения этих общих ресурсов как конечных объектов папок DFS.
    Консоль управления DFS пока что не умеет ни конфигурировать дополнительные функции или параметры общего доступа, ни синхронизировать разрешения NTFS для общих ресурсов корня пространства имен и конечных объектов папки. Если будет использоваться несколько серверов корней пространства имен или несколько серверов конечных объектов папки, разрешения между этими серверами потребуется синхронизировать вручную так, чтобы они совпадали, иначе возможны проблемы с доступом.
    Distributed File System Replication (Репликация распределенной файловой системы) подразумевает использование нового протокола RDC (Remote Differential Compression — удаленное дифференциальное сжатие), который умеет копировать только изменившиеся части файла, а функция cross-file RDC меньше нагружает канал при копировании новых файлов. Том системы домена (SYSVOL) будет реплицироваться между контроллерами домена с помощью службы DFSR.
    Механизм репликации DFS и пространства имен DFS не зависят друг от друга. Репликация папок может настраиваться между серверами, не обслуживающими ни пространства имен DFS, ни папки пространств имен DFS, но тогда служба репликации DFS должна быть установлена на всех системах, принимающих участие в репликации.
    WServer увеличивает безопасность и производительность репликации DFS, поскольку вся репликация DFS сжимается и шифруется. Обратите внимание, что поток данных не может передаваться в незашифрованном виде.
    WServer теперь позволяет определять реплицированную папку как доступную только для чтения. Когда нужны реплицированные папки только для чтения, при работе с мастером репликации папок выбирайте переключатель No Topology. После создания группы репликации выберите ее в панели с древовидным представлением, а в панели действий выберите вкладку Membership (Членство). ПКМ на желаемом члене Replicated Folder (Реплицируемая папка) и выберите в контекстном меню пункт Make Read-only.
    В качестве полезного совета: при использовании реплицированных папок только для чтения конфигурируйте подключения репликации как однонаправленные — в сторону папки только для чтения.
    При первой настройке репликации с помощью консоли DFS и мастера создания группы репликации администратор может выбирать, какой из серверов назначения будет первоначальным ведущим сервером. Данные, находящиеся на первоначальном сервере, реплицируются в остальные конечные объекты. Для конечных объектов на серверах, не являющихся первоначальными, существующие данные пересылаются в скрытый каталог, а в текущий каталог заносятся данные, содержащиеся только в совместно используемой папке первоначального сервера. После завершения первичной репликации администратор может восстанавливать данные, пересланные в скрытую папку, обратно в рабочий каталог, что может запускать репликацию во все остальные реплики.
    Промежуточная папка (staging folder) — это место, где член репликации DFS хранит данные, которые будут реплицироваться на другие члены репликации внутри группы репликации. В полностью синхронизируемой группе репликации промежуточная папка на всех серверах будет пустой. Поскольку данные репликации будут проходить через эту папку, диск, на котором находится промежуточная папка, должен иметь достаточно свободного пространства для вмещения промежуточной папки максимального размера и при этом иметь возможность обрабатывать дополнительную дисковую нагрузку. По умолчанию размер промежуточной папки составляет 4 Гбайт. Местоположение промежуточной папки по умолчанию — в целевой папке общего доступа, находящейся в скрытой папке по имени c:\ Apps \DfsrPrivate\Staging, если цель, к примеру, находится в C:\Apps.
    В WServer система DFS поставляется с несколькими встроенными топологиями репликации. В общем, если организации необходима настоящая многоуровневая репликация, администратору лучше настраивать подключения и график репликации DFS в соответствии с текущими подключениями топологии репликации сайта AD или уже существующей сетевой топологией.
    Топология "Звезда" (hub-and- spoke ) - один конечный объект назначается центральным (hub server) сервером репликации, а все остальные конечные объекты автоматически становятся лучевыми (spoke server) серверами репликации и осуществляют репликацию только с этим центральным сервером. Центральный сервер имеет два подключения с каждым лучевым сервером: одно для отправки данных и одно для получения данных. Такая топология требует трех или более серверов. В WServer появилась возможность задавать более одного центрального объекта при создании звездообразной топологии.
    В случае применения топологии "Полная сетка" (full mesh) каждый конечный объект имеет соединение со всеми остальными конечными объектами в группе репликации. Это позволяет продолжать выполнение репликации между доступными членами репликации даже тогда, какой-то из членов становится недоступным. Поскольку у каждого члена имеется соединение с каждым из всех остальных членов, репликация может продолжаться даже при доступности всего лишь двух членов репликации. Использование этой топологии с наборами репликации для чтения/записи может приводить к конфликтам данных, если данные изменяются на нескольких сайтах, поэтому данную топологию следует применять с осторожностью.
    No Topology - выбор этой опции позволяет администратору создавать после создания группы репликации специальную топологию репликации, в которой он может определять для каждого конечного объекта специальные подключения репликации. Такой вариант может быть удобен в случаях, когда организация хочет использовать однонаправленную репликацию для централизованного резервирования или оптимизировать реплицируемые папки только для чтения. Также это может оказаться удобнее всего при создании топологии для сети, подключаемой через линии глобальной сети (WAN) различной скорости, или когда для каждого подключения репликации нужно свое расписание и параметры пропускной способности.

    Создание пространства имён и корня DFS


    DFS можно установить при добавлении роли сервера Файловые службы:
  • На странице Сервер пространства имен введите имя сервера, который будет управлять именным пространством. С целью обеспечения избыточности позже можно добавить серверы для управления именным пространством.
  • Если откроется страница Тип пространства имен, выберите, следует ли использовать именное пространство домена (для сред AD) или выбрать автономное пространство имен (для рабочих групп). Доменные пространства имен используют в качестве корня имя домена AD, а автономные именные пространства — имя сервера.
    Автономные корни могут поддерживать только один конечный объект корня, но администратор при необходимости может настраивать несколько конечных объектов папки. Они представляются с помощью имени сервера, на котором находится корень и сам общий ресурс. Данные, хранящиеся в этих нескольких конечных объектах папки, должны обязательно вручную поддерживаться в синхронизированном состоянии, если только сервер автономного пространства имен и все серверы конечных объектов папки не являются членами одного домена Active Directory и не используют репликацию DFS. Автономные корни обычно развертываются в средах без доменов AD и могут применяться для включения функции ABE папок DFS, а также активизации возможности включения в пространство имен более 5000 папок (ограничение доменных корней связано с тем, что
    вся структура хранится в специальном объекте, который также необходимо дублировать на всех DC при любом малейшем изменении в структуре DFS. В документации рекомендуется ограничивать максимальный размер объекта 5 Мб, что соответствует приблизительно 5000 ссылок (каталогов). Эта величина зависит от многих параметров (длины имени ссылок, наличия и размера комментариев и пр.), которые также хранятся в этом объекте. Но в среднем DFS редко превышает 50-100 ссылок, и после первоначальной настройки она остается в основном статичной, а значит, часто дублироваться не будет, и этих ограничений достичь просто не удастся.). Не связан с AD, и все ссылки на сетевые ресурсы хранятся в реестре самого сервера DFS. При выходе из строя сервера DFS вся иерархия становится недоступной, хотя пользователи могут обращаться к ресурсам напрямую. К слову, несколько серверов Standalone DFS способно работать в кластере, поэтому эта проблема может быть решена.
    Чтобы администратор мог создать доменный корень DFS, первоначальный сервер корня пространства имен должен являться членом домена AD. Доменные пространства имен DFS могут использовать службу репликации DFS для репликации данных между множеством конечных объектов папки.
  • Если откроется страница Конфигурация пространства имен, можно добавить папки. Это можно сделать и потом, с помощью оснастки Управление DFS.
  • На странице Наблюдение за хранилищем (Storage Usage Monitoring) установите флажки для всех локальных дисков.
    Dcsrvl следует отконфигурировать как контроллер домена, а машину Boston — как член домена. Повторите установку DFS на машине Boston, но не создавайте именное пространство.
    Для создания пространства имен DFS администратор должен обладать на каждом из серверов, которые будут обслуживать это пространство имен, правами уровня группы локальных администраторов, а в случае выбора пространства имен домена — еще и правами администратора домена, поскольку информация о доменном пространстве имен хранится в Active Directory.
    Для создания корня пространства имен DFS требуется общий файловый ресурс. При создании корня DFS корню может назначаться либо имя, соответствующее имени какого-то существующего общего файлового ресурса, либо специальное имя. Мастер выполняет на указанном сервере поиск существующего общего файлового ресурса, соответствующего имени корня DFS; если ему не удается найти таковой, он создает его самостоятельно в рамках процесса.
    В качестве наилучшего практического приема, общий файловый ресурс с надлежащими разрешениями разделяемого ресурса и NTFS рекомендуется создавать и конфигурировать до создания корня DFS. Однако следует иметь в виду, что имя разделяемого ресурса должно соответствовать пространству имен DFS. Заблаговременная настройка необходимых разрешений NTFS поможет упростить устранение неполадок и администрирование пространства имен в будущем.
    Чтобы консоль DFS Management появилась в программе Server Manager, нужно закрыть все экземпляры Server Manager и затем снова открыть перед выполнением последующих шагов.
    Войдите в систему WServer от имени учетной записи с правами локального администратора сервера. Если будет создаваться доменное пространство имен и корень DFS, удостоверьтесь, что данная учетная запись обладает необходимыми привилегиями в контейнере DFS-Configuration внутри Active Directory.
    Первичное имя корня DFS должно совпадать с именем созданного ранее общего файлового ресурса. Если общего ресурса с таким именем не существует, мастер предложит создать его из какой-нибудь существующей или вообще новой папки.
    На машине Dcsrvl ПКМ Роли\Файловые службы\Управление DFS\Пpoстранства имен\'\Public' примените команду Добавить сервер пространства имен. Если один из них отключен, клиенты смогут подключаться ко второму. Создайте и установите заранее необходимые разрешения NTFS для всех серверов и общих ресурсов, которые будут обслуживать корень пространства имен DFS. Если подходящий общий ресурс уже существует, во всплывающем окне, которое появится далее, щелкните на кнопке ОК, чтобы использовать имеющийся общий ресурс и существующие разрешения. Если общего ресурса не существует, он будет создан автоматически по умолчанию в папке с:\DFSRoots.

    Cоздание папки DFS и группы репликации

    Способ 1


    Создадим общую папку с именем Files на Dcsrvl и Boston, добавим эту общую папку в пространство имен DFS и отконфигурируем ее для репликации.
    1. На машине Dcsrvl ПКМ узел Роли\Файловые службы\Управление общими ресурсами и хранилищами (Share And Storage Management) - Подготовить общий ресурс (Provision Share).
    2. На странице Размещение общей папки введите путь C:\Files. На странице Разрешения (Permissions) NTFS выберите опцию Да, изменить разрешения NTFS.
    3. На странице Параметры SMB щелкните кнопку Дополнительно. На вкладке Кэширование выберите опцию Все файлы или программы из общего ресурса недоступны в автономном режиме (No Files Or Programs From The Share Are Available Offline). Таким образом, мобильные компьютеры не будут хранить локально кэшируемую копию файлов.
    4. На странице Политика квот установите флажок Применить квоту, Выберите опцию Автоматически применять шаблон для создания квот на существующих и новых вложенных папках. Затем в раскрывающемся списке Наследовать свойства из следующего шаблоны квоты (Derive Properties From This Quota Template) выберите шаблон Предел 200 МБ с расширением 50 МБ.
    5. На странице Политика фильтра блокировки файлов (File Screen Policy) установите флажок Применить фильтры блокировки файлов (Apply File Screen). В раскрывающемся списке Наследовать свойства из следующего шаблона фильтра блокировки файлов (Derive Properties From This File Screen Template) выберите шаблон Блокировать исполняемые файлы.
    6. Если пространство имён ты уже создал, то на странице Публикация в пространстве имен DFS установите флажок Публиковать общий ресурс SMB в пространстве имен DFS. В поле Родительская папка в пространстве имен введите путь к папке \\nwtraders.msfi\Public (или укажите имя своего домена). В поле Имя новой папки введите имя Files.
    7. На машине Boston откройте окно командной строки с полномочиями администратора и запустите следующие команды для создания папки, предоставления разрешения NTFS Изменение для группы Пользователи и назначения общего доступа к папке. Так вы продублируете общую папку, созданную на машине Dcsrvl:
    mkdir C:\Files
    icacls C:\Files\ /grant users:M
    net share Files=C:\Files /GRANT:Users, READ /GRANT:Administrators,
    FULL /CACHE: None
    8. На Dcsrvl ПКМ \\nwtmders.msft\Public\Files и примените команду Добавить конечный объект папки (Add Folder Target) (если нажимать не на что, то сначала нажми Обновить). В диалоговом окне Создание конечного объекта папки (New Folder Target) введите имя папки \\Boston\Files.
    9. В диалоговом окне Репликация (Replication) щелкните кнопку Yes, чтобы создать группу репликации между серверами Dcsrvl и Boston. На странице Группа репликации и имя папки репликации (Group And Replicated Folder Name) щелкните кнопку Далее. На странице Replication Eligibility щелкните кнопку Далее.
    10. На странице Основной член (Primary Member ) выберите компьютер Dcsrvl.
    11. На странице Выбор топологии (Topology Selection) выберите опцию Полное слияние (Full Mesh). Отметим, что в случае с несколькими партнерами репликации (более двух-трех) о постоянном обновлении одного сервера более эффективно использовать топологию Hub And Spoke.
    12. Войдите на компьютер Dcsrvl как обычный пользователь, щелкните опцию Подключить сетевой диск (Map Network Drive ). Введите имя папки \\nwtraders.msft\Public\Files.
    13. На новом подключенном диске создайте текстовый файл. Ваши права ограничены компонентом UAC до уровня обычного пользователя, а группа Пользователи имеет лишь разрешение на чтение, поэтому, даже несмотря на предоставление группе Пользователи разрешения NTFS Изменение, создать файл вы не сможете.
    14. В проводнике Windows выберите папку C:\Files. Создайте текстовый документ. На машине Boston откройте проводник Windows и просмотрите папку С:\Files. Обратите внимание на выполнение репликации документа Текстовый файл (на это может потребоваться несколько минут).

    Способ 2


    Папка DFS может создаваться для охватывания как существующих общих ресурсов или имеющихся в них папок, так и для совершенно новых общих ресурсов, создаваемых специально на желаемом сервере или серверах. В случае создания новой папки DFS с множеством конечных объектов одновременно вместе с ней может также создаваться еще и группа репликации.
    1. Войдите в систему WServer от имени учетной записи с правами локального администратора сервера.
    2. Создайте и установите заранее необходимые разрешения NTFS для всех серверов и общих ресурсов, которые будут обслуживать папку пространства имен DFS.
    3. Пуск/Все программы/Администрирование\Управление DFS. Выделите желаемое существующее пространство имен и щелкните на ссылке Создать папку. Введите имя папки и щелкните на кнопке Add, чтобы добавить нужные конечные объекты папки.
    4. Когда откроется окно Replicate Group and Replicate Folder Name (Репликация группы и репликация имени папки), проверьте имя, предлагаемое для группы репликации, а также имена папок. Эти имена должны совпадать с именем пространства имен и конечных объектов папки.
    6. Далее появится окно Replication Eligibility (Пригодность для репликации) с информацией о пригодности каждого из конечных объектов папки для осуществления репликации DFS. Если все они пригодны, щелкните на кнопке Next.
    7. На странице Primary Member (Главный член) щелкните на стрелке раскрывающегося списка Primary Member и выберите сервер конечных объектов папки, который будет использоваться для заполнения всех остальных серверов-членов. Данные, существующие в папке главного сервера-члена, будут реплицироваться на каждый из остальных серверов-членов.
    8. На странице Topology Selection (Выбор топологии) выберите желаемую топологию репликации. Для данного примера выберите вариант Hub and Spoke (Звезда), и щелкните на кнопке Next, чтобы продолжить.
    9. На странице Hub Members (Центральные члены) все серверы изначально будут перечислены в разделе Spoke Member (Лучевой член). Выполните двойной щелчок на желаемых серверах для перемещения их в раздел Hub Member, если они будут использоваться в качестве центрального сервера. Центральные серверы реплицируются со всеми прочими серверами, а периферийные серверы реплицируются только центральными серверами, определенными на этой странице. Как только все необходимые центральные серверы окажутся в разделе Hub Member, щелкните на кнопке Next.
    10. На странице Hub and Spoke Connections (Соединения звезды) каждый из периферийных серверов будет перечислен вместе со своим обязательным и дополни- тельным центральными серверами. Дополнительные центральные серверы будут заполнены только в том случае, если на предыдущем шаге в качестве центральных выбрано несколько серверов. Несмотря на то что центральные серверы показаны как обязательный и дополнительный, периферийные серверы будут выполнять ре- пликацию с обоими, и между обоими дополнительными и периферийным сервером будут установлены соединения. Кроме того, центральные серверы будут осуществлять репликацию друг с другом.
    11. При выбранной группе репликации в древовидной панели в панели задач выберите вкладку Connections для просмотра соединений, установленных на предыдущих шагах.

    Рекомендации по репликации DFS


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

    Управление и устранение неполадок в DFS


    С помощью команды «Проверить статус» для пространства, вызываемой из меню консоли или контекстного меню, можно проверить состояние реплики. Состояние будет указано в одноименном столбце, и рядом с именем появится кружок с отметкой. Если она зеленого цвета, значит все нормально. Для проверки можно зайти по указанному UNC или использовать на локальном компьютере команду net share, а на удаленном — net view computer_name. Покажет информацию о DFS:
    >dfsutil /Root:\\server.com\ first /View
    DFS Utility Version 5.2 ( built on 5.2.3790.3959)
    Domain Root with 0 Links [Blob Size : 284 bytes ]
    Root Name="\\SERVER\first" Comment="first Root"
    State="1" Timeout="300"
    Target Server="GRINDERS" Folder="first" State="2"
    [Site: Default-First-Site-Name]
    Командные утилиты DFS:
    DfsUtil. Может использоваться для управления пространствами имен DFS, серверами и клиентами. DfsUtil также можно применять для экспорта пространств имен DFS в файлы XML с целью последующей миграции в новые системы. Имеет больше возможностей, чем DfsCmd, но по умолчанию не включена в состав ОС. Чтобы ее использовать, необходимо установить пакет Support Tools. Обрати внимание, что для успешной установки Support Tools требуется скачать два файла: suptools.msi и support.cab.
    Для просмотра корней DFS в домене:
    dfsutil domain «имя_домена»
    Чтобы просмотреть корни на конкретном сервере:
    dfsutil server
    Если нужно просмотреть конечные объекты в именном пространстве
    dfsutil target \\\
    При необходимости просмотреть конечные объекты в папке, введите:
    dfsutil link \\\\
    Дли просмотра сайта AD, на котором работает клиент
    dfsutil client siteinfo
    Включение ABE
    dfsutil property abde enable \\'namespace_root'
    должна показать состояние всех подключенных ссылок и их свойства
    dfsutil /view
    DfsCmd. Может использоваться для управления папками и конечными объектами внутри существующего пространства имен DFS.
    DfsrAdmin. Может использоваться для выполнения действий на существующих группах репликации DFS, включая добавление новых папок групп репликации и генерации отчетов о существующих членах реплицируемых папок.
    DfsDiag. Может использоваться для запуска репликации, останова репликации или отчета о работоспособности репликации.
    Консоль управления DFS позволяет отображать и просматривать в единственном окне как автономные, так и доменные корни DFS. Администратор может проверять в ней доступность корней и конечных объектов папки DFS просто путем просмотра информации о состоянии подключения всех конечных объектов в определенной группе репликации. С ее помощью он еще также может и создавать специальные диагностические отчеты по репликации DFS. Необходимые для создания такого отчета шаги описаны ниже.
    1. Если требуемой группы репликации в списке не окажется, щелкните на узле Репликация правой кнопкой мыши, выберите в контекстном меню пункт Add Replication Groups to Display (Добавить группы репликации для отображения) и выполните шаги по добавлению желаемой группы.
    2. Щелкните на требуемой группе репликации правой кнопкой мыши и выберите в контекстном меню, которое появится после этого, пункт Create Diagnostic Report 3. Если был выбран отчет, он будет сохранен в папке c:\DFSReports со стандартным именем; при необходимости измените имя и размещение отчета и щелкните на кнопке Next.
    4. На странице Members to Include (Охватываемые члены) добавьте или удалите желаемые целевые серверы папок для отчета и щелкните на кнопке Next.
    5. На странице Options выберите желаемые параметры для деталей отчета, укажите, нужно ли учитывать файлы фоновых журналов, реплицированные файлы и папки, включать размер набора данных каждого члена, а затем щелкните на кнопке Next.
    6. Просмотрите выбранные параметры, и если все в порядке, щелкните на кнопке Create, чтобы сгенерировать и отобразить отчет. После этого отчет появится в окне используемого по умолчанию браузера.
    Перевод конечного объекта в автономный режим для обслуживания
    При необходимости перезагрузить какой-то конечный объект или просто перевести его на некоторое время в автономный режим для обслуживания, подключающиеся пользователи должны либо аккуратно перенаправляться на другую копию, либо вообще отклю- чаться от сервера DFS.
    Чтобы перевести целевую папку в автономный режим для обслуживания, потребуется выполнить следующие шаги.
    1. Откройте окно консоли DFS Management, найдите пространство имен и раскройте его, чтобы добраться до нужной папки, после чего выберите ее.
    2. При выбранной папке в панели древовидного представления, в панели задач выберите вкладку Folder Targets (Целевые папки) и выберите цель, которая должна быть переведена в автономный режим.
  • Щелкните на требуемом конечном объекте правой кнопкой мыши и выберите в кон- текстном меню, которое появится после этого, пункт Enable Folder Target (Включить целевую папку) или Disable Folder Target (Отключить целевую папку), как показано на рис. 28.27. Это приведет к изменению текущего состояния ссылки выбранного конечного объекта.
    4. Повторите предыдущие шаги для всех остальных корней или конечных объектов папки DFS на переводимом в автономный режим сервере.
    5. Подождите, пока не закроются все существующие подключения. Обычно после из- менения состояния ссылок конечных объектов отключение всех пользователей про- исходит сразу же после истечения интервала кэширования. Отсчет времени следует начинать с момента перевода ссылок в отключенное состояние. Один из способов удо- стовериться, что все пользователи отключились от цели, состоит в открытии консоли Share and Storage Management (Управление общим доступом и хранением) на целевом сервере и использовании ссылок Manage Sessions (Управление сеансами) и Manage Open Files (Управление открытыми файлами) в панели Actions (Действия), которые позволяют определить, имеются ли подключенные пользователи и системы.
  • После закрытия всех подключений на целевом сервере проведите все необходимые процедуры, а по завершении обслуживания и восстановления функциональности сервера снова включите все отключенные ранее конечные объекты с помощью консоли DFS Management.
    Администратору для контроля следует почаще заглядывать в журнал «Администрирование / Просмотр событий / Журналы Windows-Репликация DFS»

    Отключение репликации на длительный период


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

    Резервное копирование данных DFS


    Для резервного копирования данных DFS администраторам не нужно выполнять никаких специальных шагов, кроме резервного копирования фактических данных, которые хранятся внутри самих папок, и данных состояния системы (System State) на тех серверах, которые обслуживают или участвуют в пространстве имен DFS. Таким образом, к числу подлежащих резервному копированию элементов относятся следующие.
    • Данные конечных объектов папок DFS. Это реальные данные, к которым обращаются конечные пользователи. В случае использования настоящей топологии репликации с участием нескольких главных копий, для каждого конечного объекта папки DFS должно выполняться резервное копирование только одного конечного объекта.
    • Иерархия DFS. В случае автономных пространств имен DFS должно выполняться резервное копирование как состояния системы сервера корня DFS, так и состояния системы всех серверов, на которых содержатся конечные объекты DFS, а в случае доменных пространств имен DFS — состояний систем контроллеров доменов и всех остальных серверов, на которых находятся конечные объекты DFS. Вся информация об иерархии DFS и подключениях репликации DFRS хранится в Active Directory. А резервное копирование Active Directory осуществляется вместе с резервным копи- рованием состояния системы контроллера домена.
    Для резервного копирования только иерархии DFS с помощью утилиты DFSutil можно выполнить экспорт настроек. Ниже описаны соответствующие шаги.
    1. Войдите в систему WServer, на которой установлены службы DFS, от имени учетной записи с правами локального администратора сервера.
    2. Выберите в меню Пуск пункт Run (Выполнить), введите cmd и нажмите для открытия окна командной строки.
    3. В окне командной строки введите dfsutil domain companyabc.com и нажмите для получения списка всех пространств имен в домене companyabc. com. В рассматриваемом примере будет возвращено пространство имен Apps, располо- женное в Wcompanyabc. com\apps.
    4. Определив название пространства имен, введите
    dfsutil root export Wcompanyabc.com\apps c:\dfs-export-namespace-Apps.xml и нажмите для экспорта этого пространства имен.
    5. В окне командной строки введите c:\dfs-export-namespace-Apps.xml для про- смотра экспортированной информации.
    Этот процесс должен быть выполнен на всех пространствах имен сервера DFS и до- мена. Кроме того, полученный в результате файл может применяться для миграции про- странства имен DFS с одного набора серверов пространств имен на другой набор серверов, для чего понадобится удалить первоначальное пространство имен, отредактировать этот файл и воспользоваться командой dfsutil root import.

    Автономные файлы


    Мобильным юзерам может понадобиться доступ к общим папкам даже в случае отключения их компьютеров от внутренней сети организации, Автономные файлы обеспечивают эту возможность, разрешая клиентским компьютерам автоматически копировать копии файлов в общих папках, а также предоставляя прозрачный доступ к файлам при отключении пользователя от сети, при следующем подключении к сети компонент Автономные файлы синхронизирует все обновления и предлагает пользователю самому разрешить конфликты.
    Администраторы сервера могут конфигурировать автономные файлы в общей папке, а пользователи клиентских компьютеров могут настраивать автономные файлы при подключении к общей папке. Чтобы отконфигурировать кэширование автономных файлов в общей папке, выполните такие шаги. Роли\Файловые службы\Управление общими ресурсами и хранилищами. В панели сведений щелкните ПКМ общий ресурс, который хотите настроить, и примените команду Свойства. На вкладке Доступ (Sharing) щелкните кнопку Дополнительно. Перейдите на вкладку Кэширование (Caching). Выберите одну из следующих трех опций и дважды щелкните ОК.
    а) Все открываемые пользователем файлы и программы доступны и автономном режиме. Файлы, к которым пользователи подключаются в сети, автоматически копируются в течение ограниченного интервала времени. При включении этой опции пользователям необязательно знать принципы работы с автономными файлами.
    б) Все файлы или программы с общего ресурса недоступны в автономном режиме.
    Доступ к этим параметрам можно также получить в Проводнике Windows, щелкнув кнопку Дополнительный Доступ (Advanced Sharing) на вкладке Доступ (Sharing) диалогового окна свойств общей папки, а затем щелкнув кнопку Кэширование (Caching).
    Если выбрать опцию Только указанные пользователем файлы и программы доступны в автономном режиме, пользователи должны отконфигурировать подключенные диски для включения автономных файлов. В WClient настройка автономных файлов на подключенном диске выполняется следующим образом.
    В Проводнике Windows ПКМ сетевую папку или файл и примените команду Свойства. На вкладке Автономные файлы установите флажок Всегда доступны в автономном режиме и щелкните ОК.
    В WClient сетевой файл или папку можно щелкнуть правой кнопкой мыши и применить команду Всегда доступны в автономном режиме (Always Available Offline).
    Система Windows автоматически синхронизирует файл или папку.
    Пользователи могут позже вернуться на вкладку Автономные файлы (Offline Files) и скопировать последнюю версию файла.

    Управление принтерами


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

    Стенд


    Компьютер Dcsrvl, который будет служить контроллером домена Nwtraders.msft. Компьютер с именем Boston — член домена Nwtraders.msft. Один или несколько принтеров.

    Роль сервера служб печати


    В WServer предусмотрена роль Службы печати, обеспечивающая комплексное управление принтерами с помощью оснастки Управление печатью. Вы по-прежнему можете использовать Панель управления для установки, назначения общего доступа и управления принтерами, но оснастка Управление печатью обеспечивает более функциональный пользовательский интерфейс. В WServer можно назначить общий доступ к принтерам и без использования ролей сервера, но это сложнее. Есть также много инструментов командной строки для создания сценариев задач по управлению печатью и компьютерами с установленным ядром сервера WServer.
    На странице Выбор служб ролей установите соответствующие флажки напротив следующих служб ролей:
    1. Сервер печати устанавливает оснастку Управление печатью. Этого вполне достаточно, чтобы обеспечить возможности печати Windows и многих клиентов других ОС.
    2. Служба LDP позволяет клиентам выполнять печать с помощью протокола LDP (Line Printer Daemon), который используется клиентами UNIX.
    3. Печать через Интернет (Internet Printing ) позволяет клиентам выполнять печать с помощью протокола IPP (Internet Printing Protocol) и создает веб-сайт, на котором пользователи могут управлять заданиями печати посредством своих браузеров. Эта служба ролей требует установки веб-сервера IIS. Примите для IIS параметры по умолчанию.

    Установка принтеров


    Чтобы обеспечить физический доступ пользователей к принтерам и вместе с тем безопасность серверов печати, самые современные принтеры подключают к сети. Хотя пользователи могут печатать прямо на сетевых принтерах, сервер печати обеспечивает большие возможности управления.
    Установку принтера можно произвести с помощью Панели управления. Мастер установки сетевых принтеров, описанный в следующем подразделе, намного лучше выполняет поиск сетевых принтеров.
    Чтобы установить принтер с помощью оснастки Управление печатью в Диспетчере сервера ПКМ Роли\Службы печати\Управление печатью\Серверы печати\ и примените команду Добавить принтер. Ход установки зависит от модели принтера.

    Совместное использование принтеров


    Вы можете в оснастке Управление печатью щелкнуть принтер ПКМ и применить команду Управление доступом (Manage Sharing). Чтобы разрешить обнаружение принтера в AD, установите флажок Внести в AD (List In The Directory).
    Если клиентская операционная система использует тот же драйвер, что и сервер, клиент сможет автоматически загрузить этот драйвер при первом подключении к принтеру. Если клиенту нужен другой драйвер, на сервере потребуется инсталлировать дополнительный драйвер, чтобы клиент смог автоматически установить его. На вкладке Доступ (Sharing) щелкните кнопку Дополнительные драйверы (Additional Drivers), установите флажки напротив платформ, которые хотите поддерживать (рис. 12-6), а затем выберите драйвер принтера.
    По умолчанию печатать на принтере может любой пользователь.
    Чтобы добавить драйверы принтера с помощью оснастки Управление печатью в Диспетчере сервера ПКМ узел Роли\Службы печати\Управлеиие печатью\Серверы печати\\Драйверы и примените команду Добавить драйвер.
    Если пользователь подключится к общему принтеру, для которого не добавлен нужный драйвер, пользователю будет предложено установить этот драйвер. Чтобы разрешить пользователям устанавливать драйверы принтеров без привилегий администратора, можно отключить политику Конфигурация компьютера\Политики\Конфигурация Windows\Пapaмeтpы безопасности\Локальные политики\Параметры безопасности\Устройства: запретить пользователям установку драйверов принтера (\Policies\Windows Settings\Sccurity Settings\Local Policics\Security Options\Devices: Prevent Users From Installing Printer Drivers).

    Настройка пула печати


    Пул печати состоит из двух или нескольких идентичных принтеров, на которых можно печатать как на одном устройстве. Как правило, в таком случае принтеры нужно физически расположить рядом друг с другом. Хотя любое отдельное задание печати всегда может быть выполнено на одном принтере, наличие многих принтеров снижает время ожидания пользователей в очередях заданий печати, поскольку эти задания будут распределяться среди нескольких принтеров.
    Принтеры в пуле печати должны использовать один драйвер. Хотя принтеры необязательно должны быть идентичными, клиентские компьютеры установят лишь один драйвер для всех принтеров в пуле печати. Иногда отдельный драйвер принтера работает со многими моделями принтеров одного производителя, позволяя использовать разные модели в одном пуле печати.
    Чтобы создать пул печати, выполните следующие действия.
    1. Установите все принтеры, которые хотите включить в пул печати.
    2. В Диспетчере сервера выберите узел Службы нечати\Управление печатыо\Сервсры печмм\\Принтеры, В панели сведений ПКМ один из принтеров в пуле и примените команду Свойства.
    3. Перейдите на вкладку Порты и установите флажок Разрешить группировку принтеров в пул (Enable Printer Pooling).
  • Установите флажок напротив порта каждого принтера в пуле печати, как показано на рис. 12-9. Щелкните ОК.
    Вам нужно назначить общий доступ лишь к одному принтеру, для которого разрешена группировка в пул. Все задания печати дли этого общего принтера будут пересылаться первому доступному принтеру в пуле. Если назначить в пуле печати общий доступ к нескольким принтерам, пользователи смогут печатать на конкретном принтере и без помощи пула печати.

    Настройка приоритетов принтеров


    Если в очереди печати несколько документов, с помощью приоритетов принтеров можно вначале вывести на печать документы с высоким приоритетом, а уже потом - с более низким. Например, на предприятии эта возможность позволит, чтобы документы членов группы Руководство выводились на печать перед документами членов группы Служащие.
    Чтобы настроить приоритеты принтера:
  • Установите принтер, на котором будет использоваться много приоритетов, Затем вновь установите этот же принтер на том же порте. Вы должны получить по одному логическому принтеру для каждого требуемого уровня приоритета, даже если используете один физический принтер. Каждому логическому принтеру будет назначен отдельный уровень приоритета.
  • В Диспетчере сервера ПКМ один из логических принтеров и примените команду Свойства.
    3. Перейдите на вкладку Дополнительно и укажите уровень приоритета для логического принтера. Все задания печати, отправляемые на логический принтер с более высоким приоритетом, будут выполняться перед заданиями печати, отправляемыми на принтеры с низким приоритетом. Вы можете назначить уровень приоритета от 1 до 99.
    4. Повторите шаги 2 и 3 для каждого логического принтера.
    5. Подключите пользователей с высоким приоритетом к логическому принтеру с высоким приоритетом, а пользователей с приоритетом ниже к логическому принтеру с низким приоритетом. Настройте разрешения принтеров, чтобы разрешить доступ для конкретных групп пользователей.
    Хотя задания с высоким приоритетом в очереди печати всегда размещаются перед заданиями с низким приоритетом, выполнение уже запущенного задания прервать нельзя.

    Управление печатью через Интернет


    В результате установки службы ролей Печать через Интернет (Internet Printing) принтерами можно управлять с помощью браузера, открыв страницу http:///Рrinters . На этой веб-странице перечислены совместно используемые сервером принтеры и указано их текущее состояние.
    Щелкните принтер, чтобы просмотреть более подробные сведения, включая текущую очередь печати, а также приостановить, возобновить или отменить печать. После щелчка кнопки Подключение пользователю будет предложено установить принтер, если он еще не установлен. Для подключения к принтеру требуется разрешить запуск надстроек в обозревателе Internet Explorer. Подключение к принтеру с помощью браузера удобно для гостей, но чтобы настроить принтеры для клиентских компьютеров, следует использовать параметры групповой политики.
    Чтобы напрямую подключиться к принтеру с общим доступом печати через Интернет, укажите URL в формате http:///Printers//.printer .

    Генерирование уведомлений


    Для генерирования уведомлений электронной почты или автоматического запуска сценариев при соответствии принтера конкретным условиям можно использовать настраиваемые фильтры. Например, при отсутствии или застревании бумаги в принтере администратору печати можно отправлять уведомления по электронной почте.
    Сначала создайте настраиваемый фильтр, выполнив следующее.
    1. В Диспетчере сервера откройте и ПКМ узел Роли\Службы печати\Управление печатью\Настраиваемые фильтры и примените команду Добавить новый фильтр принтеров.
    2. На странице Определить фильтр принтеров отконфигурируйте Критерии фильтрации (Filter Criteria ) по отдельности в каждой строке, как описано далее.
    3. Поле. Определяет сопоставляемый критерий. Чаще всего в параметре Поле выбирают критерий Состояние очереди (Queue Status ), указывающий текущее состояние печати.
    4. Условие ( Condition ) Зависит от критерия, выбранного в Поле ( Field ), и может принимать значения Совпадает, Не совпадает, Начинается с, Содержит (is exactly, is not exactly, begins with, contains) и многие другие.
    5. Значение ( Value ) Этому критерию фильтрации должны соответствовать значения Поля (Field) и Условия (Condition) принтера.
    На рис. 12-12 показан критерий фильтрации для общих принтеров с застрявшей бумагой и местоположением Boston.
    6. На странице Настроить уведомления (необязательно) (Set Notifications (Optional)) выберите отправку уведомления по электронной почте, запуск сценария в случае соответствия принтера критерию, определенному на предыдущей странице, или обе эти опции.

    Развертывание принтеров с помощью групповой политики


    Чтобы развернуть общие принтеры для клиентов на предприятии, нужно использовать параметры групповой политики. Для развертывания принтера с помощью параметров групповой политики выполните следующее.
    1. В Диспетчере сервера выберите узел Роли\Службы печати\Уиравление печатью\Серверы печати\\Принтеры. В панели сведений щелкните принтер правой кнопкой мыши и примените команду Развернуть с помощью групповой политики (Deploy With Group Policy).
    2. В диалоговом окне Развертывание с помощью групповой политики (Deploy With Group Policy) щелкните кнопку Обзор, чтобы выбрать объект групповой политики (GPO), который хотите использовать.
    3. Чтобы развернуть принтер для всех пользователей, входящих на отдельный компьютер, установите флажок компьютеров, к которым применим данный объект групповой политики (The Computers That This GPO Applies To).
    Чтобы развернуть принтер для конкретных пользователей независимо от компьютера, на который они входят, установите флажок пользователей, к которым применим данный объект групповой политики (The Users That This GPO Applies To). Вы можете установить и оба флажка, чтобы развернуть принтер с помощью обоих узлов — Конфигурация компьютера и Конфигурация пользователя - в объекте групповой политики.
    4. Щелкните кнопку Добавить, чтобы добавить объект групповой политики в список (рис. 12-13).
    5. Повторите шаги 2 и 3, чтобы развернуть принтер в дополнительных объектах групповой политики.
    Развернутые принтеры можно просмотреть, открыв объект групповой политики Политики\Конфигурация Windows\Развернутые принтеры в папке Конфигурация компьютера или же Конфигурация пользователя.

    Миграция принтеров


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

    Экспорт принтеров


    Чтобы экспортировать очереди печати и параметры принтера в файл, выполните следующие действия.
    1. В Диспетчере сервера ПКМ узел Управление печатью (Print Management) и примените команду Миграция принтеров (Migrate Printers). Запустится мастер Миграция принтеров.
    2. На странице Начало работы с переносом принтеров ( Getting Started With Printer Migration ) щелкните опцию Экспортировать очереди и драйверы принтера в файл (Export Printer Queues And Printer Drivers To A File).
    Щелкните кнопку Далее (Next).
    3. На странице Выберите сервер печати (Select A Print Server) выберите сервер и щелкните Далее.
    4. На странице Просмотреть список экспортируемых элементов (Review The List Of Items To Be Exported) щелкните кнопку Далее (Next).
    5. На странице Выберите расположение файла (Select The File Location) введите имя файла и щелкните Далее (Next).
    Принтеры можно также экспортировать с помощью командной строки или из сценария, используя инструмент PrintBRM, который находится в папке %SystemRoot%\System32\spool\tools\. Чтобы экспортировать принтеры в файл,
    запустите утилиту PrintBRM с параметром -b, как в этом примере:
    printbrm -b -f printers.printerexport
    Чтобы получить подробные сведения об этой утилите, введите команду PrintBRM -?.

    Импорт принтеров


    Чтобы из файла импортировать очереди печати и параметры принтера, выполните следующие действия,
    1. В Диспетчере сервера (Server Manager) ПКМ узел Управление печатью и примените команду Миграция принтеров (Migrate Printers), Запустится мастер Миграция принтеров (Printer Migration).
    2. На странице Начало работы с переносом принтеров (Getting Started With Printer Migration) щелкните опцию Импортировать очереди и драйверы принтера из файла (Import Printer Queues And Printer Drivers From A File).
    Щелкните кнопку Далее (Next).
    3. На странице Выберите расположение файла (Select The File Location) введите имя файла и щелкните Next.
    4. На странице Просмотреть список импортируемых элементов (Review The List Of Items To Be Imported) щелкните кнопку Далее (Next).
    5. На странице Выберите сервер печати (Select A Print Server) пыберите сервер и щелкните Next.
    6. На странице Выберите параметры импорта (Select Import Options), представленной на рис. 12-14, щелкните раскрывающийся список Режим импорта (Import Mode) и укажите, сохранить или переписать существующие принтеры. Затем укажите, перечислить ли принтеры в Active Directory.
    Щелкните кнопку Далее (Next).
    На последней странице щелкните кнопку Открыть просмотр событий (Open Event Viewer), для того чтобы просмотреть все ошибки, возникшие при импорте (ошибки с источником PrintBRM). Затем щелкните кнопку Готово (Finish).
    8. Вы можете также дважды щелкнуть файл .PrinterExport, созданный во время экспорта принтеров, и следовать инструкциям.
    Чтобы импортировать принтеры с помощью командной строки или сценария, запустите утилиту PrintBRM с параметром -r, как в этом примере;
    printbrm -r -f printers.printerexport

    Наблюдение за принтерами


    С помощью оснастки Системный монитор можно наблюдать за использованием принтеров в реальном времени. Для объекта Очередь печати (Print Queue) удобней всего применять следующие счетчики:
    1. Ошибок заданий (Job Errors) и Ошибок "Отсутствует бумага" (Out Of Paper Errors) Подсчитывает общее число ошибок заданий и ошибок, связанных с отсутствием бумаги, с момента последней перезагрузки.
    2. Заданий ( Jobs ) и Заданий, обрабатываемых диспетчером очереди (Jobs Spooling ) Подсчитывает число текущих заданий в очереди печати.
    Наблюдая за этими счетчиками, можно определить загруженность отдельного принтера, чтобы заменить его более быстрым или добавить пул печати.
    3. Всего напечатано страниц ( Total Pages Printed ) и Всего заданий напечатано (Total Jobs Printed) Общее количестов страниц и заданий, напечатанных принтером.
    Если вы хотите просмотреть данные счетчиков для какого-то конкретного принтера, выберите этот принтер в области Экземпляры выбранного объекта (Instances Of Selected Object) диалогового окна Добавить счетчики (Add Counters).

    Развёртывание

    Активация

    Применение инфраструктуры активации Windows


    Лицензионный ключ — это ключ продукта, используемый для регистрации нескольких копий программного обеспечения. Обычно подобные ключи применяются в больших корпоративных сетях. Ключ нужно вводить во время установки. Установленные системы нужно активировать в течение 30 дней после установки. Как результат, процесс активации является неотъемлемой частью корпоративного развертывания.
    Новые параметры, процедуры и технологии, используемые для WСlient или WServer, известны как Volume Activation 2.0.
    Существует 3 типа активации продуктов для WClient и WServer: OEM, Retail и Volume.
    OEM-активация основана на BIOS . Это активация, которая происходит автоматически после установки операционной системы. Привязана к машине. Оторвать лицензию от машины можно путём крепления лицензии к Software Assurance.
    Retail-активацией называется активация ОС, купленной у розничного продавца. При такой активации используется код активации, который можно применить только к одному компьютеру. После ввода этот лицензионного кода вы можете активировать программное обеспечение по Интернету или по телефону.
    Volume-активация — более комплексный процесс. Выполняется она 3 методами с применением 2 видов ключей.
    1. Многоразовый активационный ключ (Multiple Activation Key, МАК):
    а) независимая МАК-активация;
    б) активация МАК-рrоху.
    2. Ключ службы управления (Key Management Service, KMS): KMS-активация.
    Чтобы получить volume-лицензионный ключ для продуктов Microsoft, перейдите по ссылке www.microsoft.com/licensing. Здесь же вы получите информацию о некоторых программах volume-лицензирования и контактные данные продавцов. Чтобы приобрести volume-лицензию для WClient и WServer, необходимо приобрести минимум 5 лицензий.
    Все покупатели могут приобретать и использовать МАК, но KMS-ключ предназначен только для организаций, активирующих не менее 25 компьютеров (для WClient) или 5 физических компьютеров (для WServer).
    Всё начинается с того, что после оплаты тебе выдают бумажку с реквизитами лицензии. Эти реквизиты нужно забить на сайте www.microsoft.com/licensing/servicecenter (VLSC) предварительно зарегистрировавшись на нём (Windows Live ID).
    Volume можно переносить с машины на машину с перерывом в 90 дней.
    A TechNet (technet.microsoft.com/subscriptions/ms772427.aspx) subscription is intended to give IT pros easy access to Microsoft software for evaluation purposes only.

    Применение МАК-активации


    МАК-активация обычно используется в средах, где количество компьютеров составляет менее 25. Ключ продукта используется для активации указанного числа установок системы Windows. Его не нужно вводить во время установки, так как во всех выпусках систем WClient и WServer вам предоставляется 30 дней, для того чтобы ввести ключ продукта и активировать систему. Активация Windows будет действительной до тех пор, пока в аппаратное обеспечение компьютера не будут внесены существенные изменения.
    Есть 2 способа активации компьютеров с помощью МАК.
    1. Независимая МАК-активация. Первый этап — ввод МАК в каждый компьютер. После установки вы можете ввести ключ клиента локально с помощью мастера изменения ключа продукта (Change Product Key Wizard) или удаленно — для этого нужно подключиться к компьютеру с помощью утилиты Volume Activation Management Tool (VAMT). Утилиту VAMT можно загрузить из центра загрузок Microsoft (www.microsoft.com/download).
    После завершения ввода МАК вы можете активировать систему на каждом компьютере с помощью утилиты VAMT или же по телефону.
    Независимая активация — это метод, используемый для активации клиентов, которые подключены к сети Интернет. По телефону активируют не более 3 компьютеров, которые к Интернету не подключены.
    Чтобы активировать WServer с МАК- или Retail-ключом, воспользуйтесь командой Slmgr и выполните:
    1. Если вы не ввели ключ во время установки Windows, выполните следующую команду из командной строки:
    slmgr -ipk product key
    2. Выполните следующую команду для активации:
    slmgr -ato
    Для удаленной активации вы можете воспользоваться командой slmgr. Чтобы получить дополнительную информацию по данной теме, выполните в командной строке команду slmgr.
    2. Активация МАК- proxy . Активация клиентов но телефону — процедура очень кропотливая и отнимающая много времени. Если в вашей сети имеется от 4 до 24 компьютеров и все они изолированы от сети Интернет, то активировать их по телефону будет, мягко говоря, глупо. К счастью, существует простой метод активации групп компьютеров, не подключенных к сети Интернет. При выполнении активации МАК-proxy на компьютере, который может подключиться к изолированным компьютерам, вы для сбора установочных номеров (Installation ID IID этих компьютеров) и их последующего сохранения в XML-файл будете использовать утилиту VAMT.
    Затем на компьютере, который подключен к Интернету, вы, опять воспользовавшись утилитой VAMT, подключитесь к веб-узлу Microsoft для получения подтвержденных номеров (Confirmation ID CID), которые ассоциированы с этими IID. При необходимости вы можете перемещать XML-файл от одного компьютера к другому вручную. CID сохраняются в тот же XML-файл, а после этого вы опять запускаете утилиту VAMT для подключения к изолированным компьютерам и используете обновленный XML-файл для их активации.
    Когда вам необходимо активировать небольшое количество компьютеров, то МАК-лицензирование — это именно то, что нужно. Такое лицензирование не требует никакой инфраструктурной установки. Для упрощения процедуры можно воспользоваться утилитой VAMT, но у вас также есть возможность ввести ключ продукта и активировать компьютеры локально — подобно тому, как это делается при использовании retail-ключей.
    Однако если нужно активировать большое число компьютеров клиентов, то администратор вряд ли согласится производить лицензирование этим методом. Вводить 250-2000 ключей продукта, запоминать, сколько раз тот или иной ключ был использован, и помнить, какие именно компьютеры уже активированы, — непростая задача.
    Для столь больших сетей приемлемым решением будет такой способ акти- вации, который не потребует ввода каких-либо ключей продукта на локальном компьютере и позволит активировать компьютеры клиентов без вмешательства пользователей. Такой способ существует, и называется он KMS-лицензированием.

    Применение KMS-активации


    KMS-активация разрешает пользователям в больших сетях активировать свои компьютеры автоматически, без подключения к серверу Microsoft. В KMS-инфраструктуре существует только один ключ на всю сеть — ключ KMS, и он устанавливается на один компьютер, который называется KMS-хоcтом. Из всех компьютеров сети в Microsoft активируется только KMS-хост, и эта процедура выполняется только один раз.
    Компьютеры, па которых установлены volume-версии WClient и Server 2008 (KMS-клиенты), подключаясь к KMS-хосту, пытаются активироваться автоматически. Клиенты, которые не прошли процедуру активации, будут пробовать подключиться к KMS-хосту каждые 2 часа. KMS-клиенты проходят повторную активацию каждые 180 дней (или каждые 210 дней, если берется отсрочка) и это единственное отличие данного метода активации от других. Активированные KMS-клиенты будут пытаться подключиться к KMS-хосту каждые 7 дней и, если подключение пройдет успешно, обновлять 180-дневный термин активации. Если клиенты не могут подключиться к KMS-серверу по прошествии 180 дней, им предоставляется дополнительная 30-дневная отсрочка для завершения активации или выполнения нереактивации. Компьютеры клиентов, которые не прошли активацию в указанный срок, перейдут в режим неполной функциональности (Reduced Functionality Mode, RFM).
    Чтобы KMS-активация наверняка сработала, к KMS-хосту необходимо подключить минимальное количество физических (не виртуальных) компьютеров. Такое минимальное число называют порогом (Threshold). Этот ненастраиваемый параметр помогает удостовериться в том, что служба активации используется только в корпоративном окружении и работает в защищенной среде.
    KMS-xocт считает запросы на активацию, и отвечает па каждый верный запрос количеством систем, которые сделали запрос KMS-хосту за последние 30 дней. Если это значение равно или не превышает установленный порог KMS- активации, то KMS-клиенты будут активированы.
    Пороги для систем Windows Server 2008 и WClient различны и рассчитываются по определенной схеме.
    1. Для успешной активации системы Windows Server 2008 нужно как минимум 5 физических KMS-клиентов, которые запросят активацию у KMS-хоста. Запросы клиентов могут быть как от системы WServer, так и от WClient.
    2. Чтобы успешно активировать систему Windows 7, нужно как минимум 25 запросов физических KMS-клиентов к KMS-хосту. Запросы клиентов могут быть как от системы WServer, так и от Windows 7. Заметьте, что виртуальные машины не влияют на количество запросов, но после того как порог будет превышен, эти виртуальные машины также можно будет активировать.

    Обнаружение KMS-хоста


    Либо методом автообнаружения (Autodiscovery), при котором KMS-клиенты для автоматического определения KMS-хоста используют записи DNS, либо методом прямого подключения (Direct Connection), когда системный администратор указывает адрес KMS-порта и порт подключения.
    1. Автообнаружение (Autodiscovery) По умолчанию KMS-клиенты обнаруживают KMS-хост с помощью запроса к DNS-серверу на наличие записи SRV с именем _vlmcs._TCP, в ко- тором указан адрес KMS-хоста.
    KMS-хост будет автоматически пытаться создать запись SRV с номошью динамического DNS. Чтобы функция автоматического обнаружения KMS работала корректно, DNS-сервер должен поддерживать регистрацию дина- мического DNS и записи ресурсов SRV.
    Полное имя записи должны быть следующим: _vlmcs._TCP.DNSDomainName, где DNSDomainName — это имя локального DNS-домена. Время жизни (TTL) для таких записей составляет 60 мин. Адрес KMS-хоста и порт (1688/ТСР) также должны быть включены в каждую запись.
    2. Прямое подключение (Direct Connection) Используя сценарий Windows Software Licensing Management Tool Slmgr.vbs, который находится в папке %SystemRoot%\Systcm32, вы сможете указать KMS-хост на компьютере клиента и пропустить процесс автоопределения. Чтобы настроить такой тип прямого подключения, выполните следующую команду на компьютере KMS клиента (KMS-host — это DNS-имя или 1Р-адрес KMS-хоста): сsсript %systemroot%\system32\slmgr.vbs - skms KMS-host

    Установка и настройка KMS-хоста


    Все утилиты, необходимые для работы с KMS-хостом, уже включены в системы WClient и Windows Server 2008. Вам нужно лишь использовать сценарий Slmgr.vbs для установки и последующей активации KMS-ключа. После выпол- нения этих процедур KMS-хост может начать обслуживание получаемых от KMS-клиентов запросов на активацию.
    Вы должны настроить KMS-хост, выполнив указанные далее шаги на ком- пьютере с системой WClient или Windows Server 2008.
    1. Установите корпоративный лицензионный ключ, выполнив в командной строке команду (Key — это корпоративный лицензионный ключ):
    Cscript %SystemRoot%\system32\slmgr.nbs -ipk Key
    2. Активируйте KMS-хост по сети Интернет, выполнив следующую команду: Cscript %systemroot%\system32\slmgr.vbs -ato
    3. Для того чтобы активировать KMS по телефону, запустите мастер активации Windows (Windows Activation Wizard) с помощью команды
    Slui.exe
    Щелкните сначала Активировать Windows по сети (Activate Windows Online Now), а затем — Использовать для активации телефон (Use The Automated Phone System To Activate).
    4. Удостоверьтесь, что KMS-порт (по умолчанию это 1688/ТСР) разрешен во всех брандмауэрах между KMS-хостом и компьютерами KMS-клиентов.
    Не настраивайте незащищенный доступ к KMS-хосту по неконтролируемой сети, например через Интернет. Если вы это сделаете, то компьютеры других пользователей (не из вашей сети) могут быть активированы через вашу орга- низацию.
    5. Измените настройки с учетом потребностей окружения.
    Используя сценарий Slmgr.vbs и изменяя регистр KMS-хоста, нетрудно из- менить настройки KMS. Например, вы можете настроить KMS на регистра- цию SRV-записей ресурсов на нескольких DNS-доменах, на неполную ре- гистрацию на DNS, использование нестандартных портов и даже на контроль временных интервалов обновления на компьютерах клиентов.

    Преимущества и недостатки KMS-лицензий


    KMS-лицензирование предпочтительнее МАК-лицензирования, поскольку не требует вмешательства со стороны пользователей. KMS-хост автоматически регистрирует свои адреса на DNS-сервере, после чего KMS-клиенты автомати- чески используют DNS для обнаружения KMS-хоста.
    Недостатком KMS-лицензирования являются большие инфраструктурные требования. Во-первых, порог KMS-клиентов равен 25 KMS-клиентам системы WClient и 5 клиентам системы Windows Server 2008. Во-вторых, все KMS-клиенты должны иметь возможность подключаться к KMS-хосту как
    минимум один раз в 180 дней. МАК-лицензирования таких требований не выдвигает; МАК-клиент после активации остается активированным навсегда (по крайней мере до того, как в аппаратное обеспечение компьютера не будут вне- сены существенные изменения).
    Эти технологии рассчитаны на применение в больших корпоративных сетях и обычно используются параллельно. Этот принцип проиллюстрирован на рис. 1-37 на примере сети с четырьмя площадками.
    Как видите, на рисунке изображена частная сеть с четырьмя площадками. На площадке главного офиса 500 клиентов требуют использования KMS-ли- цензирования, поэтому выполняется KMS-активация. (Два сервера, показанных на рисунке, могут быть использованы для поддержки активации двух раздель- ных DNS-доменов и для распределения нагрузки запросов между ними). На площадке А имеется 25 или более клиентов, и этого вполне достаточно для использования локального KMS-хоста. На площадке Б для использования ло- кального KMS-хоста клиентов не хватает, поэтому KMS-лицензирование на ней не применяется. К тому же клиенты с данной площадки не могут подключиться к KMS-хосту, который находится в частной сети. В данном случае KMS-лицен- зирование применить невозможно, а вот МАК-лицензирование — вполне при- емлемый вариант. На площадке В для использования локального KMS-xocra не хватает клиентов, но клиенты могут подключиться к KMS-хосту, который расположен на площадке главного офиса. Следовательно, KMS-лицензирование будет лучшим выбором.

    Автоматизация установки


    Для выполнения автоматической (в терминах Microsoft - unattended) установки или апгрейда WClient необходимо подготовить специальный файл ответов, из которого программа установки будет черпать ответы на свои многочисленные вопросы. Файл ответов обычно называется Unattend.txt, но при сетевой инсталляции вы можете назвать его как вам угодно. При установке с CD вы должны назвать файл Winnt.sif и разместить его на дискете, где программа установки его найдет. Подготовка файла ответов не означает, что он будет использован программой установки. Программу установки нужно с помощь ключей соответствующим образом сконфигурировать. Программа установки может быть запущена в 5 режимах, отличающихся степенью участия пользователя в процессе установки. В полностью автоматическом режиме программа установки предполагает, что ответы на все вопросы, включены в файл ответов. В остальных режимах допускается не все ответы помещать в файл ответов. Стоит отметить, что если вы переустанавливаете Windows XP, то программа установки проигнорирует файл ответов и возьмет все данные у системы, которую вы переустанавливаете.

    Файл ответов


    Исчерпывающая информация может быть получена из файла справки deploy.chm, расположенного в том же каталоге, что и setupmgr.exe. Наиболее интересные возможности, появившиеся в Windows XP:
    ;; все параметры добавляются в соответствующие секции файла ответов, предназначенного для Windows 2000
    [Unattended]
    ; секция означает, что будет выполняться автоматическая установка
    AutoActivate =No
    ; не выполнять автоактивацию Windows XP
    DisableDynamicUpdates=Yes
    ; не подключаться к сайту Microsoft для получения обновлений Windows XP
    WaitForReboot=No
    ;; не ожидать 15 секунд после завершения GUI-mode установки, а перезагрузится немедленно, что, несколько, ускорит установку
    [ Shell ]
    ;: секция управляет внешним видом оболочки. Это новая секция, которой не было в Windows 2000
    DefaultStartPanelOff=Yes
    ; использовать стиль Win2k для меню Start вместо стиля WinXP
    DefaultThemesOff=Yes
    ; использовать стиль Win2k вместо стиля WinXP
    [SystemRestore]
    ;; секция определяет работу с контрольными точками. Это новая секция, которой не было в Windows 2000
    CheckpointCalendarFrequency=1
    ; частота в днях создания контрольных точек
    MaximumDataStorePercentOfDisk=10
    ; процент дискового пространства отведенный для хранения контрольных точек

    Параметры файла ответов


    Все секции логически можно сгруппировать следующим образом (в каждой секции указаны параметры, появившиеся в Windows XP, по сравнению с Windows 2000):
    Группа
    Секция в Unattend.txt
    Параметры секции
    Назначение
    Setup
    [Unattended]
    ActivateProxy
    прокси, используемый при автоактивации
    AutoActivate
    автоактивация вашей копии WClient
    CrashDumpSetting
    сохранять или нет системную информацию при крахе системы для последующей отладки
    DisableDynamicUpdates
    подключаться или нет к сайту Microsoft для получения обновлений
    FactoryMode
    не удалять Windows Welcome или Mini-Setup из папки %systemdrive%\Sysprep при последующей загрузке компьютера.
    ForceHALDetection
    обновлять или нет HAL
    Hibernation
    добавить или нет Hibernate к Shutdown меню и создать файл Hiberfil.sys
    UnattendSwitch
    пропустить или нет  Windows Welcome при установке с CD
    WaitForReboot
    будет ли компьютер ожидать 15 секунд после завершения GUI-mode установки  или перезагрузится немедленно
    [GuiUnattended]
    EncryptedAdminPassword
    шифруем пароль администратора в файле ответов
    ОС
    [PCHealth]
    Display
    конфигурирование отчетов об ошибках, удаленной помощи, как от Microsoft, так и от OEM партнеров.
    ER_Display_UI
    ER_Enable_Applications
    ER_Enable_Kernel_Errors
    ER_Enable_Reporting
    ER_Enable_Windows_Components
    ER_Exclude_EXE(n)
    ER_Include_EXE(n)
    ER_Include_MSApps
    ER_Report_Path
    Headlines
    RA_AllowFullControl
    RA_AllowToGetHelp
    RA_AllowUnsolicited
    RA_MaxTicketExpiry
    [RegionalSettings]
    InputLocale_DefaultUser
    тоже, что и InputLocale, но для DefaultUser
    UserLocale_DefaultUser
    тоже, что и UserLocale,  но для DefaultUser
    [Shell]
    CustomDefaultThemeFile
    путь к файлу, хранящему стиль WinXP, если не указать, то будет стиль по умолчанию.
    DefaultStartPanelOff
    использовать ли стиль Win2k для меню Start вместо стиля WinXP
    DefaultThemesOff
    использовать ли стиль Win2k вместо стиля WinXP
    [SystemRestore]
    CheckpointCalendarFrequency
    частота в днях создания контрольных точек.
    CheckpointSessionFrequency
    продолжительность работы WinXP в часах, после которой создается контрольная точка
    MaximumDataStorePercentOfDisk
    процент дискового пространства допустимый для хранения контрольных точек.
    RestorePointLife
    продолжительность в днях хранения контрольных точек.
    Сеть
    [Homenet]
    Bridge
    Секция и ее параметры предназначены для конфигурирования установок домашней сети для сетевых адаптеров, Internet Connection Sharing (ICS) и Internet Connection Firewall (ICF)
    EnableICS
    ExternalAdapter
    InternalAdapter
    InternetConnectionFirewall
    InternalIsBridge
    ShowTrayIcon
    [Identification]
    EncryptedDomainAdminPassword
    шифруем пароль администратора в файле ответов
    [MS_WLBS parameters]
    IGMPSupport
    оптимизация загрузки сети для серверных Win
    McastIPaddress
    [MS_TCPIP parameters]
    DisableDynamicUpdate
    дополнительные параметры для тонкой настройки протокола
    EnableAdapterDomainNameRegistration
    SyncDomainWithMembership
    Сервис
    [DCInstall]
    AllowAnonymousAccess
    настройка контроллера домена для серверных Win
    ConfirmGc
    CriticalReplicationOnly
    NewDomain
    ReplicationSourcePath
    ReplicationSourceDC
    SafeModeAdminPassword
    Syskey
    [Fax]
    ArchiveIncoming
    тонкая настройка факса
    ArchiveIncomingFolderName
    ArchiveOutgoingFolderName
    FaxUserName
    FaxUserPassword
    ReceiveFaxes
    RouteToEmailRecipient
    RouteToFolder
    SkipConfigWizardDeviceSettings
    SendFaxes
    SmtpNotificationsEnabled
    SmtpSenderAddress
    SmtpServerAddress
    SmtpServerPort
    SmtpServerAuthenticationMechanism
    [RemoteInstall]
    UseWholeDisk
    при удаленной установке разрешить расширять радел установки до конца диска или нет
    [TerminalServices]
    AllowConnections
    настройка TerminalServices
    LicensingMode
    Прочее
    [Components]
    fax
    устанавливаемые компоненты
    fp_extensions
    fp_vdir_deploy
    hearts
    IEAccess
    iis_www_vdir_printers
    iis_www_vdir_terminalservices
    msmq_ADIntegrated
    msmq_Core
    msmq_HTTPSupport
    msmq_LocalStorage
    msmq_MQDSService
    msmq_RoutingSupport
    msmq_TriggersService
    msnexplr
    spider
    TerminalServer
    TSWebClient
    wms
    wms_admin_asp
    wms_admin_mmc
    wms_server
    zonegames
    [CertSrv_Server]
    CAType
    дополнительные параметры для тонкой настройки Certificate Services для серверных Win
    DBDir
    Interactive
    LogDir
    Years
    Months
    Weeks
    Days

    Терминалы


    Службы терминалов работают по протоколу Remote Desktop Protocol (RDP).
    Существует 2 режима: RD Service (Remote Desktop и роль RD Server (Службы терминалов)) и RD Services Session.
    Remote Desktop - компонент служб терминалов (на серверах часто именуется как RDA (Remote Desktop for Administration)). Отличия между компонентами RD и RDS заключаются в том, что Службы терминалов предоставляют больше возможностей для расширяемости, а также содержат много дополнительных важных компонентов. Например, на компьютере с включенным компонентом RD лишь 2 пользователя (администратора) могут одновременно подключиться к активному сеансу рабочего стола (в том числе все локальные пользователи активных консольных сеансов). Т.е. обычного пользователя без RDS подключить не удастся. Таких ограничений не существует на сервере с установленными и отконфигурированными Службами терминалов.
    Разница между RDA и компонентом RD на клиентских системах состоит в том, что RDA включает 2 активных сеанса рабочего стола на сервере: либо 2 удаленных сеанса, либо 1 удаленный и 1 консольный сеанс. Клиентские системы не позволяют одновременно запускать два сеанса рабочего стола. Пользователь может подключиться лишь к одному рабочему столу, причем в момент подключения удаленного пользователя должен быть выполнен выход локального пользователя из системы.
    Терминальные службы Terminal Services были переименованы в Remote Desktop Services. Далее перечислены роли терминальных служб и связанные с ними компоненты, которые были переименованы. Вместо слова Terminal теперь используется Remote Desktop (RD) кроме следующих сочетаний:
    • Terminal Server - RD Session Host. Эта служба роли используется для размещения приложений Windows или полного рабочего стола Windows для пользователей, которые подключаются к RD Session Host, используя либо RDC, либо приложение RemoteApp.
    • Terminal Services Session Broker - RD Connection Broker
    • Terminal Services Configuration - RD Session Host Configuration

    Поддерживаются вложенные сессии.
    Для не-Windows RDC-клиентов от Microsoft нет.

    Проверка подлинности


    RDC поддерживает новый метод взаимной проверки подлинности пользователя, клиентского компьютера и сервера — Network Level Authentication (NLA). Проверка подлинности клиента теперь осуществляется до начала сеанса Terminal Services, в частности, до появления окна (удалённого) для ввода учетных данных пользователя.
    Чтобы настроить NLA, запустите утилиту system из Панели управления, щелкните Remote Settings и установите третий переключатель.
    Другое улучшение в системе безопасности RDP связано с проверкой подлинности сервера; клиенты теперь могут при помощи Transport Layer Security (TLS) убедиться, что они подключаются именно к своему серверу терминалов, а не подделке. Чтобы использовать на клиенте Server Authentication, запустите RDC и на вкладке Подключение выберите в раскрывающемся списке вариант Do not Connect if Authentication Fails. Проверку подлинности сервера можно также настроить при помощи оснастки Terminal Services Configuration.
    Службы терминалов позволяют пользователям с доменными учетными записями зарегистрироваться один раз, а затем получить доступ к серверу терминалов без необходимости вновь вводить учетные данные. Эта возможность называется единым входом (single sign-on, SSO). Она работает как с учетными записями, защищенными паролем, так и со смарт-картами. Пользователь волен использовать SSO как при запуске удаленного рабочего стола, так и при запуске отдельных приложений RemoteApp. Паролей много, и каждый нужно запомнить. Смарт-карта гораздо лучше, потому что для нее достаточно запомнить только PIN-код, но и смарт-карт у меня тоже несколько, а значит и PIN-кодов нужно запомить несколько.
    Чтобы реализовать SSO в службах терминалов, вам понадобятся WClient на клиентском компьютере и WServer на сервере терминалов. Включение SSO — двухэтапный процесс, требующий настройки проверки подлинности на сервере терминалов и настройки клиентов, чтобы разрешить использовать для регистрации на серверах терминалов учетные данные по умолчанию.
    Чтобы включить SSO на сервере терминалов, откройте оснастку Terminal Services Configuration, дважды щелкните подключение RDP, которое хотите настроить, перейдите на вкладку General и убедитесь, что для Security Layer задан вариант Согласование или SSL (TLS 1.0). Настроить SSO на клиенте можно при помощи групповой политики, включив параметр Computer Configuration\Administrative Templates\System\ Credentials Delegating\Allow Delegating Default Credentials и добавив ваши серверы терминалов в список серверов для этой политики.
    Чтобы настроить единый вход с клиента на сервер TS Gateway, включите параметр политики User Configuration\Administrative Templates\Windows Components\Terminal Services\TS Gateway\Set TS Gateway Server Authentication Method и задайте вариант Use locally Logged-On Credentials. Также установите флажок Allow Users to Change this Setting . Потребность в этом флажке возникла из-за того, что поддержка параметров групповой политики осуществляется на сервере TS Gateway несколько иначе, чем в других компонентах Windows. Как правило, у конечных пользователей нет права на изменение параметров групповой политики. Но когда включена групповая политика для TS Gateway и установлен этот флажок, конечный пользователь может выбрать способ проверки подлинности на сервере TS Gateway, например, задать вход с другим именем пользователя. Иными словами, в этом случае администратор лишь предлагает использовать этот параметр политики, но не навязывает его.

    Отображение данных


    Сеансы Terminal Services теперь поддерживают максимальное разрешение 4096 х 2048. Кроме того, теперь поддерживается не только формат 4:3, но и другие форматы, в том числе, заданные пользователем, например, 16:9 или 16:10. Задать формат можно в интерфейсе RDC, непосредственно в файле .rdp, или запустив RDC из командной строки, то есть, введя команду mstsc /w:ширина /h:высота.
    Есть поддержка составных мониторов. Учтите, что у всех мониторов должно быть одно и то же разрешение, а суммарное разрешение не должно превышать 4096 х 2048. Кроме того, мониторы с помощью параметра / span можно составлять только по горизонтали, но не по вертикали.
    Лично я разницы между 24-разрядными и 32-разрядными цветами не ощущаю, но вполне допускаю, что она будет очевидна для людей, работающих в Photoshop. Чтобы работать с 32-разрядными цветами, вы должны задать их использование как на клиенте (на вкладке Display окна свойств RDC), так и на сервере терминалов, работающем под управлением WServer. Задать применение 32-разрядных цветов можно со стороны сервера, открыв оснастку Terminal Services Configuration щелкнув дважды подключение RDP, которое вы хотите настроить (например, подключениe по умолчанию RDP-Tcp). Вариант с 32-разрядными цветами задан тсперь по умолчанию, поскольку при использовании приложений с высокими требованиями к цветности, наподобие IЕ и PowerPoint, новый механизм сжатия RDP, как правило, при работе с 32-разрядными цветами передает по сети меньше данных, чем при работе с 24-разрядными цветами. Вообще, если вам нужны хорошие краски, сначала пробуйте 15-, 16- и 32-разрядные цвета и лишь потом 24-разрядные цвета.
    В сеансах служб терминалов RDC поддерживается ClearType (сглаживание шрифтов), благодаря чему экранный текст стало значительно легче читать. На сервере нужно просто поставить сглаживание на рабочем столе. При включенном сглаживании шрифтов нагрузка на сеть во время редактирования или прокрутки текста возрастает в 4-10 раз.
    Поддерживает TCP и UDP. Технология RemoteFX позволяет виртуализировать видеоадаптер сервера и при удаленном RDP-подключении к виртуальным машинам использовать полноценные графические эффекты, включая DirectX. RemoteFX не требует массивов GPU. Хранилище образов VDI оптимизировано. Теперь администратор, используя один шаблон как основу, может создавать индивидуальные сессии для каждого пользователя. Чтобы система не обращалась каждый раз к серверу, используется локальный кеш, образы могут храниться на локальном диске или сетевых ресурсах.

    Приоритет отображаемых данных


    Данные клавиатуры, мыши и дисплея обладают более высоким приоритетом, чем остальной трафик. По умолчанию в WClient и WServer под отображаемые и вводимые данные отводится 70% ресурсов, а остальному трафику отводятся оставшиеся 30. Это распределение можно изменить, отредактировав следующие параметры DWORD реестра сервера терминалов из раздела HKLM\SYSTEM\CurrentControlSet\Services\TermDD:
    • Задав для параметра FlowControlDisable значение 1, вы отключите приоритетность отображаемых данных. Все запросы будут обрабатываться по принципу «первым вошел, первым вышел».
    • Параметр FlowControlDisplayBandwidth задает относительный приоритет отображаемых данных. Значение по умолчанию равно 70, максимально допустимое значение 255.
    • Параметр FlowControlCbannelBandwidth задает относительный приоритет остальных данных. Значение гю умолчанию равно 30, максимально допустимое значение — 255.
    • Присвоив параметру FlowControlChargePostCompression значение 0, вы зададите распределение полосы пропускания на основе объема трафика до сжатия. Значение 1 задает распределение полосы пропускания на основе объема трафика после сжатия. Значение по умолчанию 0.

    Вы, вероятно, будете настраивать параметры FlowControlDisplayBandwidth и FlowControlCbannelBandwidth Помните, что приоритетность отображаемых данных определяется отношением величин двух этих параметров, а не их абсолютными значениями.
    Со стороны клиента есть настройка частоты отправки сигналов мыши. Она стоит на значении 100 мс. Обработка отображения передвижения мыши не успевает за мышью! Зайдите в реестр HKEY_CURENT_USER\Software\Microsoft\Terminal Server Client и создайте параметр Min Send Interval типа DWORD в значение 10.
    Desktop Experience позволяет пользоваться темами рабочего стола, управлять фотографиями, работать с Windows Media Player и другими элементами рабочего стола компьютеров с Windows.
    Чтобы включить функции функции рабочего стола на сервере терминалов, зарегистрируйтесь на нем как администратор, выберите Server Manager, щелкните правой кнопкой узел Features и выберите в контекном меню команду Add Feature. В окне мастера Add Feature Wizard установите флаг Desktop Experience и завершите работу мастера. Затем вам нужно будет запустить сервере службу Themes и настроить тему, которую должны применять пользователи в своих сеансах. На стороне клиента делать ничего не надо, поскольку поддержка возможностей рабочего стола встроена в RDC.
    Функция Композиция рабочего стола позволяет удаленно пользоваться интерфейсом Windows Aero с прозрачными окнами, значками окон на панели задач, эффектами Flip 3D. Клиентские компьютеры должны работать под управлением Windows 7. Функция Desktop Composition поддерживается в двух случаях:
    1. сеанс удаленного рабочего стола с Windows Server при работе служб терминалов в однопользовательском режиме;
    2. сеанс удаленного рабочего стола с компьютером WClient.
    Чтобы задействовать функцию Desktop Composition, задайте на сервере использование оформления рабочего стола и выберите тему WClient. На клиенте откройте окно свойств RDP, перейдите на вкладку Experience и установите флажок Desktop Соmposition.

    Перенаправление устройств Plug and Play


    RDC поддерживает перенаправление конкретных устройств PnP за время сеансов Terminal Services. Оно работает как с полномасштабными сеансами удаленного рабочего стола Terminal Services, так и с TS Remote Арр. Когда вы запускаете сеанс Terminal Services, перенаправляемое PnP-устройство включается в него автоматически, так что вы увидите на экране привычные уведомления РnР и окна AutoPlay. Область доступности перенаправляемого устройства ограничена конкретным удалённым сеансом. Из другого сеанса (удаленного или консольного) оно будет недоступно. Чтобы включить перенаправление PnP-устройств на клиенте, откройте окно свойств RDP, идите на вкладку Local Resources, щелкните More и установите нужные флажки.
    Чтобы включить перенаправление PnP-устройств на сервере, откройте оснастку Terminal Services Configuration, щелкните дважды подключение RDP, которое хотите настроить, перейдите на вкладку Client Settings.
    В каскадных подключениях к серверу терминалов перенаправление PnP-устройств не работает.
    Поддержка перенаправления некоторых устройств Plug and Play по подключению удаленного рабочего стола. Хотя пока в комплект ОС включена только поддержка портативных устройств Windows и точка службы для устройств .NET 1.11, среда РnP Device Redirection Framework достаточно стандартна, чтобы поддерживать больший диапазон оборудования.
    Суть работы перенаправления устройств РnР состоит в перенаправлений пакетов запросов ввода-вывода (I/O request packet, IRР). У этого подхода несколько преимуществ. Во-первых, серверу нужен только стандартный драйвер перенаправляемoгo устройства, а не отдельные драйверы для всех устройств. Во-вторых, сервер защищен от потенциальных проблем с некорректно работающими драйверами от сторонних производителей. На клиенте перенаправление IRP позволяет локальным приложениям продолжить использование перенаправляемого, устройства. Одно и то же устройство можно перенаправлять по нескольким одновременным удаленным сеансам. Когда вы начинаете новый сеанс при включенном перенаправлении устройств, сервер терминалов для каждого перенаправляемого устройства создает на сервеpe прокси-узел. Затем Windows запускает программу WUDFhost.exe, которая загружает библиотеку usbdr.dll, играющую роль драйвера для каждого перенаправляемого устройства. Один экземпляр WUDFhost.exe способен поддерживать несколько устройств, что положительным образом сказывается на масштабируемости сервера терминалов. Когда приложение на стороне сервера вызывает NtCreateFile на перенаправляемом устройстве, usbdr.dll передает этот вызов по подключению RDP, на клиенте Remote Desktop Connection вызывает NtCreateFlle на реальном устройстве и возвращает серверу результат. Дополнительные операции ввода-вывода обрабатываются сходным образом.
    В комплект включен стандартный драйвер перенаправляемого устройства, но устройствам некоторых типов требуется дополнительная обработка. Например, цифровой фотоаппарат необходимо идентифицировать именно как фотоаппат, чтобы Windows Shell обеспечила соответствующий пользовательский интерфейс. Дополнительная информация необходима и для портативных медиаплееров в, чтобы Windows Media Player распознал их и мог с ними синхронизироваться.
    Если перенаправляемое устройство является точкой службы для устройства .NET, предприняты дополнительные шаги, чтобы включить его с Microsoft Point of Service for NET 1.11.
    Независимые разработчики могут обеспечить возможность перенаправления своих устройств при условии соблюдения некоторых требований. Рекомендуется, чтобы драйверы перенаправляемых устройств опирались на User-Mode Device Framework, хотя это и не cтрого обязательно. Для поддержки перенаправляемой версий устройства в INF-файл драйвера необходимо добавить несколько новых разделов. Кроме того, в WServer имеется файл ts_generic.inf, который можно включить в INF-файл драйвера, чтобы добавить в него поддержку перенаправления. Включив файл ts_generic.inf, вы укажете WServer на необходимосгь во время сеанса Terminal Services использовать в качестве драйвера устройства usbdr.dll, а эта библиотека будет автоматически передавать все операции драйверу устройства на клиентской стороне. На соответствующие разделы можно ссылаться посредством директив Include= и Needs=. В дополнительные разделы можно также включить информацию об оптимизации драйвера, как это было сделано для портативных устройств Windows и точки службы устройств NET.
    Точки службы для перенаправления устройств .NET
    В RDC также поддерживается перенаправление точек службы Microsoft (Point of Serviсe, POS) для устройств .NET 1.1. Microsoft POS для .NET 1.1 — это библиотека классов, обеспечивающая интерфейс для приложений .NET, позволяющий им обмениваться данными с периферийными устройствами POS, например, сканерами штрих-кодов, биометрическими устройствами и устройствами для чтения магнитных карт Перенаправление устройств Microsoft POS для .NET 1.1 поддерживается только на серверах терминалов х86, работающих под управлением WServer.

    Принтеры Terminal Services


    После установки роли сервера печати у Вас на перенаправленных принтерах будет возникать ошибка о том, что вам отказано в доступе, вам необходимо дать права записи Всем на папку c:\windows\system32\spool\printers. Для чего это делается? Вы предоставляете пользователям создавать очередь печати. Возникает данная незадача из-за того, что вы заходите с компьютера, который не введен в контроллер домена, т.е. он не прошел авторизацию в AD.
    Если, например, не видно локальный принтер в RemoteApp или в терминале, то нужны обновления. Например NET Framework 3.5 для XP.
    TS Easy Print повышает эффективность перенаправления принтеров, освобождая администратора от необходимости устанавливать какие бы то ни было драйверы принтеров на сервере терминалов, попутно гарантируя перенаправление принтера на клиенте и доступность свойств принтера в удаленных сеансах. В TS Easy Print используется новый путъ печати XPS, примененный в WClient и WServer.
    В прошлом, чтобы успешно перенаправить конкретный принтер, соответствующий драйвер нужно было устанавливать как на клиенте, так и на сервере TS. При этом многие пользователи сталкивались с проблемами конфигурации на сервере, связанными с требованием устанавливать на Сервере TS драйверы многих принтеров. Единственный драйвер, необходимый для системы TS Easy Print, устанавливается по умолчанию.
    Реализация этого решения состоит из двух частей. Первая часть — посредством графического интерфейса предоставить пользователю доступ к параметрам печати, чтобы он мог настроить задание печати на произвольном принтере, вместо того чтобы создавать на стороне сервера некий интерфейс с абсолютным минимумом параметров (количество копий, книжная-альбомная ориентация и пр.) и применять этот интерфейс ко всем принтерам, драйвер TS Easy Print играет роль прокси и перенаправляет все обращения к пользовательскому интерфейсу на реальный драйвер клиентского компьютера. Когда пользователь редактирует параметры задания печати на перенаправляемом принтере, клиент TS запускает этот интерфейс на клиентском компьютере поверх удаленного сеанса. В результате пользователь видит тот же самый детальный интерфейс для конкретного принтера (при условии, что ему открыт доступ ко всем параметрам принтера), какой он увидел бы, если бы печатал что-то локально. Заданные пользователем параметры затем перенаправляются на сервер.
    Вторая часть — возможность направлять задание печати с сервера на клиент и надежно выполнять его. Для этого придется воспользоваться новым форматом Microsoft для документов — XPS. Перенаправляя задание, печати, на сервере мы создаем XPS-файл, используя заданные пользователем параметры, передаем ХРS-файл на клиент, а затем при помощи других компонентов печати, печатаем задание на соответствующем принтере. Самое большое преимущество использования формата XPS состоит в том, что он обеспечивает использование высококачественной системы обработки печати, не зависящей от конкретного принтера, на котором будет выполняться задание печати.
    Основные опции перенаправления принтеров модифицируются на вкладке Параметры клиента диалогового окна RDP-Tcp Свойства. Галочка Принтеры Windows отвечает за отключение перенаправления всех клиентских принтеров.
    Важные дополнительные опции перенаправления содержатся в групповой политике.
    Перенаправление принтеров можно отключить или настроить с помощью групповой политики. Чтобы найти опции перенаправления принтеров в групповой политике, откройте объект групповой политики GPO и выполните команду Конфигурация компыотера\Административные шаблоны\Компоненты Windows\Служ6ы терминалов\Сервер терминалов\Перенаправление принтеров. Вы перейдете в папку Перенаправление принтеров, где можно настроить пять параметров политики.
    Задать поведение сервера терминалов при выборе резервного драйвера принтера (Specify Terminal Server Fallback Printer Driver Behavior) - этот параметр политики позволяет задать поведение сервера терминалов при выборе резервного драйвера принтера. По умолчанию подбор резервного драйвера принтера для сервера терминалов отключен. С помощью данного параметра можно назначить выбор драйвера принтера PCL (Printer Control Language), драйвера принтера PS (PostScript) или обоих драйверов. Использовать в первую очередь драйвер принтера Easy Print служб терминалов (Use Terminal Services Easy Printer Driver First) Драйвер обеспечивает пользователям комфортное выполнение операций печати между локальными и удаленными сеансами. По умолчанию сервер терминалов вначале пытается использовать драйвер принтера Easy Print служб терминалов для установки всех клиентских принтеров. Однако с помощью этого параметра политики можно отключить драйвер принтера Easy Print служб терминалов.
    Перенаправлять только используемый по умолчанию принтер клиента — ещё одна опция GPO.

    Ядро Terminal Services


    В WClient и WServer ядро служб терминалов (termsrv.dll) разделено теперь на 2 компонента: lsm.exe (диспетчер локальных сеансов) и termsrv.dll (отвечает за удаленные подключения).
    Диспетчер локальных сеансов (Local Session Manager, LSM) — один из процессов ядра системы, запускаемый в ходе загрузки. LSM также взаимодействует с другими основными системными компонентами, например smss.exe, winlogon.exe, logonui.exe, csrss.exe и win32k.sys. Этo гарантирует, что остальная часть ОС будет синхронизирована с операциями управления сеансами, что будет загружен правильный графический драйвер, что он будет выгружен после завершения сеанса и т.д. LSM управляет всеми подключениями и обеспечивает работу компонентов WClient, наподобие Fast User Switching (FUS), даже когда удаленный рабочий стол выключен.
    Служба Termsrv (termsrv.dll, работающая в svchost.exe) обеспечивает работу прослушивателя, который обменивается данными с драйвером TDI режима ядра, чтобы детектировать запросы на входящие подключения. Кроме того, он участвует в арбитраже сеансов, взаимодействует с сервером License Server, поддерживает сеансы расширителя Media Center, обменивается данными с уровнями RDP в стеке протоколов и с LSM.
    Это позволяет отключать удаленные соединения без выключения FUS. В результате одним компьютером могут локально пользоваться несколько человек, и никому из них не придется выходить из системы! Всю функциональность управления сеансами, необходимую FUS, обеспечивает LSM.
    Еще одно значительное преимущество связано с безопасностью: с системными полномочиями работает только LSM, a termsrv.dll запускается с полномочиями сетевой службы, которые далеко не так обширны. В LSM включена лишь треть прежнего кода termsrv, что приводит к значительному сокращению поверхности атаки.

    Сеансы и их состояния


    Зарегистрировавшись на компьютере (локально или удаленно), пользователь начинает интерактивный сеанс. Сеансом называется определенное пространство, которое содержит коллекцию запущенных процессов, представляющих систему или пользователя с его рабочим столом и приложениями.
    Каждому сеансу соответствует идентификатор. В WServer первый интерактивный пользовательский сеанс называется сеансом 1 независимо от того как зарегистрировался пользователь — локально или удаленно. По мере регистрации на сервере новых пользователей значения идентификаторов сеансов увеличиваются. Когда пользователь выходит из системы и его сеанс прерывается, идентификатор высвобождается и доступен для повторного использования.
    Сеанс за время своего существования проходит через несколько состояний. Наиболее интересные из них: активное и отключенное. Если пользователь действительно работает в сеансе, сеанс находится в активном состоянии. Если пользователь к сеансу не подключен, но его приложения все еще работают, сеанс находится в отключенном состоянии.

    Терминалы локальный и удаленный, сеанс консоли


    Активный сеанс соединен с набором устройств ввода и вывода (клавиатура, мышь, монитор и т.д.). Для краткости мы будем называть этот набор терминалом. Терминал может быть локальным — в этом случае клавиатура, мышь и монитор физически подключены к серверу. Терминал может быть удаленным — в этом случае сеанс на сервере привязан к клавиатуре, мыши и монитору на клиентском компьютере. Удаленный терминал также связан с подключением - объектом, содержащим информацию о протоколе, драйверах стека, прослушивателе и пр.
    В отключенном состояний сеанс не привязан ни к одному терминалу. При разрыве удаленного сеанса (точнее, подключения), объекты удаленного терминала и подключения уничтожаются. Подключение служб терминалов выполняется лишь для открытия окна Подключение к удаленному рабочему столу, в котором отображается рабочий стол удаленного компьютера. С другой стороны, локальный терминал никогда не уничтожается окончательно.

    Сеанс 0


    Изоляция сеанса 0 (session 0 isolation) — новый компонент WClient и WServer, призванный укрепить безопасность платформы. (В предыдущих версиях Windows все службы работают в сеансе 0 вместе с пользовательскими приложениями, что рискованно с точки зрения безопасности). В WClient и WServer пользовательские приложения работают в других сеансах. Службы, подобные LocalSystem, обычно работает с весьма обширными полномочиями, которые пользовательским приложением не нужны. Однако, если и те и другие работают в одном и том же интерактивном сеансе, приложения с узкими полномочиями легко могут атаковать приложения с широкими полномочиями. Наиболее типичный способ такого нападения называется «подрывной атакой» (shatter attack) и опирается на пользовательский интерфейс некоторых служб, например, сообщения об ошибках и информационные окна.
    В WClient и WServer сеанс 0 предназначен исключительно для работы системных служб. Интерактивный вход в сеанс 0 не разрешается.
    Разумеется, это изменение повлияет на разработку приложений, которые будут запускаться на серверах терминалов. Поскольку службы работают в собственном сеансе, разработчики служб и приложений должны следовать таким правилам:
    • Не предполагайте в коде, что приложение будет работать в сеансе 0 или что приложения и службы будут работать в одном и том же сеансе. Например, если ваша служба создаёт событие (без префикса Global\), не считайте, что ваше приложение автоматически увидит это событие (или сможет его дождаться). Если вы планируете использовать, эту модель, явно создавайте именованные объекты с флагом Global\.
    • Чтобы определить, не работает ли приложение в сеансе физической консоли (т.е. с локальной (физически подключенной) клавиатурой и мышью), некоторые современные приложения проверяют, не работают ли они в сеансе 0. Понятно, что делать так не стоит, даже в ХР и WServer 2003 (где консольным сеансом мог был сеанс 0). Корректный способ такой проверки состоит в определении идентификатора текущего сеанса приложения при помощи API ProcessIdToSessionId. Затем при помощи API WTSGetActiveConsoleSessionId определите идентификатор сеанса физической консоли и проверьте, совпадают ли два идентификатора.
    • Если службе нужно отобразить какой-то элемент интерфейса (скажем, сообщение о состоянии), лучше всего воспользоваться для этого АPI CreateProcessAsUser, создав процесс в целевом пользовательском сеансе. Этот процесс должен работать с теми же полномочиями, что и зарегистрированный пользователь.
    • Если службе нужно взаимодействовать с приложением, примените обычный клиент-серверный механизм. Например, служба и приложение в различных сеансах могут обмениваться данными посредством протокола, подобного RPC или СОМ. При этом приложение может выполнять в пользовательском сеансе действия от имени службы.

    Для приложений, способных работать только в сеансе 0, будут поставляться программные клинья компонента OS Арр Compat. Для работы с пользовательским интерфейсом прежних версий служб из сеанса 0 будет использоваться специальный компонент — средство просмотра сеанса 0.
    В WS2003 консольным назывался сеанс с идентификатором 0. Он всегда привязан к локальному терминалу. Когда пользователь входит на локальный терминал, он регистрируется в сеансе 0. Этот сеанс прекращается только при выключении компьютера. Есть некоторые действия, выполнить которые можно только в сеансе 0. Скажем, есть приложения, которые, нормально работают только в сеансе консоли. Кроме того, к сеансу 0 привязаны некоторые службы, которые способны выводить сообщения только на локальный терминал.
    В WServer сеанс 0 более не является интерактивным. В нем работают только службы. Консольным считается сеанс, привязанный к локальному терминалу, однако нет одного определенного сеанса, который всегда был бы консольным. Из сеанса, привязанного к локальному терминалу, можно выйти или отключить его. Будет создан и привязан к локальному терминалу новый сеанс. Вообще, консольным считается сеанс, в данный момент привязанный к локальному терминалу. Подключаться удаленно к консольному сеансу в WServer не нужно, поскольку все сеансы на удаленных терминалах обладают теми же возможностями, что и сеанс на локальном терминале.
    Когда сеанс на локальном терминале отключается, создается новый сеанс консоли, к которому присоединяется новый локальный терминал. В этом случае сеанс соединен с терминалом, хотя и находится в неактивном состоянии. Такой сеанс находится в подключенном состоянии. Например, если вывести на экран список сеансов в тот момент, когда локально никто не зарегистрирован, вы увидите, что сеансу консоли соответствует подключенное состояние (именно он отвечает за отображение окна Ctrl+Alt+Del).

    Переподключение сеанса


    Отключенный сеанс можно переподключить к другому терминалу (локальному или удаленному). В приведенном ниже примере показана последовательность событий при отключении и переподключении сеанса на локальном терминале:
  • Когда пользователь регистрируется на локальном терминале, с этим терминалом связывается сеанс (сеанс 1) в активном состоянии, называемый также сеансом консоли.
  • Пользователь отключает или блокирует сеанс. На этом этапе с сеансом 1 не связан ни один терминал. При завершении локального терминала он создает новый сеанс (сеанс который отвечает за отображение окна Ctrl+Alt+Del). Создается новый локальный терминал, привязанный к сеансу 2. Теперь сеанс 2 находится в подключенном состоянии, а сеанс 1 — в отключенном. Консольным называется сеанс 2.
  • Тот же самый пользователь подключается к серверу удаленно. Создается новый терминал. Пo умолчанию, каждый пользователь ограничен единственным сеансом. Поскольку он уже связан с отключенным сеансом, его удаленный терминал подсоединяется к уже существующему сеансу (сеансу 1). Состояние сеанса 1 изменяется на активное.
  • Пользователь разрывает сеанс, удаленный терминал уничтожается, и сеанс 1 остается в отключенном состоянии.
  • Сеанс 1 прекращает существовать, только когда пользователь выходит из системы или когда администратор разрывает сеанс при помощи собственных инструментов.

    /admin


    Параметр /console в WS2003 нужен для удаленного подключения к локальному терминалу, конкретно, к сеансу 0 (как в режиме Remote Administration, так и в режиме Terminal Server). Благодаря этому администратор может устанавливать и запускать приложения, а также просматривать сообщения служб или просто получить доступ к сеансу на локальном терминале. Кроме того, это единственный способ удаленного администрирования сервера без использования клиентской лицензии TS CAL при установленном Terminal Server.
    Таким образом, из всех предназначений параметра /console в WServer осталось только администрирование сервера без использования клиентской лицензии TS. Поскольку теперь для этого не нужно подключаться именно к сеансу консоли, параметр переименован в /admin.
    В WServer при установленной роли TS использование переключателя /admin вызывает либо создание нового сеанса, либо переподключение к любому существующему сеансу. В режиме Remote Administration параметр /admin не действует.
    В WS2003, если параметр /console не использован, пользователь попадает в новый сеанс, даже если у него уже есть сеанс на локальном терминале, причем независимо от значения политики Restrict user to single session. В WServer, как при использовании параметра /admin, так и без него, пользователь подключается к своему существующему сеансу, если задана эта политика (по умолчанию она задана).
    При установленной роли ТS удаленные подключения, начатые при помощи mstsc.exe, используют клиентскую лицензию TS. Чтобы удаленно администрировать компьютер, не используя TS CAL, применяется параметр /admin (например, mstsc /admin). С его помощью можно организовать не более 2 административных сеансов (как и в режиме удаленного администрирования), включая сеанс на локальном терминале.
    Чтобы начать административный сеанс с параметром /admin, на локальном и удаленном терминале нужны разные разрешения. Чтобы начать удаленный сеанс при помощи /admin, пользователь должен входить в группу Remote Desktop Users и список SD_CONSOLЕ. По умолчанию, в этот список и в эту группу входят только администраторы. Администраторы могут редактировать ACL-список SD_CONSOLE при помощи WMI. Графический интерфейс для решения этой задачи не предусмотрен, поскольку, как правило, менять этот список не нужно.
    Чтобы создать административный сеанс на локальном терминале, пользователю необходимо право локального входа в систему (Эту политику можно увидеть в Локальных политиках безопасности).

    Административные и пользовательские сеансы

    • В административных сеансах в отличие от пользовательских, перенаправление часового пояса не производится, даже если оно задано. По сути, это означает недоступность перенаправления часового пояса в режиме Remote Administration, поскольку при этом нет сеансов CAL.
    • На административные сеансы не влияет значение политики Deny User Permissions to Log on to Terminal Server в профиле Terminal Services пользователя. Если в параметрах пользователя установлен этот флажок, он не сможет создать удаленное подключение при помощи mstsc, не используя параметр /admin. Однако с параметром /admin это действие будет доступно тому же самому пользователю, если он включен в список SD_CONSOLE или входит в группу администраторов.
    • На административные сеансы не распространяется действие режима очистки (drain mode). Если сервер находится в этом режиме, вы сможете подключиться к нему без параметра /admin только при условии, что у вас уже есть сеанс на этом сервере.
    • На административные сеансы не распространяется настроенное на сервере максимальное количество сеансов, но не забывайте, что одновременно может существовать не более 2-ух активных сеансов /admin. Когда превышено предельное число административных сеансов, конфликт разрешается за счет того, что новому пользователю разрешено договариваться с другими пользователями (см далее). Для сеансов CAL обработка конфликтов не производится. Если у вас есть действующая лицензия CAL, вы всегда можете подключиться удаленно.

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

    Обработка конфликтов


    В режиме удаленного администрирования WS2003 разрешается иметь не более трех сеансов независимо от их состояния, например, один сеанс на локальном терминале и два удаленных или три удаленных сеанса — один с переключателем /console и два — без него. Если вы при этом пытаетесь начать четвертый сеанс, то получаете сообщение об ошибке « Maximum number of sessions exceeded». В режиме сервера терминалов WS2003 разрешается иметь только один удаленный административный сеанс, не использующий СAL. Если кто-то уже зарегистрирован на консоли, он должен выйти из сеанса.
    В WServer разрешается иметь не более 2 активных: административных сеансов (локальных или удаленных). Если при двух активных администраторах начать административный сеанс пытается третий пользователь (например, инициируя удаленное подключение с параметром /admin или регистрируясь на локальном терминале), он видит на экране диалоговое окно, в котором можно запросить отключение одного из двух других пользователей. Перечислены только сеансы, созданные на локальном терминале или на удаленном терминале с помощью переключателя /admin.
    Флажок для принудительного отключения одного из пользователей присутствует, только если третий пользователь входит в группу администраторов.
    Когда вы выбираете в этом окне пользователя, он получает запрос на отклонение, как это делается и в клиентах ХР и Vistа. Если пользователь не отвечает на запрос в течение 30 с, производится его отключение (сеанс не завершается).
    Обратите внимание, что это ограничение распространяется только на активные сеансы. Одновременных отключенных сеансов может быть сколько угодно.

    Планирование разделяемых ресурсов процессора


    В предыдущих версиях Terminal Services планировщик Windows имел политику планирования, которая распределяла время процессора поровну между всеми потоками одного
    уровня приоритета. Хотя эта методика планирования позволяла предотвращать монопольный захват ресурсов процессора любым пользователем, она не могла равномерно распределять время процессора на основе динамических нагрузок. Чтобы лучше справляться с динамическими нагрузками, компонент Fair Share CPU Scheduling (Планирование разделяемых ресурсов процессора) в службе Remote Desktop Services использует механизм пла-
    нирования WServer уровня ядра для динамического распределения процессорного времени между сеансами в зависимости от количества сеансов и их нагрузки.
    НА ЗАМЕТКУ :
    По умолчанию средство Fair Share CPU Scheduling включено. Чтобы отключить его, установите в 0 следующий элемент реестра:
    НКЕY_LOCAL_MACHINE\SOFTWARE \ Policies\Microsoft\Windows \SessionManager\DFSS\EnableDFSS.

    Установка служб терминалов и управление ими


    В небольших и средних организациях вашим лучшим другом в этом отношении будет Server Manager. Если вы добавляете роль при помощи мастера, вам предоставляется возможность выбора из 5 служб роли Terminal Server:
    TS Licensing Server
    TS Session Broker
    TS Gateway Позволяет клиентам использовать HTTPS для безопасного доступа внешних клиентов из Интернета к серверам терминалов внутренней сети. Предполагает установку роли Network Policy and Access Services.
    TS Web Access Позволяет клиентам получать доступ к серверам терминалов через веб и запускать приложения с помощью веб-браузера.
    Помимо удаленного рабочего стола Службы терминалов WServer включают следующие дополнительные компоненты. Многопользовательская поддержка (Multiuser capacity). Службы терминалов поддерживают два режима: режим выполнения Execute (для стандартного запуска приложений) и режим установки Install (для инсталляции приложений). При установке приложения на сервер терминалов в режиме TS Install параметры записываются в реестр или файлы .ini таким образом, чтобы обеспечить поддержку множества пользователей. В отличие от служб терминалов компонент Удаленный рабочий стол в Windows не включает режим установки и не обеспечивает многопользовательскую поддержку приложений.
    После выбора роли Службы терминалов Мастер добавления ролей напомнит о том, что все приложения, которые развертываются для пользователей через службы терминалов, должны быть установлены после добавления роли Службы терминалов. Если вы уже установили какие-либо приложения для развертывания, их следует удалить и установить позже (в режиме TS Install), чтобы обеспечить к ним доступ множества пользователей.
    Совместимость с RDS программы установки Windows
    В прежних версиях Terminal Services поддерживалась одновременно только одна копия программы установки Windows (Windows Installer). Это означало, что пользовательские
    MSI-действия (такие как персонализация) были ограничены одним параллельным запуском на один терминальный сервер. Чтобы облегчить развертывание приложений на серверах RS Session Host, было разработано средство Windows Installer RDS Compatibility (Совместимость с RDS программы установки Windows), которое ставит в очередь установки приложений пользователями с последующей их обработкой с помощью программы установки Windows.
    В качестве альтернативы режим Remote Desktop for Administration может быть включен через GPO с использованием следующих опций политики:
    Computer Configuration\Policies\Administrative Templates\Windows
    Components\Remote Desktop Services\Remote Desktop Session Host\
    Connections\Allow позволяет пользователям подключаться удаленно, используя службу Remote Desktop Services;
    Computer Configuration\Policies\Administrative Templates\Windows
    Components\Remote Desktop Services\Remote Desktop Session Host\
    Security\Require требует аутентификации пользователя для удаленных соединений, используя аутентификацию уровня сети (NLA).
    Кроме того, администраторы могут также использовать PowerShell и следующие команды для включения режима Remote Desktop for Administration:
    (Get-WmiObject -Class "Win32_TerminalServiceSetting"
    -Namespace root\ cimv2 \terminalservices).SetAllowTsConnections(1)
    (Get-WmiObject -class "Win32_TSGeneralSetting"
    -Namespace root\cimv2\terminalservices
    -Filter "TerminalName='RDPtcp'”).SetUserAuthenticationRequired(1)
    В то время как описанный ранее метод с использованием диспетчера сервера также конфигурирует необходимые правила брандмауэра узла для удаленных рабочих столов, два других метода оставляют настройку необходимых правил брандмауэра за администратором.

    Запуск


    Активируйте по официальной инструкции. А в самый ответственный момент введите 9557260. Таких номеров в Интернете много. Ищи по Enrollment Number.
    В свойствах системы на сервере будет свойство для открытия доступа через брандмауэр.
    Входить в терминал как пользователь домёна можно даже если клиентский компьютер не входит в состав домёна.
    Пользователи домена должны быть включены в группу RDS.
    В политиках безопасности разреши вход через терминалы пользователям домёна (локальные политики не повлияют на групповые!).
    При входе с клиентов возможно придётся указывать поле Имя в формате NetBiosИмяСервера/Имя.

    Файл ответов Unattend.xml для роли TS


    Не забывайте, что файлы Ответов рекомендуется создавать в Windows: System Image Manager (Windows SIM). Даже если вы создаете файл ответов вручную, при помощи Windows SIM его можно проверить. Поскольку доступные параметры и значения пo умолчанию время от времени меняются, перед повторным использованием файл ответов рекомендуется проверять.
    Разрешение удаленных подключений (fDenyTSConnections) задается в файле ответов, чтобы разрешить работу Remote Desktop.
    component name: ''Microsoft-Windows-TerminalServices-LocalSessionManager»
    ratting: fDenyTSConnections
    possible values : false or true
    default: true
    Если значение равно TRUE, удаленный рабочий стол разрешен. Если значение FALSE или не задано, удаленный рабочий стол запрещен (вариант по умолчанию).
    Если вы хотите включить Remote Desktop при наличии брандмауэра Windows, помимо этого параметра необходимо еще задать исключение брандмаура для Remote Desktop.
    Параметры проверки подлинности пользователя этот параметр задает, как производится проверка подлинности пользователя перед установлением подключения Remote Desktop. Если вы не зададите этот параметр, по умолчанию у вас не будет возможности удаленно подключиться к данной машине с компьютеров, на которых не запущен Remote Desktop с проверкой подлинности Network Level Authentication.
    Component nаmе: "Micosoft-Windows-TerminalServices-RDP-WinStationExtensions”
    Setting: UserAuthentication
    possible values: 0 or 1
    default: 1
    Значение 0 означает, что проверка подлинности Network Level перед установлением подключения Remote Desktop не требуется. Оно соответствует следующему переключателю на вкладке Remote окна свойств системы (рисунок). Если этот параметр не задан или для него задано значение 1, требуется проверка подлинности Network Level (последний переключатель).
    Параметры безопасности (SecurityLayer) этот параметр определят, как проверяется подлинность серверов и клиентов перед установлением соединения Remote Desktop.
    Component nаmе: "Micosoft-Windows-TerminalServices-RDP-WinStationExtensions” Setting: UserAuthentication
    Possible Values: 0 or 1 or 2 default: 1
    Этому параметру соответствуют следующие параметры на вкладке General диалогового-окна свойств rdp-tcp в tsconfig (рисунок):
    Значение 0 означает, что во время автоматической установки будет задан вариант RDP Security Layer, то есть, перед установлением соединения Remote Desktop для взаимной авторизации сервера и клиента будет использоваться протокол RDP.
    При значении 1 будет выбран вариант Negotiate. Этот же вариант используется по умолчанию, если параметр в файле ответов не задан. Перед установлением соединения Remote Desktop сервер и клиент будут согласовывать метод авторизации.
    Значение 2 приводит к использованию варианта SSL (TLS 1.0). Перед установлением соединения Remote Desktop сервер и клиент будут использовать для взаимной авторизации протокол Transport Layer Security (TLS).
    Режим лицензирования (LicensingMode) параметр применим только при установке роли Terminal Server и задает режим лицензирования.
    Component name: ''Microsoft-Windows-TerminalServices-RemoteConnectionManager» Setting: LicensionMode Possible Values: 2 or 4 or 5 Default: 5
    Этот параметр соответствует следующему параметру графического интерфейса конфигурации сервера (рисунок):
    Значение 2 соответствует режиму лицензирования «на устройство», значение 4 — режиму «на пользователя», Значение 5 означает, что лицензирование еще не настроено.
    Отключение разрешительного списка (fDisableAllowList) параметр определяет, можно или нельзя использоватъ в режиме одного приложения программы, не включенные в разрешительный список.
    Component name: "Miсrosoft-Windows-TerminalServices-Publishing-WMIProvider" Setting: fDisabledAllowList Possible values: false or true Default: false
    Значение TRUE означает, что в качестве начальной программы можно запускать приложения, не включенные в список разрешенных приложений. Значение FALSE означает, что запускать можно только приложения из списка.
    Область действия автоматического обнаружения License Server (Rale) параметр определяет область действии автоматического обнаружения License Server Component nаmе: "Micosoft-Windows-TerminalServices-LicenseServer" Settings: Role Possible values: 0 or 1
    Default: 0
    Если значение этого параметра равно 1 и на одном из компьютеров домена установлен License Server, область обнаружения License Server совпадает с лесом. Если параметр обнулен и на одном из компьютеров домена установлен License Server, областью действия является домен. Если парамегр равен нулю и License Server установлен на компьютере рабочей группы, областью обнаружения License Server является рабочая группа. В рабочей группе присвоить этому параметру значение 1 нельзя. Все прочие значения некорректны, и вместо них будет использовано значение по умолчанию (0).
    Если вы задали для параметра значение 1 на компьютере из домена, то есть, выбрали в качестве области обнаружения лес, по завершению автоматической установки администратор должен опубликовать сервер лицензий в Active Directory. В ходе автоматической установки можно только менять парамегры реестра License Server, но не опубликовать его в Active Directory, поскольку для этого требуются полномочия администратора предприятия. Включено 2 новых способа публикации License Server после установки:
    Первый способ состоит в использовании нового диалогового окна для настройки License Server в TS Licensing Manager (консоль администратора TS License Server) Для публикации License Server выполните следующие действия:
    1. Подключитесь к License Server.
    2. Щелкните Server правой кнопкой и выберите команду Review Configuration.
    3. Если для License Server задана область обнаружения Forest и он не опубликован, в диалоговом окне будет отображена информация об этом и кнопка Publish. Щелкните кнопку, чтобы опубликовать License Server. Чтобы публикация прошла успешно, TS Licensing Manager должен быть запущен с полномочиями администратора предприятия.
    Второй способ — использовать метод WMI Win32_TSLicenseServer::Publish(). Этот API также нужно запускать с полномочиями администратора предприятия.
    Папка БД TS Licensing (DBPath) задает папку, в которой будут храниться файлы с данными о лидировании TS.
    Component nаmе: "Micosoft-Windows-TerminalServices-LicenseServer" Setting: DBPath
    Default: %SystemRoot%\System32\LServer Узел для веб-доступа к TS
    Этот параметр позволяет изменить узел для веб-доступа к TS.
    Component nаmе: "TSPortalWebPart" Setting: WebSite Default: Empty
    Узел веб-клиента TS ЭтОт параметр позволяет изменить узел веб-клиента TS.
    Component nаmе: «Microsoft-Windows-TerminalSeivices-WebControlExtension" Setting: WebSite Default: Empty

    Включение удаленного рабочего стола на Server Core


    Конфигурация установки ядра сервера WServer не полностью поддерживает роль Службы терминалов. Однако вы можете при таком типе установки включить компонент Удаленный рабочий стол с помощью сценария Scregedit.wsf Редактора реестра ядра сервера. Данный сценарий обеспечивает упрощенный способ настройки компонентов на компьютере с установленным ядром сервера WServer. Scregedit.wsf можно найти в %System Root%\System32.
    Включить удаленный рабочий стол позволяет команда:
    Cscript.exe C:\Windows\System32\Scregedit.wsf /AR 0
    Задайте для переключателя /AR значение 0, чтобы разрешить подключения к удаленному рабочего столу (По умолчанию переключателю /AR присвоено значение 1, запрещающее подключения к удаленному рабочего столу).
    При подключении вы получите такой же интерфейс, как на сервере (без GUI).

    Управление службами терминалов


    С помощью консоли Server Manager.Если на компьютере установлены службы роли, наподобие TS Gateway и TS Web Access, для управления ими также будут добавлены оснастки.Веб-доступ к службам терминаловКомпонент TS Web Access. Прежде всего, вы должны добавить на сервер WServer роль TS Web Access. При этом вам также придется добавить роль Web Server (IIS) и компонент Windows Process Activation Service (WPAS). Затем вы должны задать источник данных, на основе которого будет формироваться список программ RemoteApp, отображаемый в Web Part.В предыдущую версию Terminal Services из Windows Server 2003 был включен компонент Remote Desktop Web Connection, являющийся на самом деле элементом управления ActiveX и обладающей практически той же функциональностью, что и полный клиент Terminal Services, но работающий через веб-браузер. Внедрив этот элемент ActiveX в веб-страницу, размещённую в IIS, вы позволяли пользователю открыть эту веб-страницу в веб-браузере, например, в Internet Explorer, загрузить и установить элемент управления ActiveX и открыть сеанс с удаленным сервером терминалов. RDC при этом на клиентском компьютере не нужен. Сеанс TS работает в веб-браузере посредством фнкциональности ActiveX.И в этом случае вы могли запускать посредством Remote Desktop Web Connection только рабочий стол целиком, но не отдельные приложения. Кроме того, для организации сеанса с сервером терминалов пользователь должен был загрузить и установить элемент управления ActiveX. Если это действие было запрещено политикой безопасности на компьютере пользователя, ему оставалось только посочувствовать. В WClient и WServer функциональность Remote Desktop Web Сonnection расширена в двух базовых аспектах. Во-первых, в клиент RDC необходимый элемент управления ActiveX встроен, поэтому загружать и устанавливать его отдельно не приходится. Во-вторых, компонент TS Web Access интегрирован с компонентом TS RemoteApp. Благодаря этому пользователи, открыв веб-страницу, видят список доступных программ RemoteApp, щелкают значок нужной программы и запускают ее на своем компьютере. В комплект TS Web Access включена веб-страница по умолчанию, которую можно использовать для развертывания приложений RemoteApp через веб. Она включает в себя настраиваемый фрагмент Web Part, в котором перечислены доступные программы RemoteApp. Если вы не хотите использовать веб-страницу по умолчанию, то можете разместись Part на узле Microsoft Windows SharePoint Services.Программа RemoteApp, запущенная с веб-страницы по умолчанию, выглядит точно также, как программа, работающая локально. Если пользователь запустил с помощью веб-страницы несколько программ на одном и том же сервере терминалов, все эти программы RemoteApp будут работать в рамках одного и того же сеанса Terminal Services.

    Работа с TS Web Access


    IIS может заполнять список программ RemoteApp, отображаемый в Web Part, как из локального, так и из внешнего источника данных, к тому же, этот список автоматически обновляется. Если вы с помощью TS RemoteApp Manager добавили в список программ RemoteApp новое приложение, пользователь увидит его, когда в очередной раз откроет веб-страницу TS Web Access по умолчанию. Все это означает, что компьютер WServer, на котором установлена служба роли TS Web Access (и, следовательно, IIS) не нуждается в установке основной службы роли Terminal Server. Вы вольны заводить в сети несколько серверов терминалов для удаленного запуска приложений, и при этом вам будет достаточно одного сервера IIS для роли TS Web Access, на котором будет находиться веб-страница для доступа к серверам терминалов и запуска программ RemoteApp.
    Источником данных для заполнения списка Web Part может быть конкретный сервер терминалов. При этом все приложения, включенные на нем в список RemoteApp, будут доступны всем пользователям. Иными словами, при просмотре веб-страницы с Web Pan все пользователи будут видеть один и тот же список программ RemoteApp.
    Зарегистрируемся WClient с доменной (но не административной) учетной записью, откроем Internet Explorer и перейдем к URL http:///ts , где — имя (имя хоста или FQDN-имя) или IP-адрес сервера терминалов. Введя учетные данные (и, возможно, сохранив их для будущего использования).
    Приложение работает на рабочем столе, а не в веб-браузере.
    Как настроить источник данных для TS Web Access? При установке службы роли Web Access на компьютер WServer никакой подузел Web Access в узле Terminal Services консоли Server Manager не появился. Это связано с тем, что Web Access на самом деле представляет собой приложение IIS и настраивается в IIS Manager. Но вам туда не нужно — настроить источник данных можно прямо в веб-браузере! Только вместо учетных данных пользователя домена на WClient нужно открыть IE на сервере TS Web Access и виести учетные данные локального администратора. Можно также открыть IE локально или удаленно и ввести учетные данные пользователя из локальной группы TS Web Access Administrators сервера TS Web Access. Когда вы это сделаете, на экране появится веб-страница, как на клиенте, но с одним важным отличием. Когда страницу открывает обычный пользователь, кнопка Configuration не отображается.

    Шлюз служб терминалов


    Его назначение — предоставить прошедшим проверку пользователям безопасный шифрованный доступ к серверам терминалов внутренней корпоративной сети через Интернет. Если администратор должным образом настроил политики доступа к ресурсам, пользователь, возможно, получит даже доступ к рабочему столу своего настольного компьютера, при условии что на нем включен удаленный рабочий стол. Если же удаленный пользователь сам администратор, он получит доступ к рабочим столам любых серверов внутренней сети (при условии, что на них включен Remote Desktop). И все это — без подключения VPN и независимо от типа брандмауэра, применяемого в вашей компании, даже если вы используете NAT. Как показано на рис. 8-4, все, что вам нужно сделать, это разрешить на брандмауэре TCP-порт 443, чтобы он пропускал входящий трафик HTTP SSL.
    Как показано на рисунке, работа TS Gateway заключается в создании туннеля для трафика RDP поверх HTTPS. Клиентский компьютер слева пытается подключиться к серверам терминалов справа. Они скрыты от клиента парой брандмауэров в сети периметра. Шлюз TS Gateway находится между брандмауэрами в защищённой сети. Когда входящий трафик RDP поверх HTTP попадает во внешний брандмауер, тот удаляет из него информацию HTTP и передает пакет RDP шлюзу TS Gateway. TS Gateway затем может при помощи Network Policy Server определить, разрешено ли пользователю подключаться к серверу терминалов, и проводит проверку удаленного пользователя при помощи Active Directory. Когда проверка подлинности пользователя завершена, он получает доступ к внутренним серверам терминалов и волен запускать с них программы RemoteApp.
    TS Gateway будет поддерживать NAP. Когда удаленный клиентский компьютер пытается подключиться к серверу терминалов во внутренней корпоративной сети, он должен сначала пройти проверку состояния, которая гарантирует, что на нем установлены свежие обновления безопасности и антивирусные базы данных, что на клиенте включон брандмауэр и т. д. Исправлять «больные» клиенты, подключившиеся через TS Gateway, NAP не сможет. Он просто запретит им доступ к внутренним серверам теминалов. Кроме того, для удаленных клиентов, подключенных посредством TS Gateway, инициируется перенаправление устройств (вообще-то рекомендуется блокировать такое перенаправление на серверах терминалов, а не на шлюзе TS Gateway).
    Если вам не хочется помещать TS Gateway в сети периметра, установите его в корпоративной сети, то есть, за внутренним брандмауэром. Затем разместите в сети периметра терминатор SSL, который будет безопасно переправлять входящий RDP-трафик на TS Gateway. Как бы вы его ни реализовали, одно преимущество этого компонента всегда есть - вам не нужно больше беспокоиться о VPN. Уходит в прошлое вся головная боль, с которой была сопряжена настройка виртуальных частных сетей.
    Важный аспект TS Gateway — интеграция с NAP, поскольку для многих организаций среднего и крупного размера наличие NAP будет одним из основных стимулов к развертыванию WServer.
    В чем главная ценность TS Gateway? Он открывает удаленным пользователям доступ к серверам терминалов, полностью скрытым за брандмауэрами, но без обычной головной боли настройки VPN-подключения к этим серверам. Нет, я не хочу сказать, что о VPN можно забыть, но если пользователю не нужна локальная копия данных, ресурсы сети ограничены или приложениям нужно передавать большие объемы данных, при помощи TS Gateway вы добьетесь более высокой производительности, чем посредством VPN.
    Нужны советы по развертыванию этого компонента? Используйте для TS Gateway специальный компьютер (его можно объединить с Outlook RPC/HTTP) и разместите его не за простым брандмауэром на основе портов, а за брандмауэром Microsoft Internet and Federation Server (ISA).

    TS Gateway, ISA Server и NAP


    Удаленный доступ на базе Terminal Services на протяжении долгого времени использовался в качестве более простой и безопасной альтернативы классическим технологиям VPN. Там, где VPN зачастую обеспечивали доступ к внутренней сети организации по принципу «все порты, все протоколы», службы терминалов ограничивают подключение одним хорошо определенным портом и протоколом. Однако, чем больше возможностей появляется в RDP (копирование и вставка, перенаправление дисков), тем сильнее расширяется поверхность атаки. Например, удаленный диск, доступ к которому осуществляется посредством RDP, таит в себе те же угрозы, что и диск, подключенный при помощи обычных средств CIFS/SMB.
    Помимо стандартных возможностей шифрования и проверки подлинности TS Gateway можно объединять с ISA Server и платформой NAP, обеспечив тем самым безопасный управляемый доступ от клиента до конечного сервера терминалов через сеть периметра.
    Благодаря ISA Server решение TS Gateway становится более безопасным в двух аспектах. Во-первых, ISA-Server способен действовать как терминатор-SSL и потому позволяет размещать серверы TS Gateway более безопасно. Поскольку ISA может быть конечной точкой трафика SSL со стороны Интернета, сам TS Gateway в сети периметра размещать не надо. Его можно: держать во внутренней сети, перенаправляя ему трафик при помощи ISA Server. Однако, если бы ISA просто перенаправлял трафик, выгода от него была бы невелика. Второй важный вклад в безопасность ISA вносит благодаря возможности предварительной проверки подлинности. Он не просто передает кадры на TS Gateway. ISA проверяет пользователей до того, как они вообще вступят в какой-либо контакт с TS Gateway, гарантируя, что до шлюза доберутся только корректные пользователи. Применение ISA в качестве конечной точки SSL и устройства проверки трафика позволяет безопаснее размещать ресурсы TS Gateway, гарантируя, что они получат из Интернета только проверенный, «чистый» трафик.
    Для получения этого HTTPS-подключения в периметре сети на сервере шлюза служб терминалов должен быть запущен IIS. После приема подключения сервер TS-шлюза извлекает данные HTTPS и направляет RDP-пакеты на конечные серверы терминалов, расположенные за вторым, внутренним брандмауэром. Если в данном сценарии требуется разрешить или запретить входящие подключения к учетным записям Active Directory, на шлюзе служб терминалов нужно установить Службу каталогов Active
    Directory.
    ISA Server защищает TS Gateway от сетевых угроз, но не от самого клиента. А ведь на компьютере пользователя, подключающегося к сеансу TS Gateway, может работать вредоносная программа, или сам компьютер может не соответствовать политике безопасности организации. Чтобы свести к минимуму эти угрозы, TS Gateway интегрируется с Network Access Protection. Платформа NAP включена в WServer и может работать на том же компьютере, что и TS Gateway. Кроме того, TS Gateway можно настроить на использование существующей инфраструктуры NAP на других компьютерах. В сочетании с TS Gateway платформа NАР позволяет применить к удаленным подключениям тот же самый подход, основанный на политиках, что применяется к обычным (не на базе RDP) сетевым подключениям. Конкретно, NAP может управлять доступом к TS Gateway на основе информации об обновлениях, антивирусных программах и брандмауэре клиента. Допустим, если вы решили включить перенаправление дисков на серверах терминалов, то можете потребовать, чтобы на клиентах работало актуальное антивирусное ПО.
    Помимо прочего, при доступе по порту 80 ISA проверяет поток HTTP. Хотя это и не является напрямую проверкой RDP/HTTP, но обеспечивает дополнительную защиту от злоумышленников, пытающихся воспользоваться самим подключением HTTP.
    В альтернативном сценарии, схема которого показана па рис. 4-14, ISA-сервер (под номером 2) выступает в качестве моста HTTPS-to-HTTPS или HTTPS-to-HTTP к серверу шлюза TS (под номером 3), а сервер шлюза TS затем направляет RDP-
    подключение к соответствующему внутреннему ресурсу (под номером 4). Этот метод обеспечивает преимущество защиты информации Active Directory в корпоративной сети.
    При использовании ISA-сервера в качестве моста HTTPS-to-HTTPS к шлюзу служб терминалов не забудьте экспортировать сертификат сервера, применяемый к SSL-подключению с сервера шлюза TS к компьютеру с ISA-сервером, и установить этот сертификат на последнем сервере.

    Реализация TS Gateway


    TS Gateway требует добавления службы роли gateway для роли Terminal Services. Если вы будете делать это при помощи Server Мanager, вам также будет предложено установить следующие роли и компоненты:
    • роль Network Policy and Access Services (точнее, службы роли Network Policy Server);
    • роль Web Server (IIS) и некоторые ее службы и компоненты;
    • Компонент RPC Over HTTP Proxy

    В небольших сетях вполне допустима установка TS Gateway и NPS на одном и том компьютере WServer. На крупных предприятиях их лучше разделить для лучшей изолированности и управляемости.
    Добавляя роль TS Gateway, вы должны также задать сертификат для своего сервера, чтобы он мог шифровать сетевой трафик с клиентами Terminal Services при помощи SSL. Для работы TS Gateway требуется действительный цифровой сертификат. При установке будет предоставлена возможность импортировать сертификат (например, сертификат VeriSign, если вы хотите предоставить клиентам возможность Интернет-доступа к внутренним серверам терминалов со всего мира), создать сертификат с собственной подписью (это удобно для тестирования) или отложить установку сертификата.
    Импортировав сертификат для сервера, вы сможете создать политики авторизации (их можно создать и позже при помощи консоли TS Gateway Management). Политики авторизации бывают двух видов:
    • Политики авторизации подключений позволяют пользователям получать доступ к сети на основе заданных вами условий.
    • Политики авторизации ресурсов позволяют получить доступ к серверам терминалов только конкретно указанным пользователям.

    Установив TS Gateway настройте его, при необходимости создав новые подключения и политики авторизации ресурсов. Можно, например, посредством политики задать группу серверов терминалов внутренней корпоративной сети, к которым авторизованные удаленные клиенты должны получать доступ посредством TS Gateway (рисунок):
    Создавая политики авторизации подключений, вы указываете группы безопасности, а также при необходимости и группы компьютеров, к которым они применяются. Также вы задаете метод проверки подлинности — смарт-карты, пароли или и то, и другое. Создавая и настраивая группу ресурсов, вы определяете набор ресурсов (например, серверов терминалов), к которым будет разрешено обращаться удаленным пользователям. Вы можете либо выделить группу безопасности, в которую входят учетные записи этих компьютеров, либо явно указать их имена (хостов или FQDN) или IP-адреса. Можно также разрешить удаленным пользователям доступ к любому компьютеру (клиенту или серверу) внутренней сети, на котором включен удаленный рабочий стол. Чтобы TS Gateway работал в полную силу, вы должны создать политики авторизации и подключений, и ресурсов.
    Наконец, узел Monitoring консоли TS Gateway Management позволяет следить за соединениями, осуществляемыми через TS Gateway, и при необходимости разрывать их.

    Установка и настройка сервера шлюза служб терминалов


    Сервер шлюза TS можно установить и отконфигурировать, добавив вначале роль службы шлюза TS, а затем отконфигурировав клиентов для указания сервера шлюза служб терминалов.
    При добавлении роли шлюза служб терминалов с помощью Server Manager запускается мастер Добавление служб ролей, который выполняет две основные задачи. Во-первых, он авто-
    матически устанавливает (при необходимости) предварительные роли для шлюза служб терминалов — веб-сервер IIS и сервер сетевых политик NPS (Network Policy Server). Во-вторых, он выполняет процесс настройки трех компонентов шлюза TS, которые требуются для функционирования роли, — сертификата сервера для шифрования SSL, сетевой политики авторизации подключений к службам терминалов (TS Connection Authorization Policy, TS CAP) и политик авторизации ресурсов служб терминалов (TS Resource Authorization Policy, TS RAP).
    Сертификат сервера для SSL. SSL требует сертификат серве-
    ра. В качестве менее защищенного варианта, подходящего для тесто-
    вых сред, мастер Добавление служб ролей может также самостоятельно генерировать сертификат сервера для использования со шлюзом служб терминалов.
    Если сертификат издан не доверенным сторонним СА и не центром СА, интегрированным в собственный домен Active Directory клиента, вы должны экспорти-
    ровать и установить корневой сертификат сервера шлюза служб терминалов (TS Gateway Server Root Certificate) в хранилище доверенных корневых центров сертификации (Trusted Root Certification Authorities) клиента служб тер-
    миналов. Это хранилище можно просмотреть с помощью оснастки Сертификаты.

    Лицензирование служб терминалов

      В задачу TS Licensing входит упрощение управления клиентскими лицензиями Terminal Services (TS CAL). TS Licensing управляет клиентами без лицензий, с временными лицензиями, клиентскими (постоянными) лицензиями. Он также управляет лицензиями как для устройств, так и для пользователей, подключающихся к серверам терминалов.

    Лицензирование TS для устройств работает следующим образом. Когда клиент пытается подключиться к серверу терминалов, тот первым делом определяет, нужна ли клиенту лицензия (TS CAL). Если лицензия нужна, сервер терминалов связывается с сервером TS Licensing и запрашивает маркер лицензии, который затем перенаправляется клиенту. Тем временем сервер TS Licensing отслеживает все установленные на нем маркеры лицензий, чтобы ваша среда не нарушала требований лицензирования. Если клиенту нужен постоянный маркер лицензии, сервер TS Licensing должен быть активирован (Неактивированные серверы TS Licensing способны выдавать только временные маркеры).
    B WServer у TS Licensing появилась новая возможность — отслеживание запуска лицензий TS CAL на пользователя. Если ваш сервер терминалов работает в режиме лицензирования на пользователя, любому пользователю, подключающемуся к нему, необходима лицензия TS Per-User CAL. Если у пользователя такой лицензии нет, сервер терминалов связывается с сервером лицензирования, чтобы получить для пользователя лицензию CAL. При помощи инструмента управления TS Licensing администратор может контролировать выпуск CAL. Помните, что для мониторинга лицензий TS Per-User необходима инфраструктура Active Directory.
    TS Licensing Manager способна находить проблемы с его конфигурацией. Информация о состоянии конфигурации License Server отображается в новом столбце Configuration. Если с конфигурацией License Server возникли какие-то проблемы, в этом столбце будет отображаться Review. TS Licensing Manager позволяет администратору подробно просматривать текущие параметры конфигурации License Server. Щелкните по имени сервера ПКМ и выберите в меню команду Review Configuration (Проверить настройку), чтобы открыть конфигурационное диалоговое окно, в нем отображается следующая информация:
    • Членство в группе Terminal Server License Server на контроллере домена AD. Во время установки роли ТS Licensing на компьютере домена программа установки пытается добавить License Server в группу Terminal Server License Server на контроллере домена, для чего требуются полномочия администратора домена. Членство в этой группе позволяет серверу лицензирования следить за использованием лицензии на пользователя.
    • Состояние глобальной политики License Server Security Group (TSLS). Если эта политика включена, а группа Terminal Server Computers не создана, будет отображено соответствующее предупреждение. Если политика выключена, сообщения не будет.

    Обнаружив какие-то сбои в конфигурации License Server, администратор может их исправить. В диалоговом окне конфигурации License Server администратор может выполнить следующие действия:
    • Изменить область действия License Server. Если областью, действия License Server является лес и License Server не опубликован в Active Directory, в диалоговом окне конфигурации License Server отображается соответствующее предупреждение для администратора; оно же позволяет опубликовать License Server в Active Directory.
    • Добавить группу TSLS в AD.
    • Если включена групповая политика License Server Security Group и локальная группа Terminal Server Computers не создана, в диалоговом окне конфигурации License Server отображается соответствующее предупреждение. Здесь же администратор может создать на License Server локальную группу Terminal Server Computers.

    Отзыв возможен при использовании лицензий на устройство, но не лицензий на пользователя. Процесс автоматического освобождения лицензий CAL также применяется только к лицензиям на устройство. Лицензии CAL на устройство выдаются клиентам на определенный срок ( validity period), по истечению которого лицензия недействительна. Если клиент достаточно часто обращается к серверу терминалов, действие СAL продлевается до истечения этого срока. Если клиент долго не обращался к серверу терминалов, срок действия CAL рано или поздно заканчивается. Сервер Terminal Services License периодически освобождает все CAL с истекшим сроком действия.
    Время от времени у администратора возникает необходимость забрать лицензию CAL у клиента и вернуть ее в пул свободных лицензий на License Server — этот Процесс называется освобождением (reclaiming) или отзывом (revoking) лицензии. Однако есть определенные ограничения на количество CAL, которые можно отозвать в данный момент времени. Оно накладывается сервером лицензирования, чтобы предотвратить злоупотребление этой возможностью. Это ограничение можно сформулировать следующим образом: в любой момент времени количество лицензий CAL на устройство в состоянии отзыва не должно превышать 20% от полного числа лицензий, установленных на License Server. CAL переходит в это состояние сразу после отзыва и остается в нем до тех пор, пока не истечет предзаданный срок действия лицензии. Чтобы узнать, какие лицензии CAL находятся в состоянии отзыва, откройте консоль TS Licensing Manager в представлении списка клиентов и проверьте содержимое столбца Status. Если администратор превысил этот предел, ему будет сообщена дата, начиная с которой, снова можно будет отзывать лицензии. Злоупотреблять отзывом TS CAL не следует. Отзывайте их только в том случаe, если компьютер, которому они выданы, более не является частью окружения, например, вышел из строя.
    Как бы редко ни осуществляли подключения клиентские компьютеры, лицензия TS CAL должна быть у них постоянно. Это относится и к лицензированию на пользователя.
    1. Лицензирование TS на устройство является перманентным и назначается для любого компьютера или устройства, которое неоднократно подключается к службам терминалов. При использовании режима лицензирования на устройство и при первом подключении к серверу терминалов клиентский компьютер или устройство по умолчанию получает временную лицензию. В случае повторного подключении при условии активации сервера лицензий и при наличии лицензий TS Per Device CAL сервер лицензий выдает клиентскому компьютеру или устройству постоянную лицензию TS Per Device CAL.
    2. Режим лицензирования TS на пользователя. Лицензии TS Per User CAL предоставляют пользователям право доступа к службам терминалов с любого количества устройств. Лицензии TS Per User CAL не назначаются конкретным пользователям.
    Примите во внимание количество устройств и пользователей в организации. С финансовой точки зрения вполне приемлемо выбрать лицензии CAL на устройство, если в течение жизненного цикла сервера терминалов устройств будет меньше, чем пользователей. Если же пользователей в организации меньше, чем устройств, выберите лицензирование на пользователя. При этом следует учесть, как часто пользователи путешествуют и подключаются с различных компьютеров. Лицензирование на пользователя имеет смысл использовать, в частности, тогда, когда очень небольшое количество пользователей подключается к серверу терминалов с множества различных сайтов, предположим, в потребительских сетях.

    Диагностика сбоев лицензирования Terminal Server


    В оснастку Terminal Services Configuration (TSConfig.msc) встроен инструмент Licensing Diagnosis. В совокупности с командой Review Configuration для License Server этот инструмент незаменим при выявлении проблем, возникших из-за некорректной конфигурации TS Licensing. В ходе диагностики инструмент не сообщает обо всех возможных проблемах во всех возможных сценариях, а просто собирает всю информацию о TS Licensing на серверах терминалов и лицензирования в одном месте и обнаруживает типичные ошибки в конфигурации.
    После запуска Licensing Diagnosis сначала составляет список серверов лицензирования, которые могут быть обнаружены сервером терминалов в ходе автообнаружения, а также серверов, использование которых можно задать вручную либо при помощи параметра Use the Specified License Servers в TSConfig.msc, либо при помощи групповой политики Use the Specified Terminal Services License Servers. Затем он по очереди связывается с каждым сервером лицензирования и собирает информацию о его конфигурации — состояние активации, информацию о ключевых пакетах лицензии (License Key Pack), соответствующие групповые политики и пр. Чтобы все это работало должны образом, необходимо запускать инструмент Licensing Diagnosis с учётными данными, имеющими администраторские полномочия на серверах лицензирования. При необходимости воспользуйтесь параметром Provide Credentials, чтобы во время исполнения программы задать подходящие учетные данные для каждого License Server в отдельности. Затем анализируются и сравниваются параметры лицензирования сервера терминалов — режим лицензирования, групповые политики и пр. Совместно с информацией о серверах лицензирования эти сведения используются для выявления типичных проблем с TS Licensing. В конце процесса инструмент выводит на экран диагностические сообщения и возможные шаги для устранения обнаруженных проблем.
    Чтобы глубже разобраться, как работает этот инструмент, рассмотрим несколько образцовых сценариев

    Сценарий 1. Общая диагностика


    Итак, сервер терминалов настроен, но его режим лицензирования остается в состоянии Not Yet Configured (еще не настроен). Никакие другие параметры лицензирования на сервере терминалов не настроены, и сервер License Server отсутствует. В такой ситуации TS разрешает клиентам подключения на протяжении 120-дневного ознакомительного периода.
    По истечению этого периода администратор обнаруживает; что клиенты более не в состоянии подключаться. Он запускает диагностический инструмент и обнаруживает два сообщения. Одно из них гласит, что TS необходимо перевести в режим лицензирования на пользователя (Per-User) или на устройство (Per-Device). Второе — что на сервере терминалов не обнаружены серверы лицензирования. Администратор с помощью TSConfig.msc выбирает режим лицензирования TS на устройство. (Если режим лицензирования TS задается при помощи групповой политики Set the Terminal Services Licensing Mode, вкладка Licensing в TSConfig.msc отключена.) Администратор домена задает сервер лицензирования. Если теперь перезапустить диагностический инструмент, он сообщит, что далее нужно активировать сервер лицензирования и установить на нем ключевые пакеты лицензии для выбранного режима. И так далее.

    Сценарий 2. Более сложные случаи


    В домене действует групповая политика Terminal Services License Server Security. Администратор не добавил имя TS-компьютера в локальную группу Terminal Server Computers (TSC) нa License Server. После запуска инструмента Licensing Diagnosis получено диагностическое сообщение о том, что данному Серверу терминалов лицензии не выдаются из-за заданных параметров групповой политики. Чтобы исправить это, используйте параметр Review Configuration консоли TS Licensing Manager для создания группы TSC. Добавьте TS в эту группу при помощи оснастки Local Users and Groups.
    Если имя License Server не включено в локальную группу Terminal Server License Servers контроллера домена Active Directory, в который входит TS, лицензирование на пользователя и Отчеты о нем работать не будут. Если вы в этих обстоятельствах запустите Licensing Diagnosis на сервере, терминалов, поле Per-User Reporting and Tracking в панели License Server Configuration Details укажет, что отслеживание лицензий на пользователя недоступно. Что бы исправить это, используйте параметр Review Configuration консоли TS Licensing Маnager для добавления имени компьютера License Server в группу Terminal Server License Servers.

    Сценарий 3. Диагностика обнаружения сервера лицензирования на TS


    При установке License Server администратор задал лес в качестве области обнаружения. Но поскольку он запустил установку, не обладая необходимыми полномочиями Active Directory, сервер License Server нe был опубликован как объект лицензирования Active Directory. Инструмент Licensing Diagnosis, запущенный на TS обнаружить License Server не может. В качестве начальной меры для диагностики проблем с обнаружением администратор может задать сервер лицензирования вручную, указав его в параметре Use the Specified License Servers консоли TSConfig.msc. После этого, перезапустив Licensing Diagnosis, администратор обнаруживает, что область обнаружения License Server отображается в разделе License Server Configuration Details, но не как лес, а как домен. Чтобы исправить это, воспользуйтесь параметром Review Configuration консоли TS Licensing Manager и параметром Change Scope.

    Сценарий 4. Диагностика несовпадения режимов лицензирования


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

    Прочие усовершенствования служб терминалов


    Теперь мы вкратце затронем еще три компонента служб терминалов WServer:
    • поставщик WMI для управления службами терминалов при помощи сценариев;
    • интеграцию Windows System Resource Manager со службами терминалов:
    • Terminal Services Session Broker

    Использование поставщика WMI служб терминалов


    Поставщик TS WMI (tscfgwmi) предоставит вам большой набор шаблонов классов, позволяющий настраивать сервер TS как удаленно, так и локально. Однако для его успешной работы необходимо несколько условий:
    1. По умолчанию читать и записывать свойства и методы WMI имеют право только пользователи из административных групп.
    2. При локальном применении поставщика TS WMI возможна проблема с контролем учетных записей (User Account Control, UAC). Запуск сценария или приложения, в которых применен TS WMI, требует повышения полномочий. Если вы получили сообщение «Access Denied (0x80041003), Unspecified Error (0x80004005)», скорее всего, проблема связана с тем, что полномочия не были должным образом повышены.
    При удаленном использовании поставщика TS WMI учетная запись должна принадлежать пользователю домена, включенному в группу локальных администраторов удаленного компьютера
    3. При удаленном использовании поставщика TS WMI задайте следующие исключения брандмауэра:
    а)File and Printer Sharing, Windows Management Instrumentation (WMI), если удаленный компьютер находится в режиме TS Remote Administration
    б)Terminal Services, если удаленный компьютер находится в режиме TS Application
    Об отсутствии нужных исключений брандмауэра говорят коды ошибок (HRESULT) WBEM_E_ACCESS_DENIED (0x80041003), RPC Server Is Unavailable (Win32 0x800706ba).
  • B Win2k3/XP поставщик TS WMI помещен в пространство имен root/cimv2. В WClient/WServer он помещен в пространство имен root/cimv2/TerminalServices. Кроме того, в WClient/WServer требуются уровень олицетворения WMI wbemImpersonationLevelImpersonate и уровень проверки подлинности vbemAuthenticationLevelPktPrivacy. Об использовании неверного пространства имен говорит код ошибки WBEM_ E_INVALID_NAMESPACE (0x8004100Е).
    Поставщик TS WMI также представляет собой уровень абстрагирования интерфейса Terminal Services Configuration (TSConfig.msc). По сути, TSConfig — это пользовательский интерфейс для TS WMI. Это, в частности, означаег, что TS WMI можно использовать Для диагностики Проблем при использовании TSConfig. Например, если вы при работе TSConfig получили сообщение «Unspecified error”, попробуйте задать параметры удаленного управления, написав небольшой сценарий TS WMI с использованием шаблона класса Win32_TSRemoteControlSetting. Если ошибка повторяется и после этого, она, скорее всего, связана с UAC.

    Windows System Resource Manager


    Дополнительный компонент Windows System Resource Manager (WSRM) применяется для управления выделением ресурсов процессора и памяти приложениям, службам и программам, работающим на компьютере. WSRM не относится к службам терминалов.
    В WSRM для управления распределением ресурсов компьютера используются политики выделения ресурсов. При установке WSRM на сервере терминалов вы можете выбрать одну из двух политик:
    Equal_Per_User Ресурсы процессора равным образом распределяются между всеми пользователями. Процессы, созданные данным пользователем в пределах его квоты потребляют столько ресурсов, сколько им необходимо.
    Equal_Per_Session Каждый пользовательский сеанс и связанные с ним процессы получают равную долю ресурсов процессора.
    Полезность политики Equal_Per_User в среде Terminal Services проявляется при наличии нескольких сеансов, запущенных одним и тем же пользователем. Допустим, у вас два сеанса одного пользователя и еще один сеанс другого пользователя. В этом случае первые два сеанса в сумме получат столько же ресурсов процессора, сколько и третий. А вот если вы используете политику Equal_Per_Session, первый пользователь получит в два раза больше ресурсов процессора, чем второй. Помните, что в Windows Server по умолчанию пользователям Terminal Services разрешен только один сеанс (Чтобы изменить это ограничение, воспользуйтесь главной страницей оснастки Terminal Services Configuration консоли Server Manager.)

    Посредник сеансов TS


    Для настройки фермы серверов терминалов нужно вначале службу ролей Посредник сеансов (TS Session Broker) установить на сервер, где планируется производить наблюдение за пользовательскими сеансами всей фермы. Затем в локальную группу Компьютеры каталогов сеансов (Session Directory Computers) на сервере посредника нужно добавить серверы терминалов. И наконец, серверы терминалов необходимо присоединить к ферме, настроив соответствующие опции на описываемой вкладке.
    На DC попытка установить Посредник приводит к необрабатываемым ошибкам.
    Во время работы в реальных средах помните, что на сервере посредника каждого члена фермы нужно добавить в локальную группу Компьютеры каталогов сеансов (Session Directory Computers).
    При распределении исходных подключений в ферме серверов для балансировки нагрузки посредника сеанса служб терминалов должно использоваться такое решение балансировки, как Round-Robin DNS, NLB, или аппаратное средство балансировки нагрузки. Broker включает в себя встроенную возможность балансировки нагрузки, призванную стать заменой для NLB. Однако при этом Session Broker сохранил способность работать как с NLB, так и с решениями сторонних разработчиков.
    Эта служба ролей расширяет возможности функциональности фермы серверов, позволяя клиентам вновь подключаться к отключенным сеансам. Доступен даже в WServer Standard. В каталоге сеансов (session directory) ведется список сеансов, индексированный по имени пользователя и по имени сервера терминалов. Благодаря ему пользователь, отключивший сеанс, может затем подключиться к тому же серверу терминалов, где остался отключенный сеанс, чтобы возобновить работу в нем. Больше того, переподключение сработает, даже если пользователь подключается к серверу не с того клиентского компьютера, на котором был инициирован сеанс.
    Для включения TS Session Broker используется оснастка Terminal Services Configuration. Щелкните дважды ссылку Member of Farm in TS Session Broker в нижней части области сведений, чтобы открыть окно Properties. На вкладке TS Session Broker установите флажок Join a Farm in TS Session Broker (Присоединиться к ферме в посреднике сеансов служб терминалов) и введите необходимые сведения (это нужно сделать на всех серверах терминалов фермы).
    Имя фермы в посреднике сеансов служб терминалов (Farm Name In TS Session Broker). В данное текстовое поле следует ввести имя фермы, которое будет совместно использоваться всеми ее серверами. Это DNS-имя будет использоваться клиентами для подключения к ферме серверов терминалов. (На соответствующем DNS-сервере нужно добавить множество записей DNS, отвечающих имени фермы, которые будут определять IP-адреса каждого члена фермы.)
    Участвовать в балансировке нагрузки посредника (Participate In Session Broker Load-Balancing) Установите этот флажок, чтобы отконфигурировать участие локального сервера в балансировке нагрузки, включенной посредником сеансов служб терминалов.
    Относительный вес этого сервера в ферме (Relative Weight Of This Server In The Farm) Данный параметр используется для назначения мощным серверам большего количества пользовательских сеансов и снижения таким образом нагрузки на менее мощные серверы. Например, если вы назначите мощному серверу вес 200, а более слабому — вес 100, то первый сервер будет принимать в два раза больше сеансов, чем второй.
    Использовать перенаправление IP-адресов (Use IP Address Redirection (Recommended)) Посредник сеансов может использовать два метода перенаправления клиента к отключенному сеансу: перенаправление IP-адреса и перенаправление маркера маршрутизации. Перенаправление IP-адреса включено по умолчанию и применяется в большинстве сценариев. Данный метод перенаправления работает в том случае, если клиенты могут непосредственно подключаться к каждому серверу терминалов в ферме. Этот флажок можно сбросить лишь в том случае, если клиенты служб терминалов не могут напрямую подключаться ко всем серверам терминалов в ферме, а в конфигурации балансировки сетевой нагрузки поддерживаются маркеры маршрутизации посредника сеансов служб терминалов.
    Выберите IP-адреса для переподключения (Select IP Addresses То Be Used For Reconnection) Здесь можно указать IP-адрес, который будет использоваться в ферме серверов терминалов.
    Если в вашу сеть включен компонент для балансировки нагрузки (обычно аппаратный), поддерживающий маркеры маршрутизации, отключите перенаправление IP-адресов.
    Session Broker Load Balancing простое в развертывании решение для балансировки нагрузки в небольших компаниях. Создайте запись DNS для фермы, содержащую IP-адреса серверов терминалов фермы. DNS (или циклический DNS) направит начальное подключение одному из серверов фермы, однако затем Session Broker перенаправит его на наименее загруженный сервер (опираясь на количество сеансов). Клиент TS обеспечивает базовый уровень отказоустойчивости для первоначального подключения. В случае сбоя на сервере он через 20 секунд автоматически попробует подключиться к следующему элементу записи DNS. Session Broker способен детектировать сбои на серверах и не направляет пользователей на неисправные серверы. Вместо DNS можно использовать NLB или другой механизм перенаправления подключений.

    RemoteApp


    Компонент RemoteApp, позволяющий пользователям запускать на сервере терминалов отдельные программы Windows. Консоль TS RemoteApp Manager позволяет выбрать программы, которые пользователи смогут удаленно запускать на своих рабочих столах. Как теперь разрешить пользователю ее запускать? Для этого необходимо развернуть пакет с информацией RemoteApp. Этот пакет можно создать в двух видах: как файл установки Windows или как файл .RDP. Нам, как администраторам, привычнее разворачивать пакеты Windows Installer на клиентских компьютерах при помощи групповой политики. По умолчанию пакет Windows Installer и у него будет расширение .rdp.msi.
    На клиенте файлы .rdp можно найти в C:\Users\\AppData\Roaming\Microsoft\Workspaces\\Resource.
    Как же отличить локальную программу от программы RemoteApp? Откройте окно Task Manager — в нем вы увидите две работающие копии Paint . Удаленная версия Paint четко выделена. Щелкните ее ПКМ и выберите команду Go To Procces. Откроется вкладка Process, и мы убедимся, за работу этой копии Paint реально отвечает процесс mstsc.exe (то есть, RDC). Можно запустить и несколько экземпляров Paint. Если пользователь запускает более одного приложения RemoteApp, каждое такое приложение использует существующий сеанс терминального сервера.
    Допустим для начала, что у вас есть несколько программ, которые должны работать вместе. Например, в них используется внедрение или связывание посредством DDE. Такие программы RemoteApp удобно запускать на одном и том же сервере терминалов, а не распределять их по разным серверам. A вот если у вас есть приложения, испытывающие проблемы с совместимостью, их лучше разместить на разных серверах терминалов.
    RDP-файл привязывается к уникальному имени приложения, которое присваивается автоматически.
    В службе удаленных рабочих столов WServer средство RemoteApp было расширено добавлением возможности группировать и персонализировать программы RemoteApp, рабочие столы на основе сеансов и виртуальные рабочие столы с обеспечением доступа к ним для пользователей из меню Пуск в WClient и WServer. В результате это расширенное средство RemoteApp было переименовано в RemoteApp and Desktop Connection (Подключение к удаленным рабочим столам и приложениям RemoteApp). Для развертывания средства RemoteApp and Desktop Connection администратор сначала должен развернуть и сконфигурировать службы ролей RD Connection
    Broker и RD Web Access. Затем, как только программы RemoteApp определены в источнике, администраторы могут использовать инструмент Remote Desktop Connection Manager
    для конфигурирования виртуальных рабочих столов или определения, какие источники RemoteApp будут использованы для RemoteApp and Desktop Connection.
    После конфигурирования и развертывания администраторами пользователи машин WClient или WServer могут запускать программы RemoteApp, открывать рабочие столы на базе сеансов и виртуальные рабочие столы, которые были определены как часть RemoteApp and Desktop Connection. Элементы для подключения пользователь может найти в меню Start. По мере внесения изменений в RemoteApp and Desktop Connection, таких как добавление или удаление программ RemoteApp, эти изменения автоматически отображаются в меню Start. Вдобавок пользователи могут применять значок области уведомлений RemoteApp and Desktop Connection в панели задач для выполнения
    следующих операций:
    • просмотр состояния соединения RemoteApp and Desktop Connection;
    • управление состоянием подключения (отключения) для RemoteApp and Desktop Connection в случае необходимости.
    Фильтрация RemoteApp уровня пользователя.
    Используя это средство, администратор может теперь фильтровать список программ RemoteApp, доступных пользователю при регистрации на RD Web Access. До появления
    этого средства каждый пользователь получал список программ RemoteApp независимо от того, имеет ли он права на их запуск.

    Освобождение от нагрузки


    Вспомним о непрерывном потоке обновлений и исправлений, с которым сталкиваются современные администраторы. Начиная с версии WServer, новый компонент Server plaining позволяет планировать обслуживание ферм серверов терминалов с балансировкой нагрузки так, чтобы оно не прерывало работу пользователей. В этом сценарии необходимо временно запретить вход на сервер новых пользователей в то же время, сохранив для уже зарегистрировавшихся и работающих пользователей возможность сохранить результаты работы и выйти из системы в штатом режиме.
    В WServer введена процедура освобождения сервера (server draining). Ее можно выполнить из командной строки (с помощью новых параметров chglogon.exe), из окна Terminal Services Configuration, а также средствами WMI. Когда сервер переведен в режим освобождения, новые регистрации не разрешены, но пользователям разрешается повторное подключение к отключенным сеансам. Кроме того, для осуществления удаленного администрирования администраторам разрешается вход с параметром /admin, даже если включён режим освобождения. Этот режим поддерживается только при установленной роли TS.
    Прежде чем провести обслуживание сервера, администратор сможет перевести его в режим освобождения, а затем разослать пользователям сообщение с предложением сохранить результаты и в следующие день-два завершить работу!
    Когда пользователю отказано в регистрации из-за включенного режима освобождения, в журнале событий Windows регистрируется соответствующая запись.

    Кластеризация


    Диски


    Потребуется следующее:
    Кроме диска с установленной ОС Server2 должен быть оснащен одним или двумя дополнительными жесткими дисками. Оба дополнительных диска должны иметь емкость, равную емкости диска с операционной системой или большую.

    Архивация


    При перегрузке энергосистем может возникать отключение питания. Происходит оно тогда, когда компания по энергоснабжению из-за перегрузки или аварии в своих системах отключает подачу электроэнергии для определенных абонентов или областей обслуживания, чтобы сохранить ее для критически важных служб, вроде пожарных депо, полицейских участков, больниц и светофоров. Веерным (rolling blackouts) его называют потому, что по истечении определенного количества времени компания по электроснабжению отключает подачу энергии в другой электроэнергетической сети и восстанавливает подачу в той, что была отключена ранее.
    Отказы оборудования для каждого из этих отказов может предусматриваться свое решение, но для обеспечения избыточности на уровне системы или сервера ключевые службы должны быть развернуты на избыточном кластере, построенном с помощью компонента Enterprise Edition Failover Clustering или NLB.
    Отказы жестких дисков поистине являются наиболее распространенным типом проблем с оборудованием, возникающих в компьютерах и сетях, с которым организациям приходится иметь дело. WServer поддерживает жесткие диски, допускающие возможность замены во время работы, а также диски 2 следующих типов: базовые диски, обеспечивающие обратную совместимость, и динамические диски, позволяющие конфигурировать программные дисковые массивы без специального аппаратного контроллера дискового массива. Кроме того, в случае использования в качестве дисков данных как базовые, так и динамические диски могут легко переноситься на другие серверы для предоставления данных или дисковой емкости в случае отказа системного оборудования и необходимости как можно быстрее сделать хранящиеся на этих дисках данные доступными. В WServer также имеются средства для создания, подключения и конфигурирования хранилищ, размещаемых в SAN, а также позволяющие легко монтировать файлы VHD как диски операционной системы с использованием диспетчера Disk Manager или утилиты diskpart.
    При настройке работающего на аппаратном уровне диска RAID конфигурационные данные дискового массива сохраняются на карте контроллера. Поэтому для получения необходимых средств либо документации по резервному копированию, восстановлению или воссозданию этой конфигурации вручную в случае отказа контроллера или при необходимости в переносе этого диска на другую машину с контроллером точно такого же типа, нужно связываться с производителем.
    Если необходимы возможность сохранять резервные копии на ленточных носителях и упростить управление внутренними и внешними носителями, рекомендуется использовать программу Microsoft System Center Data Protection Manager (Диспетчер защиты данных центра систем Microsoft) или какие-то сторонние приложения для архивации.
    WServer по умолчанию позволяют выполнять операции резервного копирования и восстановления всем пользователям в группе локальных администраторов и группе операторов архивации. На контроллерах домена члены доменных групп безопасности имеют точно такие же права на контроллерах домена Active Directory в соответствующем домене (или доменах).

    DAS


    DAS — это система хранения данных, подключенная только к одному серверу. В качестве примера DAS можно привести группу внутренних жестких дисков сервера или смонтированную в стойке матрицу независимых дисковых накопителей с избыточностью (RAID), подключенную к серверу посредством SCSI или FC-контроллера. Основная особенность DAS заключается в том, что система предусматривает единственный сервер с быстрым доступом к данным на блочном уровне непосредственно через внутреннюю или внешнюю шину (доступна на блочном уровне, в противоположность доступу на файловом уровне, означает, что данные перемещены в неформатированные блоки, а не в отформатированные файлы). DAS будет возможным решением проблемы хранения данных для серверов с высокой производительностью и не требующих значительных объемов памяти для хранения данных. Например, DAS часто применяется для серверов с инфраструктурой DNS, WINS и DHCP, Файл-серверы и веб-серверы.
    Основное ограничение системы DAS заключается в том, что прямой доступ к данным возможен только с единственного сервера, что приводит к неэффективному управлению системой хранения. Например, на рис. 2-1 изображена локальная сеть, в которой вся система хранения данных непосредственно подключена к серверам. Несмотря на то что серверы Web и Арр2 имеют систему хранения с избыточностью, эти ресурсы не могут быть простым способом перенесены на серверы Mail или на App1, для которых требуется большая емкость хранилища.
    Основной инструмент, используемый для управления DAS в операционной системе Windows, — оснастка Управление дисками (Disk Management console). Это средство, доступное из консоли Диспетчер серверов, позволяет разбивать диски и форматировать наборы томов. Для выполнения таких же и других дополнительных функций вы можете использовать утилиту Diskpart.exe, работающую в режиме командной строки.

    NAS


    Это удобный корпус для установки жестких дисков, обладающий сетевым портом, процессором и различными дополнительными интерфейсами. NAS позволяет организовать не только банальное хранилище файлов, но и автономный загрузчик торрентов, принт- и веб-сервер, почтовый сервер, систему видеонаблюдения на базе IP-камер и много другое. Раз уж в NAS устанавливаются по несколько жестких дисков, то глупо было бы не организовать из них дисковый массив по технологии RAID.
    Недостаток NAS (Network Attached Storage) заключается в том, что из-за подключения серверов и клиентов к устройству NAS по локальной сети, а не посредством локальной шины, доступ к данным осуществляется медленнее и происходит на файловом уровне, а не на блочном. Поэтому система NAS практически всегда работает медленнее системы DAS.

    SAN


    Сеть хранения данных (Storage Area Network, SAN) — это высокопроизводительная сеть, выделенная для передачи блочных данных между серверами и подсистемами хранения данных. С точки зрения операционных систем, SAN фигурирует как установленная локально сеть. Наиболее важное отличие SAN от DAS заключается в том, что подключенное в SAN устройство хранения является доступным не только одному, а любому из серверов (в SAN устройство хранения может быть перемещено с одного сервера на другой, но за пределами конфигурации кластеризованной файловой системы не может быть одновременно доступно более чем для одного сервера). Несмотря на не на много большую скорость шины DAS, сети SAN, тем не менее, считаются предпочтительными, так как их преимущество заключается в обеспечении одновременного общего доступа серверов к хранилищу данных.
    Сеть SAN состоит из специальных устройств, таких как адаптеры главной шины (Host Bus Adapters, НВА) на хост-серверах, коммутаторы, помогающие распределять трафик системы хранения, дисковые подсистемы хранения данных и библиотеки типов. Такие аппаратные устройства, соединяющие серверы и системы хранения данных в сети SAN, называются фабриками SAN. Все эти устройства связываются по волоконно-оптическому или медному кабелю. После первого подключения к фабрике общедоступный дисковый массив разбивается на виртуальные разделы, называемые логическими номерами устройств ( Logical Unit Numbers, LUN), которые впоследствии становятся локальными дисками для серверов.
    Параллельная архитектура шины SCSI накладывает следующие ограничения на систему DAS: 16 устройств (включая контроллер) на расстоянии не более 25 м. Технология волоконно-оптического канала для SAN позволяет увеличить расстояние до более чем 10 км и обеспечивает подключение к сети фактически неограниченного числа серверов.
    Сети SAN являются хорошим решением для серверов, где необходим быстрый доступ к очень большому массиву данных (особенно данных на уровне блоков). Такими серверами могут быть серверы электронной почты, серверы резервного копирования, потоковые мультимедийные серверы и серверы баз данных. Использование сетей SAN также предусматривает эффективное дублирование удаленных на большое расстояние данных, что является решением проблемы их аварийного восстановления после отказа системы. На рис. 2-3 показана простая сеть SAN.
    Обычно сети SAN встречаются в двух модификациях: FC и iSCSI .
    1. Сети SAN на базе технологии FC (Fibre Channel ) волоконно-оптический канал обеспечивает высокоскоростную передачу блочного ввода-вывода (Input/Output, I/O) на устройства хранения данных. Основанная на последовательной архитектуре SCSI, технология соединения FC является наиболее широко применяемой для сетей SAN. В отличие от устройств с параллельной архитектурой SCSI, FC-устройства не требуют вынесения на общую шину. Вместо этого в технологии FC используются специальные коммутаторы для одновременной передачи информации между множеством серверов и устройствами хранения данных.
    Основным преимуществом FC является то, что данная технология получила широкую реализацию в сетях SAN и, по крайней мере до недавнего времени, обеспечила наилучшую производительность. В числе недостатков технологии FC — высокие затраты на оборудование и сложная настройка. Компонентами сети на основе волоконно-оптического канала являются: HBAs, кабельная система и коммутаторы. Все эти составляющие, разработанные ведущими поставщиками специально для технологии FC, не всегда совместимы, относительно дороги, и для их установки требуются специальные знания.
    2. Internet SCSI (iSCSI) является промышленным стандартом, разработанным для обеспечения передачи блоков команд SCSI по сети Ethernet с использованием протокола TCP/IP. Сетевое соединение серверов с устройствами iSCSI осуществляется посредством локально установленной исполнительной программы, которая известна как инициатор iSCSI (iSCSI Initiator). Инициатор iSCSI выполняет запросы и получает ответы от исполнителя iSCSI (iSCSI Target), который сам по себе может быть конечным узловым устройством сети хранения или устройством-посредником, таким как коммутатор. Для фабрик iSCSI сеть также включает один или несколько серверов Службы имен устройств хранения (Internet Storage Name Service, iSNS), которые подобно серверам DNS в локальной сети обеспечивают открытость и разбивку на зоны ресурсов SAN. Основанные на протоколе TCP/IP, сети SAN на базе технологии iSCSI используют преимущества сетевых устройств, которые являются широко доступными и знакомыми пользователям, что в большинстве случаев делает сети SAN на базе технологии iSCSI более простыми и менее дорогими в реализации, чем сети SAN с использованием технологии FC. Кроме сравнительно низкой стоимости и удобства исполнения существуют другие преимущества технологии iSCSI. Возможность соединения на больших расстояниях. Организациям, рассредоточенным на больших территориях, может понадобиться последовательное соединение удаленных «островов SAN», чего нельзя обеспечить из-за существующего ограничения связи в пределах 10-километровой зоны для технологии FC. (Существуют новые средства расширения зоны установления связи для сетей на базе технологии FC до нескольких сотен километров, однако эти методы являются сложными и дорогими.) В отличие от FC, протокол iSCSI позволяет устанавливать соединение между удаленными офисами в SAN с использованием не только общегородских сетей (Metropolitan Area Networks, MANs), но и территориально распределенных сетей(Wide-Area Networks, WANs).
    Встроенная функция безопасности. Протокол волоконно-оптического канала передачи данных не предусматривает никаких встроенных методовобеспечения безопасности. Вместо этого функция безопасности реализована в первую очередь посредством ограниченного физического доступа в сети SAN. В противоположность технологии FC, введение в эксплуатацию протокола iSCSI корпорацией Microsoft обеспечивает безопасность для устройств, подключенных к сети, с использованием Протокола аутентификации по квитированию вызова (Challenge Handshake Authentication Protocol, CHAP) для аутентификации и Межсетевого IPSec для кодирования данных. Поскольку указанныевыше методы обеспечения безопасности сетевых соединений уже существуют в сетях Windows, они могут быть полностью распространены с локальных сетей на сети SAN.
    Технология iSCSI SAN может использовать специализированные устройства для фабрики или работать на основе уже существующей в организациях инфраструктуры сетей LAN, MAN или WAN. Для обеспечения безопасности ипроизводительности на базе протокола iSCSI рекомендуется отделить сетевой трафик от трафика хранилища.
    Основным недостатком сетей SAN на базе технологии iSCSI, за исключением того, что они используют специализированные (а также дорогие) 10-гигабайтовые кабели и коммутаторы сети Ethernet, является меньшая скорость обмена I/O по сравнению с той, которую может обеспечить SAN на базе технологии FC. Но если вы действительно предпочли использование 10-гигабайтового оборудования для ваших сетей SAN на базе технологии iSCSI использованию расширенного стандарта Gigabit Ethernet, высокая стоимость такого решения нивелирует преимущество невысоких затрат на организацию сети, предлагаемых технологией iSCSI относительно технологии FC.
    Управление сетями SAN. Операционная система WServer содержит службу виртуальных дисков ( Virtual Disk Service, VDS), представляющую собой интерфейс для программирования приложений (Application Programming Interface, API). Это дает возможность поставщикам аппаратных средств для сетей SAN на базе технологий FC и iSCSI предоставлять дисковые подсистемы и техническое оснащение для сетей SAN, доступное средствам администрирования в операционной системе Windows. Если аппаратные средства поставщика включают аппаратные провайдеры VDS, вы можете управлять аппаратными средствами в операционной системе WServer, используя такие инструменты, как оснастка Управление дисками, Диспетчер хранилища для сетей SAN (Storage Manager for SANs, SMfS), Обозреватель хранилищ (Storage Explorer), Инициатор iSCSI (iSCSI Initiator), приложение DiskRAID.exe, работающее в режиме командной строки.
    1. SMfS Операционная система WServer содержит средство SMfS, которое можно добавить с помощью мастера добавления компонентов (Add Features Wizard). Вы можете использовать SMfS для управления сетями SAN, резервируя диски, создавая локальные сети LAN и назначая сети LAN различным серверам сети SAN.
    2. Обозреватель хранилищ доступен по умолчанию в группе программ Администрирование. Вы можете использовать Обозреватель хранилищ для отображения детализированной информации о серверах, подключенных к сети SAN, а также о компонентах фабрик, таких как НВА, FC-коммутаторы, инициаторы и исполнители iSCSI. Для выполнения административных задач на фабрике iSCSI вы также можете использовать Обозреватель хранилищ.
  • Инициатор iSCSI доступен по умолчанию в WServer в группе программ Администрирование. Это средство дает вам возможность настроить безопасность, обнаружение и другие функциональные возможности локальных соединений серверов с исполнителями iSCSI.
  • DiskRAID является приложением, работающим в режиме командной строки, которое позволяет вам управлять сетями LAN в аппаратных средствах RAID с поддержкой VDS.

    Управление дисками, томами и разделами в WServer


    Основной инструмент, который вы можете использовать для управления дисками, томами и разделами в WServer, — оснастка Управление дисками. С ее помощью вы можете инициализировать диски, переносить их в режиме онлайн и в автономном, создавать тома на дисках, изменять стили разделов дисков. Чтобы открыть окно оснастки, нужно ввести команду Diskmgmt.exe, в консоли Диспетчер серверов выбрать под узлом Запоминающие устройства (Storage) элемент Управление дисками или выбрать узел Управление дисками в консоли Управление компьютером (данная консоль доступна из папки Администрирование).
    Стили разделов (MBR и GPT) относятся к наиболее простой структуре дисков, распознаваемой операционной системой. Стили разделов не имеют отношения к форматам файлов NTFS или FAT32 в разделах. Базовые и динамические диски могут иметь любой из перечисленных стилей разделов.
    Динамические диски обеспечивают расширенные возможности, не поддерживаемые базовыми дисками; к ним относятся: возможность создания неограниченного числа томов, томов, охватывающих несколько дисков (составные тома и тома с чередованием) и отказоустойчивых томов (зеркальные тома и тома уровня RAID-5). Существует 5 типов динамических томов: простые, составные, чередующиеся, зеркальные и тома уровня RAID-5.
    Несмотря на это усовершенствование, для конфигураций с загрузкой одной из двух операционных систем все еще важно знать, что многие ранние версии операционной системы Windows (в том числе Windows NT, 98, ME) не поддерживают динамические диски. Динамические диски совместимы только с операционными системами семейства Windows.
    Концепция системы хранения информации была пересмотрена,
    чтобы сервер мог работать с большими объемами данных, размещенных на нескольких сотнях виртуальных дисков. Теперь она
    включает storage pools, то есть массивы дисков, которые могут быть использованы для хранения VDI, и storage spaces — инструменты для настройки производительности и отказоустойчивости.
    Новые диски добавляются в пул по мере необходимости и автоматически подхватываются системой хранения данных как единый storage pool. И главное, нет необходимости покупать софт сторонних разработчиков для SATA - и SAS-дисков. Функция дедупликации позволяет экономить объем за счет исключения избыточных данных в дисковом хранилище.
    CheckDisk запускается в онлайн-режиме и проверяет только проблемный раздел. Сам процесс занимает всего несколько секунд.

    Создание томов


    Оснастку Управление дисками и служебную программу в режиме командной строки Diskpart можно использовать для создания следующих типов томов в WServer:
  • Простые, или базовые, тома - это базовые диски, которые не являются отказоустойчивыми. Простой том может состоять из одной области на диске или нескольких объединенных вместе областей. Простые диски практически ничем не отличаются от обычных разделов, за исключением того, при переразбиении диска отпадает необходимость в перезагрузке. Опорный тип для всех остальных динамических дисков.
    избыточность: нет.
    эффективность: низкая
    Для создания простого тома с помощью оснастки Управление дисками ПКМ в области нераспределенного пространства диска, а затем щелкните Создать простой том. (Эта операция аналогична при создании тома и на базовом, и на динамическом диске, даже при создании тома на базовом диске новый том технически называется разделом или базовым томом.) Возможно, сначала вам нужно щелкнуть ПКМ на диске и сделать раздел активным (Online).
    Для создания простого тома с помощью утилиты Diskpart выберите диск, используя эту программу, а затем для динамического диска введите команду create volume simple . Для создания нового тома (раздела) на базовом диске введите команду create partition. Если вы хотели бы получить дополнительную информацию относительно синтаксиса данных команд, введите create volume? или create partition?.
    2. Составной том (spanned - классический линейный RAID) — это динамический том, состоящий из дискового пространства более чем одного физического диска. Если простой том не является системным или загрузочным, вы можете расширить его за счет присоединения дискового пространства других дисков, получив в результате составной том, или создать новый составной том, используя нераспределенное пространство более чем одного диска. Состоит из одного или нескольких simple-дисков, находящихся в различных разделах или даже устройствах, представленный как один логический диск. Данные на simple-диски пишутся последовательно.
    Для создания нового в оснастке Управление дисками ПКМ в области нераспределенного пространства одного из дисков — того, на котором вы хотите создать составной том, а затем щелкните Создать составной том. В результате будет запущен Мастер создания составных томов, с помощью которого к составному тому можно добавить свободное пространство из доступных дисков.
    избыточность: нет
    эффективность: низкая
  • Чередующийся том (RAID 0), представляет собой динамический том, в котором данные разбиваются на полосы и хранятся на двух или большем количестве физических дисков. На рис. 2-8 показано, каким образом данные чередующегося тома записаны в набор дисков. Уровень RAID 0 используется только для повышения производительности. Он объединяет два или более накопителей одинаковых размеров, но, вместо их объединения последовательно один за другим, он распределяет данные между дисками, входящими в пул. Операции последовательного чтения и записи в этом случае оказываются распределенными между несколькими дисками, что снижает время записи и доступа к диску.
    Обратите внимание на то, что надежность уровня 0 ниже, чем надежность отдельных дисков. Вероятность отказа массива из двух дисков в течение года примерно в два раза выше, чем у отдельного диска, и т.д.
    Чередующиеся тоже самое, что и составной, но данные записываются параллельно на все simple-диски при условии, что они расположены на различных каналах IDE-контроллера. Это значительно увеличивает скорость обмена данными.
    избыточность: нет
    эффективность: средняя
    Чередующийся том является лучшим решением проблемы хранения временных данных, для которых не требуется отказоустойчивость, по необходима высокая производительность. Примерами таких временных данных являются файлы подкачки и папки каталога Temp. Для создания нового чередующегося тома ПКМ в области нераспределенного пространства на диске, а затем щелкните New Striped Volume.
    Для создания чередующегося тома, как и для всех решений RAID, используются диски одинакового объема.
    4. Зеркальный том (RAID 1) является отказоустойчивым томом, который обеспечивает избыточность данных путем использования двух копий, или зеркал, одного и того же тома. Все данные, отображенные в зеркальном томе, записаны в двух томах, расположенных на отдельных физических дисках. В случае отказа одного из физических дисков его данные становятся недоступными, но система продолжает функционировать, используя неповрежденный диск.
    Хотя зеркальные тома, настроенные в WServer, предполагают использование двух дисков, существует возможность создать зеркала на трех и более дисках. В конфигурации с тремя зеркалами, например, содержимое одного диска дублируется на два дополнительных диска. Множественные зеркала снижают производительность при выполнении записи, однако повышают отказоустойчивость.
    Записи дублируются одновременно на нескольких дисках. Эта схема замедляет процесс записи по сравнению с записью данных на отдельный диск. Однако она обеспечивает скорость считывания, сравнимую с уровнем RAID 0, потому что чтение можно распределять между несколькими дублирующими накопителями.
    Зеркальные - 2 simple-диска, расположенные на разных устройствах. Данные дублируются на оба носителя.
    избыточность: средняя
    эффективность: средняя
    Зеркальные тома, будучи отказоустойчивыми, имеют преимущества и недостатки. Одним из преимуществ зеркального тома является обеспечение очень высокой производительности при чтении данных, равно как и довольно высокой производительности при записи данных. Кроме того, для создания зеркальных томов достаточно наличия только двух дисков, и практически любой том, включая системные и загрузочные тома, может быть зеркалирован. Для создания зеркального тома можно добавить зеркало к существующему тому или создать новый зеркальный том. Для добавления зеркала к существующему тому в оснастке Управление дисками ПКМ нужный том (например, системный), а затем щелкните Добавить зеркало (Add Mirror ).
    Для создания нового зеркального тома в оснастке Управление дисками ПКМ в области нераспределенного пространства диска, а затем щелкните Создать зеркальный том (New Mirrored Volume). Новый зеркальный том изображен на рис. 2-12. Обратите внимание на то, каким образом диск использует 5,86 Гбайт пространства обоих дисков, Disk 1 и Disk 2, являясь при этом единственным томом Е с емкостью 5,86 Гбайт.
    5. RAID-5 — это отказоустойчивый том, объединяющий области свободного пространства минимум 3 физических жестких дисков в один логический том. Тома RAID-5 предполагают чередование данных с информацией о контрольной сумме (четности или нечетности) и равномерно распределены по всем дискам набора. При отказе одного из дисков WServer использует информацию о четности для восстановления данных вышедшего из строя диска. Тома RAID-5 допускают потерю данных только на одном диске из набора.
    Чередующиеся с контролем четности (stripped with party) (RAID 5) состоит из 3, или более дисков. Представляет из себя stripped volume с контролём ошибок. Данные пишутся на 2 диска, в два блока, а на третий диск, и в третий блок записывается ECC, код коррекции ошибок, с помощью которого, по информации любого из блоков можно восстановить содержимое 2 блока.
    избыточность: высокая
    эффективность: высокая
    На рис. 2-13 показан том RA1D-5, состоящий из четырех дисков. Данные, записанные в этот том, равномерно распределены в виде полос на всех дисках слева направо. Для каждой полосы данных из дискового набора одни диск используется для хранения контрольной информации о четности или нечетности для остальных данных полосы. В упрощенном примере, показанном на рис. 2-13, контрольной сумме присваивается значение 1, если сумма значений в полосе нечетная, и 0 — если сумма оставшихся значений четная. В случае отказа какого-либо одного (и только одного) диска операционная система Windows может восстановить все содержимое вышедшего из строя диска, используя информацию о четности вместе с оставшимися данными. Данные вышедшего из строя диска могут быть воссозданы в реальном времени по требованию пользователей. Информация о четности также может быть восстановлена на новом диске после замены отказавшего диска.
    Объем пространства, приблизительно эквивалентный размеру одного диска, всегда используется для обеспечения отказоустойчивости в томе RA1D-5. Например, если вы создадите том RAID-5 из четырех дисков размером 120 Гбайт каждый, то общая емкость доступного хранилища в этом томе составит 360 Гбайт.
    RAID-5 характеризуется очень высокой производительностью при выполнении операций чтения, относительно низкой производительностью при выполнении операций записи и оптимальным использованием пространства хранения для обеспечения отказоустойчивости данных. Заметьте также, что системному или загрузочному разделу нельзя назначить том RAID-5, созданный в операционной системе WServer.
    ПРИМЕЧАНИЕ Программная и аппаратная реализация RAID
    Том RAID-5, созданный с помощью оснастки Управление дисками, является примером программного RAID, так как он создан операционной системой. Несмотря на это, некоторые поставщики продают дисковые модули, включающие собственные встроенные программы установки RAID. Если вы настраиваете RAID-5 с собственным программным обеспечением, операционная система WServer видит запоминающее устройство как единичный локальный том. Подобная конфигурация RAID, которая является прозрачной для операционной системы, известна как аппаратная RAID. Хотя программная реализация RAID обеспечивает более низкую производительность, чем аппаратная, программная RAID является недорогой и легкой в настройке, так как, кроме необходимости наличия нескольких дисков, отсутствуют специальные требования к аппаратным средствам. Если фактор стоимости является более важным, чем производительность, программная RAID будет подходящим решением.
    Для создания тома RAID-5 в оснастке Disk Management ПКМ в области нераспределенного пространства одного из динамических дисков — того, на котором вы хотите создать том RAID-5, а затем щелкните Создать том RAID-5 (New RAID-5 Volume). После этого следуйте инструкциям мастера создания томов RAID-5. Для создания тома RAID-5 с помощью программы Diskpart воспользуйтесь командой create volume raid. Чтобы получить дополнительную информацию относительно синтаксиса данной команды, введите help create volume raid.
    RAID 5 распределяет и данные, и информацию о четности, добавляя избыточность и одновременно повышая производительность чтения. Кроме того, уровень RAID 5 более эффективно использует дисковое пространство, чем уровень RAID 1. Если массив состоит из N накопителей (требуется не менее трех), то N—1 из них могут хранить данные. Следовательно, эффективность использования дисковой памяти на уровне RAID 5 превышает 67%, в то время как зеркальное отражение не может превысить 50%.
    Требует как минимум 3 дисков. Обычно используется пять HDD, при этом 1/5 объема массива занимают коды коррекции ошибок, за счет которых RAID выдерживает отказ любого из дисков матрицы. Хорошие контроллеры поддерживают режим гибридизации, позволяющий совмещать RAID 0 с RAID 1, в результате чего мы… кхм, удваиваем (в теории!) производительность и отказоустойчивость ценой 50% избыточности. На самом деле отказоустойчивость приближается к 75%, поскольку при вылете двух зеркальных дисков мы сохраняем 100%, но вот если выйдет из строя один зеркальный и парный ему диск, мы получаем ту же ситуацию, что и с RAID 0, описанную выше.
    RAID 6 аналогичен уровню RAID 5 с двумя дисками четности. Массив RAID 6 может сохранить работоспособность при полном отказе двух накопителей без потери данных.
    RAID 0+1 и RAID 1+0. RAID 0+1 (или 01) является зеркалом сегментов чередования, преимущественно двойной копией чередующегося тома. Этот тип RAID построен путем создания массивов RAID 0 с последующим их зеркалированием. RAID 1+0 (или 10), наоборот, представляет собой чередование зеркал, в котором данные чередуются в нескольких зеркальных наборах. Для конструирования данного типа RAID сначала необходимо создать набор зеркальных массивов, а затем построить массив RAID 0 из этого набора.
    В вышеописанных технологиях 50 % дискового пространства отводится для обеспечения отказоустойчивости, и в обоих случаях достигается отличная производительность операций чтения и записи. RAID 1 + 0 однако, обеспечивает наибольшую вероятность восстановления данных в случае отказа более чем одного диска.
    Заметьте также, что условные обозначения двух указанных уровней RAID не являются утвердившимися. Некоторые компании (включая Microsoft) могут обобщенно называть обе технологии RAID 01 и 10 одним термином 0+1. Если вам нужно разъяснить ваши требования к поставщикам, лучше употребить термины зеркало сегментов чередования или чередование зеркал.
    Уровни RAID 1+0 и 0+1 представляют собой группы зеркал или зеркала групп. С логической точки зрения они представляют собой сочетание уровней RAID 0 и RAID 1, но многие контроллеры и программы обеспечивают их непосредственную поддержку. Цель обоих режимов — одновременно достичь производительности уровня RAID 0 и избыточности уровня RAID 1.
    Зеркальный с чередованием (mirrored striped) соответствует массиву RAID 1+0.
    избыточность: средняя
    эффективность: высокая

    Расширение тома


    Емкость существующих простых и составных томов можно увеличить, расширяя их на нераспределенное пространство того же или другого диска. Том можно расширить лишь при условии, что он отформатирован под файловую систему NTFS либо вообще неформатированный. Для расширения тома в оснастке Управление дисками щелкните ПКМ том, который вы хотите расширить — простой или составной, а затем щелкните Расширить том (Extend Volume).
    Вы не можете расширить загрузочный или системный том на другой диск.

    Сжатие тома


    Вы можете уменьшить пространство, используемое простыми или составными томами, посредством их сжатия на смежное свободное пространство в конце тома. Например, если вам необходимо увеличить размер нераспределенного пространства на диске для освобождения места под новый раздел или том, можно попытаться сжать существующие тома на диске. Когда вы сжимаете раздел, все обычные файлы автоматически перемещаются на диске для создания нового нераспределенного пространства. Нет необходимости переформатировать диск для сжатия раздела.
    Размер пространства, получаемого сжатием тома, может значительно варьироваться. В общем случае, чем больше процент неиспользованного пространства тома и чем меньше неисправных кластеров, тем больше вы сможете сжать том. Тем не менее, если количество неисправных кластеров, выявленных динамическим переназначением плохих кластеров, слишком велико, то вы вообще не сможете сжать том. В подобном случае лучше переместить данные и заменить диск.
    Если раздел не отформатирован под файловую систему, но все еще содержит данные (например, файл базы данных), сжатие раздела может фактически привести к уничтожению данных.
    Для сжатия тома в оснастке Управление дисками щелкните ПКМ том, который вы хотите сжать — простой или составной а затем щелкните Сжать том (Shrink Volume).

    Настройка точки монтирования


    Точка монтирования — это папка тома, которая выполняет функцию указателя на корневой каталог другого тома. Например, если вам необходимо создать дополнительное свободное пространство для системного или загрузочного диска, можно создать новый том на другом диске и затем смонтировать этот том как папку на системном томе.
    Вы можете создать точку монтирования в оснастке Управление дисками, создав новый том с последующим выбором параметра монтирования тома к пустой папке NTFS (рис. 2-16).
    Поскольку вы не можете расширить системный том на другой диск, создание точки монтирования — единственный способ получить дополнительное свободное пространство для системного тома без замены аппаратных средств.
    Можно также создать точку монтирования для существующего тома, щелкнув ПКМ том и выбрав Изменить букву диска и путь к диску (Change Drive Letter And Paths). В одноименном окне щелкните Изменить, а затем выберите параметр монтирования тома к пустой NTFS-папке.

    Настройка кластеров серверов


    Лучшим средством для отказоустойчивости и архивации является кластер. Точка сбоя — слабое место сервера. Поддерживаются кластеры 3 видов:
  • кластеры отказоустойчивых серверов
  • балансировка сетевой нагрузки (Network Load Balancing, NLB);
  • вычислительные кластеры (compute clusters) используются в вычислительных целях, когда задачу можно разделить на несколько подзадач, каждая из которых может выполняться на отдельном узле. Отдельно выделяют высокопроизводительные кластеры (HPC — high performance computing clusters), которые составляют около 82% систем в рейтинге суперкомпьютеров Top500. Существует отдельная редакция WServer HPC для организации высокопроизводительных вычислительных сред. Эта редакция лицензируется только для запуска HPC-приложений (то есть на таком сервере нельзя запускать базы данных, web или почтовые сервера).
    Программные решения могут быть довольно чувствительны к задержкам — так, например, для Oracle RAC задержки не должны превышать 15 мс. В качестве технологий хранения могут выступать Fibre Channel, iSCSI или NFS файловые сервера.
    Отказоустойчивым кластером (Failover Cluster ) называют группу компьютеров (нодов), которая функционирует как единая система для обеспечения высокой доступности. Пользователь или программа видят такой кластер, как один виртуальный сервер. Когда кластеризованный ресурс на одном из узлов выходит из строя, управление им возлагается на другой сервер. При восстановлении ресурса исходный сервер возвращает себе функции управления и переходит в оперативный режим. Весь процесс восстановления после отказа полностью прозрачен для пользователей (см. рисунок). Также обеспечивается масштабируемость — добавление новых нодов.
    Могут возникать сложности с приложениями, которые полагаются на сессионные данные, при перенаправлении клиента на другой узел, на котором этих данных нет.
    Приложения без поддержки кластеров (cluster-unaware) не взаимодействуют со службами кластера и могут быть переключены на другой узел только в случае аппаратного сбоя. Приложения с поддержкой кластеров (cluster-aware), разработанные с использованием Cluster API, могут быть защищены от программных и аппаратных сбоев.
    Как пример сценария для отказоустойчивости может быть развертывание серверов с несколькими сетевыми адаптерами с применением стороннего сетевого программного обеспечения поддержки командной работы. В результате создаётся виртуальный сетевой адаптер, предназначенный для обеспечения доступа к серверу посредством одного или всех физических сетевых адаптеров сервера. В случае использования в системе WServer устройств хранения iSCSI следует знать, что назначаемые для коммуникаций iSCSI сетевые адаптеры не могут применяться в конфигурации командных сетевых адаптеров.На каждой из систем, которые будут входить в состав кластера, все локальные диски и тома должны конфигурироваться абсолютно одинаково, включая буквенные обозначения дисков и назначаемые точки монтирования. Активный и пассивныйАктивным узлом называется такой узел в кластере, на котором в текущий момент функционирует хотя бы одна группа SA. Каждая группа может работать только на одном узле сразу и потому все остальные узлы, на которых она также может находиться, считаются по отношению конкретно к ней пассивными. Пассивным узлом относительно кластера называется тот узел, на котором в текущий момент не функционируют никакие группы SA.Кластер типа "активный-пассивный" — это такой кластер, в котором имеется хотя быть один узел с функционирующей группой Services and Applications, и несколько дополнительных узлов, которые также могут обслуживать эту группу, но пока что находятся в состоянии ожидания. Такая конфигурация является типичной в случаях, когда в отказоустойчивом кластере развертывается только одна единственная группа Services and Applications.Кластер типа "активный-активный" — это такой кластер, в котором на каждом узле активно обслуживается или функционирует хотя бы одна группа SA. Такая конфигурация является типичной в случаях, когда в одном отказоустойчивом кластере развертывается множество групп SA для обеспечения максимального использования серверных или системных ресурсов. В случае выхода одной активной системы из строя оставшейся системе или системам нужно обслуживать все группы и предоставлять доступ к службам и/или приложения в кластере всем необходимым клиентам.Для организации active/active кластера требуются более изощренные механизмы, которые позволяют нескольким узлам обращаться к одному ресурсу и синхронизовать изменения между всеми узлами. Для организации кластера требуется, чтобы узлы были объединены в сеть, для чего наиболее часто используется либо традиционный Ethernet, либо InfiniBand. Oracle RAC и NLB являются примерами active/active кластера. Failover Cluster в WServer служит примером active/passive кластера. ТерминыКластерный ресурс — это служба, приложение, IP-адрес, аппаратный ресурс или сетевое имя, которое определяется и управляется с помощью кластера. Внутри самого кластера кластерные ресурсы объединяются и управляются вместе - группы служб и приложений (Services and Applications, SA). Эти группы представляют собой своего рода единицы подхвата функций в кластере. В случае выхода одного кластерного ресурса из строя и невозможности осуществить его автоматический перезапуск, его группа служб и приложений, переводиться в автономный режим и перемещается на другой узел в кластере. Подхват функций (failover) - процесс перемещения группы SA с текущего активного узла на другой доступный узел кластера в случае выхода какого-нибудь кластерного ресурса из строя. Подхват функций происходит либо тогда, когда сервер становится недоступным, либо тогда когда один из ресурсов в кластерной группе выходит из строя и не поддается восстановлению на протяжении выделенного для этого промежутка времени.
    Возврат функций (fallback) - процесс автоматического возврата кластерной группы на рекомендованный узел после возобновления его работы. По умолчанию механизм возврата функций не активен, но может легко включаться в окне свойств конкретной группы SA путем указания рекомендованного (preferred) узла и предельного времени осуществления возврата функций этой кластерной группе. Рекомендованный узел — узел, на котором кластерная группа должна функционировать или обслуживаться во время обычного режима работы кластера, при котором в нем доступны все узлы. При возврате функций группы в кластере в принципе выполняется та же самая операция подхвата функций, но только инициируется она рекомендованным узлом, который снова присоединяется к кластеру или возобновляет свою работу в нем, а не отказом ресурса на текущем активом узле.
    Точка клиентского доступа (CAP) — это термин, который применяется в отказоустойчивых кластерах WServer и подразумевает под собой комбинацию, состоящую из сетевого имени и ассоциируемого с ним IP-адреса. По умолчанию при добавлении новой группы служб и приложений CAP создается с именем и адресом IPv4. Стандарт IPv6 тоже поддерживается в отказоустойчивых кластерах, но требует либо добавления ресурса IPv6 в какую-то существующую группу, либо создания отдельной общей группы служб и приложений и добавления всех необходимых ресурсов и их зависимостей в нее.
    Виртуальным сервером кластера называется такая группа SA, в которой содержится ресурс CAP, ресурс диска и хотя бы еще один дополнительный ресурс конкретной службы или приложения. Доступ к ресурсам виртуального сервера кластера осуществляется либо с помощью имени DNS, либо с помощью имени NetBIOS со ссылкой на адрес IPv4 или IPv6. Имя и IP-адрес остаются одинаковыми, независимо от того, на каком именно узле кластера функционирует виртуальный сервер.
    Сигнал активности кластера (cluster heartbeat) — это термин, который применяется для описания сообщений, пересылаемых между отдельными узлами кластера и используемых для определения их состояния. Обмен сигналами активности может осуществляться как по отдельной сети, так по той же самой, что и обмен данными с клиентами. Объем трафика, генерируемый во время обмена сигналами об активности, большим не является, исходя из размера передаваемых данных, но частота его пересылки может требовать принятия определенных мер.
    Географически распределенные кластеры - кластеры, которые распределены по разным физическим местам, а иногда и сетям, обеспечивая отказоустойчивую функциональность для удаленных зданий и центров данных, обычно по линиям глобальной сети (WAN). Такие кластеры теперь могут охватывать различные сети, обеспечивая отказоустойчивую функциональность, но при этом скорость и пропускная способность сети должна быть достаточно высокой, а репликация данных не должна обрабатываться кластером. Многосайтовый кластер — это когда узлы кластера развернуты на разных сайтах Active Directory.
    Растяжимые (stretch) кластеры. Это распространенный термин, означающий в некоторых случаях географически распределенные кластеры, в которых используются различные подсети, но каждая из подсетей является частью одного сайта Active Directory; отсюда термин "растяжимые", т.е. речь идет о растяжении сайта AD через сеть WAN. В других случаях этот термин используется для описания географически распределенного кластера, когда кластер "растянут" между географическими местоположениями.
    Есть поддержка теневых копий для быстрого восстановления конфигурации кластера.

    Хранилище


    Общее хранилище - диски и тома, представляемые кластерным узлам WServer в виде LUN-номеров. В частности, общее хранилище может быть доступно каждому узлу кластера, но не всем одновременно. LUN-номера (Logical Unit Number) (логический номер устройства) применяется для обозначения диска или тома, который представляется обслуживающему серверу или серверам устройством общего хранилища через общий массив хранилищ (shared storage array — SAN). LUN-номера, предоставляемые общим хранилищем, прежде чем использоваться с отказоустойчивыми кластерами должны проверяться на соблюдение множества требований, но в случае соблюдения этих требований все активные узлы в кластере могут получать к ними эксклюзивный доступ.
    В случае failover-кластера доступ к LUN, хранящему данные, может осуществлять только активный узел, который владеет этим ресурсом. При переключении на другой узел происходит размонтирование LUN и монтирование его для другого узла. В большинстве случаев эта задержка не является критичной, но при виртуализации может требоваться вообще нулевая задержка на переключение виртуальных машин с одного узла на другой (см. рисунок).
    Быстрая миграция. Вместе с механизмом виртуальных машин Hyper-V на отказоустойчивых кластерах быстрая миграция предлагает администраторам этих кластеров возможность перемещения виртуальной машины на другой узел без останова этой виртуальной машины. Это осуществляется посредством параметра завершения виртуальной машины: если он установлен в значение по умолчанию Сохранить, то выполнение быстрой миграции сохранит текущее состояние памяти, перенесет виртуальную машину на желаемый узел и быстро продолжит ее выполнение. Конечные пользователи должны при этом почувствовать лишь краткую задержку в обслуживании, и будут быстро вновь подключены без проблем, в зависимости от службы или приложения, развернутого на этой виртуальной машине. Быстрая миграция не требует для своей работы CSV.
    Общие тома кластера (Cluster Shared Volumes, CSV) - диск или LUN-номер, определенный внутри кластера, который может быть доступен множеству узлов кластера одновременно. Это отличает его от любого другого тома кластера, которые обычно могут быть доступны только по одному за раз, и в настоящее время средство CSV используется только в кластерах Hyper-V, но его применение будет расширяться в ближайшем будущем на любые отказоустойчивые кластеры, поддерживающую живую миграцию.
    Еще одна проблема, возникающая из-за того, что LUN является минимальной единицей обхода отказа, заключается в том, что при сбое одного приложения, находящегося на LUN, приходится переключать все приложения, которые хранятся на этом LUN, на другой сервер. Во всех приложениях (включая Hyper-V до Server 2008 R2) это удавалось обходить за счет многочисленных LUN, на каждом из которых хранились данные только одного приложения. В WServer появилось решение для этих проблем, но предназначенное для работы только с Hyper-V и CSV.
    CSV позволяет размещать на общем хранилище виртуальные машины, запускаемые на разных узлах кластера — тем самым разбивается зависимость между ресурсами приложения (в данном случае виртуальными машинами) и дисковыми ресурсами. В качестве файловой системы CSV использует обычную NTFS. Для включения CSV необходимо в Failover Cluster Manage выполнить команду Enable CSV. Отключить поддержку CSV можно только через консоль:
    Get-Cluster | %{$_.EnableSharedVolumes = "Disabled"}
    Для использования этой команды должен быть загружен модуль PowerShell.
    Живая миграция - средство Hyper-V, которое активизируется, когда виртуальные машины развертываются на отказоустойчивом кластере WServer. Живая миграция позволяет виртуальным машинам Hyper-V на отказоустойчивом кластере перемещаться между узлами кластеров без нарушения коммуникаций или доступа к виртуальной машине. Живая миграция использует CSV, доступный всем узлам в группе одновременно, и передает память между узлами во время активных клиентских коммуникаций для поддержания доступности. Живая миграция в настоящее время применяется только с отказоустойчивыми кластерами Hyper-V, но, скорее всего, в ближайшем будущем распространится на многие другие службы и приложения Microsoft.
    Использование CSV совместно с живой миграцией позволяет перемещать виртуальные машины между физическими серверами в считанные миллисекунды, без обрыва сетевых соединений и совершенно прозрачно для пользователей. Стоит отметить, что копировать любые данные (например, готовые виртуальные машины) на общие диски, использующие CSV, следует через узел-координатор. Несмотря на то, что общий диск доступен со всех узлов кластера, перед записью данных на диск узлы запрашивают разрешение у узла координатора. При этом, если запись требует изменений на уровне файловой системы (например, смена атрибутов файла или увеличение его размера), то записью занимается сам узел-координатор.

    Циклическое распределение


    Первая группа, называемая группой циклического распределения, представляет собой множество компьютеров, использующих технологию DNS для обеспечения основного распределения нагрузки с минимальными требованиями к конфигурации. В технологии циклического распределения DNS-сервер настроен более чем с одной записью для преобразования имени другого сервера в IP-адрес. Когда клиенты осуществляют запросы к DNS-серверу на поиск адреса другого сервера, отклики DNS-сервера осуществляют циклическое переключение между записями за каждую единицу времени, и каждый успешный клиент направляется на разный адрес и разную машину. См. Рисунок.
    Циклическое распределение DNS по умолчанию доступно в большинстве DNS-серверов, поэтому для настройки этого простого вида балансировки нагрузки вам потребуется только создать соответствующие записи DNS на DNS-сервере.
    Самый большой недостаток технологии заключается в том, что если выходит из строя один из целевых серверов, DNS-сервер не может откликнуться на это событие и препятствует клиентам, направляя их на недействующий сервер до тех пор, пока системный администратор не удалит с этого DNS-сервера запись DNS. Вторым недостатком технологии DNS является то, что каждой записи присваивается один и тот же весовой коэффициент, независимо от того, является ли целевой сервер более мощным, чем другой, и не занят ли уже данный сервер. Последний недостаток технологии заключается в том, что циклическое распределение не всегда функционирует так, как ожидается. Поскольку клиенты DNS кэшируют отклики серверов на запросы, клиент DNS по умолчанию будет подключаться к одному и тому же целевому серверу до тех пор, пока отклики, помещенные в кэш, будут оставаться активными.
    При наличии потребности в возврате функций конфигурируйте расписание возврата функций так, чтобы он осуществлялся только либо во время наименьшей загрузки сети, либо после определенного часа для снижения вероятности возврата функций группы обратно узлу в обычное рабочее время.
    Тщательно тестируйте механизмы подхвата и возврата функций.
    В случае удаления узла из кластера, в котором используется модель кворума Node Majority (Большинство узлов), проверяйте, чтобы функционировать оставалось большинство узлов, иначе кластер может перестать работать.
    Тщательно продумывайте процедуры резервного копирования и восстановления кластера и не развертывайте никаких кластеров до тех пор, пока эти процедуры не будут должным образом протестированы и документированы.

    Отказоустойчивый кластер


    Отказоустойчивая кластеризация (Failover Clustering) обеспечивает устойчивость к отказам на уровне системы с помощью процесса, называемого подхватом функций (failover). Когда какая-нибудь система или узел в кластере выходит из строя или перестает отвечать на запросы клиентов, кластеризованные службы или приложения, которые функционировали на этом конкретном узле, переводятся в автономный режим и перемещаются на другой узел, где снова делаются функциональными и доступными. В большинстве реализаций отказоустойчивые кластеры требуют доступа к общему хранилищу данных и больше всего подходят (но не ограничиваются) для развертывания перечисленных ниже приложений и служб.
    Служба Cluster Service работает в контексте безопасности встроенной локальной учетной записи LocalSystem. Попутно кластер становится менее подверженным риску случайных изменений в учетных записях, например, из-за того что вы создали или изменили групповую политику, или случайно удалили CSA, или случайно отказали ей в каких-то полномочиях.
    Проверка подлинности в отказоустойчивых кластерах теперь производится исключительно средствами Kerberos. NTLM для внутренних целей болеене используется. Это связано с тем, что авторизация узлов кластера теперь производит-ся при помощи учетной записи компьютера, а не учетной записи пользователя. Есть идругие усовершенствования, но нам пора двигаться дальше.
    Если службы и приложения поддерживают работу в кластерах или были протестированы на совместимость с отказоустойчивыми кластерами WServer, они контролируются и управляются службой кластеров для обеспечения правильной работы.
    В случае появления проблемы с каким-нибудь кластерным ресурсом служба отказоустойчивого кластера сначала пытается устранить ее путем перезапуска этого ресурса и всех остальных зависимых от него ресурсов. Если это не помогает, группа Services and Applications, членом которой является данный ресурс, переносится с помощью процесса подхвата функций на другой доступный узел в кластере, где она затем может быть запущена снова. Перенос группы Services and Applications на другой узел кластера может происходить по нескольким причинам, а именно — либо из-за отключения электропитания на активном узле, либо потери им сетевой связности, либо возникновения на нем какого-нибудь аппаратного или программного сбоя. Чаще всего процесс подхвата функций замечается либо клиентами лишь в виде небольшого перерыва в обслуживании, либо вообще никем не замечается. Конечно, в случае настройки механизма подхвата функций для группы Services and Applications, которая просто является нестабильной, но все возможные узлы доступны, эта группа будет постоянно перемещаться туда и обратно между узлами до тех пор, пока не достигнет заданного порога, после чего будет просто остановлена и переведена в автономный режим службой кластеризации.
    Во избежание выполнения нежелательных процессов подхвата функций следует отключать управление питанием на каждом из узлов кластера в BIOS материнской платы, на сетевых адаптерах (Network Interface Cards — NIC) и в оснастке Power панели управления операционной системы. Настраивать параметры питания, отвечающие за отключение монитора, допускается, но при этом нужно обязательно конфигурировать диски так, чтобы они, также как и все сетевые адаптеры, никогда не переводились в режим ожидания (Standby Mode).
    Кластерные узлы могут следить за состоянием ресурсов, функционирующих на их локальной системе, а также отслеживать и состояние других узлов в кластере посредством специальных пересылаемых по частной сети сообщений, которые называются сигналами активности (heartbeats). Обмен сигналами активности позволяет как определять состояние узлов, так и отправлять информацию об этом и появившихся в конфигурации кластера изменениях механизму кворума кластера.
    На первом этапе необходимо сконфигурировать аппаратную часть, которая должна соответствовать The Microsoft Support Policy for WServer Failover Clusters. Все узлы кластера должны состоять из одинаковых или сходных компонентов. Все узлы кластера должны иметь доступ к хранилищу, созданному с использованием FibreChannel, iSCSI или Serial Attached SCSI. От хранилищ, работающих с WServer, требуется поддержка persistent reservations.
    Серверы должны принадлежать к одному домену. Желательно, чтобы все узлы кластера были с одинаковой ролью, причем лучше использовать роль member server, так как роль domain controller чревата возможными проблемами с DNS и Exchange.
    Если для проверки конфигурации указан только один узел, то часть проверок будет пропущена.
    Если серверы подключены к сетям, которые не будут использоваться для общения в рамках кластера (например, подключение только для обмена данными с хранилищем), то в свойствах этой сети в Failover Cluster Management необходимо установить параметр «Do not allow the cluster to use this network».
    После этого можно приступить к настройке приложения, которое требуется сконфигурировать для обеспечения его высокой доступности. Для этого необходимо запустить High Availability Wizard, который можно найти в Services and Applications оснастки Failover Cluster Management.
    Может быть использована для увеличения уровня доступности приложения или службы в случае отказа сервера. Отказоустойчивый кластер представляет собой группу, состоящую из 2 или более компьютеров, используемых для предотвращения длительных простоев приложений и служб. Серверы кластера (называемые узлами) соединены между собой посредством физических кабелей и подсоединены к общему дисковому хранилищу данных. В случае отказа одного из узлов кластера другой узел берет его работу на себя. В результате пользователи, подключенные к серверу, практически не ощущают сбоя в обслуживании.
    Отказоустойчивый кластер не позволит веб-сайту поддерживать возрастание рабочей нагрузки. Он только может разрешить одному серверу взять на себя работу другого сервера в случае, если тот откажет.
    Серверы отказоустойчивого кластера могут выполнять различные функции,в том числе функцию файлового сервера, печатного сервера, сервера электронной почты или сервера баз данных, при этом серверы кластера позволяют обеспечить высокую доступность для множества других служб и приложений.
    В большинстве случаев отказоустойчивый кластер содержит общее запоминающее устройство, которое физически подсоединено ко всем серверам кластера, хотя любой том запоминающего устройства за единицу времени можетбыть доступен только одному серверу.
    На рис. 2-19 изображен процесс перехода на другой ресурс при сбое в базовом двухузловом отказоустойчивом кластере.
    В отказоустойчивом кластере тома запоминающего устройства или сети LUN, доступные узлам кластера, не должны быть доступны другим серверам, в том числе серверам другого кластера. Этот процесс проиллюстрирован на рис. 2-20: два двухузловых отказоустойчивых кластера разделяют хранилище данных сети SAN.
      Инструмент управления - cluster.exe.
      Диагностика с помощью журналов событий, заменивших прежний журнал cluster.log.

    Почему мы как потребители привязаны к производителю кластерного оборудования, продукция которого включена с список совместимого оборудования (Hardware Capability List, HCL) или каталог Windows Server? Как выяснилось, я не могу обновить микропрограммный драйвер HВА, поскольку его нет в списке HCL!

    Модели кворума


    Кворум кластера отвечает за отличительные конфигурационные данные кластера и текущее состояние каждого узла, каждой группы SA, каждого ресурса и сети в кластере. Более того, при считывании данных кворума каждый узел определяет на основании извлекаемой информации то, должен ли он остаться доступным, завершить работу кластера или активизировать конкретные группы SA на локальном узле. Кластерный диск-свидетель или общий файловый ресурс-свидетель применяются для хранения информации о конфигурации кластера и оказания помощи с определением состояния кластера в случае невозможности установить связь с каким-нибудь или всеми узлами кластера.
    В кворуме кластера содержатся конфигурационные данные, необходимые для восстановления кластера до рабочего состояния. Это исключает вероятность возникновения так называемого синдрома "расщепления мозга", при котором два узла в одном и том же кластере оба верят, что являются активным узлом и пытаются управлять общим ресурсом одновременно, или хуже того — каждый узел может представлять собственный набор данных, когда доступны различные наборы данных, что приводит к изменениям в обоих наборах и массе проблем с их обработкой. ОС WServer поддерживает 4 разных модели кворума. Сервера, оставшиеся без кворума, автоматически закрывают все службы.
    В Win2k3 «кворумом» называли общий диск с настройками кластера, потеря которого была критичной. Как вариант, предлагался кворум набора узлов, состоящий из общего SMB-ресурса. В этом случае для функционирования кластера требовалось участие большинства узлов. Несмотря на все усилия производителей SAN, направленные на создание надежных RAID-накопителей, даже эти устройства нет-нет да и выходят из строя.
    В WServer обе эти модели слиты в единую гибридную, или смешанную (mixed-mode), модель кворума, которая называется моделью кворума большинства (majority quorum model) и соединяет в себе лучшие черты прежних моделей. Диск кворума, называемый теперь диском-свидетелем (witness disk), перестал быть критической точкой кластера, как это было в модели общего диска. Node and Disk Majority (большинство узлов и диск) — удобен при четном количестве узлов. Голоса (vote) имеют узлы и общие диски-свидетели. Кворум может быть получен, если доступно более 50% узлов (или меньше, если есть диск-свидетель). Кластер теперь в состоянии «пережить» любой сбой, приводящий к потере одного голоса. Иными словами, кластер из двух узлов с общим накопителем теперь способен пережить потерю кворума или потерю одного из узлов (потерю одного голоса). Каждый узел получает голос за внутренний диск, на котором хранится куст реестра кластера. Диск-свидетель получает голос, потому что на нем также хранится копия реестра кластера. Модель общего диска существенно более распространена, поскольку значительную долю кластеров составляют кластеры из двух узлов. Когда вы организуете кластер с двумя и более узлами и с общим диском-свидетелем, на свидетеле будет создана папка \Cluster с кустом реестра кластера.
    Диск-свидетель делается доступным для всех узлов в кластере посредством общего устройства хранения (shared storage device) с помощью соединений SAS, Fibre Channel или iSCSI. Эта модель прекрасно подходит для отказоустойчивых кластеров с общим хранилищем, одной сетью и четным количеством узлов. Например, в случае использования такой модели для кластера с 2, 4, 6, 8 или 16 узлами кластер будет функционировать до тех пор, пока в нем будет оставаться доступной как минимум половина из общего количества узлов и пока он сможет связываться с диском-свидетелем. В случае выхода диска-свидетеля из строя кластер сможет продолжать работу, только если будет доступно большинство узлов. Подсчитать это "большинство" можно так: взять половину от общего количество узлов и добавить еще один узел, это и будет наименьшее количество доступных узлов, необходимое для поддержания кластера в рабочем состоянии, когда дисксвидетель поврежден или отключен.
    • No Majority: Disk Only (без большинства: только диск). Отсутствие диска-свидетеля в любом случае означает отсутствие кворума. В этой конфигурации кластер сохраняет работоспособность, если в нем остается хотя бы один узел, способный обмениваться данными со свидетелем.
    • Node Majority (большинство узлов). Если у вас нет общего накопителя, а есть только локальные (реплицируемые) накопители на каждом узле, вы можете назначить по одному голосу каждому узлу. Кластер сохраняет работоспособность и доступ к запущенным на нем приложениям, при условии что работает большинство его узлов. Для ее функционирования необходимо, чтобы в кластер входило не менее 3 узлов (или 1). Кластеры с моделью кворума Node Majority были разработаны и прекрасно подходят для узлов, которые являются разбросанными с географической или сетевой точки зрения, но чтобы их поддерживала компания Microsoft, требуют серьезных усилий, качественного оборудования, стороннего механизма для репликации серверных данных и очень надежной сети.
    • Node and File Share Majority (кворум решают большинство узлов и файловых ресурсов) — вместо диска-свидетеля используется файловый ресурс. Этот режим также рекомендуется при четном количестве узлов и кластере без общего хранилища данных. Если вы захотите использовать в качестве свидетеля общий ресурс, то не обязательно должен быть отдельный диск (правда, общий свидетель не может быть общим ресурсом DFS). Теперь в этом качестве можно использовать общий ресурс на любом файловом сервере сети; кроме того, один файловый сервер может исполнять роль свидетеля для нескольких серверов (Каждому кластеру нужен собственный общий ресурс, но вы вольны создать несколько ресурсов — по одному на кластер — на одном файловом сервере). Этот вариант удобен при создании, кластера, узлы которого разбросаны географически.
    Таким образом, доступно 4 режима. Настройка производится через меню More actions — Configure Cluster Quorum Settings на странице Select Quorum Configuration. При установке кластера будет выбран наиболее оптимальный вариант. Менять кворум потребуется только при добавлении нового узла или других изменениях в структуре кластера. В зависимости от текущей конфигурации, некоторые режимы могут быть также отмечены, как не рекомендуемые (not recommended for your current number of nodes). После создания кластера для изменения модели кворума можно воспользоваться мастером Configure Quorum Settings, но делать этого, как правило, не следует. Лучше изначально как следует продумайте организацию кластера, чтобы потом вам уже неприходилось менять в нем модель кворума.
    С помощью Failover Cluster Management вы можете изменить модель кворума, задать высокую доступность приложений и служб, настроить разрешения кластера, включая новую функцию — аудит доступа к кластеру, если на ваших серверах включен аудит), а также выполнить другие типичные действия по управлению кластером. Больше того, с помощью этой ММС-консоли можно управлять одновременно несколькими кластерами. Для управления сервером из командной строки применяется утилита cluster.exe (она тоже несовместима с кластерами предыдущих версий Windows). Наконец, вы вольны использовать поставщик WMI кластера для автоматизации задач управления кластером с помощью сценариев.

    Требования к приложениям


    Хотя многие из приложений и могут функционировать в отказоустойчивых кластерах, некоторые из них могут не быть оптимизированы под кластеризацию или не поддерживаться производителем ПО или даже самой компанией Microsoft.
    Поскольку кластеризация основывается на использовании IP, кластерное приложение или приложения должны обязательно поддерживать какой-нибудь IP-протокол.
    Приложения, которым требуется доступ к локальным базам данных, должны иметь опцию, позволяющую настраивать место хранения данных, поэтому для хранилища данных, не относящихся к основным файлам приложений, может быть указан диск, отличный от системного.
    Некоторым приложениям необходимо иметь доступ к данным независимо от того, на каком из узлов кластера они функционируют. В случае таких приложений рекомендуется, чтобы их данные хранились в общем дисковом ресурсе, предусматривающем возможность подхвата функций вместе с группой SA. Если приложение будет функционировать и сохранять данные только на локальном системном или загрузочном диске, должна обязательно использоваться либо модель кворума Node Majority (Большинство узлов), либо модель кворума File Share Majority (Большинство общих файловых ресурсов) вместе с отдельным механизмом репликации файлов для данных этого приложения.
    Клиентские сеансы должны иметь возможность восстанавливать связь в случае прерывания сетевой связности или подхвата функций каким-то альтернативным узлом кластера. Во время процесса подхвата функций связь с клиентами прерывается до самых тех пор, пока приложение не будет возвращено в оперативный режим. Если в случае разрыва сетевого соединения клиентская программа не пытается восстановить подключение и дожидается завершения тайм-аута, скорее всего, она не годится ни для отказоустойчивых кластеров, ни для кластеров NLB.

    Сеть и безопасность


    Полностью поддерживается IPv6, DHCP. Это означает, что теперь IP-адреса кластера можно получать от DHCP-сервера. Говоря точнее, если вы настроили серверы, которым предстоит стать узлами кластера, на динамическое получение адресов, динамически будут получаться все адреса кластера. Но если вы назначили серверам статические адреса, адреса кластера вам также придется настраивать вручную. Во время написания этих строк динамическая адресация работала только для адресов IPv4.
    В отказоустойчивой кластеризации устранены все оставшиеся зависимости от протокола NetBIOS. Стандартным методом разрешения имен стал DNS. Это изменение позволяет избавится от нежелательного широковещательного графика, связанного с разрешением имен NetBIOS, а также упрощает передачу трафика SMB внутри кластера.
    Еще одно изменение состоит в том, что для передачи пульса кластера вместо RPC over используются более надежные протоколы, ориентированные на сеансы TCP. Усовершенствования IPSec означают, что переход на резервный компьютер в случае сбоя с точки зрения клиента происходит почти мгновенно — если для защиты коммуникаций кластера вы применяете IPSec. Ресурсы Network Name теперь сохраняют работоспособность, даже если в оперативном режиме остался всего один ресурс IP-адреса. В предыдущих реализациях кластеров ресурс Network Name был доступен клиенту, только если в оперативном режиме находились все ресурсы IP-адресов.
    Узлы кластера теперь могут размещаться в разных подсетях. А это означает, что различные узлы могут располагатьсяв географически весьма разнесенных точках! Эта штука называется географически разбросанным кластером (Geographically Dispersed Cluster), или сокращенно геокластером. Такая форма геокластеров поддерживалась и в прежних серверных платформах Windows, в ней посредством различных технологий, например, виртуальных ЛВС, приходилось обеспечивать размещение всех узлов одной и той же подсети, что иногда бывало очень неудобно. Кроме того, возможность настройки времени задержки пульса в WServer, по сути, означает, что практического предела расстояния между узлами отказоустойчивого кластера не существует. Конечно, вам, может быть, и не удастся разместить один узел на мысе Канаверал во Флориде, а второй — на горе Олимп на Марсе, но расстояние между Нью-Йорком и Каламазу (штат Мичиган) проблемы не составит. Для передачи пульса кластера по-прежнему используется UDP-порт 3343, но в нем теперь вместо ненадежных многоадресных передач UDP применяются одноадресные UDP-пакеты (как в процессе вопроса-ответа команды ping). Благодаря этому геокластеры стали сущест венно более надежными и простыми в управлении. (По умолчанию, прежде чем счесть узел недосягаемым, служба Failover Clustering ждет 5 секунд. Чтобы просмотреть значение этого и другого параметров, введите в командной строке cluster. / prop .)
    Еще несколько замечаний по поводу геокластеров от эксперта Microsoft.

    Общие хранилища данных


    Общее дисковое хранилище данных (shared disk storage) является обязательным требованием для тех отказоустойчивых кластеров WServer, в которых используются модели кворума Disk Majority (Большинство дисков) и Disk Only. Общие дисковые устройства хранения могут делаться частью любой конфигурации кластера и в случае их применения все представляемые ими диски, дисковые тома или LUN-номера должны представляться в системах Windows в виде базовых дисков Windows.
    Драйверы всех устройств хранения должны обязательно иметь цифровую подпись и отметку о прохождении тестирования на совместимость и пригодность работы в WServer. Все общие устройства хранения для отказоустойчивых кластеров в WServer обязательно должны соответствовать стандарту SCSI-3 Architecture Model SAM-2. Это касается абсолютно всех унаследованных и последовательных контроллеров SCSI, адаптеров главных шин Fibre Channel и аппаратных и программных инициаторов и исполнителей iSCSI. Если кластер попытается выполнить на LUN или общем диске какое-то действие, и эта попытка приведет к прерыванию связи с другими узлами в кластере или любой другой системой, подключенной к общему устройству хранения, может произойти повреждение данных и потеря у всего кластера и каждой подключенной к сети хранения данных (SAN) системе связности с устройством хранения.
    При представлении LUN-номеров узлам отказоустойчивого кластера каждый LUN-номер должен предоставляться каждому узлу в кластере. Кроме того, при получении доступа к общему хранилищу данных кластером и другими системами LUN-номера должны маскироваться или предоставляться только кластерным узлам и контроллерам кластерных устройств хранения. Требования для поддержки общих хранилищ являются очень жесткими, особенно когда дело касается отказоустойчивых кластеров. Ниже приведен перечень основных условий и рекомендаций, которые должны соблюдаться при использовании как сетей хранения данных (SAN), так и других видов общих хранилищ.
    1. Все Fibre-, SAS и iSCSI-адаптеры главной шины (Host Bus Adapter — НВА) и адаптеры Ethernet, используемые с программными инициаторами iSCSI, должны иметь логотип "Поддерживаются Microsoft Windows", и драйверы устройств с соответствующей цифровой подписью.
    2. Все Fibre-, SAS и iSCSI-адаптеры главной шины должны использовать драйверы устройств StorPort для обеспечения возможности сброса целевых LUN-номеров и других функций, свойственных спецификации драйверов StorPort. В одно время для кластеров с двумя узлами разрешалось использовать драйвер SCSIport, но сегодня, если доступен драйвер StorPort, следует использовать именно его для уверенности в получении поддержки от производителей оборудования и Microsoft.
    3. Все предназначенные для обеспечения общего хранилища НВА-адаптеры и вспомогательные ( back -end) устройства хранения должны поддерживать стандарты SCSI-3, а также устойчивое привязывание и резервирование LUN-номеров.
    4. Все предназначенные для обеспечения общего хранилища НВА-адаптеры должны развертываться с соответствующими версиями встроенного ПО и драйверов. Отказоустойчивые кластеры с общим хранилищем требуют очень стабильной инфраструктуры, а применение новейших драйверов управления хранением к устаревшему ПО НВА-адаптеров чревато возникновением нежелательных ситуаций и прерыванием доступа к данным.
    5. Все узлы в кластере должны содержать одни и те же НВА-адаптеры и использовать одну и ту же версию драйверов и встроенного ПО. Каждый узел кластера должен представлять собой точную копию всех остальных узлов в том, что касается оборудования, конфигурации и версий драйверов и встроенного ПО. Это делает конфигурацию более надежной и упрощает процессы управления и стандартизации.
    6. В случае использования программных инициаторов iSCSI для подключения программных или аппаратных исполнителей iSCSI сетевой адаптер, предназначенный для обслуживания соединений iSCSI, должен подключаться к отдельному коммутатору, не применяться для обслуживания кластерных соединений и не выступать в роли командного сетевого адаптера, поскольку таковые не поддерживаются iSCSI.
    Для того чтобы Microsoft официально поддерживала отказоустойчивые кластеры и общее хранилище, помимо соблюдения всех перечисленных выше требований вся конфигурация марок и моделей серверов, конфигурация локальных дисков, встроенное ПО контроллеров НВА-адаптеров или сетевых адаптеров и версии драйверов, ПО программных инициаторов iSCSI, массивы хранения и версия встроенного ПО контроллера массивов хранения или операционной системы SAN должны быть протестированы как одно целое, прежде чем смогут официально считаться поддерживаемой конфигурацией отказоустойчивых кластеров WServer (WServer Failover Cluster Supported Configuration). Главное, о чем должны помнить компании, действительно желающие рассмотреть вариант применения отказоустойчивых кластеров — это то, что они должны проводить исследование и подбирать такое решение, которое будет отвечать их бюджетным возможностям. В случае если подобрать протестированное и поддерживаемое решение в рамках своих ценовых возможностей не удастся, они должны рассматривать альтернативные решения, позволяющие восстанавливать системы если не за несколько минут, то хотя бы за один или нескольких часов. Правда состоит в том, что отказоустойчивые кластеры подходят не для всех, оказываются "по зубам" не каждому и вписываются в рамки бюджета (с точки зрения внедрения, обучения и поддержки) далеко не каждой организации. Администраторы могут развертывать тестовые конфигурации отказоустойчивых кластеров для приобретенная навыков и опыта работы с их компонентами и функциями, обращаясь к более дешевым альтернативам, вроде Windows-инициатора iSCSI и программного исполнителя iSCSI, памятуя, однако, о том, что в случае возникновения проблем или потери или повреждения данных такие конфигурации могут не поддерживаться Microsoft.

    Хранение данных


    Многие из усовершенствований стали результатом полной переработки драйверов дисков для кластеров (clusdisk.sys) и ресурса Physical Disk. Отказоустойчивая кластеризация никогда не оставляет диски кластера (диски, видимые всем узлам кластера) в незащищенном состоянии, которое может сказаться на целостности данных.
    В WServer применяются только технологии хранения данных, поддерживающие постоянное резервирование (persistent reservation). В целом, это означает, что разрешены типы общих шин FC, iSCSI и SAS. Использование интерфейса Parallel-SCSI не допускается.
    Диску кворума более не нужна буква диска, поскольку в отказоустойчивой кластеризации применяется прямой доступ к ресурсу кворума. Это на самом деле хорошо, поскольку в больших кластерах буквы диска часто бывают в дефиците. Впрочем, если вам это зачем-то нужно, вы вольны назначить кворуму букву самостоятельно.
    WServer поддерживаются диски ОРТ (GUID Partition Table), на которых можно создавать разделы объемом более 2 терабайт (Тб). Кроме того, эти диски обладают повышенной избыточностью и восстанавливаемостью и потому идеальны для использования в очень больших кластерах. GPT-диски поддерживаются кластерами на всех аппаратных платформах WServer (х86, х64 и IА64).
    Новая логика проверки позволяет сохранять отношения точек подключения и предохранять их от разрыва.
    К вашим услугам новый встроенный механизм, позволяющий восстанавливать отношения между физическими дисковыми ресурсами и логическими номерами устройств (LUN).
    Изменены параметры команды chkdsk.exe и усилена команда DiskPart.exe.
    Усовершенствованный режим обслуживания Maintenance Mode, который позволяет временно предоставлять другим приложениям исключительный доступ к дискам кластера.
    Поддержка восстановления дисков кластера из аппаратных моментальных снимков служб теневого копирования (VSS).
    Драйвер диска кластера более не предоставляет функциональности прямого ограждения диска (ограждением диска называется процесс предоставления и запрета доступа к диску), в результате чего снизился риск повреждения диска.
    Как мне известно, потребители высказывали пожелание, чтобы Microsoft разработала встроенную поддержку использования динамических дисков для хранения данных в кластере. Однако в WServer это пожелание не реализовано. Думаю, тому есть две причины: во-первых, эту функциональность уже предоставляют продукты сторонних разработчиков, подобные Symantec Storage Foundation for Windows. Во-вторых, на самом деле в отказоустойчивой кластеризации возможность просто не нужна. Почему? Разделы на GPT-дисках могут быть настолько большими, что у вас вряд ли когда-то возникнет потребность изменить их размер. Кроме того, если вам понадобится изменить размер раздела на основном диске, вы вольны сделать это с помощью команды. Она, в частности, позволяет уменьшать тома и увеличивать их.
    Обрати внимание на положения кластеризации, включенные в каталог Windows Server Catalog.

    SAS


    Диски SAS могут обеспечивать организации доступными по цене, начальными, аппаратными, подключаемыми напрямую массивами, подходящими для кластеров WServer. Массивы SAS обычно ограничиваются 4 хостами, но некоторые модели поддерживают расширители, позволяющие при необходимости добавлять дополнительные хосты. Одним из главных недостатков подключаемого напрямую хранилища является то, что добиться в нем репликации данных без задействования одной из хост-систем и программ, предоставленных поставщиком оборудования, обычно невозможно.

    Массивы хранения данных Fibre Channel


    В случае использования адаптеров главной шины Fibre Channel система WServer может получать доступ как общим, так и не общим дискам в SAN, подключенной к общему коммутатору FC. Это позволяет при желании размещать в SAN и общее хранилище данных, и тома операционной системы и тем самым создавать бездисковые серверы. Во многих случаях, однако, бездисковое хранилище может быть нежелательным, если операционная система выполняет много действий по страничному обмену, поскольку кэш на контроллерах хранилища может очень быстро исчерпываться и потому приводить к задержкам в операциях чтения и записи данных на дисках для выделенного кластеру хранилища. Если такое поведение является желаемым, однако, SAN должна поддерживать эту опцию и быть настроена на предоставление выделенных LUN-номеров операционной системы только исключительно одному единственному хосту. LUN-номера, определяемые для общего кластерного хранилища, должны быть зонированными, а также представляться каждому узлу в кластере и больше никаким другим системам. Зонирование или маскирование LUN-номеров во многих случаях конфигурируется на коммутаторе волоконно-оптических каналов (Fibre Channel), который соединяет узлы кластера и общее устройство хранения данных. И FC, и iSCSI требуют общего коммутатора волоконно-оптических каналов или коммутатора Ethernet для установки и поддержания соединения между хостами и хранилищем.
    Правильно сконфигурированная для кластера зона FC будет включать WWPN-номер (World Wide Port Number — глобальный номер порта) НВА-адаптеров FC каждого хоста кластера и WWPN-номер контроллера или контроллеров НВА-адаптеров из общего устройства хранения. Если либо сервер, либо устройство хранения использует несколько НВА-адаптеров для подключения к одному или нескольким коммутаторам FC с целью обеспечения возможности подхвата функций или балансировки нагрузки, это называется разветвленным вводом-выводом (Multipath I/O — МРIO) и требует применения соответствующего драйвера для управления и осуществления связи МРIO. Кроме того, механизм подхвата функций МРIO и/или балансировки нагрузки МРIO должен обязательно проверяться на возможность работы с WServer путем опрашивания и изучения документации производителя устройства общего хранения, производителя коммутатора волоконно-оптических каналов включительно, на предмет поддерживаемых конфигураций, и просмотра списка совместимого оборудования HCL на веб-сайте Microsoft.

    iSCSI


    При желании использовать хранилище iSCSI для отказоустойчивых кластеров WServer организациям настоятельно рекомендуется заботиться об обеспечении безопасности и изоляции сети. iSCSI использует инициатор или хост, который требует доступа к LUN-номерам или iSCSI-исполнителям. Исполнители (targets) размещаются или обслуживаются на исполнительных порталах iSCSI. В случае использования исполнительного портального интерфейса исполнитель должен настраиваться в конфигурации кластера так, чтобы к нему могли получать доступ несколько инициаторов. Как инициаторы, так и исполнительные порталы iSCSI поставляются в виде программных и аппаратных моделей, но модели и того и другого вида все равно предполагают применение IP-сетей для осуществления обмена данными между инициаторами и исполнителями. Исполнители должны представляться Windows в виде базовых дисков. В случае применения стандартных сетевых адаптеров для iSCSI-обмена данными в системах WServer может использоваться встроенный в WServer инициатор iSCSI при условии, что исполнитель iSCSI способен поддерживать предлагаемые опции аутентификации и безопасности, если таковые используются.
    Какой бы инициатор iSCSI, программная или аппаратная модель и исполнители не вы бирались, iSCSI-канал обмена данными должен обязательно развертываться в изолированных сегментах сети, и желательно с использованием отдельных сетевых коммутаторов и сетевых адаптеров. Более того, представляемые отказоустойчивому кластеру LUN-номера должны маскироваться и защищаться от всех остальных систем, которые не являются узлами кластера, путем применения механизма аутентификации и протокола IPSec соответствующим возможным образом. Внутри операционной системы WServer никакой НВА-адаптер или специальная сетевой адаптер iSCSI не должен ни использоваться для конфигурации отказоустойчивого кластера, ни развертываться с помощью сетевого командного ПО (network teaming software), иначе она не будет поддерживаться Microsoft.
    К счастью, теперь совершенно очевидно, что Microsoft желает оказывать поддержку только тем организациям, которые развертывают отказоустойчивые кластеры на протестированных и одобренных системах, но во многих случаях отказоустойчивые кластеры все равно можно будет развертывать и использовать, поскольку мастер создания кластера (Create a Cluster Wizard) позволяет развертывать даже кластеры с не поддерживаемой конфигурацией.
    При развертывании кластера для уверенности в том, что развертываемая конфигурация является поддерживаемой, нужно обязательно как следует просматривать результаты мастера проверки кластера (Validate a Cluster Wizard) на предмет прохождения всех тестов по хранилищу.

    Технология разветвленного ввода-вывода


    WServer позволяет применять технологию разветвленного ввода-вывода (Multipath I/O) для внешних устройств хранения, вроде сетей SAN и исполнителей iSCSI, в случае использования в локальной системе или общим хранилищем множества НВА-адаптеров. В частности, эта технология может применяться для обеспечения отказоустойчивого доступа к дисковому хранилищу в случае выхода контроллера или НВА-адаптера из строя, но некоторые драйверы также поддерживают балансировку нагрузки между НВА-адаптерами как в конфигурациях автономных систем, так и в конфигурациях отказоустойчивых кластеров. В состав WServer входит встроенный драйвер разветвленного ввода-вывода для iSCSI, который может применяться при условии соблюдения производителем всех необходимых для его использования спецификаций. Инициатор iSCSI, встроенный в WServer, является дружественным к пользователю и обеспечивает очень простое добавление исполнителей iSCSI, делая их повторно подключаемыми по умолчанию. Поддержка Multipath I/O (МРIO) также устанавливается по умолчанию, что отличается от прежних выпусков программного обеспечения инициаторов iSCSI.

    Использование службы VSS для тома общего хранилища


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

    ОС


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

    Развертывание отказоустойчивых кластеров


    Удаленное управление на административных рабочих станциях может быть обеспечено с помощью средства Remote Administration Tools (Инструменты удаленного администрирования), в состав которого входит оснастка Failover Cluster Manager, но компонент Failover Clustering все равно должен устанавливаться на всех узлах, которые будут принимать участие в отказоустойчивом кластере. Перед установкой самого компонента Failover Clustering на каждом узле кластера должен быть выполнен ряд шагов для подготовки к развертыванию надежного кластера. Эти шаги описаны ниже.
    • Сконфигурируйте отказоустойчивые тома или LUN-номера с помощью локальных дисков или подключаемых к SAN хранилищ для тома операционной системы.
    • Сконфигурируйте, по крайней мере, два сетевых адаптера: один для обмена данными между клиентами и кластером и один для обмена данными внутри кластера.
    • В случае использования общего хранилища iSCSI настройте для него дополнительный специальный сетевой адаптер или НВА-адаптер iSCSI аппаратной модели.
    • Для кластеров Hyper-V сконфигурируйте дополнительный выделенный сетевой адаптер на каждом узле для взаимодействия с виртуальной гостевой операционной системой.
    • После создания отказоустойчивого кластера переименуйте каждый сетевой адаптер для упрощения его распознавания внутри консоли Failover Cluster Manager. Например, если требуется и возможно, замените имя Local Area Connection (Подключение по локальной сети) на PRODUCTION (Рабочий), имя Local Area Connection 2 (Подключение по локальной сети 2) — на iSCSI NIC, а имя Local Area Connection 3 (Подключение по локальной сети 3) — на HEARTBEAT (Подключение для передачи сигналов активности). Также, если будут применяться программные средства сетевой командной работы от независимых поставщиков, заранее сконфигурируйте команду и переименуйте каждый относящийся к ней физический сетевой адаптер в TEAMMEMBER1 (Член команды 1), TEAMMEMBER2 (Член команды 2). Виртуальный командный адаптер тогда, соответственно, получит имя PRODUCTION (Рабочий). Помните, что командная работа не поддерживается и не рекомендуется для подключений iSCSI и сигналов активности.
    • Сконфигурируйте все необходимые адреса IPv4 и IPv6 как статические.

    Удостоверьтесь в том, что на всех НВА-адаптерах и других контроллерах хранилищ функционирует надлежащее встроенное ПО и подходящая версия драйвера, пригодные для использования в отказоустойчивых кластерах WServer.
    Если будет применяться общее хранилище, запланируйте использование как минимум двух отдельных LUN-номеров: одного для роли диска-свидетеля и одного для роли кластерного диска для высоконадежной группы Services and Applications.
    Если в отказоустойчивом кластере будут развертываться приложения или службы, не входящие в состав WServer, в соответствии с рекомендациями добавьте в систему дополнительный отказоустойчивый массив или LUN для хранения установочных и служебных файлов этих приложений или служб.
    Удостоверьтесь в том, что для обмена данными с общим хранилищем FС или iSCSI на уровне коммутаторов FC или Ethernet настроено должное маскирование и зонирование LUN, пригодное для отказоустойчивой кластеризации. Каждый узел в отказоустойчивом кластере, наряду с НВА общего устройства хранения, должен иметь монопольный доступ ко всем представленными этому кластеру LUN-номерам.
    Если для каждого отказоустойчивого узла или общего устройства хранения будут использоваться несколько НВА-адаптеров, удостоверьтесь в том, что был установлен подходящий драйвер разветвленного ввода-вывода (Multipath I/O). Для выполнения этой функции может применяться и встроенный в WServer компонент Multipath I/O, при условии, что это было одобрено производителями коммутаторов и устройств хранения и самой компанией Microsoft.
    Отключите все узлы, кроме одного, и на этом оставшемся узле сконфигурируйте LUN-номера общего хранилища в виде базовых дисков Windows, отформатируйте их так, чтобы они представляли один раздел или том, и затем определите для этого тома соответствующее буквенное обозначение и метку. Отключите узел, использовавшийся для настройки дисков, а затем по одному включите все остальные узлы, проверьте доступность каждого LUN-номера и при необходимости сконфигурируйте подходящее буквенное обозначение, если то, что было настроено на первом узле, не подходит.
    • Если требуется, протестируйте механизм разветвленного ввода-вывода на предмет балансировки сетевой нагрузки и/или отказоустойчивости с помощью соответствующей утилиты диагностики или мониторинга для гарантии должного функционирования каждого из узлов.
    • Назначьте доменную учетную запись пользователя, которая должна применяться для управления отказоустойчивым кластером, и добавьте ее на каждом узле кластера в локальную группу Administrators. В рамках домена предоставьте этой учетной записи разрешение на создание учетных записей компьютеров (Create Computer Accounts) на уровне домена, что позволит после создания административных и высоконадежных групп Services and Applications с ее помощью создавать необходимые учетные записи для компьютеров.
    • Создайте электронную таблицу с сетевыми имена, IP-адресами и кластерными дисками, которые будут использоваться для административного кластера и высоконадежной группы Services and Applications (Службы и приложения) или групп, развертываемых в отказоустойчивом кластере. Для каждой группы Services and Applications требуется отдельное сетевое имя и адрес IPv4, но в случае использования IPv6 адрес можно добавить отдельно в дополнение к адресу IPv4 или создать для него специальную или обобщенную группу Services and Applications.

    Самовосстановление накопителей кластера


    Для идентификации дисков служба Cluster Service по-прежнему использует подпись диска (Disk Signature), расположенную в главной загрузочной записи, но помимо этого для идентификации дисков применяются также данные SCSI Inquiry . Подпись расположена в секторе 0 и сама является частью данных диска. Но они могут изменяться по целому ряду причин. Данные SCSI Inquiry являются атрибутом LUN, предоставляемым массивом накопителей. Если службе Cluster Service по какой-то причине не удается идентифицировать диск по его подписи, она ищет диск по данным SCSI Inquiry. Если диск найден, служба Cluster Service самовосстанавливается и обновляет свою информацию о подписи диска. Точно так же, если диск найден по подписи, а его ранее известные данные SCSI Inquiry изменились, служба Сluster Service самовосстанавливается, обновляет свою информацию и переводит диск в оперативный режим. Выигрыш состоит в том, что диски теперь идентинфицируются по нескольким атрибутам.
    Возможна, конечно; экстремальная ситуация, когда для данного LUN нзменились как данные SCSI Inquiry, так и подпись диска — например, в случае восстановления после катастрофического сбоя. Чтобы противостоять подобным неприятностям, в WServer включен новый инструмент восстановления. Если диск переведен в состояние Failed или Offline, поскольку диски не удалось идентифицировать (в журнале System этому соответствует событие 1034), выполните следующие действия. Откройте оснастку Failover Cluster Management (CluAdmin.msc), щелкните правой Кнопкой ресурс Physical Disk и выберите команду Properties. Щелкните кнопку Repair в нижней части вкладки General. Будет отображен список всех общих дисков, которые еще не включены в состав кластера. Вы сможете указать, каким диском должен управлять данный дисковый ресурс, и восстановить отношения между логическими дисками и физическими дисковыми ресурсами кластера. Как только вы выбираете восстановленный диск, его свойства обновляются. Вы можете перевести диск в оперативный режим, где им снова смогут пользоваться службы и приложения высокой доступности.

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


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

    Проверка кластеров


    Допустим, корпорация отказывается от сертификации и включения в каталоги HCL (www.microsoft.com/whdc/hcl/default.mspx) или Windows Server Catalog целых кластерных решений, вместо этого предоставляя своим клиентам необходимый инструментарий для собственноручной проверки этих решений. Это не означает, конечно, что вы теперь можете собирать отказоустойчивый кластер по кусочкам от разных производителей. Microsoft пытается сделать модель несколько более гибкой, но отнюдь не призывает вас приматывать разные запчасти друг к другу скотчем. Правда, вы по-прежнему должны покупать оборудование, помеченное эмблемой Windows, то есть, сертифицированное в рамках Windows Logo Program, и теперь у вас уже нет обязанности покупать все решение целиком у одного производителя (хотя в большинстве случаев это самый правильный образ действия).
    Настраивайте подходящие параметры управления электропитанием для системы и сетевых адаптеров во всех кластерных узлах.
    После выполнения требований к аппаратному обеспечению и подключения серверов кластера к хранилищу данных вы можете установить компонент Средство отказоустойчивости кластеров на всех серверах (например на двух для файлового кластера).
    На втором шаге мастера проверки конфигурации Select Servers or a Cluster указываем на узлы, которые будут тестироваться. Далее отмечаем тесты для выполнения. А вот при подключении следующего узла некоторые тесты можно пропустить. Обрати внимание на тесты, которые помечены значком с восклицательным знаком (Warning; есть еще и not applicable , но они не так критичны). Если не будут убраны все предупреждения, «мастер создания кластера», который мы собираемся вскоре запустить, скорее всего, прекратит работу из-за ошибки. Предупреждение является следствием, например, наличия точки отказа. Если некоторые тесты закончились результатом Failed, соответствующую проблему необходимо решить, а затем заново запустить процесс проверки; иначе кластер WServer должным образом работать не будет (даже если вам удалось завершить процесс его создания). Нажми на More about cluster validation tests, — так можно вызвать соответствующий раздел справки. после закрытия мастера отчет сохраняется в html-файле в каталоге SystemRoot\Cluster\Reports\Validation Report на всех проверяемых серверах (В этой папке на каждом узле кластера сохраняются все конфигурационные отчеты). Имейте в виду, что в некоторых конфигурациях этот процесс может длиться довольно долго (скажем, полчаса).
    Существуют четкие требования к программно-аппаратному обеспечению отказоустойчивых кластеров.
    1. Используйте группу соединенных компьютеров, состоящую из одинаковых или похожих компонентов (рекомендуется). Убедитесь, что на всех серверах кластера установлены одни и те же обновления. В противном случае вы можете получить непредсказуемые результаты начиная с предупреждений во время проверки. В качестве узлов кластера можно использовать либо контроллеры домена, либо рядовые серверы, но не те и другие одновременно. Если вы попытаетесь это сделать, проверка кластера завершится ошибкой. (Как правило, Microsoft не рекомендует размещать узлы кластера на контроллерах домена). Учетные записи всех серверов, которым предстоит стать узлами кластера, должны располагаться в одном домене и в одном подразделении. Подходит нам только WServer Enterprise или Datacenter. Обязательно включение серверов в домен AD. Предпочтительна одинаковая роль рядового сервера.
    2. Аппаратное обеспечение для сетей, как и остальные компоненты, должно быть совместимо с WServer. Можно соединить узлы кластера посредством нескольких отдельных сетей. Альтернативный вариант — связать узлы кластера с одной сетью, построенной с помощью объединенных в группу сетевых адаптеров, резервных коммутаторов, резервных маршрутизаторов или аналогичного оборудования, позволяющего устранить единичные точки отказа. Это весьма пригодится, так как помимо Heartbeat-сообщений, которые предназначены для мониторинга состояния узлов кластера, по кластерному сетевому интерфейсу будут идти данные синхронизации и управления.
  • Контроллеры устройств или соответствующие адаптеры для хранилища. Если вы используете интерфейсы SCSI с последовательным подключением или FC, то контроллеры запоминающих устройств большой емкости, предназначенные для системы хранения данных кластера, должны быть идентичными во всех кластеризованных серверах. Кроме того, на них должна быть установлена одна и та же версия встроенного программного обеспечения. При использовании интерфейса iSCSI у каждого сервера в кластере должен быть хотя бы один сетевой адаптер или адаптер главной шины НВА, выделенный для системы хранения данных кластера. Сеть, которую вы применяете для технологии iSCSI, не может быть использована для сетевых взаимодействий. Во всех серверах кластера сетевые адаптеры, используемые для подключения к хранилищу iSCSI-цели, должны быть одинаковыми. Рекомендуется также применять адаптеры Gigabit Ethernet или адаптеры с большей скоростью. (Обратите внимание на то, что для технологии iSCSI нельзя использовать объединенные в группы сетевые адаптеры).
    Если в вашей сети SAN на основе Fibre Channel или iSCSI поддерживается МРIO, в ходе проверки будет проведен тест, поддерживается ли ваша конфигурация. В хранилище кластера необходимо использовать команды Persistent Reserve из нового стандарта SCSI-3, а не из старого стандарта SCSI-2.
  • Общее хранилище данных, совместимое с WServer. Для отказоустойчивого кластера, состоящего из двух узлов, хранилище данных должно содержать минимум два отдельных тома (LAN), настроенных на аппаратном уровне. Первый том будет функционировать в качестве диска-свидетеля, который содержит копию базы данных кластерной конфигурации. Второй том будет содержать общие файлы пользователей.
    Развертывайте операционные системы кластерных узлов только на отказоустойчивых дисковых массивах.
    Ниже перечислены требования, предъявляемые к хранилищу.
    а) Чтобы иметь возможность использовать встроенные средства поддержки дисков, включенные в отказоустойчивый кластер, задействуйте базовые, а не динамические диски.
    б) Рекомендуется отформатировать разделы дискового хранилища под файловую систему NTFS (Для раздела диска-свидетеля файловая система NTFS является обязательной).
    в) При развертывании SAN с помощью отказоустойчивого кластера получите гарантии производителей и поставщиков относительно того, что хранилище, включая все драйверы, встроенное программное обеспечение и другие программы, используемые для хранилища, совместимы с отказоустойчивыми кластерами в WServer.
    Тесты хранилищ сначала собирают данные с узлов кластера и определяют, какое хранилище доступно для всех узлов. Это общее хранилище будет считаться потенциальным диском кластера. Когда список всех таких устройств составлен, производятся тесты времени задержки, процедуры выбора общих дисков, процедуры отказоустойчивого переключения дисков между всеми узлами кластера, наличия сценариев множественного выбора устройств, файловой системы, использования стандарта MS-MPIO (если применяется многопутевое ПО), соответствие командам SCSI-3 SPC3 (Persistent Reservations, Unique Disk IDs), а, также сценариев одновременного сбоя.
  • Все серверы кластера должны быть либо 32-разрядными, либо 64-разрядными; совместить эти архитектуры в одном кластере нельзя (компьютеры х64 и IА64 тоже нельзя комбинировать в одном кластере).
  • Должны быть запущены нужные кластеру службы (например, служба Remote Registry).
    Благодаря тому, что процесс проверки встроен в продукт, вы получаете дополнительный способ диагностики возникающих проблем. Проверку можно запустить и на уже настроенном кластере, как полностью, так и частично (только заданную группу тестов). Единственное ограничение состоит в том, что перед проверкой хранилища все физические диски должны быть переведены в автономный режим (Offline). Иными словами, придется на некоторое время прекратить обслуживание клиентов.
    Сразу после того как программа завершит проверку конфигурации, создайте кластер, запустив Мастер создания кластера. На заключительном этапе необходимо запустить Мастер высокой надежности (High Availability Wizard) для настройки режима работы кластера и определения доступности выбранных служб.
    Если оснастка Failover Cluster Management используется на сервере, который не является узлом мастера (в составе компонента Remote Server Administration Tools), пользователь должен вручную добавить в нее все кластеры, которыми предполагается управлять. Когда она открыта на узле кластера, производится подключение к службе мастера (если она запущена на локальном узле). Кластер, в который входит данный узел, показан в левой панели.

    Создание


    Этот мастер устанавливает основное программное обеспечениедля кластера, преобразует подключенную систему хранения в диски кластера и создает для кластера учетную запись компьютера в AD. Для запуска этого средства в оснастке Failover Cluster Management щелкните ссылку Создать кластер в разделе Управление.
    В окне Мастера создания кластера в ответ на приглашение программы введите имена узлов кластера. Затем мастер предложитвам ввести имя кластера и назначить ему IP-адрес, после чего этот кластер будет создан.
    Выполните указания мастера Create a Cluster: задайте имена серверов, введите имя кластера (следуя стандартным соглашениям), чтобы задать точку доступа клиентов (Client Access Point, САР), задайте информацию о статических 1Р-адресах (если на узлах не применяется DHCP) и щелкните Finish. Когда вы закончите работу отчет о ней в виде XML-файла будет помещен в папку %windir%\cluster\reports на каждом узле кластера. Помните, что максимальное количество узлов зависит от использованной архитектуры процессоров. Кластеры на оборудовании х64 могут содержать до 16 узлов, тогда как в архитектурах х8б и IA64 их число ограничено восемью. Это ограничение распространяется как на версию Enterprise, так и на версию Datacenter.
    После завершения работы мастера потребуется настроить службы и прило-жения, для которых нужно обеспечить отказоустойчивость. Для выполненияданного вида настройки запустите Мастер высокой надежности (High Availabi-lity Wizard).

    Запуск Мастера высокой надежности


    Мастер высокой надежности (High Availability Wizard) настраивает параметры высокой надежности для отдельных служб и приложений. Для запуска этого мастера в оснастке Failover Cluster Management щелкните пункт Настройка службы или приложения в разделе Действия или в области Конфигурировать.
    1. На странице Выберите службу или приложение выберите службу или приложение, для которых требуется обеспечить высокую надежность, и щелкните кнопку Далее.
    2. Следуйте инструкциям мастера для уточнения необходимых деталей относительно выбранной службы. Например, для службы Файловый сервер необходимо определить следующие параметры:
    • имя кластеризованного файлового сервера;
    • данные IP-адресации, не предоставляемые автоматически используемыми параметрами DHCP;
    • один или несколько томов хранилища, которые должны использоваться этим кластеризованным файловым сервером.

    Есть возможность создания пустого сервиса: это можно сделать из меню More actions — Create Empty Service or application.

    Файловый сервер


    Выбранная роль уже должна быть установлена.
    Щелкните Next и задайте имя точки доступа клиентов (САР) для вашего кластера (следуя стандартным соглашениям). Если серверы подключены к нескольким сетям, и вы применяете статическую адресацию, вам придется указать адреса для всех подсетей, поскольку мастер предполагает, что вы хотите обеспечить высокую доступность файлового сервера для пользователей во всех подключенных подсетях.
    На средней панели показано САР-имя экземпляра файлового сервера (оно отличается от САР-имени самого кластера) и имя общего реcypca, используемого этим экземпляром. На панели Actions перечислены дополнительныевозможности, например добавление общей папки, добавление хранилища и пр. Командой Add a Shared Folder, будет запущен мастер Create a Shared Folder Wizard.В этом мастере вы можете указать папку на общем диске и открыть к ней доступ, чтобыданные на файловом сервере были доступны другим пользователям. В WServer разрешается создавать новые файловые общие ресурсы при помощи Explorer.
    Введя команду cluster res, вы уведите список всех ресурсов кластера с информацией об их состоянии. Общие папки будут отображаться в формате UNC, например, \\\. Команда cluster .res / priv отобразит свойства Private экземпляра файлового сервера (например, ресурса Network Name), акоманда cluster .res /prop покажет его свойства Public.
    Еще одна новинка файловых серверов в WServer — области (scoping) общих файловых ресурсов. По умолчанию области действия включены, в чем можноубедиться, взглянув на значение параметра ScopedName, отображенного в составе свойствPrivate ресурса Network Name. Областью действия ограничены ресурсы сервера, видимые через подключение NetBIOS, например, когда вы вводите в командной строке netview \\, где имя САР — ресурс Network Name отказоустойчивого кластера, а не экземпляра файлового сервера. Запустив эту команду в прежних версиях кластерных платформ Windows, вы увидели бы все общие ресурсы, размещенные на кластере.В WServer вы не увидите ничего, поскольку общие папки входят в областьотдельных экземпляров файлового сервера, а не самого кластера. Чтобы увидеть общиересурсы из области конкретного экземпляра файлового сервера, введите в команднойстроке net view \\
    Наконец, на кластере с файловым сервером вы можете включить для общих папок функцию Access Based Enumeration (ABE). Ее назначение — разрешить пользователям домена просматривать толь-ко те файлы и папки общих сетевых ресурсов, на доступ к которым у них есть разрешение. (Если вам интересно, это достигается посредством установки флага SHARE_INFO_1055 общей папки с помощью API NetShareSetInfo, как описано в MSDN.) Чтобы задействовать ABE для общей папки на кластерном файловом сервере WServer,откройте окно Properties общего ресурса, затем окно Advanced Settings и установитефлажок Enable Access Based Enumeration.
    Появилось по-настоящему крутое нововведение — Shell Integration. Благодаря нему выможете просто открыть Explorer и создавать общие ресурсы обычным способом. Компонент Failover Clustering сам разберется, что с ним делать. Если вы создаете ресурс на диске кластера, общий файловый ресурс будет создан в кластере. Это означает, что не о чем беспокоиться даже администраторам, не особо разбирающимся в кластерах. Файловые ресурсы на кластере управляются точно так же, как и файловые ресурсы на любом другом файловом сервере!
    Диски или LUN, которые предполагается задействовать в кластере, должны быть доступны только узлам кластера. Для подключения можно использовать iSCSI, диспетчер хранилища для сетей SAN или любой другой интерфейс, предоставленный производителем системы хранения. Для проверки видимости на одном из узлов будущего кластера следует перейти в администрирование -> управление компьютером -> устройства хранения -> управление дисками. Если нужные диски доступны в списке, значит, можно переходить к следующему этапу.
    консоль можно вызвать из administrative
    tools — или введя команду cluadmin.msc в окне терминала.
    интерфейс консоли традиционен для Win2k8. окно разде-
    лено на три области: в левой области показаны кластеры, а
    подменю открывает доступ к настройкам. в центре выводится
    информация о выбранном объекте. в правой же части можно
    активировать действия, также доступные из контекстного
    меню. но при помощи этой консоли нельзя управлять кластерами предыдущих версий Windows, отмечу это специально.
    затем по подсказкам мастера последовательно добавляем в список серверы, которые будут входить в состав кластера. На странице access point for administering the Cluster указываем имя кластера и его ipv4-адрес. проверяем установки на странице Confirmation и, если все правильно, нажатием next начнем процесс создания кластера. едва мастер закончит работу, появится страница Summary. посмотри, она не содержит записей об ошибках? нет? тогда создание кластера можно считать завершенным. новый кластер появится в окне консоли failover Cluster Management.
    подключиться к кластеру, которого нет в списке, можно щелчком по записи failover Cluster Management. появится контекстное меню. выбери в нем команду Manage a Cluster.
    кластер создан, но необходимо еще кое-что сделать для оптимизации работы. перемещаясь по вкладкам, проверь установки кластера. чтобы сервера для обмена информацией внутри кластера не использовали сеть, предназначенную для передачи основного потока данных, нужно выбрать
    ее в списке networks. далее — в контекстном меню перейти к пункту properties («свойства») и активировать параметр Do not allow the Cluster to Use this network («запретить кластеру использовать эту сеть»). есть еще один момент: в идеале каждый узел должен иметь одинаковое количество сетевых адаптеров, а их имена — обладать такими названиями, которые помогут администратору понять, к какой сети они подключены. по умолчанию интерфейсы имеют имена вроде «Cluster network 1», «Cluster network 2».
    не очень-то удобно! поэтому отметь сеть (в среднем окне будут выведены ее характеристики) и в контекстном меню ткни пункт rename. впиши новое имя сети. аналогично поступаем и с остальными.
    добавить новый узел в кластер очень просто. для этого в поле nodes выбираем add node и следуем указаниям «мастера добавления узла» (add node Wizard). основной страницей мастера будет Select Server page, на которой указываются данные нового сервера. после нажатия на next начнется процесс добавления узла. Результат этой операции будет показан в Summary. сам видишь, ничего сложного.
    хочешь знать, что происходит при развертывании отказоустойчивого кластера в active Directory? в контейнере «компьютеры» создается ряд объектов виртуальных компьютеров (vCo — virtual Computer object). они относятся ко всем ресурсам сетевого имени кластера, создаваемым, как «точки доступа клиента» (Cap — Client access points ). Cap понадобится даже для работы одноузлового кластера. окно, требующее его создать, будет появляться несколько раз по ходу настроек — и еще успеет тебе надоесть. так что, в меню action выбери пункт add a resource, затем Client access point и следуй указаниям еще одного мастера. фактически, он похож на предыдущий: необходимо только указать незанятый ip-адрес для Cap и все.
    Развертывание сервиса
    перед добавлением file Server необходимо, зайдя в Storage, убедиться, что дисковые ресурсы доступны кластеру.
    при необходимости можно добавить ранее не подключенные к кластеру диски: выбери в контекстном меню add Disk и укажи устройство хранения. по окончании работы мастера новый диск перейдет из категории local Disks в Clustered Disks.
    введи стандартные параметры:
    имя файлового сервера, его ip-адрес и тома, к которым нужно обращаться. по окончании работы мастера файловый сервер появится в дереве консоли Services and applications.
    выбираем его и в контекстном меню отмечаем пункт provision a Shared folder Wizard. Это вызовет одноименного мастера. следуя его инструкциям, укажи параметры создаваемой общей папки: путь и имя, разрешения файловой системы и расширенные параметры протокола SMB (кэширование, число пользователей). после завершения мастера
    проверь работу файлового сервера. затем переведи его в
    режим онлайн, выбрав в контекстном меню команду Bring
    this service or application online.
    в дальнейшем за работой файлового сервера можно следить из консолей Server Manager, failover Cluster Management и Event viewer.

    Тестирование отказоустойчивого кластера


    Когда работа мастера будет завершена, протестируйте отказоустойчивый кластер с помощью оснастки Управление отказоустойчивым кластером. Удостоверьтесь, что в дереве консоли развернута ветвь Службы и приложения, и выберите службу, которую вы только что добавили с помощью Мастера высокой надежности. Щелкните ПКМ службу кластера, затем щелкните Переместить эту службу или приложение на другой узел (а локальную в оффлайн) (Move This Service Or Application To Another Node) и выберите один из доступных узлов.После перемещения экземпляра кластеризованного файлового сервера изменения состояния можно увидеть в центральной области оснастки. Успешное перемещение службы свидетельствует о правильной работе функции отказоустойчивости.

    Удаленные узлы отказоустойчивого кластера


    Нa отказоустойчивые кластеры предыдущих версий накладывалось следующее ограничение: все узлы, кластера должны были располагаться в одной и той же логической IP-подсети. В частности, обмен данными между узлами кластера не допускал маршрутизации. Требования предъявлялись не только к репликации хранилищ, но и к организации сетей. Организациям, создававшим географические кластеры, приходилось соединять свои удаленные филиалы виртуальными ЛВС.
    К кластерным решениям ранее предъявляли требование включения в каталог Windows Server Catalog. Среди прочего в этом каталоге есть и категория Geographically Dispersed. Как правило, решения для географически разнесенных кластеров реализуются сторонними производителями оборудования. За исключением сервера Microsoft Exchange Server 2007, который развертывается как кластер с непрерывной репликацией (Cluster Continuous Replication, CCR), состоящий из двух узлов, собственной реализации репликации данных для географических кластеров у Microsoft нет.
    Чтобы реализовать эту функциональность, пришлось полностью переписать сетевой драйвер кластера и изменить способ настройки ресурсов Network Name кластера. В предыдущих версиях отказоустойчивых кластеров-ресурс Network Name должен был зависеть по меньшей мере от одного ресурса IP-адреса. Если ресурс IP-адреса неспособен перейти в оперативный режим или находится в нем, но перестал работать, ресурс Network Name также теряет работоспособность. Если ресурс Network Name зависел от двух различных ресурсов IP-адресов, он прекращал работать, когда сбой происходил хотя бы в одном из этих ресурсов. В компоненте WServer Failover Cluster все изменилось. На смену логике AND пришла логика OR. (Точнее, она используется по умолчанию, но вы вольны ее перенастроить.) Теперь ресурс Network Name, зависящий от ресурсов IP-адресов, поддерживаемых сетевыми интерфейсами в разных подсетях, сохраняет работоспособность, если в оперативном режиме находится по крайней мере один из этих ресурсов IP-адресов.

    NLB


    Кластер с балансировкой сетевой нагрузки (Network Load Balancing) (ферма NLB) — масштабируемая группа серверов для служб и приложений TCP/IP, прозрачно распределяющая клиентские подключения между несколькими серверами с реплицированной конфигурацией. Администратор NLB несет ответственность за поддержание конфигурации приложений и служб, версии и механизма безопасности операционной системы, а также обновлений и данных в согласованном состоянии на каждом узле кластера NLB независимо. NLB особенно удобна для масштабирования приложений без отслеживания состояния, работающих на веб-серверах, при возрастающем количестве клиентов, но ее также можно применить для обеспечения доступности серверов терминалов, медиа-серверов и даже VPN-серверов. NLB может быть зависим от возможности приложения/службы (например, если сессия клиента может начинаться и заканчиваться только на одном узле). В случае веб-приложения, такого как приложение электронной коммерции, сеанс с SSL-шифрованием или приложение, аутентифицируемое веб-сервером, кластер NLB должен самостоятельно руководить всем взаимодействием между клиентом и конкретным кластерным узлом. На рис. 2-18 изображена базовая конфигурация веб-фермы NLB, расположенная за кластером брандмауэра NLB.
    NLB применяет виртуальные IP-адреса и общее имя. В технологии распределения нагрузки NLB централизованный диспетчер не используется. NLB не реплицирует конфигурацию сервера или наборы данных приложений. Поскольку проведение репликации данных между узлами кластера она не предусматривает и потому не обеспечивает отказоустойчивой кластеризации, использовать приложения, требующие доступа к динамическим или часто изменяемым локальным данным, в кластерах NLB не рекомендуется. В NLB-кластер можно включать до 32 узлов на x64-редакциях, и до 16 — на x86. Есть полная поддержка IPv6 серверами NLB. Имеется также поддержка множественных выделенных IP-адресов ( dedicated IP address, DIP). Это означает, что помимо множественных виртуальных IP-адресов (virtual IP address, VIP), кластеры NLB теперь могут иметь несколько DIP-адресов IPv6.
    Поддерживается NLB и в Server Core. Поддерживается автоматическая установка NLB.
    NLB автоматически определяет серверы, отключенные от NLB-кластера, и затем перераспределяет запросы клиентов на оставшиеся рабочие хосты. В механизме NLB вы можете установить процент нагрузки для каждого хоста.
    Как показано на рис 9-4, драйвер NLB является драйвером режима ядра, который работает на каждом сервере кластера NLB. Главная причина для полной переработки драйвера NLB состоит в том, что он теперь представляет собой легкий модуль фильтра NDIS 6.0. Это означает, что он стал чище, компактнее и быстрее.
    • Диспетчер NLB стал более надежным благодаря усовершенствованиям WMI, позволяющим автоматически восстанавливать базу данных если она испорчена или случайно удалена.
    • Усиленная защита от атак DoS. Используя открытый интерфейс обратного вызова, NLB способен уведомлять приложения об атаках SYN, чтобы можно было предпринять шаги для решения проблемы.

    Microsoft не поддерживает возможность использования отказоустойчивых кластеров и кластеров NLB на одной и той же системе WServer. Многоуровневые приложения могут пользоваться преимуществами обеих этих технологий путем применения NLB для балансировки нагрузки на клиентских серверах приложений, а отказоустойчивых кластеров — для предоставления возможностей подхвата функций прикладным базам данных, которые либо содержат слишком большие объемы данных для того, чтобы их можно было реплицировать в течение дня, либо не могут выдерживать более чем нескольких минут простоя в случае выхода узла или службы из строя.
    Процедуры для резервного копирования и восстановления узлов NLB ничем не отличаются от тех, что применяются для автономных серверов. Полная резервная копия системы должна обязательно делаться с помощью программы Windows Server Backup до и после внесения в конфигурацию сервера или кластера NLB любых серьезных изменений. Восстанавливаться конфигурация NLB может просто путем восстановления состояния системы (System State) конкретного узла.
    Управление кластером NLB также может производиться и с помощью утилиты командной строки NLB.ехе, а также с использованием некоторых новых команд PowerShell, включенных в WServer. Диспетчер NLB позволяет удалять и приостанавливать работу узлов в кластере для проведения обслуживания, а также установки аппаратных или программных обновлений.

    Создание правил для портов


    Правила для портов в кластере NLB отвечают за то, нагрузка сетевого трафика какого типа будет балансироваться между кластерными узлами, и как именно будет осуществляться управление соединениями. Опция Filtering Mode (Фильтрация правил портов) в правилах для портов отвечает за то, как трафик будет балансироваться на каждом отдельном узле. Из-за того, что в кластере NLB на кластеризованный IP-адрес может откликаться каждый узел, весь входящий трафик получается и обрабатывается всем узлами. Когда узел получает запрос, он либо обрабатывает его, либо отбрасывает, если для него уже успел создать сеанс и отправить ответ какой-то другой узел.
    Когда администратор удаляет предлагаемое по умолчанию правило для портов в кластере NLB и создает правило, разрешающее откликаться на кластеризованный IP-адрес или адреса только определенным портам, и еще одно дополнительное правило, предусматривающее блокировку всего остального направляемого на данный IP-адрес трафика, все узлы в кластере получают возможность быстро исключать и отбрасывать те пакеты, которые не отвечают этим правилам. При создании правил для портов в кластере NLB, администратор NLB должен обязательно конфигурировать соответствующий режим фильтрации. Этот режим позволяет администратору указывать то, должен ли на поступающие от одного и того же клиента запросы на протяжении сеанса откликаться только один узел или же несколько. Всего существует три режима фильтрации:
    Режим фильтрации Single Host делает так, чтобы весь трафик, отправляемый на IP-адрес кластера, который удовлетворяет параметрам правила для портов с таким включенным режимом фильтрации, обрабатывался в кластере исключительно одним конкретным узлом.
    Режим фильтрации Disable This Port Range указывает кластеру, какие порты являются не активными для его IP-адреса. Все получаемые на этот IP-адрес запросы, которые удовлетворяют параметрам правила для портов с таким включенным режимом фильтрации, заканчиваются автоматическим отбрасыванием или удалением содержащихся в них сетевых пакетов. Администраторы должны конфигурировать и использовать такой режим фильтрации для тех портов и диапазонов портов, которые не нуждаются в балансировки нагрузки между узлами кластера.
    Режим фильтрации Multiple Host (Несколько хостов) является, пожалуй, наиболее часто используемым режимом фильтрации, а также режимом, применяемым по умолчанию. Он позволят трафику обрабатываться всеми узлами кластера. А при балансировке трафика между несколькими узлами должен также обязательно устанавливаться и режим Affinity (Сходство). Для этого режима могут устанавливаться 3 следующих параметра:
    1. None (Отсутствует). Этот параметр позволяет посылать во время охватываемых (span) сеансов уникальные клиентские запросы всем серверам в кластере. Он может повышать показатели времени отклика сервера, но больше всего подходит только для передачи клиентам статических данных. Он также довольно неплохо работает с данными просмотра веб-страниц, данными доступных только чтения файлов и данными серверов FTP.
    2. Network (Сеть). Этот параметр предусматривает маршрутизацию всего трафика из определенного адресного пространства класса С какому-то одному узлу кластера NLB. Такой режим применяется не очень часто, но вполне может настраиваться для обслуживания таких клиентских сеансов, в которых используются приложения, требующие сохранения данных о состоянии, или в которых клиентские запросы обраба-
    тываются маломощными прокси-серверами. Он удобен для тех компаний, в которых трафику из нескольких удаленных офисов перед подключением к службам приходится проходить через прокси-серверы и/или в которых управление приложениями осуществляется на основании установленных в кластере NLB правил для портов.
    • Single (Один). Этот параметр применяется наиболее часто. Он позволяет делать так, чтобы после получения узлами кластера первоначального запроса от определенного клиента все остальные запросы от этого же клиента до самого завершения сеанса обрабатывал только один из этих узлов. Такой режим может быть удобен для обслуживания сеансов, в которых требуется сохранение данных о состоянии, вроде сеансов веб-приложений с применением SSL-шифрования или сеансов удаленных рабочих столов (Remote Desktop). Он является стандартным режимом фильтрации при настройке правил для портов и идеально подходит для работы с практически любой службой или приложением в кластере NLB.

    Настройка NLB-кластера


    Настройте на двух серверах службу или приложение. Установите компонент NLB на всех серверах.
    Каждый узел в кластере NLB может также конфигурироваться с множеством сетевых адаптеров. Каждый адаптер, в свою очередь, может ассоциироваться с другим кластером NLB и поддерживать множество кластеров, но имя DNS и IP-адрес(а) у каждого кластера все равно должны быть свои. Единственной невозможной конфигурацией является создание одиночного кластера NLB, предусматривающего использование множества сетевых адаптеров в одном единственном узле. Для назначения множества адаптеров одиночному кластеру NLB перед конфигурированием этого кластера потребуется обязательно загрузить специальное стороннее программное обеспечение по созданию командных сетей; тогда в кластере можно будет использовать адаптер Virtual Team Network (Виртуальная командная сеть), однако конфигурировать такие командные физические адаптеры с NLB нельзя.
    1. Диспетчер балансировки сетевой нагрузки (Nlbmng.exe)-Создать кластер. В случае указания сервера, являющегося удаленной системой, и невозможности подключиться к нему, удостоверьтесь в том, что в параметрах брандмауэра этой удаленной системы активизировано исключение Inbound Remote Administration (Входящее удаленное администрирование).
    2. Настройка сетевых адаптеров для NLB эта процедура может выполняться как непосредственно во время создания кластера с помощью консоли NLB Manager, так просто путем редактирования для сетевых адаптеров каждого из кластерных узлов свойств TCP/IP. Для тех узлов в кластере NLB, которые будут работать в режиме Unicast, рекомендуется настраивать два сетевых адаптера, так чтобы один мог отвечать за обмен данными между хостами, а второй — только за обмен данными в самом кластере. Настройка нескольких сетевых адаптеров может также расширять возможности, необходимые для осуществления контроля за трафиком и управления настройками сетевой безопасности. Интерфейс содержит виртуальный IP-адрес и принимает клиентский трафик для балансировки нагрузки.
    3. Приоритет (Уникальный идентификатор узла). Узел с наименьшим числовым значением приоритета среди остальных членов кластера обрабатывает весь сетевой трафик кластеров, на которые не распространяются правила для портов. Вы можете переопределить данные приоритеты или установить балансировку нагрузки на конкретный диапазон портов, указывая правила портов на вкладке Правила портов окна Свойства NLB.
    4. На странице Параметры узла удостоверьтесь, что назначенный IP-адрес из выбранного вами интерфейса отображен в списке. В противном случае щелкните кнопку Добавить.
    5. Введите IP-адрес кластера, который будет совместно использоваться каждым узлом в кластере. NLB добавит этот IP-адрес в стек TCP/IP выбранного интерфейса всех узлов, которые должны быть частью кластера. Технология NLB не поддерживает DHCP. Протокол DHCP будет отключен на всех настраиваемых интерфейсах, поэтому IP-адреса должны быть статическими. При необходимости добавьте аналогичным образом другие дополнительные IP-адреса
    6. На странице Параметры кластера в области IP-конфигурация кластера задайте соответствующие значения для IP-адреса и маски подсети, затем введите Полное интернет-имя (FQDN) для кластера. Обратите внимание на то, что для 1Ру6-адресов не требуется указывать маску подсети. Заметьте также, что при использовании NLB со Службами терминалов не нужно вводить и Полное интернет-имя. Если на предыдущей странице было определено несколько IP-адресов, на этой странице каждый из них можно будет выбрать в соответствующем выпадающем списке и по очереди снабдить Интернет-именем и режимом работы кластера.
  • На странице Параметры кластера в области Режим работы кластера (Cluster Operation Mode) щелкните параметр Одноадресный (Unicast) — тем самым вы укажете, что для операций кластера должен использоваться одноадресный МАС-адрес. В одноадресном режиме МАС-адрес кластера назначается сетевому адаптеру компьютера, и встроенный МАС-адрес сетевого адаптера не используется. Для данного режима рекомендуем принять параметры по умолчанию. Этот выбор зависит от типа сетевой связи службы или приложения, которое будет использоваться в данном кластере NLB. Для веб-трафика, например, — Unicast.
    Всего существует 3 возможных режима работы кластера: Unicast (Одноадресный), Multicast (Многоадресная рассылка) и IGMP Multicast (Многоадресный IGMP). Большая часть традиционного сетевого трафика обрабатывается с помощью режима Unicast, при котором между клиентами и серверами поддерживается сетевое соединение типа "один к одному". Режим Multicast позволяет серверу отправлять информацию на один рассылочный адрес для обработки рядом клиентов. Для получения рассылочных данных клиент присоединяется к рассылочной группе, которая ассоциируется с данным рассылочным адресом, и получает от сервера только одну подачу или пересылку данных, что упрощает и улучшает сетевую производительность приложения. Трафик в режиме Multicast обычно передается только в одном направлении, и клиент рассылки начинает получать его сразу же, как только присоединяется к группе. К числу наиболее распространенных приложений, в которых применяется такой режим, относятся веб-сайты с потоковым видео, Интернетрадиостанции и онлайновые не интерактивные Интернет-курсы. Режим IGMP Multicast может применяться вместо режима Multicast и улучшает общую сетевую производительность в тех случаях, когда требуются возможности многоадресной рассылки. Выбор такого протокола управления позволяет рассылочным клиентам регистрироваться с помощью сервера IGMP Milticast, после чего трафик рассылки пересылается только на порты или транки коммутаторов, отвечающие за установку соединения с клиентами рассылки, что сокращает нагрузку на порты остальных сетевых переключателей. Одним важным моментом, который нужно знать о трафике рассылки, является то, что сетевые переключатели и маршрутизаторы, через которые будет проходить этот трафик, должны обязательно поддерживать передачу трафика такого типа и разрешать ее. Во многих переключателях и маршрутизатрах класса предприятия поддержка рассылки по умолчанию отключена.
    8. На странице Port Rules по умолчанию уже будет предлагаться одно созданное заранее правило, предусматривающее осуществление распределения сетевой нагрузки для всего трафика на всех портах по всему кластеру NLB между IPадресом кластера и специальным IP-адресом локального сервера. Настроить Правила для портов (Port Rules) можно следующим образом.
    • В области Диапазон портов (Port Range) выберите нужный диапазон в соответствии со службой, которую должен обеспечить NLB-кластер.
    • В области Протоколы выберите TCP или UDP, чтобы применить правила для портов к протоколу TCP/IP. Правила ограничивают сетевой трафик только для указанного протокола. Трафик, который не связан с правилом для порта, обрабатывается узлом по умолчанию.
    • В области Режим фильтрации (Filtering Mode) выберите Несколько узлов (Multiple Host), если вы хотите, чтобы для выбранного правила для порта сетевой трафик обрабатывался несколькими узлами в кластере. Выберите Один узел (Single Host), если хотите, чтобы сетевой трафик обрабатывался одним узлом.
    • Для параметра Сходство (Affinity) (применяется только для режима фильтрации Несколько узлов) установите значение Нет(None), если вы хотите, чтобы соединения с одного и того же IP-адреса клиента направлялись на различные узлы кластера. Оставьте параметр Один, чтобы NLB направляла запросы с одного IP-адреса клиента на один и тот же узел кластера. Выберите параметр Сеть, если необходимо, чтобы NLB направляла запросы с локальной подсети на один и тот же узел кластера.

  • Вернувшись на страницу Port Rules, щелкните на кнопке Add, чтобы создать дополнительное правило для портов. В разделе диапазона портов укажите в качестве начального значения значение 0, а в качестве конечного — значение 79, в разделе протоколов выберите переключатель Both , в разделе режима фильтрации установите переключатель Disable This Port Range (Отключить этот диапазон портов). И для оставшихся портов так же.
    По возвращении в окно консоли Network Load Balancing Manager кластер уже будет создан и переведен в оперативный режим, а его IP-адреса автоматически добавлены в свойства TCP назначенного сетевого адаптера. Закройте окно консоли и выйдите из системы сервера.
  • Когда откроется окно консоли Network Load Balancing Manager, выберите в меню Cluster пункт Connect to Existing. Когда откроется страница Connect (Подключение), введите имя хоста того кластерного узла в кластере, к которому будут добавляться дополнительные узлы. Введите NODE02 и щелкните на кнопке Connect, чтобы извлечь список всех кластеров NLB, которые функционируют на данном хосте.Войдите в систему WServer от имени учетной записи с правами локального администратора. Для того чтобы добавить узлы к кластеру, щелкните ПКМ кластер, а затем щелкните Добавить узел к кластеру. Настройте параметры узла (включая приоритет узла и назначенные IP-адреса) для всех добавляемых узлов, следуя тем же инструкциям, которые вы выполняли при настройке исходного узла. Поскольку вы добавляете узлы к уже настроенному кластеру, все общие для кластера параметры останутся неизменными.
    11. На странице Параметры хоста просмотрите предлагаемые параметры и щелкните на кнопке Next. Предлагаемых по умолчанию параметров должно быть достаточно, если только не требуется изменить значение Host ID или если к адаптеру уже не было привязано несколько IPадресов; в таком случае сначала выберите желаемый IP-адрес, который должен использоваться специально для передачи данных в кластере NLB, и только затем щелкните на кнопке Next.
    12. На странице Port Rules просмотрите существующие правила для портов кластера, и если не хотите, чтобы данный узел отвечал за обработку какого-то другого типа трафика в данном кластере, оставьте правила без изменений и щелкните на кнопке Finish.
    13. После этого узел будет добавлен к кластеру, и в случае успешного завершения операции по добавлению под именем кластера будут отображаться уже оба узла на зеленом фоне.

    Выполнение обслуживания на узле кластера NLB


    Для выполнения обслуживания на узле кластера NLB администратор может временно остановить службу NLB на узле кластера. Останов узла кластера без оказания негативного влияния на соединения пользователей возможен только с помощью консоли Network Load Balancing Manager, а именно — доступной в ней опции Drainstop (Мягкий останов). Эта опция информирует кластер NLB о том, что определенный узел будет остановлен, и потому никакие новые подключения на этот узел больше направляться не должны, а все существующие соединения должны нормально доработать до конца, т.е. до завершения всех сеансов, и закончиться полной остановкой работы службы NLB на данном узле. Необходимые для выполнения обслуживания на узле кластера шаги описаны ниже.
    1. Войдите в систему WServer от имени учетной записи с правами локального администратора. Network Load Balancing Manager, разверните меню Cluster и выберите в нем пункт Connect to Existing. Когда откроется страница Connect (Подключение), введите имя хоста того кластерного узла в кластере, на котором требуется провести обслуживание, и щелкните на кнопке Connect. Ни в коем случае не вводите имя самого узла, который планируете выводить из эксплуатации для проведения обслуживания, поскольку это приведет к утрате консолью NLB Manager соединения с кластером.
    2. Отыщите узел, который хотите временно вывести из эксплуатации для проведения обслуживания, щелкните на нем ПКМ и в контекстном меню, которое появится после этого, выберите пункт Control Host/Drainstop (Управление хостом/Мягкий останов), как показано на рис. 29.20.
    3. После закрытия всех соединений узел будет выделен красным цветом.
    4. Отыщите узел, который вы останавливали, щелкните на нем правой кнопкой мыши и на этот раз в контекстном меню, которое появится после этого, выберите пункт Control Host/Start.
    Для осуществления мягкого останова (Drainstop) с помощью PowerShell выполните следующие шаги.
    1. В системе WServer выберите в меню Пуск) пункт All Programs^ Accessories/System Tools/PowerShell.
    2. Введите команду
    import-module networkloadbalancingclusters и нажмите клавишу .
    3. Для останова службы NLB на узле NODE01, к примеру, используя мягкий останов, введите команду
    Stop-NlbClusterNode NODE01 -Drain и нажмите клавишу .
    4. После останова сервера командлет PowerShell вернет состояние команды.
    5. Чтобы возобновить работу на данном узле, введите команду Start-NlbClusterNode NODE01
    6. По завершении закройте окно PowerShell и выйдите из сервера.
    Для получения списка командлетов PowerShell, связанных с NLB, после выполнения команды import-module для NLB введите команду
    Get-Command -Module NetworkLoadBalancingClusters

    Мониторинг состояния приложений NLB


    Служба NLB не следит за состоянием приложений, но позволяет разработчику приложений определить, насколько работоспособно приложение с балансируемой нагрузкой. Поскольку у каждого приложения свои понятия о загруженности и работоспособности, измерение и мониторинг этих характеристик лучше возложить на само приложение. Располагая данными измерений, полученными от приложения и открытого поставщика WMI для NLB, добавить в приложение мониторинг загруженности и работоспособности относительно просто.
    Если у вашего приложения есть служба, работающая на каждом узле NLB, или служба, работающая на одном (главном) узле и обменивающаяся данными с другими узлами кластера, она может попутно осуществлять мониторинг, периодически запрашивая у узлов данные о производительности, а у приложений — данные о загруженности и состоянии. Запросы данных производительности могут осуществляться локально или удаленно посредством WMI. Например, вы можете опросить конкретный узел о нагрузке на процессор или о числе активных ТСР-соединений (последний параметр можно также определить, запустив локальнокоманду nlb params и проанализировав результаты ее работы). Запросы к приложениям осуществляются локально или удаленно посредством протокола приложения. Допустим, вы можете послать запрос на конкретный узел, направив его на порт, который прослушивает приложение, и измерив время, необходимое для получения отклика. Даже если у вашего приложения с балансируемой нагрузкой нет собственной службы для генерации подобных запросов — так обычно бывает с веб-узлами на базе IIS или на базе другого веб-сервера, напишите сценарий для сбора информации о загруженности и состоянии, который будет периодически направлять запросы на каждый узел. Посылать WMI-запросы или запросы для конкретных приложений на каждый узел способен, например, зацикленный сценарий VBScript, запушенный на одном из узлов. Конечная цель — собрать достаточно данных, чтобы определить, насколько загружен и исправен каждый экземпляр приложения.
    Собрав с каждого узла все необходимые метрики, вы должны как-то отреагировать на эту информацию. Если вы обнаружили, что какой-то узел перестал откликаться (возникли проблемы у экземпляра приложения или сам компьютер сломался), можно удалить его из NLB-кластера. Для этого нужно выполнить метод DrainStop или Stop экземпляра класса MicrosoftNLB_Node, работающего на этом узле (подробнее о классе MicrosoftNLB_Node — в документации MSDN). Помните, что эти действия повлияют на трафик, обрабатываемый узлом, и в конечном итоге удалят его из кластера. Если проблема ограничена определенным портом или сочетанием порта и виртуального IP-адреса, воспользуйтесь методами Drain/DrainEx или Disable/DisabieEx, чтобы освободить или отключить порт. Когда проблема устранена и работоспособность компьютера восстановлена, используйте методы Enable/EnableEx для возобновления обработки трафика через конкретные порты или метод Start, чтобы восстановить работу кластера на ранее остановленном узле. Поздравляю — вы включили, в свое приложение с балансируемой нагрузкой простую, но эффективную схему мониторинга работоспособности!
    Не всегда вам бывает нужно освободить или отключить весь трафик, связанный с правилом порта. Допустим, вы обнаружили, что некий экземпляр приложения доступен, но серьезно перегружен. В этом случае лучше всего временносократить нагрузку, которую ему приходится обрабатывать, и восстановить на-грузку только после того, как ситуация нормализуется. Чтобы достичь этой цели,исправьте значение свойства LoadWeight экземпляра класса MicrosoftNLB_PortRuleEx, работающего на этом узле (подробнее о классе MicrosoftNLB_PortRule-Exв документации MSDN). Изменяя этот параметр, вы можете уменьшить или увеличить объем трафика, обрабатываемого данным узлом по данному правилупорта. Поздравляю — вы включили в свое приложение с балансируемой нагрузкой простую, но эффективную схему динамической балансировки нагрузки!Отслеживая исправность своего приложения по всему кластеру и внося необходимые коррективы в нагрузку, обрабатываемую каждым узлом, вы повысите общую эффективность, надежность и производительность приложения с балан-сируемой нагрузкой — и это хорошо.
    И последнее по порядку, но не по важности: несколько полезных советов по диагностике NLB.
    Если вдруг оказалось, что-узлы NLB неспособны должным образом обслужитьклиентов, предпримите следующие шаги для выяснения причин проблемы:
    1. Первым делом убедитесь, что исправно приложение, работающее «поверх» всехузлов кластера. Если с подобным приложением происходит сбой, NLB не может автоматически переместить трафик на другой узел кластера. Для начала проверьте, сохраняется Ли проблема, если вы оставляете в кластере NLB всегоодин узел (остановите все узлы, кроме проверяемого). Если вам удалось найти проблемный узел, попробуйте воспроизвести проблему без привязки NLB.
    2. Затем запустите Network Load Balancing Manager с клиента или узла, имеюще-го доступ ко вcем узла кластера. Если диспетчер Network Load Balancing Manager выдает какие-либо ошибки, попробуйте их исправить. Ошибки, отображенныеNetwork Load Balancing Manager, как правило, исправляются применениемпоследней известной конфигурации на узле, к которому вы подключаетесь.Щелкните имя кластера в окне Network Load Balancing Manager правой кнопкой, выделите свойства кластера и щелкните ОК
    3. Перепроверьте все правила портов, щелкнув кластер правой кнопкой, выде-лив свойства кластера и взглянув на вкладку Port Rules. Ошибки в определении правил случаются часто, поэтому обязательно прочитайте описание работы различных правил портов и убедитесь, что понимаете разницу междуединственным сходством, отсутствием сходства, правилами с различным ве-сом, правилами хоста по умолчанию и пр.
    4. Следующий этап диагностики — проверить, согласуется ли информация, ото-браженная в окне Network Load Balancing Manager с результатами выполненияутилит командной строки, наподобие nib params и nib display.
  • Далее следует убедиться, что каждый узел кластера «видит весь входящий трафик. Начните с отправки команды ping на кластер с нескольких клиентов. Если ping работает, проверьте, удастся ли вам подключиться к другим службам (RPC,WMF и т. д.) на каждом узле. Дтя этого запустите на каждом узле Network Monitor. На каждом узле вы должны видеть получение клиентского трафика, а в информации захвата должен присутствовать Обмен пульсом NLB (Широковещательные пакеты Ethernet с байтами 0X886f после адреса источника в кадре Ethernet)между узлами. Если трафик обрабатывается единственным узлом, убедитесь, что вашему коммутатору неизвестен МАС-адрес кластера.

    Диагностика и ремонт


    Во-первых, если диск выходит из строя, вам, вероятно, придется заменить физический дисковый ресурс. Делается это так: инициализируйте новый диске помощью оснанастки Disk Management, расположенной в узле Storage диспетчера Server Manager. Создайте раздел и назначьте ему букву диска, откройте консоль Failover Cluster Management, ПКМ вышедший из строя дисковый ресурс, выберите команду Properties, щелкните Repair и укажи диск-замену. Переведите диск в оперативный режим и верните ему прежнюю букву диска. Теперь можете перевести в оперативный режим весь кластер. Эта процедура сработает, даже если заменяемый диск является общим диском кворума!
    Во-вторых, если у вас уже есть кластеры WS2003 и вы собираетесь перевести их на WServer, в компонент Failover Clustering будет включен новый инструмент Cluster Migration Tool, который поможет в переносе конфигурации с одного кластера (под управлением WServer или предыдущей версии платформы) на другой (под управлением WServer). Этот инструмент копирует как ресурсы, так и конфигурацию кластера. Он относительно прост в использовании, и не допускает частичного обновления. Скажем, нельзя осуществлять миграцию из старого кластера в новый по одному узлу за раз. И в отказоустойчивом кластере нельзя смешивать узлы под управлением WServer и предыдущих Windows.
    Наконец, вам не помешает узнать, как диагностировать проблемы в кластере и исправлять их. В прежних версиях кластерных платформ для этой цели приходилось использовать сочетание стандартных журналов событий Windows (Application, System и т.д.) с журналом cluster.log file из папки %systemroot%\c1uster. К ним добавлялись конфигурационные журналы из папки %systemroot%\system32\LogFiles\Cluster. В WServer протоколирование работы кластера существенно изменилось.
    В WServer существенно изменено ведение журналов кластера. Журнала cluster.log, использовавшегося в предыдущих версиях и размешавшегося впапке %windir%\cluster, больше нет. Новый процесс протоколирования работы мастера опирается на модель Eventing, реализованную в WServer. Критичеекие события кластера по-прежнему регистрируются в стандартном журнале Windows System. Но помимо них создается также отдельный журнал Ореrаtional, содержащий сведения о событиях, присущих именно кластеру. Журнал Operational — обычный журнал событий Windows (в формате .evtx),и потому для его просмотра можно использовать консоль Windows Event Viewer.В ней этот журнал расположен в узле Applications and Services Logs\Microsoft\Windows\FailoverClustering.
    Журнал кластера, работающий в «прямом эфире», просматривать в консоли Event Viewer нельзя. Поскольку к журналу кластера предъявляется требование добавления записей о событиях в реальном времени, а также из-за особенностей новой модели Eventing, журнал реализован в виде сеанса «трассировки». Информацию об этом сеансе можно просмотреть в оснастке Reliability and Performance Monitor, показанной на двух следующих рисунках:
    Журнал хранится в формате ETL (Event Trace Log). Для его анализа можно применять утилиту командной строки tracerpt, входящую в ОС. файл или файлы clusterLog.etl.-xxx расположены в той же папке, что и журнал Operational, т. е. %windir%\system32\win-evt\logs. Файлов ClusterLog.etl в этой папке может быть несколько. Перед созданием следующего файла предыдущий по умолчанию должен дорасти до размера 40 Мб (предельный размер можно перенастроить). Кроме того, новый журнал создается при каждой перезагрузке сервера.
    Интерфейс команды cluster.exe также изменен, чтобы журнал кластера мог генерироваться для всех узлов кластера или для конкретного узла. Вот пример:
    Эти журналы можно просматривать с помощью Notepad.

    Виртуализация


    HYPER-V


    Все началось с Virtual PC. Пикантность ситуации состояла не столько в появлении еще одного конкурента, сколько в том, что Virtual PC предлагался абсолютно бесплатно. И поэтому, несмотря на некоторые его недостатки (например, отсутствие хороших средств и функций управления), новичок был принят весьма неплохо. А главное, производители, чтобы не остаться за бортом, вынуждены были ответить появлением бесплатных, хотя и несколько ограниченных по возможностям версий своих продуктов. В качестве примера приведу VMware Player, который может использовать только готовые образы, но не умеет самостоятельно их создавать. Последняя проблема была решена появлением сервисов вроде EasyVMX (www.easyvmx.com), позволяющих ваять нужный образ прямо в онлайне, а некоторые производители ПО стали выкладывать рядом с обычными версиями своих продуктов еще и готовый образ для VMware Player. Как бы то ни было, Microsoft смогла быстро занять место среди лидеров, выпускающих средства виртуализации.
    Сегодня Hyper-V входит в состав 64-битных WServer — и как отдельный продукт под названием Hyper-V Server. Последний полностью бесплатен и не требует CAL (Client Access License). Технологию Hyper-V можно использовать как в режиме полной установки (с графической оболочкой), так и в Server Core.
    As usual, Microsoft has released a version of WServer that is dedicated to being used as a Hyper-V host. Hyper-V Server 2012 has all of the same Hyper-V and Failover Clustering features and functionality as the Standard and Datacenter editions of WServer 2012. There are some major differences:
    There are no free virtualization rights for installing Windows Server as a guest OS with Hyper-V Server 2012. At first, you might think that this makes Hyper-V Server 2012 seem pretty useless, but that is not the case . There are a number of uses for this free product:
    A customer might have licensed their Hyper-V hosts using Windows Server 2008 R2 and have no Software Assurance (a benefit of which is free upgrades) or budget to afford new licensing. They can upgrade the hosts to Hyper-V Server 2012 to take advantage of the new features while continuing to use their Windows Server 2008 R2 licensing for their virtual machines ’ guest operating systems.
    A student might want to use Hyper-V Server on a machine to run virtual machines with time-limited trial editions to learn Microsoft’s products and pass certification exams.
    A company might want to designate one or more hosts to run only virtual machines with Linux guest operating systems.
    The virtualization rights of Windows Server would be irrelevant to a VDI deployment, so Hyper-V Server would be suitable for the host.
    Administration Hyper-V Server 2012 does not have a GUI; it is very similar to a Core installation of Windows Server 2012. You are given a basic text wizard to configure the host, but Hyper-V Server 2012 is supposed to be remotely managed and configured using PowerShell, the Remote Server Administration Toolkit (RSAT) for Windows Server 2012 for Windows 8, or enterprise management suites such as System Center 2012 with Service Pack 1.

    Клиентские системы

    Second Level address translation


    Windows 8 (Pro and Enterprise editions) support Client Hyper-V. This is the same Hyper-V as on Windows Server 2012, but without server functionality such as clustering, Live Migration, NIC teaming, and so on.
    Client Hyper-V has all of the same requirements as Windows Server 2012 — plus one more, and that’s what caused the aforementioned confusion. Second Level Address Translation ( SLAT ) is required on a Windows 8 computer to enable Hyper-V. SLAT is a processor feature that allows Hyper-V to offload the mapping of virtual machine memory to the host’s physical memory. This reduces the pressure on the host’s processor and improves virtual machine memory performance.
    Intel refers to SLAT as Extended Page Tables (EPT), and AMD refers to it as Rapid Virtualization Indexing (RVI), which was previously known as Nested Page Tables (NPT). Outside the server space , SLAT is a relatively new feature. For example, Intel Core Duo processors don’t have EPT, but Core i processors (i5 and so on) do support it.
    Windows Server 2012 Hyper-V does not require SLAT. Having host processors with SLAT does greatly improve the performance of memory-intensive workloads such as SQL Server or Remote Desktop Services session hosts. Note that SLAT has been around in server processors for quite a while—for example, in Intel Xeon X5500 and later .
    When you enable Hyper-V, the host will reboot twice. During this process, Hyper-V is slipped underneath the WServer 2012 installation to run on the hardware at ring –1 on the processor. At this point, the Windows Server installation becomes known as the Management OS. Older terms such as parent or root partition are no longer used for the Management OS. The kernel of the Management OS is running at ring 0 on the host’s processor.
    Figure 1.2 The architecture of Hyper-V
    In user mode, you can find the Virtual Machine Management Service (VMMS). This process, called VMMS.EXE, can be found in Control Panel a Services as Hyper-V Virtual Machine Management. This is the service that manages Hyper-V on this host. The Hyper-V-VMMS logs in Event Viewer are a great place to start troubleshooting a problem on a host. A WMI provider provides a gateway to the VMMS; this is used by tools such as Hyper-V Manager and agents such as those used by System Center.
    There is one worker process for every virtual machine that is running on the host. This worker process is used to manage the virtual machine. When you perform Live Migration on a virtual machine, this is managed by the worker process of that virtual machine. If you enable Dynamic Memory for a virtual machine, the worker process is involved in allocating memory to the virtual machine.
    Enlightened Windows Guests This is a virtual machine with a Windows guest OS that has the Hyper-V integration components installed. The Hyper-V integration components are like drivers. They make the guest OS that is installed in a virtual machine aware that it is running in a Hyper-V virtual machine. The integration components add driver support for virtual devices that Hyper-V can offer, such as the SCSI controller (with support for hot add/removal of storage) or the synthetic network adapter. Additional functionality can also be made possible with the installation of integration components, such as Dynamic Memory for supported guest operating systems.
    The integration components are referred to as virtualization service clients (VSCs), which Microsoft documentation also calls virtual service clients and virtualization service consumers. VSCs in the virtual machines (in kernel mode) cooperate with virtualization service providers (VSPs) in kernel mode in the Management OS. This pairing is made possible by a communications channel called the VMBus. There is one VMBus channel for every virtual machine that is running. The VMBus is protected by DEP. This means that if an attacker does successfully gain control of the guest OS of a virtual machine, that attacker cannot send instructions to the Management OS via the VMBus to perform a buffer overrun attack.
    Enlightened guests are capable of some additional management functions. You can initiate a clean shutdown of a guest OS from a management tool such as the Hyper-V Manager console. This will initiate a shutdown of the guest OS from inside the virtual machine instead of crudely turning the virtual machine off.
    Another feature is Key Value Pairs (KVPs). A KVP allows the guest OS to share information with the Management OS. For example, a heartbeat will let the Management OS know that a virtual machine’s guest OS is running. A KVP might even return information such as the guest OS’s version or computer name.
    Linux can be enlightened, much like Windows, by Linux Integration Services. Microsoft has developed these integration services to offer almost all of the same functionality for Linux virtual machines, with some exceptions being Dynamic Memory and support for Volume Shadow Copy Service (a Windows service used for application-consistent backups). There is support for multiple processors, the virtual SCSI controller, clean shutdown, guest OS clock synchronization from the host (KVP), and heartbeat (KVP). The Hyper-V Linux Integration Services are built into the Linux kernel in version 3.3 and later.

    Лицензирование


    При покупке лицензии на виртуальную машину лицензия привязывается к хосту, а не к виртуальной машине.

    Роль Virtual Desktop Infrastructure (VDI)


    В отличие от роли RDS, которая обеспечивает
    отношения типа “один ко многим”, подразумевая разделение единственного экземпляра сервера между множеством пользователей, VDI обеспечивает между сервером и удаленным
    клиентом отношение типа “один к одному” за счет применения виртуального гостевого сеанса. Когда пользователь клиента VDI запускает гостевой сеанс, выделяемый гостевой
    сеанс делается доступным для него с загрузкой отдельной клиентской оболочки, выделением отдельного пула памяти и полной изоляцией от всех остальных гостевых сеансов на
    хост-сервере.
    WServer VDI поддерживает 2 разных режима: режим личного рабочего стола (Personalized Desktop) и режим пула рабочих столов (Pooled Desktop). Первый представляет собой выделяемый гостевой сеанс, к которому пользователи получают доступ при каждом подключении к серверу VDI и в котором, по сути, используемый гостем образ выглядит каждый раз одинаково. Второй режим — это гостевой сеанс, при котором параметры пользователя (избранные ссылки, фон и конфигурационные настройки приложений) сохраняются и при входе загружаются снова в стандартный шаблон. Выделяемые для таких гостевых сеансов ресурсы являются не постоянными, а выделяются и назначаются во время входа.

    paging File


    When you install Windows Server, the default setting for the page file is configured to Automatically Manage Paging File Size For All Drives. Hyper-V hosts often are loaded with lots of memory. Therefore, in previous versions of Windows Server, the operating system created a huge file for the virtual memory. But there is no advantage to Hyper-V having such a huge paging file. Keep in mind that the physical memory is allocated to the virtual machines and not used by the management OS.
    As mentioned earlier in this chapter, no other software should be installed on the Hyper-V host, besides the management and backup agents. If this is the case, the general recommendation is to leave this setting at the default. There are no official statements indicating that the virtual memory settings need to be changed for Windows Server 2012 Hyper-V.
    But there are always cases where this does not apply. What should be done when the virtual memory does allocate too much disk space? The paging file configuration can be done in the computer properties under Advanced—Performance Options.
    If the Hyper-V host has been installed with the Server Core installation mode, this UI will not be available. So we will use a script that can be run at the command prompt:
    $Pagefile = Get-WmiObject Win32_ComputerSystem
    $Pagefile.AutomaticManagedPagefile = $false
    $Pagefile.Put()
    $NewPagefile = gwmi -query "select * from Win32_PageFileSetting where name='C:\\
    pagefile.sys'"
    $NewPagefile.InitialSize = [int]”10240”
    $NewPagefile.MaximumSize = [int]”10240”
    $NewPagefile.Put()
    A general good rule of thumb is to have a page file of between 4 GB and 6 GB. We usually don’t configure more than 10 GB. But again, only change the size of the paging file when the default value is not optimal configured automatically.
    There is one thing you need to keep in mind when it comes to troubleshooting. When the page file is configured with a lower value than the physical memory, the memory dump might be incomplete when the system crashes. A support engineer might require a full memory dump for an analysis of the problem. If necessary, you can temporarily set the page file to a higher number just for collecting the memory dump.

    Создание виртуальной машины


    The New Virtual Machine Wizard can be started in one of two ways , depending on whether the host you are working with is clustered.
    If you are creating a non–highly available (HA) virtual machine, such as one on a nonclustered host or one that will be on a clustered host but not HA, then you can create the virtual machine in Hyper-V Manager by selecting the host and clicking New a Virtual Machine in the Actions pane. The New Virtual Machine Wizard appears.
    An HA virtual machine is one that is created on a cluster of Hyper-V hosts. The virtual machine will automatically fail over and boot up on another host if the current host should stop operating. This is the primary function of a cluster of hosts.
    If you want to create an HA virtual machine, you can do this in Failover Cluster Manager.
    Navigate into Roles in the cluster of choice , and click Virtual Machines a New Virtual Machine.
    This opens a dialog box where you select the host in the cluster that the virtual machine will be created on. After that, the New Virtual Machine Wizard starts. This is the same wizard that you can start in Hyper-V Manager. The only difference is that it will add the virtual machine as an HA role on the cluster.
    Hyper-V will use a GUID to uniquely identify the virtual machine under the covers. You might think that the virtual machine name should be forced to be unique. However , Windows Server 2012 is a cloud operating system that was designed to be multi-tenant, and you never know what name a customer will use for their virtual machine.
    A folder, named after the GUID of the virtual machine, will be created to store the virtual machine’s configuration files. The virtual hard disk(s) of the virtual machine will be stored in the root of the folder that is specified in the host settings, and not in a subfolder for the virtual machine. The virtual hard disk is named after the virtual machine (for example, New Virtual Machine.VHDX). You cannot have two identically named files in the same folder, and this will cause a failure in the creation process. It is strongly recommended that you select the option to Store The Virtual Machine In A Different Location. By choosing this option, the wizard will create a subfolder named after the virtual machine in the path of your choosing.
    Копирование виртуальных машин с установленной Windows приведёт к необходимости запускать на копиях Sysprep (в режиме окна приветствия и с галочкой подготовки системы) дабы сбросить идентификатор безопасности (что необходимо для подключения к домену).
    Pressure for more memory in the virtual machine will cause the host to allocate more physical RAM to the virtual machine; and when the virtual machine is idle, the RAM will be removed via a process called ballooning. Not all guest operating systems (Linux, for example) and not all applications (the Exchange Mailbox role, for example) support Dynamic Memory.
    А virtual switch can connect a virtual machine’s virtual network adapter(s) to a physical network (with or without a VLAN), to other virtual machines, and to the management OS of the host itself. The default setting of Connection is Not Connected, which isolates the virtual NIC from all networks, including the Management OS of the host. You should change this, if required, to connect the virtual NIC to a virtual switch. Note that you can change this later, configure VLAN filtering, and add additional virtual NICs to a virtual machine.
    Hyper-V uses GUIDs to uniquely identify virtual machines rather than their names, just as Windows uses security identifiers (SIDs) to track users, computers, and groups. One way you can retrieve the GUID of a virtual machine is to look at its files:
    1. Browse to the folder where the virtual machine was created.
    2. In there you will find a folder called Virtual Machines. Look for an XML file. The name of the file is the GUID of the virtual machine.
    Hyper-V supports up to 64 Virtual CPUs per Virtual Machine. This assumes that the host has 64 or more logical processors and that the guest operating system supports this configuration.

    Virtual hard Disks


    Although you can connect a virtual machine directly to a LUN on a host or a SAN, this is rarely chosen. Virtual hard disks are files, stored on a formatted LUN, that simulate a hard disk. A virtual machine that uses a virtual hard disk will read and write inside that file. The benefit of this type of virtual storage is that it’s abstracted from the underlying physical LUN. Files are easy to create (and great for self-service), easy to extend, easy to back up and replicate, easy to move, and easy to delete. There is no hardware integration (the only dependency is a formatted LUN that the host can access), so this simplifies ownership of virtual hard disks. None of these benefits apply to raw LUNs, known as pass-through disks in Hyper-V.
    The subject of virtual hard disks ( types , formats, and management) will be covered in much more detail when you look at configuring virtual machines.
    WServer still supports VHD format , but now offers a faster and more scalable format called VHDX.

    Why Booting from IDe Doesn’t Cause a problem


    Those who are unfamiliar with Hyper-V might be shocked to see that Hyper-V virtual machines boot from a virtual IDE controller. This has nothing to do with hardware and does not require a physical IDE controller. The virtual device does not have a performance impact.

    The great debate: where to store virtual machine files


    There are 2 schools of thought on the storage of virtual machine files. One group says to keep things simple by storing all of a virtual machine’s files in a single location. The New Virtual Machine Wizard makes this simple. However, this means that you have LUNs that aren’t as finely tuned as they could be. For example, a virtual machine with several virtual hard disks could be stored on a single RAID-10 LUN, but only one of its disks takes advantage of the speed that is offered, while the others consume RAW disk space that might seem wasteful when compared to RAID-5. The balance that is struck is that you get performance with simplicity, but at a cost.
    The other group says that you should scatter the virtual machine’s files across a number of LUNs. This type of example was used in Microsoft’s Cloud Fast Track reference architecture (www.microsoft.com/en-us/server-cloud/private-cloud/fast-track.aspx). In this type of example, virtual machines are stored on one LUN, the OS virtual hard disk on a second, sequential-write virtual hard disks (database logs) on a third LUN (probably RAID-10), and random-read virtual hard disks (database files) on a fourth LUN (probably RAID-5). You will need to edit the configuration of a virtual machine, use PowerShell, or use System Center to create a virtual machine with this storage configuration. This architecture might offer the very best balance of storage performance and raw disk usage, but it is complicated to own and manage.
    The most commonly used storage design places all of a virtual machine’s files in a subfolder for that virtual machine.
    Both camps of virtual machine storage agree on one thing: the default storage settings for virtual machines and virtual hard disks on a Hyper-V host are unsuitable for just about any purpose. By default, these locations are as follows:
    • Virtual hard disks are created at C:\Users\Public\ Documents \Hyper-V\Virtual Hard Disks
    • Virtual machine files are stored at C:\ProgramData\Microsoft\Windows\Hyper-V

    You can override these locations when creating a virtual machine or virtual hard disks. However, you might want to change these settings to something like these:
    • D:\Virtual Machines: Virtual machines should usually be stored on a dedicated LUN on a nonclustered host.
    • C:\ClusterStorage: This is where the clustered storage (Cluster Shared Volumes) of a Hyper-V cluster is mounted — for example, C:\ClusterStorage\Volume1.

    You can change these default storage locations by opening Hyper-V Manager, connecting to the relevant host, clicking the Hyper-V Settings action, browsing to Virtual Hard Disks And Virtual Machines, and changing the shown storage paths.

    Hyper-V Clusters


    Hyper-V itself has no clustering capability and relies on close integration with Windows Failover Clustering to provide such services.
    When you look at the anatomy of a cluster, as shown in Figure 8.1, it is typically made up of several components:
    ◆ Servers that are connected to multiple networks, either via a single NIC or an LBFO team of NICs
    ◆ Servers that are connected to some form of shared storage (that is, shared SAS, iSCSI, or Fibre Channel), either via a single path to the storage array or via multipath
    Figure 8.1 Hyper-V cluster

    Windows Client


    Многие задачи управления (например, дефрагментация) полностью автоматизированы.
    WClient никогда не потребляет более 500 (+-100) МБ оперативной памяти и нуждается в частоте процессора не менее 2 ГГц.

    Развертывание


    WAIK (Windows Automated Installation Kit, Пакет автоматической установки Windows) поддерживает унифицированную командную утилиту DISM (Deployment Image Servicing and Management), используемую для построения и обслуживания WIM-образов WClient и WServer. DISM функционально заменяет Package Manager (pkgmgr.exe), PEimg и Intlcfg, которые также входят в состав WClient и WServer. Можно добавлять или удалять драйвера к монтируемым или уже работающим образам (ранее драйвер необходимо было интегрировать перед началом развертывания). Кроме WIM, возможна работа и с VHD-образами. Следует отметить, WClient позволяет монтировать VHD-диски виртуальных машин, а функция VHD Boot – легко переходить в виртуальную среду и обратно.

    Миграция данных


    Средство миграции пользовательской среды USMT (User State Migration Tool) вошло в состав Windows AIK. Предназначено оно для быстрого переноса файлов, настроек ОС и приложений, а также параметров пользователей при масштабном развертывании ОС от Microsoft.
    Версия USMT 4.0 получила ряд новых возможностей. Теперь к утилитам ScanState (сбор файлов и параметров) и LoadState (перенос данных) добавлена новая – UsmtUtils - их дополняющая. UsmtUtils обладает всего двумя параметрами. При помощи /ec можно получить список поддерживаемых алгоритмов шифрования (AlgIDs) в текущей системе. А /rd удаляет ссылку на каталог, используемый в аргументе команды из базы, сформированной ScanState. Последнее полезно при удалении жестких ссылок, заблокированных по разным причинам. Нужная информация для ScanState/LoadState по-прежнему находится в нескольких XML-файлах переноса: MigApp.xml, MigUser.xml, MigDocs.xml, Config.xml (создается при помощи /genconfig).
    Теперь при переносе учетной записи не требуется обязательное подключение к домену, ScanState способен производить сбор данных из неработающей системы (например, используя Windows PE), более точно определять требуемый для миграции размер раздела и время.
    В сценарии Config.xml появились новые параметры и секции. Например, секция позволяет указать системные файлы, ошибки чтения/записи которых можно игнорировать, не прерывая операцию. При запуске с ключом /genconfig в Config.xml создается секция, в которой описаны наиболее типичные ситуации. Две функции MigXmlHelper.FileProperties и MigXmlHelper.GenerateDocPatterns могут быть использованы для контроля миграции файлов по определенным критериям (размер, время создания и модификации и т.д.) и поиска документов пользователя на компьютере. Получить полный список файлов, которые будут перенесены, можно при помощи специального ключа /listfiles. Новый раздел предоставляет возможность изменять членство в локальной группе в ходе миграции.
    Сначала данные каталогизируются, затем копируются в безопасное место и после установки ОС возвращаются обратно. Учитывая, что объем данных каждого пользователя может превышать несколько Гб, это потребует дополнительного места для их хранения и ресурсов. В итоге, развертывание системы на этом этапе сильно замедляется. В новом WAIK вместо переноса всей информации используется так называемая миграция жестких ссылок (Hard Link Migration), активируемая параметром /hardlink. Это позволяет в значительной степени сократить объемы копируемых данных, а значит, уменьшить время на развертывание и восстановление системы.
    ScanState c:\store /o /c /i:migapp.xml /i:miguser.xml /nocompress /hardlink
    Отныне в c:\store будут храниться жесткие ссылки на каждый пользовательский файл. При переносе ОС жесткий диск будет очищен (кроме файлов, заблокированных такими ссылками). Учитывая, что данные, по сути, не копируются, процесс происходит заметно быстрее. За Hard Link Migration в XML-файлах отвечает секция .
    Еще один новый ключ /vsc команды ScanState позволяет использовать службу VSC для захвата файлов, заблокированных другими приложениями. Для шифрования данных USMT 3 использовался алгоритм 3DES, – теперь через параметр /encrypt можно указать AES с ключом 128/192/256 бит.
    Рядовые пользователи для копирования всех настроек и переноса данных на внешний источник могут воспользоваться утилитой Windows Easy Transfer.

    Сеть


    SMB 2.0 означает ускоренное копирование файлов по сети за счет пакетной отправки данных, когда подтверждение дается на группу, а не каждый пакет, как это было в SMB 1.0. Изменения в стеке TCP/IP позволяют устанавливать динамический размер буфера, тогда как в SMB 1.0 буфер был фиксированный (64 Кб), что замедляло передачу больших потоков данных. В результате, средняя скорость копирования файлов увеличилась приблизительно в 3 раза! Также SMB 2.0 различает символические ссылки NTFS и позволяет их использовать в названиях сетевых ресурсов. При обмене данными с ОС не ниже WClient, SMB 2.0 устанавливается автоматически; иначе используется устаревшая версия протокола.
    В WClient появилась интересная функция BranchCache, позволяющая повысить скорость работы сети и снизить время загрузки приложений и нагрузку на внешний канал за счет кэширования данных. Выглядит это так. Пользователь открыл страницу или скачал файл с сервера головного офиса, – его копия сохраняется в кэше. Когда другой пользователь, входящий в эту же сеть, запрашивает аналогичный файл, сервер проверяет запрашиваемые данные на предмет их возможного кэширования. Если это подтверждается, то обратно, вместо повторной передачи всей информации, отправляется только хэш, по которому находятся кэшированные данные. BranchCache поддерживает стандартные протоколы HTTP/HTTPS и SMB, что позволяет взаимодействовать с широким спектром приложений.
    Новая технология может работать в одном из двух режимов:
    Hosted cache – кэшируемые данные хранятся на отдельном сервере, работающем под управлением Win2k8 R2. Этот режим удобен для больших сетей.
    Distributed cache – распределенный кэш, когда данные кэшируются на клиентских компьютерах и по (широковещательному) запросу пересылаются на другие системы.
    При построении BranchCache учтены все требования безопасности. Так, сервер выдаст хэш, только убедившись, что данный клиент имеет право получить искомый файл. При запросе производится сверка версий, гарантируя, что будет доставлена только самая последняя редакция файла.
    Теперь, если в локалке уже имеется старая версия файла, функция дедупликации загружает с сервера только его измененную часть, а не весь файл. Ранее эта технология кеширования работала в филиальных сетях, а в новой версии она адаптирована и для обмена
    данными в «облачных» сервисах.
    Нельзя не отметить, что Windows 7 автоматически находит сетевые принтеры и настраивает устройства. Более того, для каждой сети можно задать свой принтер по умолчанию. Ранее это требовало вмешательства со стороны админа/пользователя, а в некоторых случаях – применения скриптов и сторонних утилит.
    Благодаря седьмой версии протокола RDP, клиент Remote Desktop Client получил новые возможности. Среди них - поддержка технологий Aero Glass, Direct2D и Direct3D 10.1, DirectShow, Media Foundation. Увеличена производительность, уменьшены задержки звука и многое другое. Удаленный рабочий стол весьма быстро реагирует на события даже во время просмотра видео в высоком качестве.

    Безопасность


    AppLocker позволяет управлять работой приложений. Используя его, админ может четко задать программы, которые разрешается запускать на пользовательских компьютерах. Технология контролирует все типы файлов, которые могут нанести вред системе: исполняемые и установочные файлы (exe, msi, msp), скрипты (bat, cmd, vbs, js) и библиотеки (dll, ocx). Прежде для этих целей приходилось задействовать несколько запутанные политики ограниченного использования программ SRP (Software Restriction Policies). Настройка AppLocker производится при помощи групповых политик на сервере Win2k8 R2. При построении правила можно указать путь к файлу, хэш и цифровую подпись.
    Если приходится делить компьютер с другими пользователями, которые любят менять настройки или способны удалить чужой файл, на помощь придет функция «PC Safeguard », которая активируется установкой переключателя «Turn On PC Safeguard» в свойствах обычной (не админской) учетной записи. После выхода из системы все изменения в настройках будут отменены, а новые файлы – удалены (после регистрации в системе или создании нового файла пользователь предупреждается об этом). Есть возможность выделить каждому пользователю логический диск определенного размера. Ранее, чтобы получить функциональность PC Safeguard, необходимо было устанавливать отдельную утилиту Windows SteadyState (go.microsoft.com/fwlink/?LinkID=117104). Сейчас эта функция встроена, и возможно, получит большую популярность.
    BitLocker, при помощи которого можно полностью зашифровать системный раздел или раздел с данными (начиная с WClient SP1), получил в Windows 7 дальнейшее развитие. Во время установки автоматически происходит создание двух разделов (загрузочного и системного), необходимых для работы BitLocker. Напомним, некогда пользователь должен был позаботиться об этом самостоятельно. Новая технология, получившая название BitLockerToGo, позволяет шифровать и внешние носители (флешки или жесткие диски), отформатированные в FAT/FAT32, ExFAT или NTFS. Доступ к зашифрованным носителям возможен по паролю или смарт-карте с любого компьютера. Правда, если это будет не Windows 7, то удастся лишь чтение данных. Сам BitLocker для выбранного раздела или сменного носителя теперь можно включить в контекстном меню, выбрав пункт «Turn On BitLocker» (не надо искать его в «Панели Управления»). Обратная операция по расшифровке флешки также не трудна.
    При активном UAC администраторы работают в системе фактически с правами обычного пользователя. Если же для выполнения задачи требуются права администратора, то выдается запрос на подтверждение повышения привилегий (в специальном режиме Secure Desktop, не позволяющем программно нажать кнопку).

    Стабильная работа


    Heap (куча) — адресное пространство, с помощью которого реализована динамическая память. Увы, при всей гибкости системы неправильная работа памяти зачастую вызывает массу проблем: переполнение буфера, неправильное освобождение памяти и т.д. Кривое использование Heap разработчиками софта может означать для пользователя только одно — непременные падения приложений.
    Что сделали в Microsoft? На основе анализа сообщений об ошибках из WClient, разработчики написали специальную подсистему, что автоматически определяет программы, которые падают из-за неправильной работы с heap'ом, и применяет к ним алгоритмы, позволяющие избежать распространенных ошибок. Другими словами, для такой программы сама система создает такие условия, в которых та падает реже. Подсистема называется Fault Tolerant Heap и помимо настольной Windows 7 внедрена в Windows Server 2008R2. Механизм включается автоматически для избранных приложений, которые «падают» и которым FTH может помочь — система анализирует crash и принимает об этом решение. Можно даже посмотреть активность подсистемы, открыв «Просмотр событий / Журналы приложений и служб / Fault-Tolerant-Heap».
    Понятно, что пользователь никогда не задумывается о том, как достигается стабильность работы системы, однако немалый вклад вносят множество подобных FTH-механизмов.

    Активация


    Продления пробного периода:
    1. Продление пробного периода с 30 дней до 120 - официальный и легальный способ для того, чтобы попробовать новую систему. Microsoft встроила в WClient функцию, которая позволяет пользователю продлевать срок начального льготного доактивационного периода. Та же самая команда, которая продлевает срок активации WClient до 120 дней может быть использована неограниченное количество раз после замены ключа реестра.
    Перейдите к ключу реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform
    ПКМ SkipRearm и выберите Edit. Установленное значение по умолчанию - Dword с значением 00000000. Измените это значение на любое положительное целое число, например, 00000001, сохраните и закройте редактор реестра.
    Запустите командную строку с правами администратора.
    slmgr -rearm
    или
    rundll32 slc.dll,SLReArmWindows
    Эти команды используют встроенный в WClient Менеджер лицензий (SLMGR), который по умолчанию дает 30 дней доактивационного периода. Изменение ключа SkipRearm с 0 на 1 (с 00000000 на 00000001) позволяет менеджеру лицензий SLMGR проделывать процедуру сброса счетчика неограниченное количество раз! Изменение значения ключа SkipRearm с 1 на 0 возвращает SLMGR к исходному состоянию.
    Перезагрузите компьютер, чтобы изменения вступили в силу.
    Если в течение 10 дней продукт не был активирован, система будет завершать процесс работы каждый час до момента активации!
    2. Активация путем замены файлов от WClient Beta или RC. Не самый удачный способ активации. При данной активации период действия системы ограничен сроками. При этом способе происходит замена файлов, а дальнейшее возвращение оригинальных файлов не предоставляется возможным, из чего следует - обновления и полноценная активация также будут не доступны + первым делом такие системы будут заблокированы со стороны Microsoft.
    3. Также существуют методы псевдо активации. Это неполноценные активаторы, которые просто отключают либо таймер, либо службы, отвечающие за активацию и ее проверку. Такие способы ни к чему хорошему не приведут и также будут обезврежены с первыми обновлениями системы.
    Перед установкой с последующим применением активатора Вам необходимо найти диск, на который будет ставиться система.
    Этот диск обычно имеет букву С или же в описании следующие параметры:
    (eng) Boot, Primary Partition
    (rus) Загрузка, Основной раздел
    Если этот раздел стоит первым - правильный вариант.
    Если же перед ним имеются скрытые разделы, как в примере:
    (eng) System Reserved
    (rus) Зарезервировано системой или Не распределен.
    то этот раздел необходимо открыть и присвоить ему букву отличную от С.
    Либо можно просто удалить этот раздел и объединить пространство с другим разделом.
    4. Активация методом перепрошивки BIOS. Как известно, новые ОС поставляются также в виде предустановленных на ноутбуки. В таком варианте в компьютерах в Биосе прописываются некоторые данные в виде таблицы SLIC .
    Также в самой системе есть файл-сертификат.
    Для активации необходим специальный серийный номер конкретного производителя железа (единый для определенного производителя и типа версии ОС). Система для активации берет данные из этой таблицы в Биосе, сравнивает с сертификатом и введенным серийным номером при совпадении активирует систему.
    Народные умельцы смогли найти способ, как прошить в Биосы обычных компьютеров SLIC таблицу. После прошивки Windows думает, что вы ставите ее, например, на ноутбук HP или ASUS и т.д. Кроме того, что она "думает" - никаких изменений в функциональности работы приложений и полноты устанавливаемой системы – нет. Готовые версии прошивок и программы для дорабоки можно найти в Интернете.
    5. Метод похож на п.4, однако перепрошивать BIOS не надо. Он основан небольшой програмке (загрузчике), которая стартует до загрузки Windows и эмулирует таблицу SLIC.
    Способы п.4 и п.5 хороши тем, что, как показала практика применения на WClient, будут служить долго и их Microsoft не заблокирует, т.к. серийный номер, сертификат и SLIC (последние два прошиваются практически наглухо) поставляют в готовом наборе на десятках тысяч готовых к продаже компьютерах, и чтобы заменить что-либо из этой троицы - придется либо отзывать всю партию, любо напрягать тысячи законных пользователей, что приведет к убыткам компаний.
    После того как отработал активатор возможно придётся провести стандартную активацию через интернет.
    Так что актуальными остаются п.4 и п.5 - лучший п.5.

    Теория


    1. WClient при чистой установке, с нуля, создаёт раздел объёмом 100 Mb, он остаётся скрытым и зарезервирован операционной системой. На нём находятся файлы загрузки WClient. На этот раздел все известные на данный момент Автоактиваторы прописываются.
    2. На ноутбуках скрытый раздел используется производителями ноутбуков для восстановления предустановленной операционной системы. Занимает на диске этот раздел несколько гигабайт.
    Общее между пунктами 1 и 2 только то, что они скрыты от операционной системы и используются в разных целях, в зависимости от назначения...
    На практике вы этим скрытым разделом пользоваться не будете, по-этому, открыв его - перепишите данные на другой диск, раздел удалите, а его занимаемое место отдайте под системный раздел.
    Если скрытый раздел - другая ОС, то просто откройте его на время установки с него активатора.
    В: Как Разблокировать скрытый раздел?
    О: Для вызова програмы "Управление дисками" в Windows необходимо запустить diskmgmt.msc. Справа появится список разделов которые видит Винда, среди них будет раздел "System Reserved". Кликаем на нем ПКМ и выбираем "Change Drive Letter and Paths" (Изменить букву диска и путь... или как то так). В открывшемся окошке жмем "Add", а затем Ok.
    Перезагружаться не надо.
    В: Как восстановить оригинальный загрузчик WClient?
    О: 1) Вставляем/эмулируем DVD WClient.
    2) Запускаем командную строку (cmd) от имени администратора.
    3) F:\boot\bootsect.exe /NT60 All
    (где F:\ - DVD WClient)

    Консоль


    Command.com (*.bat)


    Сначала был command.com – консоль MS-DOS.
    DIR k*.sys - покажет все файлы SYS, только на букву k.
    CD \ - сразу нас выбросило в корневую папку диска C.
    CLS - и на экране чисто.
    VER Она просто выводит на экран номер версии
    ECHO OFF
    VER
    СD \
    Будет выводить версию и слово ECHO OFF
    @ECHO OFF
    VER
    СD \
    А теперь только версию и видно
    REM ляля – комментарий
    DEL – Удалить файл. Если в текущей папке, после команды пишем только имя, если нет – полный путь:
    ECHO – Выводит на экран сообщение.
    ECHO Когда я умер, не нашлось никого,
    ECHO кто бы это опроверг (Гражданская Оборона)
    LABEL – Вы когда-нибудь замечали, что написано у вас перед буквой диска C в папке «Мой компьютер»? Что-то вроде «1» или «System», или вообще «Локальный диск»? А что если сменить это серое и казённое название на другое, повеселей? Команда LABEL поможет вам. Вся её работа заключается в том, чтобы попросить: «Введите новое название».
    CHOICE – Команда задаёт юзеру вопрос с вариантами ответов.
    CHOICE Вы будете пить кофе /c:yn /t:y,10
    Параметр /c задаёт варианты ответов y и n, а параметр /t задаёт время 10 секунд, после которого система автоматически ответит y
    IF – Проверяет условия. Если они выполняются, то IF даёт сработать какой-то другой команде.
    Рассмотренная выше команда CHOICE возвращает невидимый нам код «1», если мы выбрали первый вариант ответа, «2» - если второй, «3» если… и.т.д.
    С командой IF применяется так:
    CHOICE Вы довольны своей зарплатой /c:yn
    IF ERRORLEVEL 1 ECHO Однако!
    IF NOT ERRORLEVEL 1 ECHO Я тоже!
    PAUSE – Выдает на экран надпись: Нажмите любую клавишу… и садится ждать, пока вы отважитесь…
    FOR – Нужна, чтобы заделать цикл.
    FOR %%1 in (1 2 3 4 5) do echo Доброе утро!
    «FOR” 5 раз выполняет (DO) нашу команду echo Доброе утро!
    TYPE – Замечательная команда. Выводит на экран текстовые (и не очень) файлы.
    Что-то устал я объяснять вам смысл команд. Я сделаю проще: напишу их названия, а вы набираете команду с ключом «/?», так:
    COPY, VOL, ATTRIB, XCOPY… Всё вроде. Да их много и не надо.
    Есть замечательная вещь – переназначение ввода/вывода.
    ECHO А.В.В. – учительница информатики! > text.txt
    Символ > отправил «вывод» команды ECHO не на экран, а в файл с названием text.txt
    ECHO Мне нравится её стиль преподавания >> text.txt
    >> «дописывает» к существующему файлу вывод команды ECHO
    Куда ещё можно послать вывод, кроме как в файл?
    - Можно в NUL (Это значит, что вывод этот никто никогда не увидит)
    - в PRN – это на принтер
    А наряду с этими странными NUL и PRN есть CON – эта фишка обозначает клавиатуру и экран.
    Команда COPY обычно копирует файл из одного места в другое. А можно ёё так вот приспособить:
    COPY CON STON.TXT
    Означает: скопировать то, что сейчас введут с клавиатуры, в файл STON.TXT.
    Т.е. курсор чего-то мигает… ПИШИТЕ! Когда закончите, нужно жмякнуть Ctrl + Z (метка конца).
    Знак ” | ”. Если им разделить две команды, то вывод первой попадёт на ввод во вторую! Что же это и зачем:
    А вот зачем. Если вы наберете DEL Nuzhnoe.txt , то система просто так не даст удалить, а спросит: «Вы правда хотите удалить Y/N?!». А как удалить без шума?!
    ECHO Y | DEL Nuzhnoe.txt
    ECHO Y | DEL Nuzhnoe.txt > NUL
    Так эту подлость никто не увидит!!
    Переназначение ввода – это значок ‘ 1.txt
    Label
    Если Вам требуется последовательно запускать несколько программ Windows, то Вы можете написать для этого .bat файл. Используйте команду START с ключом /W. Например создайте текстовый файл со следующим текстом:
    @START /W /MAX "C:\WINDOWS\SCANDSKW.EXE /A /N"
    @START /W /MAX "C:\WINDOWS\ DEFRAG .EXE /ALL /F /NOPROMPT"
    И сохраните его как 1.bat (обратите внимание на кавычки!). Кроме /W, Вы можете использовать следующие ключи:
    /M Запускает программу минимизированно
    /MAX Запускает программу, развернув на весь экран
    /R Запускает программу в окне (используется по умолчанию)

    Передача параметров в bat-файл.


    Для того чтобы bat-файл можно было запускать с какими-то параметрами надо в том месте файла, куда вы хотите добавить параметр, набрать %1 - для первого параметра, %2 - для второго и т.д.
    Например (файл test.bat):
    /тут идут какие-то
    /.....
    /подготовительные работы
    rar m file%1
    Теперь если вы запустите этот файл командой "test.bat 0001", то у вас будет создан файл с именем file0001.rar
    time и нажмите Enter. Вы узнаете текущее время. Его можно изменить, а можно отказаться (Enter). В том же духе действует команда date. Проверьте её, а потом еще команды ver, vol и cls.
    Сейчас я открою у себя программу WordPad и запишу в неё следующий текст.
    REM ...Это программа...
    @echo off
    cls
    ECHO В каком году родился Евгений Демченко? (1 - 1972, 2 - 1991, 3 - 1987)
    CHOICE /C:123
    IF ERRORLEVEL 3 echo Да!
    IF NOT ERRORLEVEL 3 echo Нет!
    pause
    У меня тут есть фальшивая программа форматирования жёсткого диска. Только записывать ее нужно в AUTOEXEC.BAT. Иначе неинтересно.
    cls
    ver
    vol
    echo Программа форматирования жесткого диска уничтожит всю информацию текущего раздела
    choice Вы уверены /c:y /t:y,10
    echo Идёт процесс форматирования...
    :da
    rem Выше, где da – это не команда, а метка перехода
    rem Ниже обычная команда, которая тем не менее, заставляет диск трещать, как при форматировании
    dir \ | sort > nul
    rem Команда goto перескакивает к метке da и всё повторяется до опупения
    goto da
    Остановить это безобразие можно с помощью клавиатурной комбинации Ctrl+C
    В составе всех известных мне WINDOWS’ов есть тихая, неприметная программа DEBUG, которую нужно запускать из командной строки. С её помощью можно писать программы на Ассемблере.
    Сломать компьютер таким образом, чтобы он при старте Windows всегда перезагружался.
    Это делает командный файл:
    @echo off
    echo n C:\windows\win.com>1.dat
    echo a 100>>1.dat
    echo mov ax,0040>>1.dat
    echo mov ds,ax>>1.dat
    echo mov word ptr [0072] , 0000>>1.dat
    echo jmp ffff:0>>1.dat
    echo. >>1.dat
    echo r cx>>1.dat
    echo 10>>1.dat
    echo w>>1.dat
    echo q>>1.dat
    copy c:\windows\win.com c:\
    debug nul
    Он просто-напросто с помощью команд ECHO создаёт 1.dat, в котором записаны управляющие команды для DEBUG. Потом этот файл с помощью переназначения ввода передается в DEBUG, и DEBUG…
    создает крошечный win.com вместо настоящего win.com (Это название запускалки Windows)
    в этом win.com’e записана строка перезагрузки.
    Слава богу, я успел скопировать оригинальный win.com куда то в C:\
    Если вы попробовали, и у вас эта гадость получилась, то загрузитесь по клавише F8 (давить всё время, пока компьютер грузится), выберите “Command Prompt”, и лечите «троянца»: copy c:\win.com c:\windows

    cmd


    Интерпретатор cmd.exe пришел на смену command.com из мира DOS и Windows 9x. Именно его мы запускаем, когда нам нужно поработать с командной строкой. Синтаксис аналогичен.
    Когда торопишься или просто не хочешь ждать завершения первой команды, можно ввести сразу несколько команд, разделив их амперсандом:
    команда1 & команда2 & ... & командаN
    Если эту последовательность команд приходится выполнять часто, целесообразно создать командный файл — обычный текстовый файл с расширением cmd. Каждая команда записывается в отдельной строке, но можно и использовать амперсанды.
    команда1 && команда2
    Вторая команда будет выполнена, если код завершения первой команды равен нулю (успешное завершение).
    Не успел прочитать, что написала тебе программа? Тогда вывод можно передать программе more для постраничного просмотра (листать нужно пробелом):
    команда | more
    Символ «|» используется для перенаправления стандартного вывода одной команды на стандартный ввод другой. Что будет делать с этим выводом другая программа, зависит только от нее.
    Команды бывают внутренними и внешними. Внутренние команды выполняет сам cmd.exe. Внешние команды — обычные исполняемые exe-файлы на диске. Когда мы вводим команду, cmd определяет, что это за команда. Если внутренняя, то он выполняет ее сам, если внешняя, тогда cmd производит поиск исполняемого файла в текущем каталоге и по пути поиска программ (переменная окружения PATH).
    Просмотреть содержимое переменной PATH можно так:
    echo %PATH%

    Команды для управления операционной системой


    В Unix есть очень полезная программа shutdown. С ее помощью можно не только завершить работу системы (или перезагрузить ее), но и указать время завершения. Аналог этой команды есть и в Windows. С ее помощью можно просто выключить систему, выполнить перезагрузку, убить активных пользователей, перейти в режим пониженного энергопотребления и закончить сеанс без отключения компьютера. Очень полезен параметр '-t', позволяющий задать в секундах таймаут операции.
    К командам этой группы также относится программа taskkill, которая используется для завершения/убийства работы одного или нескольких процессов. Задать процесс можно по имени образа (имени исполняемого файла — ключ ‘/IM’) или по идентификатору процесса (ключ ‘/pid’). Например:
    taskkill /IM notepad.exe
    Вообще говоря, возможностей у этой команды очень много. К примеру, можно завершить все процессы, которые используют определенную DLL.

    Команды мониторинга


    Узнать PID процесса можно с помощью команды tasklist.
    Также к командам мониторинга можно отнести: mem (вывод информации об использовании памяти), systeminfo (полная информация о системе) и tracerpt (отслеживание журнала событий с возможностью вывода отчета в формате CSV).

    Команды обслуживания жестких дисков


    Для проверки дисков используются команды chkdsk (проверка FAT-разделов) и chkntfs (проверка NTFS-разделов),
    defrag - для дефрагментации
    recover - для восстановления файлов с поврежденных разделов
    format — для форматирования дисков.
    Вместо команды fdisk, которая была в Windows 9x, в современных версиях Windows используется diskpart. Эта программа позволяет разбить диск на разделы, создать/удалить логические диски, выбрать активный раздел и т.д. Если команда fdisk работала в интерактивном режиме, то diskpart в основном ориентирована на использование в сценариях.
    Сценарии — это текстовые файлы с инструкциями, которые должна выполнить diskpart. Вызвать diskpart можно так:
    diskpart /s
    пример сценария diskpart:
    select disk 0
    clean
    create partition primary
    select partition 1
    assign letter=c:
    active
    format
    exit
    Обрати внимание, как здесь осуществляется работа с объектами. Сначала с помощью команды select мы выбираем диск (select disk). Затем мы производим две операции (clean и create partition). Далее выбираем другой объект — раздел (select partition) и производим операции с ним (делаем раздел активным и форматируем его).
    Можно указать размер создаваемого раздела (в данном случае 5 Гб), например:
    create partition primary size=5000
    К этому разделу можно отнести еще две команды: diskperf, которая управляет счетчиками производительности жесткого диска, и fsutil, управляющую поведением файловой системы. Например, с помощью fsutil можно сбросить или установить флаг тома «грязный» ( dirty ), а также получить информацию о файловой системе.

    Другие команды


    Для выполнения заданной команды в строго определенное время можно использовать планировщик at. Есть возможность задать дату запуска команды, время, интервал (например, каждый день). Программа может работать в интерактивном режиме (параметр /interactive).
    Если боишься редактировать файл boot.ini в блокноте, воспользуйся программой bootcfg, которая позволяет избежать ошибок при редактировании этого файла.
    Иногда полезно опросить драйверы устройств. Для этого используется команда driverquery.

    PowerShell


    Возможности стандартного командного интерпретатора cmd в Windows довольно скудны, особенно по сравнению с командными интерпретаторами Unix: ksh, bash , zsh. Поэтому был разработан PowerShell. Установить MSH можно на следующих платформах: XP SP2, Vista, Server 2003 и WServer. На www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx найдешь и полное руководство по ней.
    PowerShell предназначен для автоматизации административных задач в WServer. Оболочка PowerShell устанавливается в качестве компонента WServer. Командная строка начинается с PS. Командлеты можно вводить в PowerShell интерактивно или сохранять в файлах сценариев *.PS1 (на конце единица), которые потом выполняются в PowerShell.
    Для работы с веб-сервисами PS использует форматы REST и JSON . По сути, многие штатные инструменты
    управления из состава WServer вроде RSAT и Server Manager представляют собой надстройки над PS, а работа всех мастеров сводится к созданию и запуску сценария PS. При этом выполненный
    ранее сценарий можно скопировать из истории и экспортировать
    для повторного использования.
    Особенностью инструментария WMI является поддержка стандартов, описывающих взаимодействие между оборудованием и приложениями, вроде SMI-S, WSMAN или DCOM. Соответственно, третьим лицам стало проще писать WMI-провайдеры.
    Оболочка командной строки и язык сценариев PowerShell включают свыше 130 инструментов командной строки, которые называются командлетами (cmdlets от command-lets), с полностью согласованным синтаксисом и соглашениями именования, которые можно расширить с помощью настраиваемых командлетов. В отличие от традиционных командных оболочек, например Cmd.exe и BASH (в Unix), которые пересылают текстовую команду отдельному процессу или утилите и возвращают результаты этой команды в текстовом виде, оболочка PowerShell непосредственно манипулирует объектами Microsoft .NET Framework в командной строке.
    Оболочку PowerShell можно использовать для запуска программ и выполнения команд, идентичных командам, применяемым в командной оболочке. В PowerShell можно выполнять административные задачи, аналогичные командам Cmd.exe, либо использовать директивы PowerShell.
    Оболочка PowerShell — это интерактивный командный интерпретатор. С его помощью можно создавать сценарии, позволяющие администраторам автоматизировать управление системными задачами как на сервере, так и на других компьютерах сети. Сценарий — это обычный текстовый файл, содержащий команды PowerShell. Расширение у файла сценария должно быть msh. PowerShell, в отличие от cmd, предоставляющего доступ только к файловой системе, позволяет управлять всей операционной системой и ее приложениями. Например, мы можем работать с реестром Windows как с обычной файловой системой. Вот некоторые полезные команды, которые нужно знать для начала работы в PowerShell:
    Get-Command — получить список доступных команд;
    Get-Help — получить справку по указанной команде;
    Get-Drive — получить список дисков;
    Set-Location — изменить текущее местоположение (аналог команды cd в cmd);
    Set- Alias — создать псевдоним для команды;
    Get-Date — вывести дату.
    Как и в cmd, поддерживается перенаправление ввода/вывода, например:
    Get-Date > current-date.txt
    При запуске PowerShell автоматически запускаются следующие сценарии (если они найдены):
    • Documents and Settings\All Users\Documents\Msh\ profile .msh;
    • Documents and Settings\All Users\Documents\Msh\Microsoft.
      Management.Automation.msh_profile.msh;
    • $HOME\My Documents\msh\profile.msh;
    • $HOME\My Documents\msh\Microsoft.
      Management.Automation.msh_profile.msh.

    Синтаксис PowerShell похож на синтаксис любого другого языка высокого уровня. Рассмотрим несколько примеров:
    MSH> 5*5
    25
    MSH> "Конкатенация" + "строк"
    MSH> (Get-Date). year * 5
    10035
    Можно работать с переменными, причем поддерживаются массивы:
    MSH> $t = 10
    MSH> $t
    10
    MSH> $arr = 1,2
    MSH> $arr
    1
    2
    MSH> $arr[1] = 3
    MSH> $arr
    3
    2
    Перед именем переменной нужно обязательно указывать знак доллара — так PowerShell поймет, что перед ним переменная, а не значение.
    Нумерация элементов массива начинается с единицы. Для добавления нового элемента в массив — оператор «+»:
    MSH> $arr += 7
    MSH> $arr
    3
    2
    7
    Кроме простых массивов, поддерживаются ассоциативные массивы:
    MSH> $assoc = @{ one = 1; two = 2;
    three = 3}
    MSH> $assoc['one']
    1
    Для добавления элемента в ассоциативный массив используется вот такая конструкция:
    $assoc += @{ four = 4 }
    Тип переменной выбирается автоматически, но можно установить любой тип .NET: array, bool, byte, char , char[], decimal, double , float, int, int[], long, long[], regex, single, scriptblock, string, type, xml. Он определяется в квадратных скобках в момент присваивания:
    MSH> $var = [int]10;
    В сценариях можно использовать условные операторы if- elseif - else , switch, а также операторы циклов while, do-while, do-until, foreach .
    Мы рассмотрим только оператор if-elseif-else и циклы while и foreach. Конструкция if-elseif-else следующая:
    if (условие) elseif (условие) elseif (условие)
    Условие задается так:
    переменная оператор_сравнения переменная_или_значение
    Цикл while выглядит так:
    <
    Пример:
    $i = 0; while($i -lt 10)
    Этот цикл выведет числа от 0 до 9.
    Теперь рассмотрим синтаксис foreach:
    foreach (переменная in ассоциативный_массив)
    Цикл foreach удобно использовать для перебора значений ассоциативного массива, например:
    foreach ($v in Get-Process |Sort-Object Name)

    Работа с реестром


    Перейти в нужный раздел можно с помощью всем знакомой команды cd:
    MSH> cd hkcu:
    Мы попали в раздел HKEY_CURRENT_USER.
    Можно перейти в другой раздел, например HKEY_LOCAL_MACHINE, задав его имя или сокращение (hklm). Вывести содержимое раздела можно с помощью команды dir. Чтобы просмотреть его, используется команда get-property:
    MSH> cd hkcu:
    SoftwareMicrosoftNotepad
    MSH> get-property .
    В данном случае мы выводим настройки блокнота. Значение переменной в разделе устанавливается посредством set-property (следующая команда изменит шрифт блокнота):
    MSH> set-property . — property lfFaceName -value " Arial "

    Команды для работы с файловой системой


    type — просмотр файла;
    more — постраничный вывод файла;
    copy — копирование одного или нескольких файлов;
    move — перемещение одного или нескольких файлов (или переименование каталога);
    del — удаление одного или нескольких файлов;
    ren — переименование файла;
    attrib — изменение атрибутов файла/каталога (скрытый, системный, только чтение, архивный);
    fc — сравнение файлов;
    find — поиск текстовой строки в одном или нескольких файлах;
    grep — поиск текстовой строки (можно использовать регулярные выражения) в файле или в списке файлов;
    cd — смена каталога;
    dir — вывод содержимого каталога;
    tree — вывод дерева каталогов;
    md (или mkdir) — создание каталога;
    rd — удаление каталога или дерева каталогов.

    Выполнение сценария PowerShell


    По умолчанию PowerShell запрещает выполнение сценариев из соображений безопасности. Для запуска сценария требуется изменить политику выполнения PowerShell с помощью следующей команды:
    set-executionpolicy remotesigned
    Политика выполнения указывает сценарии, которые можно запускать.
    Вышеприведенная команда конфигурирует PowerShell для запуска локальных сценариев и требования подписи сценариев из удаленных источников. Изменение политики выполнения влияет на безопасность. После назначения политики выполнения можно запустить сценарий, однако если указать для запуска лишь имя сценария, возникнет ошибка. Нужно указать путь к сценарию. Вы можете использовать нотацию .\имя_сценария, которая означает текущий каталог. Например, следующая команда выполняет сценарий импорта пользователей: .\UserImport.psl Синтаксис, командлеты и объекты PowerShellВ традиционных оболочках наподобие Cmd.exe запускаются такие команды, как dir и сору, которые получают доступ к утилитам, встроенным в оболочку, а также выполняются такие программы, как attrib.exe и xcopy.exe, многие из которых принимают параметры из командной строки и обеспечивают обратную связь в виде выходных данных, ошибок и кодов ошибок.В PowerShell директивы выполняются с помощью командлетов. Командлет представляет собой команду с одной функцией, которая манипулирует объектом. Командлеты используют синтаксис Verb- Noun , то есть указывают действие и объект, разделенные дефисом: Get-Service.Эти простые команды можно использовать в комбинации или в конвейере для создания более сложных директив. Например, конвейер Get-Service|Format-List отображает все атрибуты каждой службы. Командлет Format-List генерирует более детальные результаты, чем Get-Service. Дело в том, что Get-Sevice возвращает не статический список трех атрибутов служб, а объекты, представляющие службы. При помещении таких объектов в конвейер Format-List командлет Format-List может работать непосредственно с ними и отображать все атрибуты служб.Эта концепция отличается от принципов командной оболочки Windows, где выходные данные одной команды могут помещаться в конвейер другой команды только в текстовом виде. В случае использования Cmd.exe команда format-list лишь переформатирует три элемента информации в результатах команды get-service.Командлет Format-List принимает решение об отображении атрибутов. Вы можете указать отображение всех атрибутов, добавив параметр property со звездочкой, представляющей все возможные значения. Следующая команда перечисляет все доступные параметры всех служб:get-service | format-list -property *

    Получение справочной информации


    Поиск информации в PowerShell лучше всего начать с командлета Get-Help, особенно если вы только знакомитесь с PowerShell. Чтобы получить самую простую справку, введите Get-Help, а затем укажите имя командлета, сведения о котором хотите получить.
    Более детальную информацию можно получить, добавив параметры
    help-get-command -detailed
    или
    get-help get-command -full

    Переменные


    Если вам постоянно нужно указывать путь или определение объекта, вы можете присвоить его переменной, чтобы сэкономить время. Переменные в PowerShell всегда начинаются со знака доллара ($). Например, вы можете назначить переменную $DNS для представления объекта, извлекаемого командлетом Get-Service DNS:
    $DNS=get-service DNS
    При присвоении объекта переменной создается объектная ссылка. Свойства этого объекта можно извлечь, указав свойство с точкой (.). Например, чтобы
    вернуть состояние службы DNS, введите следующую команду:
    $DNS.status
    В качестве заполнителя для текущего объекта в текущем конвейере можно
    использовать особую переменную конвейера ($_). Например, для извлечения
    списка всех запущенных служб введите следующую команду:
    get-service |
    Эта директива извлекает все службы и передает объекты в конвейер
    командлета Where-Object, который оценивает каждый объект в конвейере, чтобы определить, присвоено ли значение Running свойству состояния объекта,
    представленного переменной конвейера $_.

    Псевдонимы


    Использование псевдонима — это альтернативный способ ссылки на командлет. Например, ранее описанный командлет Where-Object имеет псевдоним Where, при использовании которого предыдущий код можно сократить так:
    get-service |
    Многие командлеты PowerShell уже имеют псевдонимы.
    Например, для отображения содержимого папки на диске используется командлет Get-ChildItem. Этот командлет имеет псевдоним Dir, а также псевдоним Ls, предназначенный для пользователей оболочки UNIX.
    Как определить командлет, который «прячется» за псевдонимом? Для этого в командную строку введите alias:
    alias dir
    Хотя в PowerShell обеспечены псевдонимы для команд оболочки, командлеты PowerShell используют другие параметры, отличные от команд оболочки Cmd.exe. Например, для извлечения каталога папок и всех подпапок в командную строку вводится команда dir /s, а в PowerShell нужно ввести команду
    dir -recurse

    Пространства имен, поставщики и PSDrive


    Командлеты оперируют с объектами в пространстве имен. Папка на диске является примером именного пространства — иерархии, в которой можно осуществлять навигацию. Пространства имен создаются поставщиками. Оболочка PowerShell может получать прямой доступ и манипулировать объектами в пространствах имен этих провайдеров.
    Вы наверняка знакомы с концепцией пространства имен тома на диске с буквой или пространства имен общей сетевой папки в виде подключенного сетевого диска. В PowerShell пространства имен любого провайдера могут быть представлены как PSDrive. Оболочка PowerShell автоматически создает пространство имен PSDrive для каждой буквы диска, уже определенной в Windows.
    Оболочка PowerShell выводит эту концепцию на следующий уровень, создавая дополнительные пространства имен PSDrive для распространенных ресурсов. Например, она создает два диска, HKCU и HKLM, для ульев реестра HKEY_CURRENT_USER и HKEY_LOCAL_MACHINE. После этого в реестре можно осуществлять навигацию и манипуляции, как в файловой системе. В командную строку PowerShell введите следующую команду:
    cd hklm:\software
    dir
    Диски также создаются для псевдонимов, среды, сертификатов, функций и переменных. Для перечисления созданных пространств имен PSDrive введите команду get-psdrive.

    Установка Windows Server Backup с использованием модуля PowerShell ServerManager


    Когда отдельный компонент или роль устанавливается с использованием модуля PowerShell ServerManager, также добавляются все средства, службы роли и зависимости данной роли. Чтобы установить средства Windows Server Backup, включая командлеты Windows Server Backup для PowerShell, выполните следующие шаги.
    1. Войдите в систему WServer от имени учетной записи с правами администратора.
    2. Выберите в меню Пуск пункт All Programs/Accessories (Все программы/Стандартные). ПКМ на значке PowerShell и выберите в контекстном меню пункт Запуск от имени администратора. Если
    откроется окно User Account Control (Контроль учетных записей пользователей), щелкните на кнопке Continue (Продолжить) для открытия окна PowerShell.
    4. Введите cd \ и нажмите клавишу .
  • Введите Import-Module ServerManager и нажмите .
    6. Введите Add-WindowsFeature Backup-Tools и нажмите . После завершения установки результаты будут представлены в списке, как показано на рис. 30.2.
    7. Введите Get-WindowsFeature | More и нажмите для получения списка установленных ролей, служб ролей и средств. Проверьте список, удостоверившись, что программа Windows Server Backup и связанные с ней инструменты командной строки были успешно установлены.
    8. Введите exit в окне PowerShell и нажмите .

    System center

    Configuration manager 2012


    Первое, что бросается в глаза, это изменение списка продуктов,
    входящих в семейство System Configuration. Теперь он выглядит следующим образом: Configuration Manager, Operations Manager, Service Manager, Data Protection Manager (DPM), Virtual Machine Manager (VMM), Orchestrator и два новых продукта — Endpoint Protection (ранее Forefront ЕР) и AppController. Центральное место в линейке
    занимает SCCM 2012 (также известен кaк v.Next), покрывающий практически полный цикл управления всей ИТ-инфраструктурой — установка ОС, приложений и обновлений, контроль конфигурации, инвентаризация софта и оборудования. Поэтому с него и начнем.
    Требования к системе SCCM 2012 немного изменились, те-
    перь только 64-битные ОС, его можно установить на Win2k8/R2
    с MSSQL2k8SP1 (х64) или позднее. Хотя точки распространения (DP,Distribution Point) по-прежнему работают на х86 Win. Так как изменилась архитектура и логика работы, апгрейд со старых версий SCCM
    не предусмотрен, только средства миграции.
    В SCCM2012 интегрирована четвертая версия инструмента ми-
    грации учетных записей USMT (User State Migration Toolkit). Функция развертывания ОС OSD (Operating System Deployment) всегда была одной из сильных сторон SCCM, с появлением иерархической модели (образы не привязаны к определенному сайту) нет необходимости
    в сохранении индивидуальных образов, существенно упрощена ра-
    бота с WIM. Возможность РХЕ теперь поддерживается только точками распространения DP. Поддержка технологии Intel vPro/AMT позволяет
    получить доступ к железу, минуя ОС. Одной из целей разработчиков
    было уменьшение количества серверов, так как ранее из-за специфи-
    ческих настроек коллекции часто требовался еще один Primary Site, в результате даже в небольшой организации серверов могло быть неприлично много. В иерархии появилась роль Central Administration Site (CAS, аналог Central Primary Site), используемая только для
    управления иерархией и отчетов.
    Такой сайт не обслуживает клиентов и поддерживает ограниченное количество ролей (AI, Software Update Point, RSP и SHV). Но главное,
    в подчинении CAS может быть только один основной (Primary) сайт, тогда как ранее поддерживалась вложенность нескольких Primary.
    Secondary Site требуют наличия SQL-сервера (можно использовать бесплатный Express ). Привычных режимов Native и Mixed нет, теперь просто
    указываем режим работы по HTTP и/или HTTPS, как для сайта в целом, так и на Distribution Point. На разные коллекции можно назначать свои
    настройки. Клиент может перебирать между несколькими Management Point внутри сайта и подключаться к доступному. Это, кстати, основные
    причины отказа от многочисленных Primary сайтов, так как такой подход упрощает структуру, да и уменьшает количество лицензий. Reporting Point теперь носит имя Reporting Services Point и базируется на SQL
    Reporting Services, поэтому не получится перенести настройки со старой
    системы. Точки Branch DP уже нет как таковой, SCCM 2012 использует технологию BrachCache. В SCCM 2012 реализована новая концепция, по-
    лучившая название UCM (User Centric Management),—такой подход сделал его более дружелюбным к пользователю, предлагая ему большие
    возможности по контролю и самостоятельному сопровождению системы (естественно, в рамках политик). Теперь именно пользователь выбирает
    приложения для установки и определяет, когда на компьютер будут загружаться обновления, указывая для этого рабочие часы в настройках.
    Ранее все было с точностью наоборот, — основной точкой управления был компьютер, пользователь оставался за кадром и решений никаких
    не принимал. Новый подход видится мне более правильным, поскольку администратор не всегда владеет ситуацией и ориентируется лишь на
    роль и группу. Кроме того, индивидуальные требования при большом количестве пользователей учитывать тяжело, а обновление, да еще
    с перезагрузкой, устанавливаемое в неподходящее время, может сильно помешать. Если за компьютером работает несколько пользователей, один из них назначается основным. Сами приложения разделены на
    обязательные и доступные (Required или Available), также определяется тип установки (локальная, терминал, виртуальное App-V, Windows Mobile CAB), зависимости и nр о ч е е . Д л я nоиска Available nриложений пользователям предложен Software Center, после выбора администратор может
    одобрить или блокировать установку. Приложение, в зависимости от
    конкретной ситуации (пользователь работает на ПК, терминале и так
    далее), может устанавливаться по-разному. Например, на ПК это будет локальная установка, а с терминала — виртуальная. Устанавливаемые программы отслеживаются в узле Monitoring, а не в Status Message Viewer, как в случае SCCM2007. При запуске мастера из Client Custom Settings администратор указывает, на кого распространяются настройки — для пользователя они или для компьютера. Многие администраторы перед развертыванием проверяют работу на тестовой группе, — теперь все установки из такой среды легко импортируются на рабочие станции.
    Интерфейс реализует ролевую модель управления доступом Role-Based Access Control (RBAC), скрывая те настройки, которые недоступны пользователю. Во вкладке Security Roles можно найти 13 предустановленных
    ролей, при необходимости администратор может самостоятельно добавлять новые, ориентируясь на бизнес-структуру компании. Сами объекты, коллекции, с которыми может работать роль, определяются в Security
    Scope, а раздавать права можно на уровне коллекции, а не сайта. В SCCM 2012 интерфейс консоли обновлен и выполнен в стиле MS Office, он со-
    стоит из так называемых Wunderbar, содержащих ссылки на меню управления, и уже не является ММС. Еще одно важное изменение, — на клиенте устанавливается специальная программа Client Health
    (ccmeval.exe), отправляющая по расписанию сообщение о его текущем состоянии и возвращающая его в рабочее состояние в случае проблем.
    Также SCCM 2012 получает некоторый функционал SC AppController, известный под кодовым именем Соnсеrо (лат. «связывать»), позволяющий
    управлять SaaS услугами и приложениями в приватных облаках, построенных на Windows Server, Hyper-V и Virtual Machine Manager 2012, и в
    публичных облаках на базе Windows Azure. Владельцы могут развертывать VM, получать доступ к ресурсам, использовать несколько подписок
    Windows Azure, копировать VHD-образы.

    System center operations manager 2012


    Теперь OpsMgr является основным инструментом для управления
    частным облаком, включая возможности мониторинга сетевых
    устройств и технологию контроля производительности приложений
    AVICode. В частности, кроме серверов можно обнаруживать и отслеживать маршрутизаторы, в том числе отдельные интерфейсы и порты, а также VLAN (обнаруживаются автоматически). Поддерживает SNMPv3, IPv4/IPv6, ведет статистику по трафику и скорости, осущест-
    вляет контроль работы протокола HSRP и многое другое.
    В новой версии OpsMgr все сервера управления стали равно-
    правными, то есть роли Root Management Server больше нет, конфигурацию агентов вычисляет каждый Management Server. Теперь с OpsMgr 2012 вся инфраструктура не зависит от доступности одного единственного сервера. Хотя в целях обратной совместимости ввели
    специальную роль RMS Emulator. Чтобы справиться с нагрузкой, не обязательно строить кластер, — администраторы могут объединять серверы управления в группы и для Health Service создавать пул ресурсов (Resource Pool) из нескольких Management Server. В обыч-
    ном режиме задачи выполняет только один из серверов пула, другие
    подхватывают его роль только в случае недоступности. Получается
    такой себе Failover Cluster без Failover Cluster. Во время установки
    по умолчанию создается три пула: AD Assignment Resource Pool, Notifications Resource Pool и All Management Servers Resource Pool,
    остальные администратор может настроить самостоятельно.
    Для хранения данных вместо ОЗУ (как это было на Root MS
    и требовало мощного сервера) используется только БД. Консоль
    управления внешне изменилась мало, зато веб-консоль перерабо-
    тана существенно, но осваивается легко. Кроме Windows, полно-
    ценно OpsMgr 2012 поддерживает Linux и *nix. Уже сегодня доступны пакеты управления (Management Pack) для поддержки популярных
    серверов приложений: Apache Tomcat, IBM WebSphere, Java EE, Oracle
    WebLogic, Red Hat JBoss и других. Обеспечивается диагностика и веб-
    приложений, созданных на базе .NET и J2EE и Windows Azure.
    Доступный набор командлетов PowerShell (имя включает SCOM/SC) теперь дает возможность управлять в том числе и *nix-системами.
    Чтобы получить список всех командлетов, достаточно ввести:
    PS> Get-Command -Module OperationsManager
    Пакет управления UNIX/Linux Shell Command Template предлагает
    шаблоны,позволяющие создавать правила,задания и мониторы,
    используя команды оболочки непосредственно с панели OpsMgr.
    В сравнении с OpsMgr 2007 сам процесс настройки при помощи
    мастеров — упрост. В финальном релизе данный пакет будет уста-
    навливаться по умолчанию, для RC его нужно скачать и установить
    отдельно.

    Deployment toolkit 2012


    Главное нововведение в MDT — улучшенная интеграция с SCCM 2012 и AD, а также поддержка DaRT (Diagnostic and Repair Toolkit, входит
    в Desktop Optimization Pack).
    При этом MDT2012 полностью вписывается в новую консоль SCCM 2012 (может работать и с SCCM2007) и понимает измененную модель
    приложений (терминальные, виртуальные и так далее). Собствен-
    но, процесс работы с MDT мало изменился, отличия в интерфейсе
    практически не бросаются в глаза. В настройках появились два новых Task Sequences: Deploy to VHD Client Task Sequence и Deploy to VHD Server Task Sequence [развертывать VDI, клиентский ПК или сервер).
    Конечно, при помощи MDT 2010 также было возможно произвести
    P2V миграцию, задействуя Sysinternal Disk2VHD (на TechNet доступна
    инструкция clck.ru/fQOp), но процесс не совсем тривиален и не всем понятен. Теперь это стандартная операция, все настройки которой выполняются за несколько кликов мышкой. Также заявлено, что
    MDT 2012 будет поддерживать грядущую ОС Win8. Используемый для редактирования установок в MDT_FOLDER/Scripts/UDIWizard_Config.xml инструмент UDI Designer (User-Driven Installation, появился
    в MTD2010 Update 1) получил новый интерфейс и возможности. Так вместо двух сценариев из коробки теперь их три: New Computer, Refresh и Replace . Администратор может просмотреть список всех
    сценариев в одном окне и изменить расположение простым перета-
    скиванием. Сам мастер расширяем, хотя процесс не совсем прост (на
    TechNet приводится пример кода). А еще — усовершенствован мастер Lite Touch, улучшена миграция учетной записи, реализована полная
    поддержка WinRE. Все задачи можно решить при помощи PowerShell.
    Поддержка старых ОС WinXP и Win2k3 сохранена.

    SQL Server 2012


    Нововведений очень много, и они затронули все без исключения
    подкомпоненты сервера. Одни направлены на повышение произво-
    дительности и доступности, другие позволили расширить круг задач.
    Приведем лишь некоторые, наиболее важные.
    Сисадмины наверняка оценят поддержку установки на Win2k8R2
    в режиме Server Core: теперь для развертывания SQL-сервера не тре-
    буется графическая оболочка. Представлено несколько инструментов
    миграции: Upgrade Advisor, Distributed Replay и Migration Assistant
    (SSMA). Базирующаяся на концепции групп доступности (Availability Groups) технология HADR (High-Availability and Disaster Recovery) позволяет повысить доступность экземпляров SQL Server за счет дополнительных копий БД. Такие копии могут работать в режиме «только чтение» и использоваться, например, для отчетов, что снимет нагрузку с рабочей БД.
    Реализована поддержка кластера на разных подсетях (SQL
    Server Multi-Subnet Clustering). Для очистки дубликатов в данных
    предложен новый компонент Data Quality Services. Инструменты
    управления позволяют эффективно манипулировать произво-
    дительностью в такой многопользовательской среде как частное
    облако. Новый компонент Power View (Crescent) с богатыми воз-можностями представления информации для анализа позволяет
    пользователям самостоятельно строить отчеты на основе BISM
    (Business Intelligence Semantic Model). Семантическая модель
    бизнес-аналитики BISM объединяет в себе модели данных UDM
    и табличную PowerPivot. Улучшены механизмы полнотекстового
    поиска: по отдельным свойствам через IFilter, и NEAR , позволяю-
    щий указать порядок следования слов и расстояние. Добавлены
    новые разрешения и механизм пользовательских серверных
    ролей, добавлена поддержка SHA2 256/512. Также предложена SQL
    Express LocalDB - легковесная версия БД с поддержкой всех функ-
    ций, не требующая конфигурирования и прав администратора.

    Appcontroller


    AppController — новое решение в семействе System
    Center, предназначено для контроля приложений внутри облака (публичного и частного), развертывания и управления
    сервисами. Это единый интерфейс ко всем ЦОД и Azure. По сути, AppController призван дополнить все имеющиеся сегодня
    инструменты, с которыми приходится иметь дело администра-
    тору: SCVMM, SSP (Virtual Machine Manager Self-Service Portal
    или Solution Accelerator), DDTK (Dynamic Datacenter Toolkit)
    и консоль Azure Platform. AppController позволяет владельцам
    приложений создавать ресурсы с использованием шаблонов
    и библиотек, управлять ими, отслеживать активности, выполнять журналирование всех действий и многое другое. Например,
    разворачивать приложения могут сами менеджеры подразделе-
    ний, а ИТ-персонал просто контролирует этот процесс. Каждый
    пользователь получает веб-интерфейс, где будут доступны только
    определенные (в зависимости от его роли) функции.

    Лицензирование линейки System center


    Модель лицензирования всех продуктов линейки System Center 2012 полностью изменилась (подробнее clck.ru/ePUN), она не
    привязывается к решению и оптимизирована под использование
    в рамках private cloud. Теперь все лицензии включают в себя
    право на использование всего функционала всех продуктов
    линейки. Другими словами, отдельные лицензии на продукты
    исчезли, и нет ограничений по возможностям. При этом консоли
    управления уже не требуют лицензии. Хотя одно ограничение
    все же есть — каждая лицензия покрывает 2 физических CPU.
    Доступны лишь два варианта: System Center 2012 Standard и Data-
    center, которые отличаются лицензированием виртуальных сред.
    Первая позволяет управлять только 2-мя виртуальными ОС (на
    частном или публичном облаке), у второй ограничения отсутствуют.
    Причем в пакет лицензий уже включены права на использование
    серверов управления и SQL Server, - отдельно их покупать тоже не
    потребуется.
    Суммарно стоимость лицензии выросла, но она нивелируется
    за счет того, что в нее включены лицензии на подкомпоненты.
    Клиентские лицензии по-прежнему требуются, но теперь они также
    объединены и будут доступны в рамках набора System Center Client
    ML Suite , в который входят лицензии для Service Manager, Operations
    Manager, Data Protection Manager и Orchestrator.

    AD


    Установка


    Компонент AD Domain Services (AD DS) и связанные с ним службы формируют основу корпоративных сетей Windows. Они хранят данные о подлинности пользователей, компьютеров и служб, а следовательно, их можно использовать для проверки подлинности пользователя или компьютера. Кроме того, указанные средства предоставляют пользователям и компьютерам механизм получения доступа к ресурсам предприятия.
    В предыдущих версиях Windows при повышении ранга рядового сервера до контроллера домена другие службы оставались доступными независимо от их использования. Для этих дополнительных ненужных служб надо было вносить исправления в систему безопасности и обновлять ее, не говоря уже о дополнительных угрозах безопасности для контроллера домена. В системе WServer эти проблемы устранены благодаря архитектуре на основе ролей. При ней сервер начинает свой жизненный цикл с весьма ограниченной установки системы Windows, в которую потом добавляются роли, а также связанные с ними службы и компоненты. Посредством установки ядра сервера (Server Core) системы WServer производится минимальная установка системы Windows, в которой нет даже пользовательского интерфейса (GUI) и есть только командная строка.
    При установке если нужно, нужно загрузить настраиваемый драйвер для получения доступа к подсистеме диска (щелкните кнопку Загрузка драйвера).

    Структура AD, идентификация и доступ


    AD DS обеспечивают идентификацию и доступ ( Identity and Access, IDA) для корпоративных сетей — это служба. Инфраструктура IDA должна выполнять следующие задачи.
    1. Хранение информации о пользователях, группах, компьютерах и других объектах идентификации. Объект идентификации (identity) — это представление сущности, выполняющей какие-то действия в корпоративной сети. Предположим, что пользователь открывает документы в общей папке на сервере. Они защищены разрешениями списка контроля доступа (Access Control List, ACL). Доступом к документам управляет подсистема безопасности сервера, который, сравнивая объект идентификации пользователя с объектами в списке ACL, предоставляет или запрещает пользователю доступ. Поскольку компьютеры, группы, службы и другие объекты тоже выполняют определенные действия в сети, они должны быть представлены объектами идентификации. Среди информации об объекте идентификации, которая хранится, есть свойства, уникальным образом идентифицирующие объект, например имя пользователя либо идентификатор безопасности (Security Identifier, SID), а также пароль объекта идентификации. Таким образом, хранилище объектов идентификации является одним из компонентов инфраструктуры IDA. В хранилище данных AD, которое также называется каталогом, хранятся объекты идентификации. Самим хранилищем управляет контроллер домена — сервер, играющий роль AD DS.
  • Проверка подлинности объекта идентификации. Сервер не предоставляет пользователю доступа к документу, пока не будет подтверждена подлинность объекта идентификации, представленного в запросе доступа. Чтобы подтвердить подлинность объекта, пользователь указывает секретную информацию, известную только ему и инфраструктуре IDA.
    Это механизм, с помощью которого проверяется подлинность объекта идентификации посредством сравнения секретной информации (скажем, паролей пользователя либо компьютера) с данными в хранилище объектов идентификации.
    Идентификация. Описанные ранее доменные службы AD DS предоставляют центральный репозиторий для управления идентификацией в организации. Они проверяют подлинность и авторизацию в сети, а также поддерживают управление объектами с помощью групповой политики.
    Кроме того, службы AD DS обеспечивают управление информацией и общим доступом к службам, помогая пользователям находить в каталоге различные компоненты: файловые серверы, принтеры, группы и других пользователей. По этой причине AD DS часто называют службой каталогов сетевой операционной системы. Службы AD DS представляют основную технологию AD, поэтому они должны быть развернуты в каждой сети с операционной системой WServer.

    Службы управления правами AD


    AD Rights Management Services — Целостность. Хотя сервер Windows может запрещать и разрешать доступ к документу на основе списка контроля доступа ACL, можно несколькими способами следить за дальнейшими операциями с документом и его содержимым после открытия документа пользователем.
    Службы управления правами AD (AD RMS) предоставляют технологию защиты информации, с помощью которой можно реализовать шаблоны устойчивых политик использования, задающих разрешенное и неавторизованное применение в сети, вне ее, а также внутри и вне периметра брандмауэра. Например, для пользователей можно сконфигурировать шаблон, который разрешает читать документ, но запрещает печатать и копировать его содержимое.
    Для роли AD RMS необходим домен AD с контроллерами, где установлены версия системы не ниже Windows 2000 Server SP3, веб-сервер IIS, сервер баз данных типа Microsoft SQL Server 2008, клиент AD RMS (он доступен в центре загрузок Microsoft, а также по умолчанию включен в версии Windows Vista и WServer), а также обозреватель или приложение RMS, например Microsoft Internet Explorer, Microsoft Office, Microsoft Word, Microsoft Outlook или Microsoft PowerPoint. В службах AD RMS может использоваться роль AD CS для вложения сертификатов в документы, а также роль AD DS для управления доступом.
    В совокупности роли AD реализуют интегрированное решение IDA:
    AD DS и AD LDS — поддерживают основные службы каталогов в доменной и независимой реализации;
    AD CS — предоставляет надежные учетные данные в виде цифровых сертификатов PKI;
    AD RMS — защищает целостность информации в документах;
    AD FS — поддерживает партнерские отношения, избавляя от необходимости создавать множество отдельных объектов идентификации для одного принципала безопасности в средах федерации.

    Помимо идентификации и доступа


    Структура AD поддерживает не только идентификацию и доступ, но и механизмы поддержки, управления и настройки ресурсов в распределенных сетевых средах.
    Администрирование на основе политики упрощает управление даже в самых больших сложнейших сетях, предоставляя единую точку, в которой можно развернуть параметры настройки во множестве систем. Эти политики - групповая, политики аудита и гранулированные политики паролей.
    Службы репликации распространяют по сети данные каталогов, в частности само хранилище данных, а также информацию для реализации политики и конфигурации вместе со сценариями входа. Для хранилища данных существует даже отдельный раздел конфигурации, который содержит информацию о сетевой конфигурации, топологии и службах. Запрашивать каталог AD и локализовывать объекты в хранилище данных можно с помощью нескольких компонентов и технологий.
    Информация обо всех объектах в каталоге содержится в разделе хранилища данных, называемом глобальным каталогом (или частичным набором атрибутов), который дает возможность локализовать объекты в каталоге. Для чтения информации из хранилища данных можно применять, например, программный интерфейс ADSI (AD Services Interface) и протокол LDAP.
    Хранилище данных AD можно использовать также для поддержки приложений и служб, напрямую не связанных с AD DS. Внутри БД в разделах приложений может храниться информация для поддержки приложений, которым необходимы данные репликации. Система доменных имен DNS на сервере WServer может хранить информацию в базе данных, которая называется интегрированной зоной AD. Она поддерживается в AD DS как раздел приложения и реплицируется с помощью служб репликации AD.

    Компоненты инфраструктуры AD


    Более подробно структура AD описана в справочном руководстве к системе WServer и на сайте TechCenter по адресу technet.microsoft.com.
    Подразделения (организационные единицы). База данных AD является иерархической. Объекты в хранилище данных можно собирать в контейнеры. Одним из типов контейнеров является класс объектов container. Открыв оснастку AD — пользователи и компьютеры, вы увидите заданные по умолчанию контейнеры, в частности Users, Computers и Builtin. Еще один тип контейнера — подразделение (организационная единица). Оно предоставляет не только контейнер для объектов, но и область действия управления объектами. Подразделение ( Organizational Unit, OU) может хранить так называемые объекты групповой политики, которые автоматически применяются к пользователям и компьютерам в подразделении.
    Сайты При проектировании сетевой топологии распределенного предприятия приходится рассматривать сайты сети. Однако в AD им придается весьма специфический смысл благодаря особому классу объектов site. Сайт (или узел) AD — это объект, представляющий часть предприятия с хорошей сетевой коммуникацией. Сайт создает периметр репликации и использования служб. Контроллеры домена внутри сайта реплицируют изменения в течение нескольких секунд. Изменения между сайтами реплицируются на основе допущения, что подключения между сайтами медленные, дорогостоящие либо ненадежные по сравнению с подключениями внутри сайта. Кроме того, клиенты предпочитают использовать распределенные службы, предоставляемые серверами в своем или соседнем узле. Например, когда пользователь входит в домен, клиент системы Windows вначале пытается пройти проверку подлинности с помощью контроллера домена в своем узле. Если же там нет доступного контроллера, клиент пробует сделать это с помощью контроллера домена в другом узле.
    конец

    Администрирование


    Оснастка AD — пользователи и компьютеры и создание здесь объектов пользователей, групп и компьютеров в подразделениях (Organizational Unit, OU) домена — основа работы IT-профессионала в среде AD DS.
    Сейчас же мы рассмотрим две важные высокоуровневые концепции предприятия: локализацию объектов в каталоге и безопасность AD с поддержкой решения задач персоналом.
    Я знаю, что многие администраторы продолжают использовать консоли по умолчанию, поэтому хотел бы описать множество средств, с помощью которых они могут выполнять свою работу, не создавая отдельно настраиваемой консоли ММС (Microsoft Management Console) со всеми необходимыми оснастками.
    Многие администраторы также значительно углубляются в свои структуры OU для локализации и управления объектами, вместо того чтобы использовать преимущества сохраненных запросов (Saved Queries) для виртуализации представления доменов. Хотя глава посвящена лишь экзаменационной теме «Поддержка учетных записей AD», приведенные в ней советы и рекомендации помогут обеспечить более высокий уровень безопасности ежедневной работы на предприятии. Мы также обсудим способы их эффективного использования.
    Административные инструменты Windows совместно используют общую структуру ММС. По центру окна находится панель сведений.
    Административные инструменты, называемые оснастками, используют дерево консоли и панель сведений консоли для обеспечения административных функций. Консоль ММС — это что-то вроде поясного ремня монтажника, к которому можно прикрепить один или несколько инструментов (оснасток).
    Большинство средств в папке Администрирование (Administrative Tools) запускаются в виде одной консоли с единственной оснасткой, как, например, Просмотр событий, Службы и Планировщик заданий. Другие инструменты, включая Управление компьютером, открываются в виде консолей со множеством оснасток — некоторые из них могут запускаться как независимые консоли.
    Существует два типа консолей ММС: предварительно откопфигурированные и настраиваемые. Предварительно отконфигурированные консоли устанавливаются автоматически при добавлении роли или компонента для администрирования этой роли пли компонента. Они функционируют в пользовательском режиме и их нельзя модифицировать или сохранять, зато пользователь может создавать настраиваемые консоли с теми же инструментами и функциями.
    Далее в книге мы будем рассматривать поддержку компонентов управления логических компонентов и инфраструктуры доменных служб AD: пользователей, групп, компьютеров и групповой политики. Все эти компоненты содержатся в базе данных каталогов и в папке SYSVOL на контроллерах домена.

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


    В большинстве случаев администрирование AD осуществляется с помощью следующих оснасток и консолей:
    AD — пользователи и компьютеры. Управление ежедневно используемыми ресурсами, включая пользователей, группы, компьютеры, принтеры и общие папки. Эта оснастка чаще всего применяется администраторами AD.
    AD — сайты и службы. Управление репликацией, сетевой топологией и соответствующими службами.
    Схема AD (AD Schema ). Анализ и модификация определения классов объектов и атрибутов. Схема — проектная модель AD. Она редко просматривается и еще реже модифицируется. Поэтому такая оснастка не устанавливается по умолчанию.
    Оснастки и консоли AD устанавливаются при добавлении роли AD DS на сервер. При установке роли AD DS в Диспетчер сервера добавляются два административных средства AD: оснастка AD — пользователи и компьютеры и оснастка AD — сайты и службы. Тем не менее для администрирования AD из системы, не служащей контроллером домена, необходимо установить средства удаленного администрирования сервера RSAT, для чего в Диспетчере сервера (Server Manager, ServerManager.msc) WServer нужно выбрать узел Компоненты (Features). Средства удаленного администрирования сервера RSAT можно загрузить на сайте Microsoft и установить на клиентах Windows Vista Service Pack 1.
    Все остальные административные средства находятся в папке Администрирование (Administrative Tools), которая расположена в Панели управления (Control Panel).
    ПКМ значок запускаемого апплета в панели управления и примените команду Запуск от имени администратора (Run As Administrator). Если эта команда не отображается, попробуйте ПКМ при нажатой клавише Shift.
    Чтобы создать настраиваемую консоль ММС, откройте пустую консоль ММС. Для этого откройте меню Пуск, в поле Начать поиск введите команду mmс.ехе и нажмите клавишу Enter.

    Сохранение и распространение настраиваемой консоли


    Если вы планируете распространить консоль, рекомендуется сохранить ее в пользовательском режиме. Чтобы изменить режим консоли, в меню Консоль (File) щелкните Параметры (Options) (зайти нужно как автор).
    Ввели понятие группы серверов. Теперь можно
    управлять несколькими серверами одновременно, а в Dashboard
    выводится информация, собранная со всех систем. Выбрав в списке сервер из меню, можно запустить другие средства управления:
    консоль Computer Management или PowerShell. Практически все инструменты администрирования, ранее предлагавшиеся в виде отдельных консолей, теперь встроены в диспетчер сервера.
    Как и ранее, настройка в основном производится при помо-
    щи мастеров. При установке роли можно выбрать один из двух
    вариантов: роль/компонент или сценарий развертывания RDS.
    Далее мастер предлагает указать сервер(а) из списка или VDI-
    диск. По окончании настройки вернуться к мастеру можно из окна
    Notification.

    Режимы консоли ММС


    По умолчанию новые консоли сохраняются в авторском режиме, позволяющем добавлять и удалять оснастки, просматривать все секции дерева консоли и сохранять настройки.
    Пользовательский режим ограничивает функциональность консоли, чтобы ее нельзя было изменять. Режим Пользовательский — полный доступ (User Mode — Full Access) часто применяется для консолей опытными администраторами. Пользователи консоли могут переключать и применять все оснастки, но не могут добавлять оснастки в консоль, удалять их пли изменять их свойства
    Пользовательский — Ограничейный доступ, много окон (User Mode — Limited Access, multiple windows) Пользователи могут переключать и применять только те оснастки, которые отконфпгурированы для отображения в дереве консоли. Для этого режима предвари-тельно конфигурируются окна, сфокусированные на конкретных оснастках. Пользователи не могут открывать новые окна
    Пользовательский — ограничейный доступ, одно окно - Пользователи могут переключать и применять лишь те оснастки, которые видимы в дереве консоли, и могут открывать их только в одном окне
    Режим Пользовательский — ограниченный доступ (User Mode — Limited Access) с множеством окон пли с одним окном — это режим с ограниченной функциональностью, поэтому он применяется для консолей администраторами с ограниченным набором задач.
    Когда консоль больше не хранится в авторском режиме, вы как автор консоли можете внести изменения, щелкнув сохраненную консоль ПКМ и применив команду Автор.
    Консоли сохраняются с файловым расширением .msc, по умолчанию — в папке Administrative Tools, но на самом деле это не папка, а апплет панели управления. Если сказать точнее, сохраняются консоли в папке главного меню (Start) профиля пользователя %userprofile%\AppData\Roaming\Microsoft\Windows\StartMenu.
    Указанная папка защищена, так что только ваша учетная запись имеет доступ к консоли. Лучше всего входить на компьютер с использованием учетной записи без привилегий, а затем запускать административные инструменты, включая настраиваемую консоль, с альтернативными учетными данными, обеспечивающими достаточные права для задач администрирования. Но из-за участия двух учетных записей в работе при сохранении консоли в подпапке главного меню пользовательского профиля одной учетной записи потребуется дополнительная навигация, что может привести к ошибкам отказа в доступе.
    Сохраните свою консоль в папке, доступ к которой можно получить с пользовательскими или административными учетными данными. Рекомендуется сохранять консоли в общей сетевой панке, чтобы получать к ним доступ с других компьютеров. Как вариант можно открыть доступ к папке для других адмииистраторов, создав таким образом централизованное хранилище настраиваемых консолей. Консоли также можно сохранять на таком переносном устройстве, как USB-диск, а также пересылать как вложения электронной почты.

    Создание объектов в AD


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

    Создание подразделения


    С целью упрощения функций управления и отображения, то есть для упрощения поиска объектов, ресурсы распределены среди подразделений.
    Подразделения (Organizational Unit, OU) в AD представляют собой административные контейнеры, которые служат для группирования объектов с общими требованиями администрирования, конфигурации или видимости. Смысл сказанного станет понятным при изучении дизайна и управления OU. А сейчас просто нужно знать, что подразделения (OU) обеспечивают административную иерархию, аналогичную иерархии па диске: подразделения представляют собой коллекции объектов, которые предназначены для администрирования. В данном случае делается акцент на слове «администрирование», поскольку подразделения не используются для назначения разрешений доступа к ресурсам — для этого существуют группы. Пользователи помещаются в группы, которым назначаются разрешения доступа к ресурсам. Подразделения же (OU) представляют собой административные контейнеры, внутри которых администраторы управляют этими пользователями и группами. Далее описан процесс создания подразделения.
    1. Откройте оснастку AD — пользователи и компьютеры.
    2. ПКМ узел домена или подразделения, в которое хотите добавить повое подразделение, выберите опцию Создать (New)
    и щелкните команду Подразделение (Organizational Unit).
    3. Установите флажок Защитить контейнер от случайного удаления ( Protect Container From Accidental Deletion).
    Подразделения имеют и другие свойства, которые можно конфигурировать;определить их можно после создания объекта.
    4. Щелкните подразделение правой кнопкой мыши и примените команду Свойства .
    Если подразделение представляет физическое пространство, например офис, в свойствах можно указать почтовый адрес подразделения.
    Вкладку Управляется (Managed By) можно применить для привязки к пользователю или группе, которая несет ответственность за подразделение.
    Щелкните кнопку Изменить под полем Имя. Откроется диалоговое окно Выбор: "Пользователь", "Контакт" или "Группа" ; по умолчанию оно не выполняет поиск групп.
    Для поиска нужно вначале щелкнуть кнопку Типы объектов (Object Types) и выбрать тип объектов Groups. Остальная контактная информация на вкладке Управляется (Managed By) заполняется данными учетной записи, указанной в поле Имя (Name).
    Вкладка Управляется используется исключительно для контактной информации. Указанные пользователи и группы не получают разрешения или доступ к подразделению.
    В административных средствах WServer появилась новая опция — Защитить контейнер от случайного удаления. При этом в подразделение добавляются два разрешения: Everyone::Deny::Delete и Everyone::Deny::Delete Subtree. Поэтому пользователи и даже администраторы не могут случайно удалить подразделение и его содержимое.
    Для того чтобы все же удалить подразделение, вначале следует отключить переключатель безопасности. Чтобы удалить защищенное подразделение, выполните следующие действия.
    1. В оснастке AD — пользователи и компьютеры щелкните меню Вид (View) и выберите команду Дополнительные компоненты (Advanced Features).
    2. подразделение ПКМ и примените команду Свойства.
    3. Перейдите на вкладку Объект (Object).
    4. Если подразделение содержит другие объекты, в диалоговом окне Подтвердить удаление поддерева (Confirm Subtree Deletion) вам будет предложено подтвердить удаление подразделения и всех содержащихся в нем объектов.
    Щелкните кнопку Yes.

    Поиск объектов в AD


    Связанные свойства - такие как атрибут Управляется (здесь нужно выбрать соответствующего пользователя или группу).
    Поиск объектов в AD может потребоваться и в других ситуациях; для него предусмотрено несколько пользовательских интерфейсов. В этом разделе мы рассмотрим некоторые технологии поиска.
    Поиск пользователей проще выполнять по фамилии, а не имени в столбце Имя, которое является основным именем CN.

    Использование сохраненных запросов


    Эта функция позволяет создавать управляемые правилами представления домена, отображающие объекты из одного или нескольких подразделений (OU).
    1. Откройте оснастку AD — пользователи и компьютеры. ПКМ узел Сохраненные запросы, Создать-Запрос.
    2. Щелкните кнопку Обзор, чтобы отыскать корень запроса. Поиск будет ограничен выбранным доменом или подразделением.
    3. Щелкните кнопку Запрос в окне Нового запроса, чтобы определить запрос. В диалоговом окне Поиск: Общие запросы (Find Common Queries) выберите тип запрашиваемого объекта.
    Созданный запрос сохраняется в экземпляре оснастки AD — пользователи и компьютеры, так что при следующем открытии одноименной консоли (dsa.msc) ваш запрос будет доступен. Для переноса сохраненных запросов в другие консоли или другим пользователям эти запросы можно экспортировать в виде XML-файлов, а затем импортировать в конечную оснастку.
    Представление сохраненного запроса в панели сведений можно настроить, как описано ранее, выбрав конкретные столбцы и тип сортировки. Важное преимущество сохраненных запросов в том, что настраиваемое представление специфично для каждого сохраненного запроса. При добавлении столбца Фамилия (Last Name) в стандартное представление подразделения (OU) этот столбец добавляется в представление каждого подразделения, и вы увидите пустой столбец Фамилия даже для подразделений компьютеров и групп. В сохраненные запросы можно добавить столбец Фамилия для поиска объектов пользователей, а также другие столбцы.
    Подробные сведения и примеры сохраненных запросов можно найти по адресу www. petri .co.il/saved_queries_in_windows_2003_dsa.htm.

    Диалоговое окно выбора пользователей, контактов, компьютеров и групп


    Щелчком кнопки Проверить имена каждое имя преобразуется в ссылку в случае его наличия. Вы можете вводить только неполные имена. Если щелкнуть кнопку ОК или Проверить имена, система Windows попытается преобразовать неполное имя в корректный объект. Если найден лишь один соответствующий объект, оно будет разрешено. Если же найдено несколько соответствующих объектов, откроется диалоговое окно Найдено несколько имен (Multiple Names Found).
    По умолчанию диалоговое окно выбора выполняет поиск во всем домене.
    Кроме того, диалоговое окно выбора пользователей, контактов, компьютеров или групп редко выполняет поиск всех четырех типов объектов.
    Например, при добавлении членов в группу поиск компьютеров не выполняется по умолчанию. Если ввести имя компьютера, оно не будет корректно разрешено.
    Чтобы корректно разрешать объекты, вы должны указать тип объектов для области поиска в диалоговом окне выбора.

    Команды поиска


    Чтобы получить расширенный контроль над запросом, в раскрывающемся списке Найти выберите Пользовательский поиск (Custom Search). Если выбрать этот тип поиска и перейти на вкладку Дополнительно, можно создавать мощные запросы LDAP.
    Например, запрос OU=*main* выполняет поиск подразделения с именем, содержащим слово main, и возвращает подразделение Domain Controllers. Другие типы поиска используют только текст в начале имени. Пользовательский поиск с групповыми символами позволяет создавать запросы содержимого.
    Для удобства поиска можно добавить на рабочий стол или в главное меню настраиваемый ярлык. Конечным объектом ярлыка должна быть команда rundll32 dsquery,OpenQueryWindow.

    Поиск объектов с помощью команды Dsquery


    В Windows есть утилиты командной строки с функциями, аналогичными функциям таких пользовательских интерфейсов, как оснастка AD — пользователи и компьютеры. Многие из этих команд начинаются с букв DS, поэтому они называются командами DS.
    Команда Dsquery может локализовать объекты в AD.
    Аналогично другим командам DS, Dsquery подробно документирована. Введите команду dsquery.exe /?, чтобы получить сведения о ее синтаксисе и применении. Для большинства команд DS требуется указать класс объекта, к которому нужно применить команду. Например, вы можете ввести команду dsquery для поиска пользователя, а также Dsquery computer, Dsquery group и Dsquery ou для поиска соответствующих типов объектов. В соответствии с указателем типа объекта можно использовать переключатели для назначения критерия запроса. Например, каждый объект можно локализовать, отыскать по имени с помощью переключателя -nаmе. Большинство объектов можно запрашивать на основе описания (переключатель - desc ). Принципалы безопасности можно также отыскать на основе имен входа пред-Windows 2000 (переключатель -samid). Чтобы узнать, какие свойства можно запрашивать, введите команду dsquery objecttype /?.
    Например, для локализации всех пользователей, имена которых начинаются с Jam, можно ввести запрос dsquery user -name jam*. После переключателя свойства (в данном случае nаmе) можно ввести критерий (без учета регистра) с такими групповыми символами, как звездочка, которая представляет все числовые и другие символы. По умолчанию команда Dsquery возвращает найденные объекты с распознаваемыми именами DN (Distinguished Name).
    c:\>dsquery user -name jam*
    "CN=Janes D. Kramer,OU=Employees,OU=People,DC=contoso,DC=com"
    "CN=James Fine,OU=People,DC=contoso,DC=com"
    "CN=James Hendergart,OU=Employees, OU=People, DC=contoso,DC=com"
    "CN=James R. Hamilton,OU=Employees,OU=People,DC=contoso,DC=com"
    "CN=James wan Eaton ,OU=Employees,OU=People,DC=contoso,DC=com"
    "CN=Janie Reding,OU=Employees,OU=People,DC=contoso,DC=com"
    Если распознаваемые имена DN неудобны для просмотра результатов, добавьте в команду Dsquery переключатель -о. Например, вы можете добавить переключатель -о samid, чтобы вернуть результаты с именами входа пред-Windows 2000, или переключатель -о uрn, чтобы вернуть список UPN-имен.

    Имена DN, RDN и CN


    Параметр DN представляет тип пути к объекту в AD. Каждый объект в AD имеет уникальный параметр DN. Например, пользователь Джеймс Файн имеет DN-путь
    CN=James Fine,OU=People,DC=contoso, DC=com
    Как видите, DN-путь начинается с объекта и доходит до домена верхнего уровня в пространстве DNS-имен contoso.com. CN означает общее имя (Common Name). Параметр OU означает подразделение (Organizational Unit), a DC - компонент домена (Domain Component).
    Секция DN до первого OU или контейнера называется относительным отличительным именем, или RDN (Relative Distinguished Name). В случае с Джеймсом Файном именем RDN объекта будет CN=James Fine. Именем RDN подразделения People соответственно станет OU=People.
    Поскольку имя DN объекта должно быть уникальным в службе каталогов, RDN-имя объекта должно быть уникальным внутри своего контейнера.
    Поэтому при приеме на работу еще одного служащего с именем Джеймс Файн и размещении объектов обоих пользователей в одном подразделении (OU) второй пользователь получит другое имя CN.

    Делегирование и безопасность объектов AD


    Ваши возможности создавать объекты пользователей, компьютеров, групп и подразделений, а также как получать доступ к свойствам этих объектов зависят от того, входите ли вы в группу Администраторы в домене. Каждому пользователю в группе технической поддержки не обязательно быть членом группы администраторов в домене, чтобы выполнять простые задания, такие как сброс пользовательских паролей и разблокирование учетных записей пользователей. Вместо этого следует каждой роли в организации предоставить разрешение выполнять задачи этой роли без дополнительных привилегий. Эти функции службы поддержки — делегированные административные задачи. Обычно служба технической поддержки не может создавать новые учетные записи пользователей, зато может вносить изменения в существующие учетные записи пользователей. На этом занятии мы обсудим, как делегировать конкретные административные задачи в AD путем изменения списков контроля доступа ACL (Access Control List) для объектов AD.
    Все объекты AD, например пользователи, компьютеры и группы, созданные на предыдущем занятии, могут быть защищены с помощью списка разрешений. Таким образом, службе группы технической поддержки предоставляется разрешение сброса паролей пользовательских объектов. Эти разрешения для объекта называются записями контроля доступа АСЕ (Access Control Entry) и назначаются пользователям, группам и компьютерам (так называемым принципалам безопасности). Записи АСЕ хранятся в дискреционном списке контроля доступа DACL (Discretionary Access Control List). Список DACL — это составляющая списка ACL объекта, который также содержит системный список контроля доступа SACL (System Access Control List) с параметрами аудита. Эта модель похожа на модель разрешений доступа к файлам и папкам, по крайней мере ее термины и концепции идентичны.
    Делегирование административного контроля, которое также называется делегированием контроля или просто делегированием, означает лишь назначение разрешений управлять доступом к объектам и свойствам в AD.
    Аналогично предоставлению группе права изменять файлы в папке, члены группы получают разрешение сбрасывать пароли объектов пользователей.

    Пользователи


    Создание объекта пользователя


    Поле Полное имя (оно же Выводимое имя) используется для создания нескольких атрибутов объекта пользователя, включая основное имя СN (Common Name), а также для отображения свойств имени. Складывается из фамилии, инициалов и имени. Имя СN пользователя отображается в панели сведении оснастки. Оно должно быть уникальным в контейнере или подразделении. Поэтому при создании объекта пользователя для лица с тем же именем, что и у существующего Пользователя в том же подразделении, вам потребуется ввести уникальное имя в поле Полное имя.
    В раскрывающемся списке выберите суффикс основного имени пользователя (UPN User Principle Name), который будет прикреплен к имени входа пользователя с символом @.
    Имена пользователей в AD могут содержать некоторые особые символы (включая точки, дефисы и апострофы) (О'Хара или Смит-Бейтс). Тем не менее определенные приложения могут иметь другие ограничения, поэтому рекомендуется использовать только стандартные буквы и цифры.
    Списком доступных суффиксов UPN можно управлять с помощью оснастки AD — домены и доверие. ПКМ корень оснастки AD — домены и доверие, примените команду Свойства и на вкладке Суффиксы UPN (UPN Suffixes) добавьте или удалите суффиксы. Имя DNS домена AD всегда будет доступно в качестве суффикса и не может быть удалено.
    В поле Имя входа пользователя (пред-Windows 2000) (User Logon Name (Pre-Windows 2000)) введите имя входа для систем, предшествовавших Windows 2000, которое часто называется низкоуровневым именем входа.
    Установите флажок Требовать смену пароля при следующем входе в систему. Рекомендуется всегда устанавливать этот флажок, чтобы пользователь мог создать новый пароль, неизвестный персоналу IT.
    Интерфейс Новый объект — Пользователь позволяет конфигурировать лишь немногие свойства учетной записи, например имя объект пользователя в AD поддерживает десятки дополнительных свойств — конфигурировать их можно после создания объекта.
    Однако эти методы могут оказаться неэффективными при работе с большим количеством учетных записей, в частности при создании учетных записей новых служащих.
    Шаблон учетной записи пользователя — это типовая учетная запись для копирования, предварительно заполненная основными свойствами и отключенная. Свойства на вкладке Общие и адрес улицы не копируются.
    Например, вам может потребоваться скопировать название задания и адрес улицы. Вы можете модифицировать схему AD и включить дополнительные атрибуты при дублировании пользователя. Инструкции можно найти в статье 827832 базы знаний по адресу support.microsoft.com/kb/827832. Тем не менее в вашем распоряжении будут расширенные методы. С помощью этих инструментов можно обеспечить полный контроль над процессом создания новой учетной записи.

    Инструменты командной строки AD


    Dsquery.exe входит в набор утилит командной строки AD, называемый командами DS. В WServer поддерживаются следующие команды DS:
    Dsget Возвращает указанные атрибуты объекта.
    Dsmod Модифицирует указанные атрибуты объекта.
    Dsmove Перемещает объект в новый контейнер или подразделение.
    Dsrm Удаляет объект и все его дочерние объекты.
    Dsquery Выполняет запрос на основе параметров, указанных в командной строке, и возвращает список объектов с аналогичными параметрами. По умолчанию результирующий набор содержит отличительные имена DN (Distinguished Name) каждого объекта, однако вы можете использовать параметр -о с такими модификаторами, как dn, rdn, upn или samid, для получения результатов с именами DN, относительными именами DN, основными именами пользователей UPN или именами входа предыдущих версий Windows (идентификаторы диспетчера безопасности учетных записей SAM).
    Большинство команд DS принимают два модификатора после самой команды: тип объекта и имя DN объекта. Например, следующая команда добавляет учетную запись пользователя Mike Fitzmaurice:
    dsadd user "cn=Mike Fitzmaurice,ou=People,dc=contoso,dc=com"
    Сразу после команды указывается тип объекта user. После типа объекта вводится имя DN объекта. Если в имени DN объекта есть пробелы, заключите DN в кавычки. Следующая команда удаляет того же пользователя:
    dsrm user "cn=Mike Fitzmaurice,ou=People,dc=contoso.dc=com"
    Для чтения или манипуляций с атрибутами объектов используются DS-кoманды Dsquery.exe, Dsget.exe и Dsmod.exe. Чтобы указать атрибут, включите его в качестве параметра после имени DN объекта. Например, следующая команда извлекает путь к домашней папке пользователя Mike Fitzmaurice:
    dsget user "cn=Kike Fitzmaurice,ou=People,dc=contoso,dc=com" -hmdir
    Параметр DS-команды, представляющий такой атрибут, как, например, hmdir, не всегда соответствует имени атрибута в оснастке AD — пользователи и компьютеры или схеме.

    Команда Dsadd


    Для создания объектов в AD используется команда dsadd. Следующая команда содержит параметры, необходимые для создания учетной записи пользователя:
    dsadd user "User DN" -samid pre-Windows 2000 logon nаmе
    -pwd Password|* -mustchpwd yes
    Параметр pwd определяет пароль. Если указать символ звездочки (*), будет предложено ввести пароль пользователя. Параметр mustchpwd указывает, что пользователь должен изменить свои пароль при следующем входе в систему.
    Команда DSADD USER принимает много параметров со свойствами объекта пользователя. Большинство названий параметров очевидны, например -email, -profile и -company. Вы можете получить соответствующую информацию, введя команду DSADD USER/? или выполнив поиск в центре справки и поддержки WServer.
    Специальный маркер $username$ представляет идентификатор SAM в значениях параметров -email, -hmdir, -profile и -webpg. Например, чтобы отконфигурировать домашнюю папку пользователя при создании пользовательской учетной записи с помощью команды DSADD USER, добавьте следующий параметр:
    -hmdir \\server01\users\$username$\documents -hmdrv U:
    -hmdrv U: означает, что сетевую домашнюю папку мы сразу пришпандориваем к сетевому диску U.

    Команда CSVDE


    Утилита командной строки CSVDE импортирует и экспортирует объекты AD в виде текстового файла с разделительными запятыми (текстовый файл разделенных запятыми значений или файл .csv). Утилита CSVDE обеспечивает способ автоматизации создания учетных записей пользователей на основе информации пользователей из баз данных Excel и Access.
    csvde [-i] [-f имя_файла] [-k]
    Параметр -i указывает режим импорта. Если не указать этот параметр, по умолчанию команда CSVDE будет использовать режим экспорта. Параметр -f идентифицирует имя файла для импорта или экспорта. Параметр -k удобно использовать для операций импорта, поскольку он указывает команде CSVDE игнорировать ошибки.
    Команда импортирует текстовый файл с разделительными запятыми (csv или .txt), в котором первая строка определяет атрибуты импорта с помощью их имен LDAP (Lightweight Directory Access Protocol). Каждый объект представлен одной строкой и должен содержать атрибуты, перечисленные в первой строке. Далее приведен пример такого файла:
    DN,objectClass,sAMAccountName,sn,givenName,userPrincipalName
    "cn=Lisa Andrews,ou=People,dc=contoso,dc=com",user,lisa.andrews,
    Lisa,Andrews,[email protected]\
    При импорте этого файла с помощью команды CSVDE в подразделении People создается объект пользователя Lisa Andrews. Файл конфигурирует имя и фамилию пользователя. Команду CSVDE нельзя использовать для импорта паролей, а без пароля учетная запись изначально будет отключена. После сброса пароля можно включить объект.
    Более подробную информацию о ней, в том числе о параметрах и принципах использования для экспорта объектов каталога, можно получить, введя команду csvde/? или воспользовавшись справкой и поддержкой WServer.

    Команда LDIFDE


    С помощью команды ldifde.exe можно импортировать и экспортировать объекты AD. Для выполнения групповых операций с каталогами, соответствующими стандартам LDAP, можно использовать стандарт Интернета файлового формата LDIF (Lightweight Directory Access Protocol Data Interchange Format). Формат LDIF поддерживает операции импорта и экспорта, а также групповые операции, модифицирующие объекты в каталоге. Команда LDIFDE реализует эти групповые операции с помощью файлов LDIF.
    Файловый формат LDIF состоит из блока строк, которые вместе образуют одну операцию. Операции в одном файле разделены пустой строкой.
    Каждая строка, составляющая операцию, содержит имя атрибута, после которого следуют двоеточие и значение атрибута. Предположим, что вам требуется импортировать объекты пользователей для Эприл Стюарт. Содержимое файла LDIF может быть примерно таким:
    DN: СN=Эприл Стюарт,OU=Кадры,DC=сontoso,DC=com
    changeType: add
    CN: Эприл Стюарт
    objectClass: user
    sAMAccountName: april. stewart
    userPrincipalName: [email protected]
    givenName: Эприл
    sn: Стюарт
    displayName: Стюарт, Эприл
    mail: [email protected]
    description : Менеджер по продажам США
    title: Менеджер по продажам
    department : Продажи
    company: Contoso, Ltd.
    Каждая операция начинается с атрибута DN объекта, который является целью операции. Следующая строка changeType указывает тип операции: add, modify или delete.
    Поскольку формат LDIF также является стандартом, многие службы каталогов и базы данных могут экспортировать файлы LDIF.
    Для получения сведений о синтаксисе и методах использования в командную строку введите команду ldifde /?. Далее описаны два самых важных переключателя команды LDIFDE. Импортировать пароль нельзя.
    -i Включает режим импорта. Без этого параметра команда LDIFDE выполняет экспорт информации.
    -f имя_файла Файл для импорта или экспорта.
    Так, следующая команда импортирует объекты из файла Newusers.ldf:
    ldifde -i -f newusers.ldf
    Эта команда принимает множество модификаций с помощью параметров, самые удобные из которых описаны ниже.
    Общие параметры:
    -s имя_сервера Контроллер домена, привязываемый к запросу
    -s FromDN ToDN Преобразует вхождения FromDN в ToDN. Например, этот параметр удобно использовать при импорте объектов из еще одного домена
    -v Включает режим подробной информации Verbose
    -j путь Расположение файла журнала
    -? Справка
    Параметры экспорта:
    -d RootDN Корень поиска LDAP. По умолчанию им является корень домена
    -r Filter Фильтр поиска LDAP. По умолчанию используется фильтр (objectClass=*), означающий все объекты
    -р SearchScope Область или глубина поиска. Для области поиска можно указать значение subtree (контейнер со всеми дочерними контейнерами), base (только непосредственные дочерние объекты контейнера) и onelevel (контейнер и все его непосредственные дочерние объекты)
    -l list Список атрибутов с разделительными запятыми, который будет включен в экспорт результирующих объектов. Этот параметр удобно использовать для экспорта ограниченного числа атрибутов
    -о list Список атрибутов (разделенных запятыми), которые не будут включены в экспорт результирующих объектов. Этот параметр удобно использовать для экспорта всех атрибутов, за исключением лишь некоторых
    Атрибуты импорта:
    -k Игнорирует ошибки и продолжает обработку в случае возникновения ошибок Constraint Violation и Object Already Exists
    В случае импорта пользователей с помощью команды CSVDE или LDIFDE учетные записи будут отключены, пока вы не сбросите их пароли и не включите эти учетные записи.
    При создании шаблона В поле Путь к профилю введите \\server-01\profiles\%usemame%.
    Хотя файлы LDIF можно импортировать с любым расширением, мы следуем соглашению, в соответствии с которым используется расширение .ldf.

    Создание пользователей с помощью PowerShell и VBScript


    Мы рассмотрим два самых мощных инструмента для выполнения и автоматизации административных задач: PowerShell и VBScript. PowerShell позволяет создавать пользователей в новой оболочке командной строки.
    WSH не обеспечивает оболочку для непосредственного выполнения команд. Кроме того, язык VBScript не настолько богат и не полностью использует структуру .NET Framework. Будущее все же за PowerShell.
    Описанные технологии и код PowerShell достаточно сложные и практически идентичны VBScript. Текущая версия PowerShell обеспечивает весьма ограниченную поддержку администрирования AD. В отличие от интерфейса управления WMI и Microsoft Exchange Server с очень богатым набором поставщиков PowerShell, поддержка AD ограничена неуклюжим адаптером ADSI и в конечном счете полагается на ADSI, как и в сценариях VBScript. В будущих версиях PowerShell будет обеспечен поставщик Active Directory, который упростит работу с объектами AD аналогично работе с файлами в файловой системе.

    Создание пользователя с помощью PowerShell


    Основной сценарий PowerShell для создания пользователя выглядит примерно так:
    $objOU= [ADSI]"LDAP://OU=Peoplе, DC=contoso, DC=com"
    $objUser=$objOU.Create(“user","CN= Mary North")
    $objUser.Put("sAMAccountName", "mаrу.north")
    $objUser.SetInfo()
    Этот код демонстрирует четыре основных шага по созданию объекта в AD с помощью PowerShell:
  • Подключение к контейнеру (например, подразделению), в котором будет создан объект. Чтобы создать такой объект, как пользователь, нужно запросить создание объекта у контейнера объекта. Таким образом, процесс начинается с выполнения действия (метода) с контейнером. Первый шаг состоит в подключении к этому контейнеру. Для работы с объектами AD оболочка PowerShell использует библиотеку адаптеров AD Services Interface (ADSI). Адаптер - это преобразователь между сложной и иногда причудливой природой .NET Framework и упрощенной и согласованной структурой PowerShell. Для подключения к объекту AD выполняется строка запроса LDAP, представляющая собой просто моникер протокола LDAP:// с именем DN объекта.
    Оболочка PowerShell использует адаптер типов ADSI для создания объектной ссылки на подразделение People и присваивает ее переменной.
    Имя переменной objOU соответствует стандартам программирования, согласно которым для идентификации типа переменной используется префикс из трех букв, а имена переменных могут быть любой длины и начинаться со знака доллара.
  • Применение метода Create контейнера вместе с указанным классом и относительным отличительным именем RDN (Relative Distinguished Name) нового объекта.
    На этом этапе переменная %objOU является ссылкой на подразделение People. Вы можете запросить создание объекта с помощью метода контейнера Create. Create требует 2 параметра, передаваемых в качестве аргументов: класс и RDN-имя объекта, которое является частью имени объекта в родительском контейнере. Большинство классов объектов используют в качестве своих RDN-имен формат СN=имя_объекта. Имя RDN подразделения (OU) указывается в формате ОU=имя_подразделения, а имя RDN домена — в формате DС=имя_домена.
    3. Заполнение атрибутов объекта с помощью метода Put.
    4. Подтверждение изменений в AD с помощью метода Setlnfo объекта.

    Заполнение атрибутов пользователя


    Важно помнить, что новый объект и изменения не будут сохранены, пока вы не подтвердите их, а для подтверждения изменений требуется заполнить все необходимые атрибуты. Необходимым атрибутом объектов пользователей является имя входа пред-Windows 2000. Имя LDAP этого атрибута — sAMAccountName, поэтому приведенная ниже строка кода присваивает объекту атрибут sAMAccountName с помощью метода Put. Стандартный метод Put используется для записи свойства объекта. Для извлечения свойства применяется стандартный метод Get. Заполнение дополнительных атрибутов пользователя:
    $objUser.put("sAMAccountName",$samAccountName)
    $objUser.put("userPrincipalName",$userPrincipalName)
    $objUser.put("displayName", $displayName)
    $objUser.put(“givenName", $givenName)
    $objUser.put("sn", $sn)
    $objUser.put("description",$description)
    $objUser.put("company", $company)
    $objUser.put("department", $department)
    $objUser.put( "title",$title)
    $objUser.put("mail",$mail)
    $objUser.SetInfo()
    Пока не будет применен метод SetInfo(), внесенные изменения будут выполняться только в локальной копии объекта. Метод Setlnfo() оценивает свойства объекта для подтверждения. Если атрибуту присвоено недействительное значение, вы получите ошибку в строке SetInfo(). С помощью метода GetInfo() объекта пользователя можно перезагрузить исходный объект, отменив таким образом все изменения.
    Чтобы узнать имя атрибута LDAP, в оснастке AD — пользователи и компьютеры откройте вкладку Редактор атрибутов диалогового окна свойств учетной записи пользователя. Редактор атрибутов выводит все атрибуты объекта, включая их LDAP-имена и значения. Чтобы отобразить свойства, заполненные для объекта пользователя, можно также использовать любую из следующих команд:
    $objUser.psbase.properties
    $objUser | get-member
    Хотя большинство атрибутов пользователя являются однозначными, некоторые из них многозначные. Если атрибут принимает множество значений, используйте метод PutEx() объекта пользователя. В Интернете выполните поиск ключевых слов PowerShell user array PutEx, чтобы получить адреса ресурсов многочисленных сообществ, где описывается работа с многозначными атрибутами.
    Команда Put не применяется для назначения пароля пользователя. Вместо нее используется метод SetPassword, как показано ниже:
    $objUser.SetPassword("C0mp!exP@ssw0rd")
    К сожалению, метод SetPassword можно использовать только после создания пользователя и активизации метода SetInfo(). Это означает, что учетная запись создается до назначения пароля. Здесь дело не в ошибке или ограничении PowerShell, а в сути протоколов Kerberos и LDAP. Тем не менее данная методика вполне безопасна, поскольку учетная запись создается в отключенном состоянии.
    После этого нужно включить учетную запись. Флагом состояния учетной записи также нельзя манипулировать с помощью команды Put. Вместо нее используется следующая команда:
    $objUser.psbase.InvokeSet("Account Disabled",$false)
    $objUser.SetInfo()

    Импорт пользователей из базы данных с помощью PowerShell


    Импорт выполняется с помощью нескольких строк дополнительного кода с мощными командлетами PowerShell. Предположим, что вы получили из отдела кадров таблицу Excel с данными о новых сотрудниках. Программа Excel может сохранить эти данные в виде текстового файла с разделительными запятыми (.csv), который затем можно импортировать с помощью PowerShell. Первая строка файла .csv должна содержать имена полей; после нее следуют данные о каждом пользователе. В качестве простого примера рассмотрим файл .csv, сохраненный под именем Newusers.csv:
    сn,sAHAccountName, FirstName,LastName
    John Woods ,john.woods,Johnathan,Woods
    Kim Akers,kim.akers, Kimberly,Akers
    Обратите внимание на то, что имена полей необязательно соответствуют LDAP-именам атрибутов. Эти имена будут сопоставлены именам атрибутов с помощью сценария.
    Оболочка PowerShell может импортировать этот источник данных с помощью одной команды:
    $dataSource=import-csv "newusers.csv"
    После импорта источника данных в нем нужно пройти циклом по каждой записи. Эта операция выполняется блоком foreach, использующим формат
    foreach($dataRecord in $dataSource)
    <
    Командлет ForEach проходит циклом по каждому объекту или записи в источнике данных, присваивая текущий объект переменной $dataRecord, так что текущую запись представляет переменная $dataRecord. Теперь вы можете просмотреть реальные поля в каждой записи, которые становятся свойствами переменной $dataRecord. Например, рассмотрим имя первого пользователя:
    $dataRecord.FirstName
    Его можно присвоить переменной:
    $givenName = $dataRecord.FirstName
    Опять-таки, переменная или имя поля необязательно должны соответствовать LDАР-имени атрибута. Сопоставление выполняется при записи переменной со значением в сам атрибут:
    $objUser.Put("givenName", $givenName)
    LDAP-атрибут givenName заключен в кавычки. Корректно использовать имя требуется только при ссылке на реальный атрибут объекта. Тем не менее код проще понять, если имена полей источника данных и переменных соответствуют именам атрибутов.
    Сложив все фрагменты кода вместе, получим сценарий импорта
    пользователя (сценарий Userimport.ps1):
    $objOU=[ADSI]"LDAP://OU=People,DC=contoso,DC=com"
    $dataSource=import-csv "NewUsers.csv"
    foreach($dataRecord in $dataSource)
    Первая строка сценария подключается к контейнеру OU (подразделение), в котором будут созданы все новые пользователи. Следующие две строки подключаются к источнику данных и выполняют цикл по всем записям, присваивая каждую запись переменной SdataRecord. Блок foreach выполняет две операции.
    Во-первых, он сопоставляет поля в источнике данных с переменными. Затем он создает пользователя.
    Обратите внимание на то, что некоторые переменные конструируются путем конкатенации (объединения) двух полей. Переменная SdisplayName использует формат LastName, FirstName, а переменная SuserPrincipalName — формат FirstName, [email protected].
    Пользователь создается с помощью метода Create подразделения. Атрибуты пользователя заполняются и подтверждаются, после чего назначается пароль и выполняется включение учетной записи.

    Введение в VBScript


    Сценарии VBScript представляют собой текстовые файлы, которые, как правило, редактируются с помощью программы Блокнот или редактора сценариев и сохраняются с расширением .vbs. Для выполнения сценария можно дважды щелкнуть его значок. Сценарий откроется с применением команды Wscript.exe. В качестве альтернативы сценарий можно запустить в командной строке с помощью команды Cscript.ехе:
    cscript.exe имя_сценария
    Обе команды, Wscript.exe и Cscript.exe, являются компонентами сервера сценариев WSH (Windows Scripting Host), представляющего собой структуру автоматизации, установленную во всех текущих версиях Windows, которая поддерживает несколько языков сценариев, в том числе и VBScript.

    Создание пользователя с помощью VBScript


    Поскольку VBScript также использует интерфейс ADSI для манипулирования объектами в AD, процесс создания пользователя в VBScript идентичен созданию пользователя в PowerShell. Приведем простой пример сценария создания пользователя:
    Set objOU=GetObject("LDAP://OU=People,DC=contoso,DC=com")
    Set objUser=objOU.Create("user","CN=Mary North")
    objUser.Put "sAMAccountName","mаrу.north"
    objUser.Setlnfo()
    Вначале сценарий подключается к контейнеру OU (подразделение), в котором будет создан пользователь. Сценарий VBScript применяет инструкцию GetObject для подключения к объекту ADSI в соответствии с его отличительным именем. При присвоении объекта переменной в VBScript для создания объектной ссылки используется инструкция Set.
    Вторая строка кода активизирует метод Create подразделения для создания объекта конкретного класса с конкретным отличительным именем точно так же, как в примере PowerShell. Поскольку результатом выполнения метода является объект, для присвоения объектной ссылки переменной можно вновь использовать инструкцию Set.
    Третья строка кода использует метод Put объекта пользователя, однако в VBScript аргумент не заключается в круглые скобки. Сохраните сценарий в виде файла Newuser.vbs и выполните его в командной оболочке или оболочке PowerShell с помощью следующей команды:
    cscript.exe newusers.vbs

    Свойства учетной записи


    На вкладке Учетная запись (Account) диалогового окна Свойства пользователя, показанной на рис. 3-6, находятся атрибуты, прямо указывающие, что пользователь является принципалом безопасности, то есть представляет собой объект идентификации, которому можно назначать разрешения и права доступа. Другими принципалами безопасности выступают компьютеры, группы и класс объектов inetOrgPerson.
    Рис. 3-6. Свойства учетной записи объекта пользователя
    Некоторые свойства учетной записи требуют отдельного внимания, поскольку они могут оказаться весьма полезными, но не всегда понятными. Эти свойства описаны в табл. 3-2:
    Время входа (Logon Hours )
    отконфигурировать время, в течение которого пользователю разрешено входить в сеть
    Вход на (Log On To)
    ограничить число рабочих станций, на которых пользователь может входить в сеть. В пользовательском интерфейсе эти параметры называются компьютерными ограничениями и сопоставляются с атрибутом userWorkstations. Для ограничения пользователям потребуется включить NetBIOS через TCP/IP, поскольку для ограничения входа этот компонент использует имя компьютера, а не МАС-адрес его сетевой карты
    Запретить смену пароля пользователем
    Установите этот флажок, если данную учетную запись (например, учетную запись гостя) будет использовать множество лиц, либо если вам требуется контроль над паролями учетных записей пользователей. Эта опция обычно используется для управления паролями учетных записей служб. Данная опция неактивна, если установлен флажок Требовать смену пароля при следующем входе в систему
    Срок действия пароля не ограничен (Password Never Expires)
    Установите этот флажок, чтобы указать неограниченный срок действия пароля. При этом будет снят флажок Требовать смену пароля при следующем входе в систему, поскольку эти опции являются взаимоисключающими. Данная опция обычно используется для управления учетными записями служб
    Хранить пароль, используя обратимое шифрование (Store Password Using Reversible Encryption)
    Эта опция, позволяющая хранить пароль в Active Directory без применения мощного алгоритма необратимого шифрования хэша Active Directory, предназначена для приложений, которым требуется знать пароль пользователя. Если вы не используете такие приложения, не устанавливайте этот флажок, поскольку уровень безопасности пароля значительно снизится. Хранение паролей с обратимым шифрованием аналогично хранению паролей в открытом текстовом виде
    Для интерактивного входа в сеть нужна смарт-карта
    Смарт-карты представляют собой переносные защищенные аппаратные устройства, которые хранят уникальную информацию для идентификации пользователя. Они подключаются к системе и обеспечивают дополнительный физический компонент идентификации для процесса проверки подлинности
    Учетная запись важна и не может быть делегирована (Account Is Trusted For Delegation)
    Эта опция позволяет учетной записи службы олицетворять пользователя для получения доступа к ресурсам от его имени. Как правило, эта опция не включена для объектов пользователей, представляющих людей. Она используется для учетных записей служб в инфраструктуре многоярусных приложений
    ПРИМЕЧАНИЕ Настройка очень сложных паролей для учетных записей служб
    Для получения доступа к системным ресурсам службам нужны учетные данные.
    Многим службам для прохождения проверки подлинности требуется учетная запись пользователя домена, которой обычно назначается пароль без истечения срока действия. В таких ситуациях следует применять длинный и сложный пароль. Если учетная запись используется службами лишь в некоторых системах, уровень безопасности учетной записи службы можно повысить, отконфигурировав свойство Вход на (Log On To) и указав список систем, использующих учетную запись службы.

    Группы


    Создание объекта группы


    Группы служат для единого управления коллекциями пользователей, компьютеров и других групп. Простейший пример применения группы — предоставление разрешений доступа к общей папке. Для управления доступом проще всего добавлять пользователей в группы или удалять их.
    Но умолчанию введенное имя также вводится как имя пред-Windows 2000 новой группы. Настоятельно рекомендуется, чтобы эти два имени были идентичны, поэтому не меняйте имя в поле Имя группы (пред-Windows 2000)
    Вместо разрешений доступа к ресурсу отдельным объектам идентификации (например, пользователям и компьютерам) рекомендуется назначить одно разрешение доступа группе, а затем управлять доступом к ресурсу, изменяя членство в этой группе.
    Хотя пользователи, компьютеры и даже службы со временем меняются, бизнес-роли и правила обычно более стабильны.
    В настоящей главе для автоматизации процесса создания учетных записей компьютеров используются компоненты Microsoft PowerShell, VBScript, Comma-Separated Values Data Exchange (CSVDE) и LDAP Data Interchange Format Data Exchange (LDIFDE).
    Реализация управления группами в AD не так проста, поскольку структура AD предназначена для поддержки крупных распределенных сред и включает семь типов групп: две группы домена с тремя областями действия в каждой и локальные группы безопасности.
    Группы представляют собой принципалы безопасности с идентификатором безопасности SID (Security Identifier), которые содержат в своем атрибуте member другие принципалы безопасности (пользователи, компьютеры, контакты и прочие группы).
    Если не пользоваться группами, при удалении учетных записей из списка ACL папки понадобится удалить разрешения доступа, иначе в ACL останется отсутствующая учетная запись (рис. 4-1), ведь SID-идентификатор в ACL ссылается на учетную запись, которую невозможно разрешить.
    При удалении учетной записи автоматически удаляется и ее членство в группе. Кроме того, мы получаем дополнительное преимущество: поскольку список ACL остается стабильным, будет проще выполнять архивацию. Изменение списка ACL папки распространяется на все дочерние файлы и папки и требует архивации всех файлов, даже если содержимое этих файлов не изменялось.
    Чтобы предоставить трем группам доступ чтения к 10 папкам на трех серверах, потребуется добавить 30 разрешений! Как видите, применение лишь одного типа группы, определяющего бизнес-роли пользователей, не позволяет эффективно управлять доступом к 10 папкам.
    Решение — использовать в этом сценарии два типа управления. Пользователями следует управлять как коллекциями на основе их бизнес-ролей. Кроме того, нужно управлять доступом к 10 папкам. Эти 10 папок также будут коллекцией элементов, представляя единый ресурс, распределенный в 10 папках на трех серверах.
    Группы продаж, маркетинга, консультантов, а также восемь отдельных пользователей могут быть членами группы ACL_Sales Folder_Read. Кроме того, значительно проще определить, кто располагает доступом чтения к этим папкам.
    Такой способ управления предприятием с помощью групп называется управлением на основе ролей. Роли пользователей определяются на основании бизнес-функций, например принадлежности к отделу продаж, маркетинга и т. д., и соответствия бизнес-правилам, например роли и отдельные пользователи могут получать доступ к 10 папкам.
    Обе задачи управления можно решить при помощи групп в каталоге. Роли представлены группами, которые содержат пользователей, компьютеры и другие роли. Такие правила, как определение права доступа чтения к 10 папкам, также представлены группами. Группы правил содержат группы ролей и, иногда, отдельных пользователей — таких как восемь пользователей в рассматриваемом примере, или компьютеры.
    Для управления предприятием любого масштаба требуется эффективно руководить группами и создать инфраструктуру групп с единым пунктом управления ролями и правилами. Технически это означает, что потребуются группы, членами которых могут быть пользователи, компьютеры, другие группы и, возможно, принципалы безопасности из других доменов.
    Группа пользователей или компьютеров может иметь несколько имен. Первое имя в поле Имя группы используется Windows 2000 и более поздними системами для идентификации объекта. Это имя преобразуется в атрибуты сn и nаmе объекта.
    Второе имя пред-Windows 2000 представляет атрибут sAMAccountName, служащий для идентификации группы на компьютерах Microsoft Windows NT 4.0 и в некоторых устройствах, таких как сетевые хранилища данных NAS (Network Attached Storage), в операционных системах не из семейства Windows.
    Атрибуты сn и nаmе не могут повторяться только внутри контейнера (подразделения), где создана группа.
    Атрибут sAMAccountName должен быть уникальным во всем домене. Технически данный атрибут sAMAccountName может содержать значение, отличающееся от сn и nаmе, однако делать так не рекомендуется. Используйте имя, уникальное в домене, и введите его в оба поля диалогового окна Новый объект — Группа.

    Типы групп


    1. Группы распространения изначально используются приложениями электронной почты. Эти группы — не субъекты безопасности и не содержат SID-идентификаторы. Поэтому им нельзя назначать разрешения доступа к ресурсам. Сообщение, отправленное группе распространения, будет переслано всем ее членам.
    2. Группы безопасности представляют собой принципалы безопасности с SID-идентификаторами. Группы безопасности могут также служить приложениям электронной почты в качестве групп распространения. Тем не менее если группа будет применяться только для распространения электронной почты, рекомендуется создать группу распространения. Иначе группе будет назначен SID-идентификатор, который добавляется в маркер безопасности доступа пользователя, увеличивая таким образом его размер.

    Область действия группы


    Группы содержат пользователей, компьютеры и целые группы. На группы могут ссылаться списки ACL, фильтры объектов групповой политики и другие компоненты управления. Область действия влияет на все эти характеристики группы: какие члены могут в нее входить, к каким группам она может принадлежать и где использоваться.
    Существует 4 области действия: глобальная, локальная в домене, локальная и универсальная. Характеристики, определяющие каждую область действия, распределены по следующим категориям.
  • Репликация Где определена группа и на какие системы выполняется ее репликация.
  • Членство. Какие типы принципалов безопасности группа может содержать в качестве членов. Может ли группа включать принципалы безопасности из доверенных доменов. Доверие позволяет домену ссылаться на другой домен для проверки подлинности пользователя, включать принципалы безопасности из другого домена в качестве членов группы и назначать разрешения доступа для принципалов безопасности в другом домене. Допустим, домен А доверяет домену Б. Домен А принимает учетные данные пользователей в домене Б. Он пересылает запросы пользователей домена Б для проверки подлинности этих пользователей на контроллере домена Б, поскольку доверяет хранилищу объектов идентификации и службе проверки подлинности в домене Б. Домен А может добавлять принципалы безопасности домена Б в группы и списки ACL в домене А.
    В отношении членства в группе нужно помнить, что если домен А доверяет домену Б, то его пользователи и глобальные группы могут быть членами локальных групп в домене А. Кроме того, пользователям и глобальным группам домена Б можно назначать разрешения доступа к ресурсам в домене А.
    3. Доступность Где будет использоваться группа. Можно ли включить эту группу в другую группу. Можно ли добавить группу в список ACL. Эти характеристики следует продумать при определении области действия каждой группы.

    Локальные группы


    Локальные группы определены и доступны только на одном компьютере. Локальные группы создаются в базе данных диспетчера безопасности учетных записей SAM (Security Accounts Manager) рядового сервера или(и) компьютера домена. В доменной среде нужно управлять локальными группами только в оснастке AD — пользователи и компьютеры.
    Репликация: Локальная группа определяется только в локальной базе данных SAM рядового сервера домена. Эта группа и ее членство не реплицируются в другие системы.
    Может содержать следующие члены:
    1. все принципалы безопасности в домене: пользователи, компьютеры, глобальные группы и локальные группы в домене;
    2. пользователи, компьютеры и глобальные группы из любого домена в лесу;
    3. пользователи, компьютеры и глобальные группы из любого доверенного домена;
  • универсальные группы, определенные в любом домене леса.
  • локальные пользователи, определенные на том же компьютере, где определена локальная группа
    Локальная группа не может быть членом других групп.

    Локальные группы в домене


    Репликация: Локальная группа в домене определяется в контексте именования домена. Объект группы и его членство (атрибут membership) реплицируются на каждый контроллер в домене.
    Членство: такое же как и у локальных групп, кроме локальных пользователей, определенных на том же компьютере, где определена локальная группа.
    Локальную группу в домене можно добавить в списки ACL любого ресурса на любом рядовом компьютере домена.

    Глобальные группы


    Глобальные группы изначально служат для определения коллекций объектов доменов на основе бизнес-правил.
    Репликация: определяется в контексте именования домена.
    Глобальная группа может содержать пользователей, компьютеры и другие глобальные группы только из одного домена.

    Универсальные группы


    Универсальные группы удобно задействовать в лесах из множества доменов.
    Они позволяют определять роли и управлять ресурсами, которые распределены на нескольких доменах.
    Репликация: Универсальная группа определяется в одном домене леса, но реплицируется в глобальный каталог.
    Членство. Универсальная группа может быть членом другой универсальной или локальной группы домена в лесу.
    Члены группы - Пользователи, компьютеры, глобальные группы и универсальные группы домёна и леса.

    Преобразование области действия и типа группы


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

    Вы не можете напрямую преобразовать глобальную группу в локальную группу домена и локальную группу домена в глобальную. Однако сделать это можно, преобразовав вначале группу в универсальную, а затем универсальную — в требуемую область действия. Таким образом можно выполнять преобразования всех областей действия.
    Если в группе уже есть члены или сама она входит в другую группу, изменение области действия может оказаться недоступным.
    Для изменения типа и области действия группы можно использовать команду Dsmod:
    dsmod group DN_группы
    В качестве DN_группы нужно указать отличительное имя модифицируемой группы. Следующие два параметра влияют на область действия и тип группы.< указывает тип группы: безопасность (yes) или распространение (nо).
    Параметр определяет область действия группы: локальная в домене (l), глобальная (g) или универсальная (u).

    Управление членством в группе


    Для добавления и удаления членов группы можно использовать несколько методов. Во-первых, вы можете открыть диалоговое окно Свойства группы и перейти на вкладку Члены группы (Members). Откроется диалоговое окно Выбор: "Пользователи", "Контакты", "Компьютеры " или "Группы"). В поле Введите имена выбираемых объектов (Enter The Object Name) диалогового окна Выбор (Select) можно ввести множество учетных записей, разделенных точкой с запятой.
    Вы можете ввести неполные имена учетных записей — полное имя вводить необязательно. Система Windows выполнит в AD поиск учетных записей, которые начинаются с введенного имени. Если найдено лишь одно имя, система выберет его автоматически.
    По умолчанию Windows выполняет поиск лишь тех пользователей и групп, которые соответствуют именам, введенным в диалоговое окно Выбор. Чтобы добавить в группу компьютеры, щелкните кнопку Типы объектов (Object Types) и установите флажок Компьютеры.
    По умолчанию Windows выполняет поиск лишь групп домена. Чтобы добавить локальные учетные записи, в диалоговом окне Выбор щелкните кнопку Размещение.
    Если вы не можете найти член, который необходимо добавить в группу, в диалоговом окне Выбор щелкните кнопку Дополнительно (Advanced). Откроется окно запросов с дополнительными опциями поиска в AD.

    Атрибуты member и memberOf


    При добавлении члена в группу изменяется атрибут member группы. Атрибут member многозначен. Каждый член представлен значением DN (отличительное имя) в группе. При перемещении или переименовании члена AD автоматически обновляет атрибуты member групп, которым он принадлежит.
    При добавлении члена в группу также косвенно обновляется атрибут memberOf. Атрибут memberOf относится к особому типу атрибутов, который называется обратной ссылкой. Он обновляется в AD, когда на объект ссылается атрибут прямой ссылки, например member. При добавлении члена в группу атрибут member всегда изменяется. Поэтому при использовании вкладки Член групп (Member Of) для добавления объекта в группу на самом деле изменяется атрибут member. Атрибут memberOf обновляется в AD автоматически.

    Автоматизация создания групп и контроля за ними

    Создание групп с помощью команды Dsadd


    С помощью команды Dsadd можно добавлять объекты в AD. Для добавления объекта в группу нужно ввести команду
    dsadd group DN_группы
    где в качестве DN_группы следует указать отличительное имя группы, например "CN=Finance Managers,OU = Groups,DC=contoso, DC=com". Если отличительное имя содержит пробелы, заключите его в кавычки. Например, чтобы создать новую глобальную группу безопасности с именем Маркетинг в подразделении Группы домена contoso.com, введите следующую команду:
    dsadd group "СN=Маркетинг,ОU=Группы, DC=contosо, DC=com" -samid Маркетинг -secgrp yes -scope g
    Параметр DN_группы можно также указать следующим образом:
    1. Поместив в конвейер список DN-имен из другой команды, например Dsquery.
    2. Вводя каждое DN-имя в командную строку с пробелом в качестве разделителя.
    3. Оставив параметр DN пустым и вводя по одному DN-имени в консоль командной строки. После ввода каждого имени нужно нажимать клавишу Enter, а после ввода последнего DN-имени — нажать клавиши Ctrl+Z.
    Команда Dsadd также может конфигурировать атрибуты создаваемых групп с помощью следующих опциональных параметров.
    1. Параметр -samid Имя указывает атрибут sAMAccountName группы. Если он не задан, используется имя группы из DN. Рекомендуется назначать одно имя для sAMAccountName и группы и не использовать этот параметр в команде Dsadd.
    2. Параметр -desc Описание конфигурирует описание группы.
    3. Параметр -members DN_члена добавляет члены в группу. Члены назначаются указанием DN-имен в списке с разделительными пробелами.
    4. Параметр -memberof DN_группы назначает новую группу членом одной или нескольких существующих групп. Группы назначаются путем указания DN-имен в списке с разделительными пробелами.
    Импорт групп с помощью команды CSVDE
    CSVDE импортирует данные из файлов .сsv. Этот инструмент может и экспортировать данные в файл .csv.
    В следующем примере показан файл .csv, который создает группу Маркетинг и включает в нее двух первоначальных пользователей — Линду Митчелл и Скотта Митчелла:
    objectClass, sAMAccountName,DN, member
    group,Маркетинг,"CN=Mapкeтинг,OU=Гpynnы,DC=contoso,DC=com",
    "СN=Линда Митчелл,OU=Kaдры,DC=contoso,DC=com;CN=Cкотт Митчелл, OU=Кадры, DC=contoso, DC=com"
    Объекты, перечисленные в атрибуте member, должны уже существовать в службе каталогов. В столбце member их DN-имена разделены точкой с запятой.
    Этот файл можно импортировать в AD посредством команды:
    csvde -i -f "Имя_файла" [-k]

    Администрирование групп на предприятии


    Рекомендуется следовать соглашению именования, по которому имя идентифицирует тип и назначение группы. В качестве примера можно привести имя группы ACL_Sales Folder_Read из предыдущего подраздела. Отметим, что разделитель не ставят между словами Sales и Folder.
    Для ссылки на эти группы в командной строке такие имена нужно заключать в кавычки.
    Помните, что группы ролей, определяющие роли пользователей, часто будут применяться неопытными в техническом отношении сотрудниками.
    Например, группе продаж можно назначить электронный адрес для распространения электронной почты. Поэтому рекомендуется не использовать в именах групп ролей префиксы и назначать понятные пользователю имена.
    Префикс для указания назначения группы и согласованный разделитель между префиксом и описательной частью имени группы поможет правильно выбрать группу для определенной цели. Например, префикс АРР можно использовать для назначения групп, управляющих приложениями. Благодаря этим префиксам легче понять назначение групп с такими именами, как APP_Accounting и ACL_Accounting_Read, или отыскать эти группы. Первая группа используется для управления развертыванием бухгалтерского программного обеспечения.
    Кроме того, при воссоздании группы новый объект группы получит новый SID-идентификатор, отличающийся от SID-идентификаторов в списках контроля доступа (ACL) к ресурсам. Поэтому пока не истекло время жизни памятника объекта, вместо повторного создания следует восстановить объект, чтобы вернуть удаленную группу. По истечении времени жизни памятника объекта (по умолчанию — 60 дней) группа и ее SID-идентификатор окончательно удаляются из AD. При реанимации объекта памятника нужно воссоздать большую часть его атрибутов, включая атрибут member объектов групп.
    Это означает, что после восстановления удаленного объекта вам потребуется заново указать членство в группе. В качестве варианта можно выполнить принудительное восстановление или использовать в WServer копии состояния AD для восстановления группы и членства в ней.
    Более подробную информацию о восстановлении удаленных групп и членства в них можно найти в статье 840001 в базе знаний по адресу support.microsoft.com/kb/840001/en-us.
    В любом случае мы надеемся, что восстанавливать удаленную группу потребуется только на «пожарных учениях», а не в производственной среде.
    Предупредите неприятные последствия удаления объекта группы, установив защиту для каждой созданной группы. В WServer любой объект можно без труда защитить от удаления, выполнив следующие действия.
    1. Откройте диалоговое окно Свойства (Properties) группы.
    2. На вкладке Объект (Object) установите флажок Защитить объект от
    случайного удаления (Protect Object From Accidental Deletion).
    3. Щелкните ОК.
    В данном случае нужно щелкнуть именно кнопку ОК. Если вы щелкните кнопку Применить (Apply), список ACL не будет модифицирован.
    Опция Защитить объект от случайного удаления (Protect Object From Accidental Deletion) применяет запись управления доступом АСЕ (Access Control Entry) к списку ACL объекта. Это явным образом запрещает группе Все
    (Everyone) Удалить и Удалить поддерево (Delete Subtree). Для того чтобы
    удалить объект, понадобится вернуться к вкладке Объект (Object) и сбросить флажок Защитить объект от случайного удаления.

    Делегирование задач управления членством в группе


    После создания группы задачи управления членством в ней можно делегировать команде или отдельному лицу, которое отвечает за ресурсы, управляемые группой. Предположим, что ваш финансовый директор должен подготовить бюджет на следующий год. Вы создаете для бюджета общую папку и назначаете разрешение записи (Write) группе ACL_Budget_Edit. Если кому-либо требуется доступ к папке бюджета, он обращается в отдел справки с запросом, отдел справки обращается к финансовому директору за подтверждением, после чero добавляет пользователя в группу ACL_Budget_Edit. Чтобы ускорить процесс, вы можете разрешить финансовому директору самому изменять членство в группе. Чтобы делегировать право управления членством в группе, нужно назначить финансовому директору разрешение Разрешить запись члена (Allow Write Member) для группы. Членство в группе предоставляет многозначный атрибут member. Существует несколько способов делегировать право записи члена в группу.
    Проще всего делегировать право управлять членством в группе при помощи вкладки Управляется (Managed By).
    Вторая функция вкладки Управляется (Managed By) — делегирование атрибута member. Обратите внимание на флажок Менеджер может изменять членов группы (Manager Can Update Membership List).
    Если установить этот флажок, пользователь или группа, указанная в поле Имя, получит разрешение WriteMember. Если сменить или удалить менеджера, в список ACL группы будет внесено соответствующее изменение.
    Вставить группу на вкладке Управляется (Managed By) диалогового окна свойств другой группы не так просто. Если щелкнуть кнопку Изменить, откроется диалоговое окно Выбор: "Пользователь", "Контакт" или "Группа " (Select User, Contact, or Group). Если ввести имя группы и щелкнуть ОК, возникнет ошибка. Дело в том, что это диалоговое окно не отконфигурировано для указания групп в качестве действительных типов объектов, хотя слово Группа (Group) есть в названии окна.
    Чтобы обойти это ограничение, щелкните кнопку Типы объектов (Object Types) и установите флажок Groups.
    При указании группы па вкладке Управляется (Managed By) контактные данные не отображаются поскольку группы не поддерживают атрибуты, связанные с контактами.

    Группы по умолчанию


    На сервере WServer автоматически создается множество так называемых локальных групп по умолчанию, включая группы Администраторы, Операторы архива (Backup Operators) и Пользователи удалепного рабочего стола (Remote Desktop Users). В контейнерах Builtin И Users домена создаются дополнительные группы, в том числе Администраторы домена (Domain Admins), Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins). Далее описаны возможности поднабора групп по умолчанию, которым предоставлены разрешения и пользовательские права, связанные с управлением AD.
    Администраторы предприятия (Enterprise Admins) в контейнере Users корневого домена леса. Эта группа — член группы Администраторы в каждом домене леса; она предоставляет полный доступ к конфигурации всех контроллеров домена. Данная группа также является владельцем раздела Конфигурация каталога и имеет полный доступ к содержимому именования домена во всех доменах леса.
    Администраторы схемы (Schema Admins) в контейнере Users корневого домена леса. Эта группа имеет полный доступ к схеме AD.
    Администраторы в контейнере Builtin каждого домена Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы в корневом домене леса может изменять членство в группах Администраторы предприятия, Администраторы схемы и Администраторы домена. Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.
    Администраторы домена в контейнере Users каждого
    домена. Эта группа входит в группу Администраторы своего домена.
    Поэтому она наследует все полномочия группы Администраторы. Кроме того, она по умолчанию входит в локальную группу Администраторы каждого рядового компьютера домена, в результате чего администраторы домена получают в свое распоряжение все компьютеры домена.
    Операторы сервера в контейнере Builtin каждого домена. Эта группа может решать задачи технической поддержки на контроллерах домена. Операторы сервера могут локально входить в систему, запускать и останавливать службы, выполнять резервное копирование и восстановление, форматировать диски, создавать и удалять общие ресурсы, а также завершать работу контроллеров доменов. По умолчанию данная группа не содержит членов.
    Операторы учета (Account Operators) в контейнере Builtin каждого домена. Эта группа может создавать, модифицировать и удалять учетные записи пользователей, групп и компьютеров в любом подразделении домена (кроме подразделения Domain Controllers), а также в контейнерах Users и Computers. Операторы учета не могут модифицировать учетные записи, включенные в группы Администраторы и Администраторы домена, а также не могут модифицировать эти группы. Операторы учета также могут локально входить на контроллеры домена. По умолчанию эта группа не содержит членов.
    Операторы архива в контейнере Builtin каждого домена Эта группа может выполнять операции резервного копирования и восстановления на контроллерах домена, а также локально входить на контроллеры домена и завершать их работу. По умолчанию эта группа не содержит членов.
    Операторы печати в контейнере Builtin каждого домена Эта группа может обеспечивать поддержку очередей заданий печати на контроллерах домена. Она также может локально входить на контроллеры домена и завершать их работу.
    Следует осторожно управлять группами по умолчанию, предоставляющими административные привилегии, поскольку, как правило, они имеют более обширные полномочия, чем требуется для большинства делегированных сред, а также часто применяют защиту для своих членов. Идеальным примером может служить группа Операторы учета (Account Operators). Права этой группы довольно обширны. На маленьких предприятиях такие права вполне могут подходить для одного или двух отдельных лиц, которые в любом случае станут администраторами домена. Однако для большинства предприятий уровень прав и разрешений доступа операторов учета обычно слишком высок.

    Особые объекты идентификации


    В Windows и AD также поддерживаются особые объекты идентификации, членством которых в группах управляет операционная система.
    Эти группы не отображаются в списках оснастки AD — пользователи и компьютеры. Вы не можете просматривать и модифицировать параметры членства этих особых объектов идентификации в группах, а также добавлять эти объекты в другие группы.
    Однако вы можете использовать эти группы для назначения прав и разрешений доступа. Далее описаны самые важные из особых объектов идентификации, которые для удобства часто называются группами.
    АНОНИМНЫЙ ВХОД (Anonymous Logon) Представляет подключения к компьютеру и ресурсы, созданные без предоставления пользовательского имени и пароля. До выхода Microsoft WS2003 эта группа была членом группы Все (Everyone). Начиная с версии WS2003, эта группа по умолчанию больше не входит в группу Все (Everyone).
    Прошедшие проверку (Authenticated Users) Представляет объекты идентификации, прошедшие поверку подлинности. Эта группа не включает учетную запись Гость, даже если назначить гостю пароль.
    Все Включает учетные записи Прошедшие проверку и Гость.
    ИНТЕРАКТИВНЫЕ (Interactive) Представляет пользователей, получающих доступ к ресурсу и локально входящих на компьютер, содержащий ресурс, вместо доступа к ресурсу по сети. Когда пользователь получает доступ к любому ресурсу компьютера, па который вошел локально, такой пользователь автоматически добавляется в группу ИНТЕРАКТИВНЫЕ в разрешениях доступа к этому ресурсу. Группа ИНТЕРАКТИВНЫЕ также включает пользователей, входящих па компьютер через подключение удаленного рабочего стола.
    СЕТЬ Представляет пользователей, получающих доступ к ресурсу по сети, в отличие от локально входящих па компьютер. Когда пользователь получает доступ к любому ресурсу по сети, такой пользователь автоматически добавляется в группу СЕТЬ в разрешениях доступа к этому ресурсу.
    Эти особые объекты идентификации играют важную роль, поскольку они позволяют предоставлять доступ к ресурсам на основе типа проверки подлинности пли подключения, а не на основе учетной записи пользователя.
    Например, вы можете создать в системе папку, позволяющую просматривать ее содержимое пользователям, локально входящим в систему, но запрещающую тем же пользователям читать содержимое с подключенного сетевого диска. Для этого можно назначить разрешения доступа особому объекту идентификации ИНТЕРАКТИВНЫЕ.

    Компьютеры


    Создание объекта компьютера


    В AD компьютеры представлены в качестве учетных записей и объектов аналогично пользователям. Компьютер располагает именем с прикрепленным знаком доллара (например, DESKTOP101$) и паролем, который устанавливается при присоединении компьютера к домену.
    Найдите подразделение или контейнер (предположим, Users), в котором хотите создать компьютер. Введенные данные автоматически заполнят поле Имя компьютера (пред-Windows 2000). Не меняйте имя в этом поле. Учетная запись, указанная в поле Имя пользователя или группы, сможет присоединить компьютер к домену. По умолчанию указаны Администраторы домена.
    Вы также можете указать пользователя, для которого предназначен компьютер.
    Не устанавливайте флажок Назначить учетной записи статус пред-Windows 2000, если эта учетная запись не предназначена для компьютера Windows NT 4.0.
    Многие свойства объектов компьютеров подлежат конфигурированию. Их можно назначить после создания объекта.
    Поскольку Описание отображается в панели сведений оснастки AD — пользователи и компьютеры, в это поле следует ввести данные, которые необходимо знать о компьютере. Существует несколько свойств для описания компьютера, включая DNS-имя, Типы DC (DC Type), Сайт, Имя операционной системы, Версия и Пакет обновления (Service Pack). Эти свойства будут автоматически заполнены при присоединении компьютера к домену. Именно для учёта этих сведений и нужны объекты компьютеров. Компьютеры в домене, как и пользователи, являются принципалами безопасности. Они имеют учетные записи и пароли, которые система Microsoft Windows автоматически изменяет каждые 30 дней или около того. Проверка их подлинности выполняется с помощью домена. Компьютеры могут принадлежать к группам, получать доступ к ресурсам и конфигурироваться групповой политикой. Как и пользователи, компьютеры иногда теряют свои пароли, и тогда требуется производить сброс пароля, а также имеют учетные записи, которые нужно включать или отключать. К сожалению, большинство предприятий не производят инвестиций в создание и управление компьютерными учетными записями в той же мере, как в учетные записи пользователей.
    Компьютеры имеют атрибут objectdass пользователя. Как и пользователи, компьютеры имеют учетные записи. Поскольку компьютеры — это принципалы безопасности и могут подпадать под действие групповой политики, учетные записи компьютеров следует интерпретировать аналогично учетным записям пользователей.
    Удаление компьютера из домена, а затем заново присоединение его к домену - такая методика аналогична удалению и воссозданию учетных записей пользователей, поэтому применять ее не рекомендуется.
    В этой главе мы обсудим рекомендуемые методы поддержки учетных записей компьютеров в домене на уровне поддержки остальных принципалов безопасности (включая пользователей и группы).
    Учетные записи компьютеров нужно создать до присоединения машин к домену. В конфигурации WServer по умолчанию, как и в Microsoft WS2003, Windows Vista, Windows XP и Windows 2000, компьютер принадлежит к рабочей группе. Перед входом на компьютер с помощью доменной учетной записи нужно присоединить компьютер к домену. Для присоединения к домену компьютер должен располагать учетной записью в домене, которая, аналогично пользовательской учетной записи, содержит имя входа (атрибут sAMAccountName), пароль и идентификатор безопасности (SID), который уникальным образом представляет компьютер в домене как принципал безопасности. Эти учетные данные позволяют компьютеру проходить проверку подлинности в домене и создать безопасную связь, с помощью которой пользователи затем смогут войти в систему с применением учетных записей домена.

    Рабочие группы, домены и доверие


    В рабочей группе каждая система поддерживает хранилище учетных записей пользователей и групп. Локальное хранилище объектов идентификации на каждом компьютере называется БД диспетчера безопасности учетных записей SAM (Security Accounts Manager). Если пользователь входит на компьютер рабочей группы, система выполняет проверку подлинности этого пользователя в своей локальной базе данных SAM. Если пользователь подключается к еще одной системе, например для получения доступа к файлу, вновь выполняется проверка подлинности пользователя в хранилище объектов идентификации удаленной системы. В отношении безопасности компьютер рабочей группы по всем параметрам — независимая автономная система.
    Компьютер, присоединяемый к домену, делегирует ему задачу проверки подлинности пользователей. Хотя компьютер продолжает поддерживать свою базу данных SAM учетных записей локальных пользователей и групп, учетные записи пользователей, как правило, будут создаваться в центральном каталоге домена. Пользователь, входящий на компьютер посредством доменной учетной записи, теперь проходит проверку подлинности на контроллере домена, а не в базе данных SAM. Доверительные отношения обычно рассматриваются в контексте двух доменов, однако доверие устанавливается также между каждым рядовым компьютером и его доменом; это происходит при присоединении компьютера к домену.
    Для присоединения к домену AD компьютер должен соответствовать трем требованиям:
    1. В службе каталогов должен быть создан объект компьютера.
    2. Вы должны иметь соответствующие разрешения доступа к объекту компьютера, включая право присоединения к домену компьютера с тем же именем, что у объекта в домене.
    3. Чтобы изменить членство компьютера в домене или рабочей группе, нужно быть членом локальной группы Администраторы.
    По-умолчанию существует контейнер Computers (CN=Computers,...). Этот контейнер — не подразделение, а именно объект класса container. Между контейнером и подразделением существует тонкое, но важно отличие. В контейнере нельзя создать подразделение, и к контейнеру нельзя привязать объект групповой политики. Поэтому для управления компьютерами настоятельно рекомендуется создавать настраиваемые подразделения.
    Большинство организаций создают как минимум два подразделения для объектов компьютеров: одно для учетных записей компьютеров-клиентов (настольные системы, ноутбуки и другие пользовательские системы) и одно для серверов. Эти два подразделения дополняют подразделение Domain Controllers, которое создается по умолчанию при установке AD. Компьютеры создаются в каждом из этих подразделений. Между объектами компьютеров в подразделении клиентов и в подразделении серверов или контроллеров домена никакой технической разницы нет — они в любом случае остаются объектами компьютеров.
    Географически распределенные организации с локальными командами поддержки часто разбивают родительское подразделение клиентов на дочерние подразделения для каждого сайта местонахождения. Этот подход позволяет команде поддержки каждого сайта создавать объекты компьютеров в узле для клиентов и с помощью этих объектов присоединять компьютеры к домену.

    Делегирование разрешения создания компьютеров


    По умолчанию группы Администраторы предприятия, Администраторы домена (Domain Admins), Администраторы и Операторы учета (Account Operators) получают разрешение создавать объекты компьютеров в любом новом подразделении. Тем не менее, рекомендуется строго ограничивать членство в первых трех группах и не вводить администраторов в группу Операторы учета.
    Вместо этого делегируйте разрешение создания объектов компьютеров соответствующим администраторам или персоналу технической поддержки.
    Разрешение Создание объектов: Компьютер, назначенное группе подразделения, позволяет членам группы создавать объекты компьютеров в этом подразделении. Например, вы можете разрешить персоналу технической поддержки настольных систем создавать объекты компьютеров в подразделении клиентов, а администраторам файловых серверов разрешить создавать объекты компьютеров в подразделении файловых серверов.

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


    Имена компьютера в полях Имя компьютера и Имя компьютера (пред-Windows 2000) должны быть одинаковыми. Настройка отдельных имен требуется крайне редко.
    ПРИМЕЧАНИЕ Уровень разрешений, предоставляемых при делегировании. Разрешений, даваемых пользователю или группе, выбранной в окне Новый объект — Компьютер, более чем достаточно для присоединения компьютера к домену. Выбранному пользователю или группе также предоставляется право на все модификации объекта компьютера.
    Создание учетной записи компьютера перед присоединением к домену называется её предварительным размещением (prestaging). Преимущество такого приема в том, что учетная запись помещается в соответствующее подразделение, а следовательно, делегируется в соответствии с политикой безопасности, определенной в списке ACL подразделения и подпадающей под действие объекта GPO, привязанного к подразделению еще до присоединения компьютера к домену. Предварительное размещение настоятельно рекомендуется по причинам, указанным в подразделе «Причины предварительного размещения объектов компьютеров».

    Присоединение компьютера к домену


    Теперь локальный администратор компьютера может изменить членство этого компьютера в домене и ввести указанные доменные учетные данные, чтобы успешно завершить процесс.
    • Войдите на компьютер, используя учетные данные, принадлежащие локальной группе Администраторы компьютера. Только локальные администраторы могут менять членство компьютера в домене или рабочей группе.
    • Щелкните правой кнопкой значок Мой компьютер и примените команду Свойства
    • В секции Является членом (Member Of) выберите параметр Домен
    • Укажите полное DNS-имя домена. Это не только требуется для успеха операции, но и поможет избежать вероятной проблемы разрешения имен DNS, которую нужно устранить до присоединения компьютера к домену.
    • Система Windows потребует указать учетные данные пользователя домена.
      Домен определяет, существует ли объект с именем компьютера. Если объект существует и компьютер с таким именем уже присоединен к домену, возникнет ошибка и вы не сможете присоединить компьютер к домену.

    Если объект существует и предварительно размещен (компьютер с таким же именем, не присоединенный к домену), домен подтверждает, что введенная учетная запись имеет разрешение на присоединение компьютера к домену. Если учетная запись компьютера не была предварительно размещена, то если вы располагаете разрешениями на создание нового объекта компьютера в контейнере по умолчанию, будет создан объект с именем компьютера. Этот метод присоединения к домену поддерживается для обратной совместимости, но использовать его не стоит. Рекомендуется предварительно разместить учетную запись.
    Затем компьютер присоединяется к домену путем его отождествления с объектом в AD. Его SID-идентификатор конфигурируется в соответствии с SID учетной записи компьютера в домене, а также назначается исходный пароль. Затем компьютер решает другие задачи, связанные с присоединением к домену. Он добавляет группу Администраторы домена в локальную группу Администраторы, а группу Пользователи домена — в локальную группу Пользователи.

    Инфраструктура групповой политики


    В среде, управляемой четко определенной инфраструктурой групповой политики, непосредственная конфигурация рабочих столов практически не выполняется. Вся конфигурация определяется, внедряется и обновляется с помощью параметров объектов групповой политики GPO (Group Policy Object), которые управляют структурами предприятия, как, например, сайты, домены, а также отдельные подразделения и группы.
    Инфраструктура групповой политики содержит много перемещаемых компонентов, и чтобы обеспечить безопасность, нужно знать принципы их работы.
    Групповая политика основана на отдельных параметрах политики (или просто политиках).
    Некоторые параметры политики влияют на пользователя независимо от компьютера, на котором пользователь входит в сеть, а другие параметры политики влияют на компьютер независимо от пользователя, который входит на этот компьютер. Такие параметры политики, как параметр, запрещающий доступ к средствам редактирования реестра, называются параметрами пользователей. Параметр политики, отключающий учетную запись администратора, а также другие аналогичные параметры, применяемые к компьютеру, называются параметрами конфигурации компьютеров.
    Параметры политики определяются и содержатся в объекте групповой политики (GPO). Объект GPO включает один или множество параметров политики и, следовательно, применяется к одному или множеству конфигураций пользователя или компьютера.
    Объекты GPO можно создавать в AD с помощью консоли Управление групповой политикой (Group Policy Management, GPMC). Они отображаются в контейнере Объекты групповой политики. Редактируемый GPO откроется в окне оснастки Редактор управления групповыми политиками (Group Policy Management Editor, GPME).
    Состояние параметра политики Не задан означает, что объект GPO не модифицирует существующую конфигурацию данного конкретного параметра. Многие параметры политики довольно сложные, а результат их включения или отключения проявляется не сразу. Влияет и взаимодействие с другими параметрами политики. Некоторые параметры политики связывают несколько настроек конфигурации в одну политику и могут требовать дополнительные параметры.
    Начальный объект групповой политики (шаблон) содержит параметры административных шаблонов. На основе начального GPO можно создать новый объект GPO, в который будут предварительно скопированы параметры начального GPO. При создании нового объекта GPO можно выбрать пустой GPO, один из предварительно существующих начальных объектов GPO или настраиваемый начальный объект GPO.
    Для передачи параметров между объектами GPO в различных доменах или лесах вы можете импортировать параметры архивированного объекта GPO.
    По умолчанию разрешение на создание объектов GPO делегируется группам Администраторы домена и Владельцы — создатели групповой политики (Group Policy Creator Owners).
    Объект GPO через Изменить откроется в Редакторе управления групповыми политиками GPME. Для того чтобы открыть объект GPO в этом редакторе, необходимо как минимум разрешение чтения через Делегирование. Редактор отображает домен, в котором определен GPO, и сервер, на котором был открыт GPO и на который будут вноситься изменения. Корневой узел использует формат Имя_GРО [Имя_сервера]. Например если корневым является узел Политика CONTOSO Стандарты [SERVER01.contoso.com]. Таким образом, объект GPO с именем CONTOSO Стандарты открыт на машине SERVER01.contoso.com, то есть этот GPO определен в домене contoso.com.

    Область действия


    Область действия GPO - коллекция пользователей и компьютеров, к которым применяются параметры GPO. Основной метод управления областью действия состоит в связывании GPO. Объекты GPO можно связать с сайтами, доменами и подразделениями в AD. Параметры политики, определенные в GPO, будут влиять на все компьютеры и пользователей внутри узла, домена или подразделения, включая дочерние подразделения. Один объект GPO можно привязать к множеству сайтов, доменов или подразделений.
    Затем область действия GPO можно ограничить дополнительно с помощью фильтров безопасности, указывающих на глобальные группы безопасности, к которым должен применяться или не применяться объект GPO, или фильтров инструментария управления Windows (WMI).
    Ещё методы управления областью действия:
  • опция Принудительный ( Enforce ) объекта GPO;
  • опция Блокировать наследование (Block Inheritance) объекта GPO;
  • фильтрация наследования групп;
  • включение и отключение узла политики;
  • нацеливание настройки;
  • обработка замыкания политики.
    Отдельный пользователь или компьютер может подпадать под область действия множества объектов GPO, привязанных к сайтам, домену или подразделениям. Поэтому нужно оценить Результирующую политику RSoP ( Resultant Set of Policy).
    После создания GPO укажите начальную область действия, привязав его к сайту, домену или подразделению. ПКМ контейнер, содержащий групповые политики - Связать существующий объект GPO (Link An Existing GPO). Чтобы отобразить сайты в консоли управления групповой политикой в узле Сайты, ПКМ контейнер Сайты, выполните команду Показать сайты.
    Кроме того, необходимо разрешение на связывание. В дереве консоли управления групповой политикой (GPMC) выберите контейнер и на панели сведений консоли перейдите на вкладку Делегирование. В раскрывающемся списке Разрешение (Permission) выберите разрешение Связанные объекты GPO (Link GPOs). Отображаемые пользователи и группы обладают этим разрешением для выбранного подразделения.
    Доменные объекты GPO, предназначенные для централизованного управления конфигурацией пользователей и компьютеров в домене, создаются в AD и хранятся иа контроллерах домена. При установке AD DS создаются два объекта GPO по умолчанию.
    1. Default Domain Policy Этот объект GPO привязывается к домену и не располагает группой безопасности или фильтрами WMI. Поэтому он влияет на всех пользователей и компьютеры в домене (включая компьютеры, являющиеся контроллерами домена). Содержит параметры, назначающие политики паролей, блокировки учетных записей и Kerberos. Существующие параметры модифицируются и приводятся в соответствие с политиками блокировки учетных записей и паролей на предприятии, однако несвязанные параметры политики, как правило, не добавляются. Чтобы отконфигурировать и применять на уровне домена другие параметры, следует создавать дополнительные объекты GPO и привязывать их к домену.
  • Default Domain Controllers Policy Данный объект GPO привязан к подразделению Domain Controllers. Поскольку учетные записи контроллеров доменов хранятся только в подразделении Domain Controllers, а учетные записи других компьютеров должны храниться в других подразделениях, этот объект GPO влияет только на контроллеры домена. Объект групповой политики Default Domain Controllers следует модифицировать, чтобы реализовать политики аудита (об этом речь идет в главах 7 и 8) и предоставить необходимые на контроллерах домена пользовательские права.
    Объект GPO, связанный с сайтом, влияет на все компьютеры в этом сайте независимо от домена, к которому принадлежат эти компьютеры (если все компьютеры принадлежат одному лесу AD). Объекты GPO, связанные с сайтами, хранятся на контроллерах в домене, где были созданы.
    Поместите контроллер домена объекта GPO в сайт, с которым связывается политика, или обеспечьте доступ подключения WAN к контроллеру домена, в котором был создан объект GPO.
    Выберите GPO и перейдите на вкладку Область (Scope), чтобы идентифицировать контейнеры, с которыми связан объект GPO.
    После связывания объекта GPO эта связь указывается в консоли GPMC на значке сайта, домена или подразделения. Связь GPO обозначена небольшой стрелкой на значке (рис. 6-7).
    Связь GPO можно удалить с помощью команды Удалить в контекстном меню. Для того чтобы отключить связь GPO, щелкните ее правой кнопкой мыши и сбросьте флажок Связь включена.
    Создадим GPO для узкого круга лиц:
    1. Откройте оснастку AD — пользователи и компьютеры, создайте подразделение первого уровня Кадры с дочерним подразделением Инженеры. Откройте консоль Управление групповой политикой. ПКМ подразделение Инженеры и выполните команду Создать объект GPO в этом домене и связать его.
    Разверните папку Конфигурация пользователя\Политики\Административные шаблоны\Панель управления\Окно свойств экрана (User Configura-
    tion \Policies\Administrative Templates\Control Panel\Display). Дважды щелкните параметр политики Таймаут экранной заставки (Screen Saver Timeout).
    2. Щелкните опцию Отключен. Закройте редактор GPME.
    4. В консоли управления групповой политикой GPMC выберите
    подразделение Инженеры и перейдите на вкладку Наследование групповой
    политики (Group Policy Inheritance).
    5. Объект GPO Параметры политики инженеров должен превалировать над
    объектом групповой политики CONTOSO Стандарты. Отконфнгурированный параметр, явно отключающий экранную заставку, заменит параметр в объекте групповой политики CONTOSO Стандарты.

    Обновление групповой политики


    Параметры политики в узле Конфигурация компьютера применяются фоново при запуске системы. В узле Конфигурация пользователя - фоново во время входа пользователя. Все параметры политики также применяются каждые 90-120 мин. Вручную - gpupdate.exe. С помощью параметров /target:computer и /target:user обновление компьютера можно ограничить соответственно параметрами компьютера и пользователя. В фоновом и ручном обновлении параметры применяются только в том случае, если использовался объект групповой политики (GPO). Переключатель /fоrсе дает указание системе заново применить все параметры во всех объектах GPO.
    Чтобы некоторые параметры политики вступили в силу, переключатели /logoff и /boot команды gpupdate.exe указывают соответственно выход или перезагрузку.
    Загружается только новый или обновленный объект GPO. Для более эффективного обновления политики клиент групповой политики кэширует объект GPO.

    Клиент групповой политики и расширения клиентской стороны


    В начале процесса обновления групповой политики служба, запущенная во всех системах Windows - клиент групповой политики определяет объекты GPO, применяемые к компьютеру или пользователю. Клиент групповой политики анализирует размещение объекта компьютера или пользователя в AD. Она загружает все объекты GPO, которые еще не кэшированы. Затем набор процессов, которые называются расширениями клиентской стороны CSE (Client-Side Extension), интерпретирует параметры в GPO и вносит соответствующие изменения в конфигурацию локального компьютера или текущего вошедшего пользователя. CSE существуют для всех основных категорий параметров политики (например, одно расширение CSE применяет изменения безопасности, другое выполняет сценарии запуска и входа в систему). Каждая версия Windows добавляет расширения CSE для наращивания функциональности групповой политики. Несколько десятков расширений CSE имеются и в WServer. Клиент групповой политики извлекает объекты GPO из домена, включая расширения CSE для локального применения параметров.
    Поведение клиентских расширении CSE можно отконфигурировать с помощью той же групповой политики. Большинство расширений CSE будут применять параметры в объекте GPO только в случае изменения GPO. Большинство политик применяется таким образом, чтобы стандартные пользователи не смогли изменить параметр в своей системе. Однако стандартные пользователи, особенно администраторы в своих системах, могут изменить некоторые параметры. Если пользователи в производственной среде являются администраторами своих компьютеров, CSE можно отконфигурировать для повторного применения параметров политики, даже если объект GPO не был изменен. Таким образом, если административный пользователь меняет конфигурацию в обход политики, конфигурация будет сброшена в соответствующее состояние при следующем обновлении групповой политики. Для этого необходимо отконфигурировать объект GPO, под область действия которого подпадают компьютеры, и определить параметры в узле Конфигурация компьютера\Политики\Административные шаблоны\Система\Групповая политика. Для каждого расширения следует открыть соответствующий параметр политики — например, Обработка политики реестра (Registry Policy Refreshing) для CSE-расширения Реестр, выбрать опцию Включен и установить флажок Обрабатывать, даже если объекты групповой политики не изменились (Process Even If The Group Policy Objects Have Not Changed).
    Важным исключением параметров обработки политики по умолчанию являются параметры, управляемые CSE-расширением Безопасность. Параметры безопасности применяются каждые 16 ч, даже если объект групповой политики не был изменен.
    Строго рекомендуется включить параметр Всегда ждать сеть при запуске и входе в систему (Always Wait For Network At Startup And Logon) для всех клиентов XP и Vista. Без этого параметра по умолчанию клиенты XP и Vista выполняют только фоновые обновления, то есть клиент может загрузиться и пользователь может войти в домен, не получив из него последние политики. Этот параметр находится в узле Конфигурация компьютера\ Политики\Административные шаблоны\Система\Вход в систему (Logon). Обязательно прочитайте описание этого параметра политики.

    Медленные подключения и отключенные системы


    Представим, что пользователь подключился к сети через медленное соединение; передача больших программных пакетов в таком случае может снизить общую производительность.
    Клиент групповой политики решает эту проблему, идентифицируя скорость подключения к домену и определяя, следует ли интерпретировать это подключение как медленное. Затем это определение используется каждым CSE, когда принимается решение о применении параметров. Например, CSE-расширение Установка программ отконфигурировано для обработки политики отказа, чтобы программное обеспечение не устанавливалось в случае медленного подключения (по умолчанию подключение считается медленным, если его скорость составляет менее 500 кбит/с).
    Если пользователь отключился от сети, параметры, ранее примененные групповой политикой, будут действовать и далее, так что в этом отношении для пользователя нет разницы, в сети он или вне нее. Существуют исключения из этого правила — в частности, сценарии запуска, входа, выхода и завершения работы не будут запускаться в случае отключения пользователя.
    Если удаленный пользователь подключается к сети в системе Windows Vista или WServer, клиент групповой политики ожидает и определяет, было ли пропущено обновление групповой политики. Если это так, пропущенное обновление групповой политики выполняется для получения последних объектов GPO из домена. На основе своих параметров обработки политики клиентские расширения CSE определяют применение параметров в этих объектах GPO.

    Объекты локальной групповой политики


    В локальной системе каждого компьютера хранится несколько локальных объектов GPO. Кроме того, компьютер может подпадать под область действия любого количества объектов GPO домена. В домене AD параметры объектов GPO, привязанные к сайту, домену или подразделениям, заменяют параметры локального объекта GPO.
    Для того чтобы создать и отредактировать локальный объект GPO, введите mmс.ехе, добавьте оснастку Редактор объектов групповой политики. Откроется диалоговое окно, в котором по умолчанию выбран GPO Локальный компьютер. Чтобы отредактировать еще один локальный объект GPO, щелкните кнопку Обзор. На вкладке Пользователи расположены объекты GPO Администраторы и Не администраторы (Non-Administrators), а также по одному GPO для каждого локального пользователя (на контроллере домёна можно выбрать только компьютер).
    Каждый компьютер Windows 2000, XP и Server 2003 содержит по одному локальному объекту GPO, который управляет конфигурацией системы. Он хранится в папке %SystemRoot%\System32\GroupPolicy. Политики в локальном объекте GPO влияют только на компьютер, где хранится GPO. По умолчанию в локальном объекте GPO системы отконфигурированы только политики Параметры безопасности. Все остальные политики Не заданы.
    Системы WClient и WServer содержат множество локальных объектов GPO. Объект GPO Локальный компьютер не отличается от объекта GPO в предыдущих версиях Windows. В узле Конфигурация компьютера отконфигурируйте все параметры, в узле Конфигурация пользователя — параметры, которые хотите применить для всех пользователей компьютера.
    Параметры пользователей в объекте GPO локального компьютера модифицируются с помощью пользовательских параметров в двух новых локальных объектах GPO: Администраторы и Не администраторы.
    Параметры пользователя и GPO пользователей заменят конфликтующие параметры в объектах GPO для администраторов и не администраторов, которые сами заменяют параметры в GPO локального компьютера. Концепция довольно простая: чем специфичнее локальный объект GPO, тем выше приоритет его параметров.

    Хранилище объектов GPO


    Параметры групповой политики представлены в инструментах пользовательского интерфейса AD как объекты GPO, однако на самом деле объект групповой политики GPO составляют два компонента: Контейнер групповой политики GPC (Group Policy Container) и Шаблон групповой политики GPT (Group Policy Template). GPT представляет собой объект AD, который хранится в контейнере Объекты групповой политики в контексте именования домена каталога. Аналогично всем объектам AD каждый объект GPC содержит атрибут глобального уникального идентификатора (GUID), который уникально идентифицирует объект в AD. Объект GPC определяет основные атрибуты GPO, но не содержит никаких параметров. Параметры находятся в объекте GPT, который представляет собой коллекцию файлов в каталоге SYSVOL каждого контроллера домена в папке %SystemRoot%\SYSVOL\Domain\Policies\GUID_объекта_GPO, где GUID-идентификатором объекта GPO является GUID объекта GPC. Изменения объекта GPO сохраняются в объекте GPT сервера, на котором был открыт объект GPO.
    По умолчанию при обновлении групповой политики клиентские расширения CSE применяют параметры GPO только в том случае, если объект GPO был изменен. Исключение составляют параметры безопасности, которые применяются каждые 16 часов независимо от изменения GPO. Клиент групповой политики может идентифицировать обновленный объект GPO по номеру версии. Любой объект GPO имеет номер версии, который увеличивается каждый раз, когда в объект вносятся изменения. Номер версии хранится в атрибуте GPC и текстовом файле GPT.ini в папке GPT. Клиент групповой политики знает номер версии каждого ранее примененного объекта GPO.
    Клиентские расширения CSE выполняют обработку политик в объектах GPO в соответствии с их конфигурацией обработки политики. Некоторые клиентские расширения CSE не применяют параметры политики в случае определения медленного подключения.

    Репликация объектов GPO


    Репликация двух составляющих объекта GPO выполняется между контроллерами домена с помощью отдельных механизмов. Объект GPC в AD реплицируется агентом репликации каталогов DRA (Directory Replication Agent) с использованием топологии, генерируемой механизмом проверки целостности КСС ( Knowledge Consistency Checker). Более подробно эти службы описаны в главе 11. В результате объект GPC реплицируется в течение нескольких секунд на все контроллеры домена в сайте, а потом — между сайтами в соответствии с конфигурацией репликации между узлами, которая также описана в главе 11.
    Объект GPT в папке SYSVOL реплицируется с помощью одной из двух технологий - FRS или DFSR.
    Поскольку объекты GPC и GPT реплицируются по отдельности, в течение небольшого промежутка времени они могут оставаться не синхронизированными. Такая ситуация, как правило, возникает, когда объект GPC реплицируется на контроллер домена первым. Системы, получающие упорядоченный список объектов GPO от контроллера домена, идентифицируют новый объект GPC, пытаются загрузить объект GPT и определяют, что их номера версий отличаются. В журналы событий вносятся данные об ошибке обработки политики.
    Если же объект GPT реплицируется на контроллер домена до объекта GPC, клиенты, получающие упорядоченный список объектов GPO от контроллера домена, не определят новые объекты GPO, пока не будет выполнена репликация GPC.
    В центре загрузки Microsoft доступно средство проверки репликации Gpotool.exe (Group Policy Verification Tool), которое входит в инструментарий Windows Resource Kits . Оно указывает состояние объектов GPO в домене и может идентифицировать на контроллере домена экземпляры GPC и GPT с разными номерами версий. Для того чтобы получить подробную информацию об использовании Gpotool.exe, введите в командной строке команду gpotool /?. Инструмент Gpotool.exe используется для устранения неполадок состояния GPO, включая ошибки репликации GPO, в результате которых нарушается согласованность версий GPC и GPT.

    Параметры политики


    Узел Политики:

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

    Узел Конфигурация Windows


    Расширение Сценарии (Scripts) позволяет указать два типа сценариев: запуск/завершение (в узле конфигурации компьютера) и вход-выход из системы (в узле конфигурации пользователя). Сценарии запуска/завершения запускаются при загрузке и завершении работы компьютера, входа-выхода — при входе и выходе пользователя из системы. Если назначить множество сценариев входа-выхода или запуска/завершения для пользователя или компьютера, CSE-расширение Сценарии будет выполнять эти сценарии в порядке их перечисления в списке. По умолчанию время ожидания обработки сценариев составляет 10 мин. Если для обработки сценариев выхода и завершения требуется больше времени, нужно изменить время ожидания с помощью параметра политики. Для создания сценариев используется любой язык сценариев ActiveX, включая Microsoft Visual Basic, Scripting Edition (VBScript), Microsoft JScript, Perl а также командные файлы .bat и .smd в стиле Microsoft MS DOS.
    Сценарии входа в общесетевом каталоге еще одного леса поддерживаются службами сетевого входа между лесами.
    Узел Параметры безопасности. Настройку безопасности системы можно выполнить после или вместо использования шаблона безопасности.
    Узел QoS на основе политики (Policy-Based QoS). Например, если понадобится, чтобы пользователи в отделе финансов во время создания годового финансового отчета обладали приоритетом запуска важного сетевого приложения, то эти параметры можно определить в узле QoS на основе политики.
    Папка Конфигурация Windows в узле Конфигурация пользователя содержит дополнительные узлы Службы удаленной установки, Перенаправление папки (Folder Redirection) и Настройка Internet Explorer (Internet Explorer Maintenance).
    Политики служб удаленной установки RIS (Remote Installation Services) контролируют удаленную установку операционной системы с помощью служб RIS. Политики перенаправления папки позволяют перенаправлять папки данных и параметров пользователей (например, AppData, Desktop, Documents, Pictures, Music и Favorites) из размещения пользовательского профиля по умолчанию в альтернативное сетевое размещение, где ими можно централизованно управлять.
    Узел Настройка:
    Этот новый узел WServer содержит более 20 клиентских расширений CSE, с помощью которых осуществляется управление огромным количеством дополнительных параметров, включая такие приложения, как Microsoft Office 2003 и Office 2007; сопоставления дисков; параметры реестра; электропитание; свойства папки; региональные параметры; главное меню и т.д.
    С помощью узла Настройка можно развернуть такие компоненты:
  • файлы и папки;
  • принтеры;
  • назначенные задания;
  • сетевые подключения.
    Например, в узле Настройка можно запретить подключение к компьютеру жестких дисков USB, включая проигрыватели мультимедиа.
    Клиентские расширения CSE для Windows XP, WS2003 и Windows Vista находятся в центре загрузки Microsoft.
    Интерфейс конфигурации параметров в узле Настройка аналогичен пользовательскому интерфейсу Windows.

    Административные шаблоны


    Административный шаблон — это текстовый файл, указывающий на изменение реестра и генерирующий пользовательский интерфейс для настройки параметра политики административных шаблонов в редакторе GPME. Наличие параметра политики, раскрывающийся список для отключения запуска редактора реестра без предупреждения, а также параметр реестра на основе политики определяются в административном шаблоне.
    Политики в узле Административные шаблоны конфигурации компьютера модифицируют значения реестра в ключе HKEY_LOCAL_MACHINE, а в конфигурации пользователя — в ключе HKEY_CURRENT_USER. Большинство значений реестра, модифицируемых политиками по умолчанию, находятся в одном из следующих четырех зарезервированных деревьев:
    HKLM\Software\Policies;
    HKCU\Software\Policies;
    HKLM\Software\Microsoft\Windows\CurrentVersion\Policies;
    HKCU\Software\Microsoft\Windows\CurrentVersion\Policies.
    Можно добавить новые шаблоны. Некоторые поставщики программного обеспечения предоставляют административные шаблоны в качестве централизованного механизма управления конфигурацией своих приложений. Вы также можете создавать собственные настраиваемые административные шаблоны.
    В Windows Vista и WServer административный шаблон представляет собой пару XNL-файлов: один с расширением .admx, указывающий изменения в реестре, второй с расширением .adml, предоставляющий в редакторе GPME интерфейс с языком пользователя. Изменения параметров, управляемых административными шаблонами, вносятся в один файл ADMX.
    Все администраторы, модифицирующие объект GPO, который использует этот шаблон, получают доступ к одному файлу ADMX и вызывают соответствующий файл ADML, чтобы заполнить пользовательский интерфейс.
    Для того чтобы создать поисковый фильтр, щелкните ПКМ узел Административные шаблоны - Параметры фильтра.
    GPO содержит только данные, необходимые клиентам для обработки групповой политики, а при редактировании GPO редактор GPME извлекает файлы ADMX и ADML на локальной рабочей станции.
    В WServer имеется центральное хранилище — отдельная папка в SYSVOL, которая содержит все необходимые файлы ADMX и ADML. После настройки центрального хранилища редактор GPME распознает его и загружает все административные шаблоны из центрального хранилища.
    Для того чтобы создать центральное хранилище, создайте папку PolicyDefinitions в папке \\FQDN\SYSVOL\FQDN\Policies. Затем скопируйте все файлы из папки %SystemRoot%\PolicyDefinitions системы WServer в новую папку PolicyDefinitions в SYSVOL. Нужно скопировать файлы .admx и файлы .adml в языковой подпапке %SystemRoot%\PolicyDefinitions. Скажем, файлы ADML для русского языка локализованы в папке %SystemRoot%\PolicyDefinitions\ru-RU. Скопируйте их в папку \\FQDN\SYSVOL\FQDN\Policies\ru-RU. Если требуются дополнительные языки, скопируйте папку с файлами ADML в центральное хранилище. Таким образом, папка PolicyDefinitions на контроллере домена должна содержать файлы ADMX. При входе на контроллер домена локально локальным путем к папке PolicyDefinitions будет путь %SystemRoot%\SYSVOL\domain\Policies\PolicyDefinitions.

    Управление областью действия групповой политики

    Наследование и приоритеты объектов GPO


    Если в GPO с более высоким приоритетом параметр политики не задан, будет применен параметр политики (включенный или отключенный) в GPO с более низким приоритетом.
    Приоритет отображается в консоли GPMC в виде номера: чем меньше его значение, тем выше приоритет. Чтобы определить приоритет каждого GPO, выберите домен или подразделение политик, а затем перейдите на вкладку Наследование групповой политики.
    При выборе подразделения в консоли GPMC вкладка Связанные объекты групповой политики отображает порядок ссылок объектов GPO, связанных с конкретным подразделением. С сайтом, доменом или подразделением можно связать множество объектов GPO. В таком сценарии объекты GPO с более высоким порядком ссылок (с меньшим номером) имеют приоритет перед объектами GPO с более низким порядком ссылок.
    Поведение групповой политики по умолчанию заключается в том, что этот GPO связывается контейнером более высокого уровня и наследуется дочерними контейнерами. Политики применяются последовательно (по умолчанию): локальные GPO, затем GPO сайта, домена и подразделения (от подразделения первого уровня до подразделения, в котором расположен объект пользователя или компьютера). GPO, примененные позже, заменяют параметры, примененные ранее, и поэтому имеют более высокий приоритет.
    По умолчанию унаследованные объекты GPO обладают более низким приоритетом, чем объекты GPO, непосредственно связанные с контейнером.
    Связанные с доменом политики не наследуются дочерним доменом.
    Для того чтобы запретить наследование параметров политики, в редакторе GPME щелкните домен правой кнопкой мыши и выполните команду Блокировать наследование (Block Inheritance). Эта опция является свойством домена или подразделения и блокирует все параметры групповой политики из объектов GPO, связанных с родителями в иерархии групповой политики.
    Блокирование рекомендуется использовать лишь изредка, поскольку оно усложняет оценку приоритетов и наследования групповой политики. В разделе «Модификация области GPO с помощью фильтров безопасности» описано, как определить область действия GPO, чтобы она охватывала только поднабор объектов или не применялась к нему. Кроме того, можно четко определить область действия GPO, чтобы объект применялся только к конкретным пользователям и компьютерам без необходимости в блокировании наследования.

    Принудительное включение связи GPO


    Если включить принудительную связь GPO, объект получит наивысший приоритет. Кроме того, принудительно включенная связь будет применена ко всем дочерним контейнерам, даже если для них задано блокирование наследования. ПКМ связь GPO и в контекстном меню выберите команду Принудительный. Эта связь GPO помечена значком в виде висячего замка.
    Чтобы оценить приоритет GPO, выберите подразделение (или домен) и перейдите на вкладку Наследование групповой политики, где отображается результирующий приоритет объектов GPO, связи GPO, порядок ссылок, блокирование наследования и принудительное включение связей. Здесь не перечислены политики, связанные с сайтом, и не указана фильтрация безопасности и WMI объекта GPO.
    Отметим, что принудительно связанные объекты GPO добавляются в список в обратном порядке: подразделение, домен, а затем сайт. Это следует учитывать при применении корпоративных политик безопасности в объекте GPO, который принудительно связан с доменом. Этот объект GPO указывается в конце упорядоченного списка и применяется последним, в результате чего его параметры получают приоритет.

    Модификация области действия GPO с помощью фильтров безопасности


    Хотя объект GPO нельзя непосредственно связать с группой пользователей или компьютеров, существует метод применения GPO к конкретным группам. Каждый объект GPO располагает списком контроля доступа ACL, который определяет разрешения доступа к GPO. Для применения GPO к пользователю или компьютеру требуются два разрешения: чтение и применение групповой политики.
    По умолчанию группа Прошедшие проверку (Authenticated Users) обладает правом применения групповой политики в каждом новом GPO. Это означает, что по умолчанию все пользователи и компьютеры подпадают под область действия набора объектов GPO своего домена, сайта или подразделения независимо от других групп, членами которых они могут быть.
    Например, со временем вы обнаруживаете, что небольшое число пользователей нужно освободить от политики таймаута экранной заставки, конфигурируемой объектом CONTOSO_Стандарты.
    1. Откройте оснастку AD — пользователи и компьютеры, создайте подразделение Группы, а в этом подразделении — глобальную группу безопасности с именем Исключения_GPO_CONTOSO_Стандарты.
    2. В контейнере Объекты групповой политики выберите объект CONTOSO_Стандарты. Перейдите на вкладку Делегирование (Delegation). Щелкните кнопку Дополнительно. В диалогом окне Параметры безопасности щелкните Добавить. Введите имя группы и щелкните ОК. В списке разрешений найдите разрешение Применить групповую политику и установите флажок Запретить.
    3. Просмотрите запись на вкладке Делегирование в столбце Разрешено группы Исключения_GPO_CONTOSO_Стандарты.
    4. Перейди на вкладку Область (Scope) и проанализируйте секцию Фильтры безопасности (Security Filtering). По умолчанию в фильтрах безопасности нового GPO группа Прошедшие проверку обладает разрешением Apply Group Policy. Вы отконфигурировали группу с запретом чтения групповой политики (Deny Apply Group Policy), который заменяет разрешение. Чтобы освободить пользователя от политики объекта CONTOSO_Стандарты, можно просто добавить его в группу.
    Чтобы применить объект GPO к конкретной группе безопасности, выберите GPO в контейнере Объекты групповой политики консоли управления групповой политикой GPMC. Во вкладке Область секции Фильтры безопасности выберите группу Прошедшие проверку и щелкните кнопку Удалить. Чтобы подтвердить изменение, щелкните ОК, а затем кнопку Добавить. Выберите группу, к которой хотите применить политику, и щелкните ОК. Таким образом, группа Прошедшие проверку не будет указана, зато будет указана конкретная группа, к которой следует применить политику.
    Объекты GPO можно фильтровать только с помощью глобальных групп безопасности. Локальные группы безопасности в домене нельзя применять для фильтрации GPO.
    Когда вы щелкните ОК после установки галочки Запретить в диалоговом окне Параметры безопасности, отобразится предупреждение о том, что заданный элемент запрета имеет более высокий приоритет, чем элементы разрешения (поэтому использовать элементы запрета рекомендуется только по мере крайней необходимости). Таким образом система Microsoft Windows напоминает, что процесс исключения групп с помощью элемента запрета применения групповой политики является более трудоемким, чем включение групп в секцию Фильтры безопасности на вкладке Область.
    К сожалению, исключенные группы не отображаются в секции Фильтры безопасности на вкладке Область. Это еще одна причина, по которой элемент запрета (Deny) рекомендуется использовать как можно реже.

    Фильтры WMI


    Инструментарий управления Windows (Windows Management Instrumentation, WMI) представляет собой технологию инфраструктуры управления, позволяющую администраторам отслеживать и контролировать управляемые объекты в сети. Запрос WMI может фильтровать системы на основе характеристик, включая объем оперативной памяти, частоту процессора, емкость диска, IP-адрес, версию операционной системы, а также уровень пакетов обновлений, установленные приложения и свойства принтеров. Поскольку WMI отображает практически каждое свойство каждого объекта на компьютере, список атрибутов, которые можно использовать в запросе WMI, практически не ограничен.
    Запрос WMI позволяет создать фильтр WMI, с помощью которого можно фильтровать объект GPO. Для развертывания приложения вы можете создать объект GPO, а затем с помощью фильтра WMI указать политику, которая должна применяться только к компьютерам с определенной операционной системой и пакетом обновлений. Далее приведен пример запроса WMI для идентификации таких систем:
    Select * FROM Win32_OperatingSystem WHERE Caption="Microsoft Windows XP Professional" AND CSDVersion="Service Pack 3"
    Когда клиент групповой политики оценивает загруженные объекты GPO, чтобы определить, какие из них нужно обработать с помощью клиентских расширений CSE, он выполняет запрос в локальной системе. Если система соответствует критерию запроса, то результатом будет логическое значение Тruе и расширение CSE выполнит обработку GPO.
    Инструментарий WMI извлекает пространства имен, где есть классы, которые можно запрашивать. Многие полезные классы, включая Win32_OperatingSystem, находятся в классе root\CIMv2.
    Чтобы создать фильтр WMI, в консоли управления групповой политикой GPMC ПКМ узел Фильтры WMI и выполните команду Создать. Введите имя и описание для фильтра, а затем щелкните кнопку Добавить. В поле Пространство имен (Namespace) укажите именное пространство для запроса. В поле Запрос введите запрос и щелкните ОК.
    Чтобы фильтровать GPO с помощью фильтра WMI, откройте вкладку Область (Scope) объекта GPO, щелкните раскрывающийся список фильтров WMI и выберите фильтр WMI. Объект GPO фильтруется лишь с помощью одного фильтра WMI, однако он может содержать комплексный запрос с множественным критерием. Таким образом, с одним или несколькими объектами GPO можно связать один фильтр WMI. Вкладка General фильтра WMI отображает объекты GPO, использующие фильтр WMI.
    Во-первых, нужно хорошо знать синтаксис WQL запросов WMI. С помощью ключевых слов WMI filter и WMI query в Интернете можно найти много примеров с описаниями запросов. Набор средств разработки программного обеспечения SDK для Инструментария управления Windows (WMI) находится по адресу http://msdn2.microsoft.com/en-us/library/aa394582.aspx .
    Во-вторых, при использовании фильтров WMI может снизиться скорость обработки групповой политики. Поскольку клиент групповой политики должен при очередной обработке политики выполнять запрос WMI, каждые 90-120 мин производительность системы снижается. С учетом производительности современных компьютеров это влияние может быть незначительным.
    Если объект GPO фильтруется с помощью фильтра WMI, система Windows 2000 игнорирует фильтр и выполняет обработку GPO, как если бы результатом на запрос фильтра было значение true.

    Включение и отключение объектов и узлов GPO


    Вы можете запретить обработку параметров в узлах Конфигурация компьютера и Конфигурация пользователя во время обновления политики, изменив состояние объекта GPO на вкладке Таблица (Details) объекта GPO.
    Состояние GPO можно конфигурировать для оптимизации обработки политики. Если GPO содержит, к примеру, только параметры конфигурации пользователя.
    Определите в GPO конфигурацию, которая будет применена в чрезвычайных обстоятельствах, при нарушении безопасности или в других аварийных ситуациях, и свяжите этот GPO для применения к соответствующим пользователям и компьютерам. Затем отключите GPO.

    Нацеливание настройки


    Новый узел Настройка в WServer содержит встроенный механизм области действия, который называется нацеливанием на уровень элемента. В один объект GPO можно включить много настроек, и каждую настройку можно нацеливать или фильтровать. Например, вы создаёте один объект GPO с настройкой, указывающей свойства папки для инженеров, и еще одной настройкой, указывающей свойства папки для отдела продаж. Вы можете нацелить эти элементы с помощью группы безопасности или подразделения, а кроме того, использовать более десятка других критериев, включая характеристики оборудования и сети, время и дату, запросы LDAP и многое другое.
    В одном объекте GPO можно нацелить множество настроек, не используя для этого несколько объектов GPO.
    Аналогично фильтрам WMI нацеливание настроек требует, чтобы клиентское расширение CSE выполнило запрос и определило, следует ли применять параметры в настройке. Нацеливание на уровень элемента потенциально влияет на производительность — в частности, при использовании таких опций, как LDAP-запросы, которые отправляют запрос на контроллер домена для обработки и ожидают результат.

    Обработка групповой политики


    Далее описана последовательность применения параметров объектов GPO в домене к компьютеру или пользователю.
    1. Запускается компьютер и запускается сеть. Запускается служба удаленного вызова процедур RPCSS (Remote Procedure Call System Service) и множественный поставщик универсальных имен MUP (Multiple Universal Naming Convention Provider). Запускается клиент групповой политики.
    2. Клиент групповой политики получает упорядоченный список объектов GPO, в область действия которых входит компьютер.
    3. Выполняется синхронная обработка объектов GPO в порядке, указанном в списке.
    4. Если параметр политики отконфигурироваи (включен или отключен) в объекте GPO, связанном с родительским контейнером, и этот же параметр не задан (Not Configured) в объектах GPO, связанных с дочерним контейнером, то в результирующем наборе политик пользователей и компьютеров дочернего контейнера будет включен параметр политики родительского контейнера.
    Если параметр политики не задан ни в родительском контейнере, ни в дочернем, то применяется параметр, полученный в результате обработки локальных объектов GPO. Если в локальных GPO этот параметр также не задан, применяется параметр конфигурации Windows по умолчанию.
    5. Когда пользователь входит в систему, для пользовательских параметров повторно выполняются шаги 2-4. Клиент получает упорядоченный список объектов GPO, в область действия которых попадает пользователь, выполняет синхронный анализ каждого GPO и передает объекты GPO, которые нужно применить, в соответствующие клиентские расширения для обработки. Этот шаг можно модифицировать с помощью опции Режим обработки замыкания политики пользователя (User Loopback Group Policy Processing ).
    ПРИМЕЧАНИЕ Параметры политики конфигурации компьютера и пользователя
    Большинство параметров политики связаны с узлом Конфигурация компьютера и Конфигурация пользователя. Хотя во многих ситуациях параметры в узле конфигурации компьютера заменяют параметры и узле конфигурации пользователя, всегда читайте объяснение параметра политики, чтобы четко понять принцип его использования и результат.
    6. Каждые 90-120 мин после запуска компьютера выполняется обновление политики компьютера, а для параметров компьютера повторяются шаги 2-4.
    7. Каждый 90-120 мни после входа пользователя выполняется обновление политики пользователя, а для параметров пользователя повторяются шаги 2-4.
    ПРИМЕЧАНИЕ Немедленное применение параметров
    Хотя большинство параметров используются во время фонового обновления политики, некоторые клиентские расширения CSE не задействуют параметр до следующегo запуска или входа пользователя. Например, новые добавленные политики сценариев запуска и входа не применяются до следующего запуска компьютера или входа пользователя. Установка программного обеспечения, описанная в главе 7, выполняется при следующем запуске, если установка программ задана в параметрах конфигурации компьютера. Изменения политик перенаправления папки будут применены при следующем входе пользователя.

    Обработка замыкания политики


    Независимо от компьютера, на который входит пользователь, результирующий набор политик, определяющих среду пользователя, остается неизменным. Тем не менее в некоторых ситуациях может потребоваться конфигурировать среду пользователя в зависимости от компьютера, на котором он входит в домен. Например, вы можете блокировать и стандартизировать рабочие столы пользователей, которые входят на компьютеры в плотно управляемых средах, таких как конференц-залы, зоны приема, лаборатории, аудитории и киоски.
    Представим сценарий, в котором нужно отконфигурировать стандартное корпоративное визуальное оформление рабочего стола Windows на всех компьютерах в конференц-залах и других общественных местах офиса. Каким образом централизованно управлять такой конфигурацией с помощью групповой политики? Параметры политики, конфигурирующие оформление рабочего стола, находятся в узле Конфигурация пользователя.
    Обработка политики по умолчанию не позволяет применить параметры пользователей к компьютерам, на которых пользователи входят в сеть. Для этого используется обработка замыкания политики.
    Обработка замыкания политики изменяет алгоритм, по умолчанию используемый клиентом групповой политики для получения упорядоченного списка объектов GPO, которые нужно применить к конфигурации пользователя.
    Вместо использования узла Конфигурация пользователя в объектах GPO, применяемых к пользователю, конфигурацию пользователей можно определять с помощью политик узла Конфигурация пользователя объектов GPO, которые применяются к объекту компьютера.
    Для политики Режим обработки замыкания пользовательской групповой политики (User Group Policy Loopback Processing Mode) в папке Конфигурация компыотера\Политики\Административные шаблоны\Система\Групповая политика GPME можно назначить опции Не задан (Not Configured), Включен (Enabled) и Отключен (Disabled). Включив эту политику, вы можете задать для нее режим Замена (Replace) или Слияние (Merge).
    1. Замена При использовании этого режима список объектов GPO для пользователя (полученный в результате выполнения шага 5, указанного в подразделе «Обработка групповой политики») полностью заменяется списком GPO, полученным для компьютера во время его запуска (шаг 2).
    К пользователю применяются параметры политик в узле конфигурации пользователя объекта GPO компьютера. Режим замены удобно использовать в аудиториях, где пользователи должны работать со стандартной конфигурацией (в отличие от пользователей в неуправляемых средах).
    2. Слияние (Merge) При использовании этого режима список объектов GPO, полученный для компьютера во время его запуска, прикрепляется к списку объектов GPO, полученному для пользователя при его входе (шаг 5). Поскольку список GPO, полученный для компьютера, применяется позже, параметры объектов GPO в списке для компьютера имеют приоритет и заменяют параметры GPO пользователя. Этот режим удобно использовать для применения дополнительных параметров к типичной конфигурации пользователя.
    Например, вы можете разрешить пользователю получать свою типичную конфигурацию при входе на компьютер в конференц-зале или области приема, однако при этом заменить обои стандартным изображением и отключить определенные приложения или устройства.

    Параметры групповой политики


    С помощью групповой политики можно управлять конфигурацией различных компонентов и функций Microsoft Windows. Мы расскажем об инструментах, с помощью которых определяются параметры, конфигурируемые на основе ролей сервера (в частности, о Мастере настройки безопасности (Security Configuration Wizard)), а в завершение — о настройке аудита файлов и папок, а также изменений Доменных служб AD (AD Domain Services, AD DS).
    Для выполнения упражнений данной главы требуется создать контроллер домена SERVER01 в домене contoso.com.
    Мои клиенты часто просили провести «санитарную проверку» своих структур AD. При таких проверках выполняется анализ параметров групповой политики с обсуждением ее преимуществ в управлении изменениями и конфигурацией. Удивительно, но через восемь лет после введения групповой политики многие организации до сих пор не используют все ее возможности, в частности в области безопасности. Три занятия из четырех, представленных в этой главе, посвящены взаимодействию между конфигурацией безопасности и групповой политикой. С помощью групповой политики можно эффективно управлять такой конфигурацией, как членство в группе Администраторы и назначение пользовательских прав, режимы запуска и политик аудита. Последние восемь лет меня часто спрашивают о том, как определить изменения, внесенные администраторами в AD.
    Теперь с помощью нового аудита Изменения службы каталогов (Directory Service Changes ) в WServer можно просто проверить журнал безопасности. Даже если вы уже используете политику управления конфигурацией безопасности, этот новый компонент вместе со значительно улучшенным Мастером настройки безопасности (Security Configuration Wizard) выведет возможности управления безопасностью на качественно новый уровень.

    Делегирование и поддержка компьютеров


    Многие предприятия содержат персонал для поддержки конечных пользователей — так называемый отдел справки. Сотрудники этого отдела устраняют неполадки, настраивают конфигурацию, а также выполняют задачи поддержки на клиентских компьютерах, для чего необходимы административные привилегии. Поэтому учетным записям персонала поддержки должен быть назначен уровень привилегий локальной группы Администраторы на клиентских компьютерах. Однако следует учесть, что уровень привилегий группы Администраторы домена (Domain Administrators) назначать не следует, поэтому рекомендуется отконфигурировать клиентские системы, добавив членов команды отдела справки в локальную группу администраторов с помощью политики групп с ограниченным доступом. На этом занятии мы рассмотрим принципы использования политики ограничения групп, с помощью которых можно добавить членов персонала поддержки в локальную группу
    Администраторы. Эта же методика применяется для делегирования команде поддержки административных задач любых компьютеров.

    Политики групп с ограниченным доступом


    GPO\Конфигурация компыотера\Полнтнки\Конфигурация Windows\параметры безопасности. Вы увидите узел Группы с ограниченным доступом (Restricted Groups).
    Параметры политик групп с ограниченным доступом позволяют управлять членством в группах. Используются два типа параметров: Эта группа является членом в и Члены этой группы.
    Если политики групп с ограниченным доступом назначены в нескольких объектах GPO, будет применен каждый параметр политики членства группы (Member Of). Например, если объект GPO, привязанный к подразделению Клиенты, указывает, что группа CONTOSO\Cправкa является членом группы Администраторы, а второй объект GPO, привязанный к дочернему подразделению NYC (в подразделении Клиенты), указывает, что группа СОNТОSО\Поддержка NYC также является членом группы Администраторы, компьютер в подразделении NYC добавит обе группы, Справка и Поддержка NYC, в свою группу Администраторы вместе со всеми существующими членами такой группы, как Администраторы домена (Domain Admins). Этот пример показан на рис. 7-3. Как видите, политики групп с ограниченным доступом, использующие параметр членства группы Member Of, являются накопительными.
    Второй тип параметра членства в группе (Members) указывает полное члена во в данной группе. Например в списке Члены группы (Members) группы Администраторы указана группа CONTOSO\CnpaBKa. Применение этого параметра политики гарантирует, что членом локальной группы Администраторы будет только группа CONTOSO\Cnpaвкa. Все члены, не указанные в политике, будут удалены, включая группу Администраторы домена (Domain Admins). Параметр членства в группе (Members) является авторитарным и определяет окончательный список членов. Если политика групп с ограниченным доступом указана в нескольких объектах GPO, то будет превалировать объект GPO с наивысшим приоритетом. Например, если GPO, связанный с подразделением Клиенты, указывает членство группы CONTOSO\CnpaBкa в группе Админпстраторы, и еще один GPO, связанный с подразделением Поддержка NYC, указывает членство группы CONTOSO\Поддержка NYC в группе Администраторы, то в локальную группу Администраторы компьютеров в подразделении NYC будет включена только группа Поддержка NYC (рис. 7-4).

    Управление параметрами безопасности


    В WServer предусмотрено несколько механизмов, с помощью которых конфигурируются параметры безопасности в одной или нескольких системах. На этом занятии мы обсудим эти механизмы и их взаимодействие.

    Локальная политика безопасности


    Каждый сервер WServer поддерживает набор параметров безопасности, которыми можно управлять с помощью локального объекта GPO. Локальный GPO конфигурируется с помощью оснастки Редактор объектов групповой политики в консоли Локальная политика безопасности.
    Поскольку контроллеры доменов содержат лишь доменные учетные записи и не содержат локальные учетные записи пользователей, вместо политик в контейнере Политики учетных записей (Account Policies) в локальном объекте GPO на контроллерах доменов следует конфигурировать политики учетных записей домена в объекте GPO, привязанном к домену. Объект Default Domain Controllers Policy создастся при повышении ранга сервера до первого контроллера в домене.
    Параметры в локальных политиках Параметры безопасности представляют собой поднабор политик, которые можно конфигурировать с помощью групповой политики домена.

    Шаблоны безопасности


    Вторым механизмом управления конфигурацией безопасности является шаблон безопасности — набор параметров конфигурации, сохраненный как текстовый файл с расширением .inf. Поскольку эти шаблоны представляют собой открытые текстовые файлы, с ними можно работать вручную, как и с любым текстовым файлом, при необходимости вырезая и вставляя секции. Шаблон безопасности содержит поднабор параметров, доступных в объекте GPO домена, которые несколько отличаются от параметров, управляемых локальным объектом GPO.
    Инструменты, используемые для управления шаблонами безопасности, отображают эти параметры в интерфейсе, где конфигурацию безопасности можно сохранить в качестве файлов и развертывать при необходимости. С помощью шаблона безопасности также можно анализировать соответствие текущей конфигурации компьютера требованиям организации.
    Далее описаны типы политики и параметров, которые можно конфигурировать с помощью шаблонов безопасности.
    1. Политики учетных записей. Назначаются ограничения паролей, политики блокировки учетных записей и политики Kerberos.
    2. Локальные политики. Конфигурируются политики аудита, назначения прав пользователей и политики безопасности.
    3. Политики журналов событий (Event Log Policies). Конфигурируется максимальный размер журналов событий и политики создания новых файлов журналов.
    4. Группы с ограниченным доступом (Restricted Groups). Пользователи включаются в конкретные группы.
    5. Системные службы (System Services). Определяются типы запуска и разрешения доступа для системных служб.
    6. Реестр (Registry). Задаются разрешения контроля доступа к конкретным ключам реестра.
    7. Файловая система. Определяются разрешения контроля доступа для файлов и папок NTFS.
    Существует множество способов развертывания шаблонов безопасности с помощью объектов групповой политики AD, оснастки Анализ и настройка безопасности (Security Configuration and Analysis), а также утилиты secedit.exe. При связывании шаблона безопасности с объектом AD параметры в шаблоне включаются в объект GPO, связанный с объектом в AD. Шаблон безопасности также можно применить непосредственно к компьютеру — в этом случае параметры в шаблоне будут включены в локальные политики компьютера.

    Оснастка шаблонов безопасности


    По умолчанию в WServer не включена консоль с этой оснасткой, так что ее нужно создать вручную. Эта оснастка создает в папке Documents папку Security с подпапкой Templates, а папка Documents\Security\Templates становится размещением, где можно хранить один или несколько шаблонов безопасности.
    Чтобы создать новый шаблон безопасности, ПКМ узел, представляющий путь поиска шаблона (например, C:\Users\Documents\Aдминистратop\Security\Templates) и выполните команду Создать шаблон. Вы можете создать шаблон с текущей конфигурацией сервера, как описано в подразделе «Создание шаблона безопасности».
    Параметры конфигурируются в шаблоне точно таким же образом, как и параметры в объекте GPO. Для настройки параметров в шаблоне безопасности используется оснастка Шаблоны безопасности. Она представляет собой лишь редактор и не играет никакой роли при реальном применении этих параметров в системе. Хотя сам по себе шаблон — это текстовый файл, его синтаксис довольно сложный. Использование оснастки гарантирует изменение параметров с применением корректного синтаксиса. Исключением из этого правила является добавление параметров реестра, которые еще не перечислены в секции шаблона Локальные политики\Параметры безопасности. Как только станут известными новые параметры безопасности, конфигурируемые с помощью ключа реестра, их можно добавить в шаблон безопасности. Для этого добавьте их в секцию Значение реестра шаблона.
    Добавление настраиваемых параметров реестра - в статье «How to Add Custom Registry Settings to Security Configuration Editor» no адресу support.microsoft.com описано, как выполнять эту задачу.
    Для сохранения параметров в шаблоне безопасности щелкните шаблон правой кнопкой мыши и выполните команду Сохранить.
    При установке сервера или повышении его ранга до контроллера домена система Windows применяет шаблон безопасности по умолчанию. Этот шаблон находится в папке %SystemRoot%\Security\Templates. На контроллере домена этот шаблон имеет имя DC security.inf. Данный шаблон нельзя модифицировать напрямую, однако его можно скопировать по пути поиска шаблонов и модифицировать копию.
    В предыдущих версиях Windows можно было модифицировать и применять к компьютеру множество шаблонов. Новая конфигурация WServer на основе ролей и улучшенный Диспетчер настройки безопасности (Security Configuration Manager) исключили необходимость в этих шаблонах.

    Развертывание шаблонов безопасности с помощью объектов групповой политики


    Шаблон безопасности можно импортировать в объект групповой политики домена, сайта или подразделения в AD. А чтобы импортировать шаблон безопасности в объект GPO, ПКМ узел Параметры безопасности и выполните команду Импорт политики. Если в диалоговом окне Импорт политики из (Import Policy From) установить флажок Очистить эту базу данных перед импортом ( Clear This Database Before Importing), все параметры безопасности в этом объекте GPO будут удалены перед импортом параметров шаблона, в результате чего параметры безопасности GPO будут точно соответствовать параметрам шаблона. Если не устанавливать этот флажок, параметры политики GPO останутся и будут импортированы параметры шаблона. Все параметры, определенные в GPO и в шаблоне, будут заменены параметрами шаблона.

    Инструмент Анализ и настройка безопасности


    Для интерактивного использования шаблона безопасности к компьютеру применяется оснастка Анализ и настройка безопасности (Security Configuration And Analysis), которая также позволяет анализировать текущую конфигурацию безопасности системы и сравнивать ее с базовыми настройками, сохраненными в шаблоне безопасности. Таким образом вы можете быстро определить изменения параметров безопасности компьютера пользователями и соответствие системы политикам безопасности организации. В WServer оснастка Анализ и настройка безопасности по умолчанию не включена.
    Для того чтобы применить оснастку Анализ и настройка безопасности, вначале нужно создать базу данных, которая будет содержать коллекцию параметров безопасности. Эта база данных является интерфейсом между реальными параметрами безопасности компьютера и параметрами, которые хранятся в шаблонах безопасности. Создайте базу данных (или откройте существующую) (ПКМ узел Анализ и настройка безопасности).
    После этого вы можете импортировать один или несколько шаблонов безопасности. При импорте нескольких шаблонов нужно принять решение относительно очистки базы данных. Если база данных очищена, она будет содержать только параметры нового шаблона, если же нет, дополнительные определяемые параметры будут заменять параметры ранее импортированных шаблонов. В случае если параметры в новом импортированном шаблоне не определены, в базе данных останутся параметры из ранее импортированных шаблонов. Параметры в базе данных можно применять к компьютеру или использовать для анализа соответствия компьютера требованиям безопасности.
    При модификации значения параметра политики в оснастке Анализ и настройка безопасности изменяются только значения в базе данных, а не реальные параметры компьютера. Чтобы изменения вступили в силу на компьютере, нужно применить параметры базы данных к компьютеру с помощью команды Настроить компьютер или экспортировать базу данных в новый шаблон и применить его к компьютеру с помощью объекта GPO или команды Secedit.exe.
    После импорта одного или нескольких шаблонов для создания базы данных параметры последней можно применить к компьютеру. ПКМ Анализ и настройка безопасности и выполните команду Настроить компьютер. Укажите путь к журналу ошибок, которые будут генерироваться во время применения параметров. После применения параметров проанализируйте журнал ошибок и зафиксируйте все неполадки.
    Прежде чем применить параметры базы данных к компьютеру, проанализируйте текущую конфигурацию компьютера, чтобы определить отличия. ПКМ Анализ и настройка безопасности и выполните команду Анализ компьютера. Далее укажите месторасположение файла журнала ошибок, после чего текущие параметры компьютера будут сравниваться с параметрами в базе данных. После окончании анализа консоль генерирует отчет.
    В отличие от отображения параметров политики в Редакторе управления групповой политикой, Редакторе объектов групповой политики, оснастках Локальная политика безопасности и Шаблоны безопасности этот отчет отображает каждый параметр политики, определенный в базе данных, и текущий параметр политики. Два параметра сравниваются, а результат отображается в виде флажка на значке политики.
    • Крестик в красном кружке. Политика определена в базе данных и на компьютере, однако отконфигурированные значения не совпадают.
    • Зеленая галочка в белом кружке. Политика определена в базе данных и на компьютере, отконфигурированные значения совпадают.
    • Знак вопроса в белом кружке Политика не определена в базе данных и поэтому не проанализирована, либо пользователь, запустивший анализ, не имеет прав доступа к политике на компьютере.
    • Восклицательный знак в белом кружке. Политика определена в базе данных, однако не существует на компьютере.
    • Нет флажка. Указывает, что политика не определена в базе данных или на компьютере.

    Дважды щелкните любую политику, чтобы отобразить ее диалоговое окно Свойства и модифицировать ее параметр в базе данных. Вы также можете напрямую модифицировать параметры безопасности компьютера с помощью консоли Локальная политика безопасности, модифицируя соответствующий объект групповой политики или вручную манипулируя разрешениями файловой системы и реестра.
    Новый шаблон безопасности можно создать из базы данных, ПКМ узел Анализ и настройка безопасности и выполнив команду Экспорт шаблона, который будет содержать параметры базы данных, импортированные из одного или нескольких шаблонов безопасности и модифицированные в соответствии с текущими параметрами анализируемого компьютера.

    Утилита Secedit.exe


    Secedit.exe, как правило, выполняет те же функции, что и оснастка Анализ и настройка безопасности. Преимущество Secedit.exe состоит в том, что ее можно выполнить в сценариях и командных файлах, а это позволяет автоматизировать развертывание шаблонов безопасности. Кроме того, с помощью утилиты Secedit.exe к компьютеру можно применить только часть шаблона, чего нельзя сделать с помощью оснастки Анализ и настройка безопасности или GPOs. Утилита Secedit.exe запускается в окне командной строки с одним из 6 основных параметров и с дополнительными параметрами для каждой функции.
    1. Configure. Все параметры базы данных или какая-то их часть применяются к локальному компьютеру. Программу также можно отконфигурировать для импорта шаблона безопасности в указанную базу данных, а потом применить параметры базы данных к компьютеру.
    2. Analyze. Выполняется сравнение текущих параметров безопасности компьютера с параметрами в базе данных. Прежде чем произвести анализ, программу можно отконфигурировать так, чтобы обеспечить импорт шаблона безопасности в базу данных. Сохраненные в базе данных результаты анализа можно просмотреть с помощью оснастки Анализ и настройка безопасности (Security Configuration And Analysis).
    3. Import. Весь шаблон безопасности или его часть импортируется в конкретную базу данных.
    4. Export. Весь шаблон или часть параметров из базы данных экспортируется в новый шаблон безопасности.
    5. Validate Выполняется проверка корректности внутреннего синтаксиса, используемого в шаблоне безопасности.
    6. Generaterollback Создается шаблон безопасности, который используется для восстановления исходной конфигурации системы после применения еще одного шаблона.
    Например, чтобы настроить машину с помощью шаблона BaselineSecurity, используется такая команда:
    secedit /configure /db BaselineSecurity.sdb
    /cfg BaselineSecurity.inf /log BaselineSecurity.log
    А чтобы создать шаблон отката для шаблона BaselineSecurity, применяется команда:
    secedit /generaterollback /cfg BaselineSecurity.inf
    /rbk BaselineSecurityRollback.inf
    /log BaselineSecurityRollback.log

    Мастер настройки безопасности


    Мастер настройки безопасности повышает уровень безопасности сервера, поскольку закрывает порты и отключает службы, ненужные для ролей сервера. Его можно запустить из домашней страницы Диспетчера сервера в секции Сведения системы безопасности или из папки Администрирование.
    Существует также соответствующая утилита командной строки scwcmd.exe. Мастер настройки безопасности — инструмент управления следующего поколения. Он располагает более обширными возможностями, чем оснастка Анализ и настройка безопасности, и основан на ролях в соответствии с конфигурацией Windows Server 2008. Мастер настройки безопасности создает политику безопасности в виде файла .xml, которая конфигурирует службы и сетевую безопасность, включая правила брандмауэра, значения реестра, политику аудита и другие параметры на основе ролей сервера. Эту политику безопасности затем можно модифицировать, применить к еще одному серверу или преобразовать в объект GPO для развертывания во множестве систем.

    Установка ПО


    Для массового развертывания программного обеспечения в организации используются такие средства, как Microsoft System Center Configuration Manager (Configuration Manager). Хотя оно обеспечивает значительные преимущества, включая счетчики использования программного обеспечения и системы инвентаризации, в большинстве случаев программное обеспечение можно развернуть без помощи этих средств, используя лишь узел Установка программ групповой политики. Расширение Установка программ является одним из многих расширений (или компонентов) клиентской стороны CSE.

    Пакеты установщика Windows


    Для установки, поддержки и удаления ПО расширение установки программ групповой политики GPSI (Group Policy Software Installation) использует службу Установщик Windows (Windows Installer), который управляет программным обеспечением с помощью информации, содержащейся в пакете приложения установщика Windows. Этот пакет представляет собой файл с расширением .msi, описывающий установленное состояние приложения и содержащий явные инструкции, связанные с установкой и удалением приложения. Пакеты установщика Windows можно настроить с помощью файлов одного из следующих типов.
    Файлы трансформации (.mst). Настройка установки приложения. Некоторые приложения содержат мастер-программы или шаблоны, посредством которых пользователь выполняет трансформации. Например, для Acrobat Reader компания Adobe предоставляет корпоративное средство развертывания, генерирующее трансформацию. Многие предприятия используют трансформации для настройки лицензионного соглашения с конечным пользователем и отключения определенных возможностей приложения.
    Файлы исправлений (.msp). Используются для обновления существующего файла .msi пакетами обновлений, исправлениями и обновлениями безопасности. Файл .msp содержит инструкции о применении обновленных файлов и ключей реестра в исправлениях программы, пакете обновления или обновлении программы. Например, обновления программ, начиная с Microsoft Office 2003, предоставляются в виде файлов .msp.
    Файлы .mst и .msp нельзя развернуть по отдельности — их нужно применять к существующему пакету установщика Windows Installer.
    Помимо MSI расширение Установка программ может ограниченно использовать низкоуровневые пакеты приложений (файлы .zap), указывающие расположение точки распространения программного обеспечения SDP и команды setup. Более подробные сведения содержатся в статье 231747 базы знаний по адресу http://support.microsoft.com/Pkbich231747 . Большинство организаций не используют файлы .zap, поскольку для установки приложения пользователь должен обладать административными привилегиями. Когда расширение Установка программ устанавливает Приложение с помощью пакета установщика Windows, пользователю не нужны административные привилегии.
    Полный контроль над приложениями расширение Установка программ может обеспечить только в том случае, если приложения развертываются с помощью пакетов Windows Installer. Другие инструменты, включая Configuration Manager, управляют приложениями, использующими иные механизмы развертывания.
    Файл .msi, трансформации и другие файлы, необходимые для установки приложения, хранятся в общей точке распространения программного обеспечения (SDP). SDP (Software Distribution Point) представляет собой общую папку, из которой пользователи и компьютеры могут устанавливать приложения. Создайте общую и отдельную папки для каждого приложения. Затем скопируйте в папки приложений программный пакет, модификации и все остальные необходимые файлы. Задайте соответствующие разрешения Чтение и выполнение для пользователей или компьютеров, предоставляющие минимальный уровень привилегий, необходимый для успешной установки приложения из точки SDP.

    Опции развертывания программного обеспечения


    Необходимое или обязательное ПО назначается пользователям и компьютерам. Опубликованное приложение пользователи могут по желанию установить для выполнения своей работы.
    При назначении приложения пользователю обновляются локальные параметры реестра приложения, включая расширения файловых имен и создание ярлыков в меню Пуск и на рабочем столе. Ярлык для доступа к приложению следует за пользователем независимо от физического компьютера, с помощью которого пользователь входит в домен. Это приложение устанавливается при первой активации приложения пользователем на компьютере.
    При публикации приложения для пользователей приложение не отображается как установленная программа на компьютерах пользователей. Однако приложение доступно в апплете Программы и компоненты (Programs And Features) в системе Vista и WServer. Кроме того, приложение может быть установлено при открытии пользователем файла типа, сопоставленного с этой программой.
    Табл. 7-1. Опции развертывания программного обеспечения
    Опция
    развертывания
    Публикация (только для пользователя)
    Назначение (пользователь)
    Назначение (компьютер)
    После развертывания объекта GPO можно установить программное обеспечение
    При следующем входе пользователя
    При следующем входе пользователя
    При следующем запуске компьютера
    Как правило, пользователь устанавливает приложение
    С помощью апплета Программы и компоненты в системе Vista и WServer
    Посредством ярлыка в меню Пуск или на рабочем столе. Приложение также можно отконфигурировать для автоматической установки при входе пользователя
    Программа устанавливается автоматически при загрузке компьютера
    Будет ли выполняться инсталляция еще не установленной программы, когда пользователь открывает файл, сопоставленный с этой программой?
    Да (если включена автоматическая установка)
    Да
    Не применяется, поскольку приложение уже установлено
    Может ли пользователь с помощью панели управления удалить программу?
    Да
    Да, и программа вновь будет доступна в виде ярлыка в меню Пуск или на рабочем столе, либо устанавливаться при открытии файла с соответствующим расширением
    Нет. Только локальный администратор может удалить программное обеспечение. Пользователь может запускать и восстанавливать приложение
    Поддерживаемые файлы установки
    .msi, .zap
    .msi

    Создание GPO для развертывания программного обеспечения


    ПКМ Конфигурация пользователя\Политики\Конфигурация программ\Установка программ (или в Конфигурация компьютера) - Создать Пакет. Укажите файл .msi приложения. Откроется диалоговое окно Развертывание программ (Deploy Software). Выберите опцию Публичный (Published), Назначенный (Assigned) или Особый (Advanced). С помощью опции развертывания Особый можно указать публикацию или назначение приложения с доступной настройкой дополнительных свойств программного пакета (рекомендуется). Откроется диалоговое окно свойств пакета.
    1. Параметры развертывания (Deployment Options). Параметры в этой области зависят от выбранного типа развертывания. Удалять это приложение, если его использование выходит за рамки, допустимые политикой управления (Uninstall This Application When It Falls Out Of The Scope Of Management). Если установить этот флажок, приложение будет автоматически удалено, когда объект GPO больше не будет применяться к пользователю или компьютеру.
    2. Обновления. На этой вкладке указывается программное обеспечение, обновляемое данным пакетом.
    3. Категории. На этой вкладке можно связать пакет с одной или несколькими категориями, которыми пользуются при публикации приложения для пользователя. Когда пользователь с помощью панели управления устанавливает программу, приложения, опубликованные с помощью расширения Установка программ, будут сгруппированы на основе этих категорий. Чтобы создать категории, доступные для связывания с пакетами, щелкните правой кнопкой мыши узел Установка программ, выполните команду Свойства и перейдите на вкладку Категории.
    4. Модификации. Если у вас есть файл трансформаций (с расширением .mst), который настраивает пакет, щелкните Добавить и свяжите трансформацию с пакетом. Параметры на большинстве вкладок в диалоговом окне Свойства пакета можно изменять в любое время. Однако вкладка Модификации доступна только при создании нового пакета и выборе метода развертывания Особый.

    Управление областью действия объекта GPO развертывания программ


    После создания объекта групповой политики развертывания программ можно задать область действия GPO, чтобы распространить программное обеспечение для соответствующих компьютеров или пользователей. Во многих сценариях управления программами приложения назначаются компьютерам, а не пользователям, поскольку большинство лицензий программного обеспечения позволяют установить приложение на одном компьютере, а если назначить приложение пользователю, то оно будет устанавливаться на каждом компьютере, куда входит пользователь.
    Многие организации предпочитают управлять программным обеспечением путем связывания объекта GPO приложения с доменом и фильтрации GPO с использованием глобальной группы безопасности, содержащей пользователей и компьютеры, для которых нужно развернуть приложение. Например, объект GPO, развертывающий инструмент XML Notepad, связывается с доменом и фильтруется с использованием группы, содержащей разработчиков, которым необходим этот инструмент. Группа получает описательное имя с указанием ее назначения (например, группа APP_XML).
    На сертификационном экзамене 70-640 вы можете получить вопросы относительно сценариев установки программ, в которых на самом деле проверяется ваша способность эффективно определять область действия GPO. Отвечая на вопросы экзамена, старайтесь определить, какие конкретно знания требуются для ответа на вопрос.

    Проверка подлинности

    Проверка подлинности Kerberos в домене AD


    В домене AD для проверки подлинности объектов идентификации используется протокол Kerberos. Когда пользователь или компьютер входит в сеть домена, этот протокол проверяет подлинность указанных реквизитов и выдает пакет данных, который называется билетом на получение разрешения TGT ( Ticket Granting Ticket). Перед подключением пользователя к серверу для запроса документа на контроллер домена пересылается запрос Kerberos вместе с билетом TGT. Контроллер домена выдает пользователю еще один пакет данных, который называется билетом доступа к службе. Этот билет идентифицирует прошедшего проверку подлинности пользователя на сервере. Пользователь предоставляет билет на доступ службе на сервере, который принимает его как подтверждение прохождения проверки подлинности.
    В результате выполнения таких действий протоколу Kerberos требуется лишь один сетевой вход. После начального входа пользователя либо компьютера и получения им билета TGT пользователь проходит проверку подлинности для всего домена и может получать идентификационные билеты на доступ к службам.
    Всеми этими операциями с билетами прозрачно для пользователя управляют клиенты и службы Kerberos, встроенные в систему Windows.
    3. Управление доступом. Списки управления доступом ACL документа отражают политику безопасности, состоящую из разрешений, в которых для отдельных объектов идентификации указаны уровни доступа. В данном примере функции контроля доступа в инфраструктуре IDA выполняет подсистема безопасности на сервере.
    4. Обеспечение данных аудита. Предприятию может потребоваться отслеживать изменения и действия, выполняемые в инфраструктуре IDA, поэтому решение IDA должно обеспечить механизм управления аудитом.
    Службы AD DS представляют не единственный компонент IDA, поддерживаемый в системе WServer. В версии WS 2008 Microsoft объединила множество ранее разделенных компонентов в интегрированную платформу IDA. Сама структура AD теперь включает пять технологий, назначение которых очевидно из их названий (рис. 1-1). Эти технологии полностью реализуют идентификацию и доступ IDA.
    Размещение контроллера домена в филиале может значительно повысить производительность для пользователей филиала, но такой контроллер физически будет менее защищен, чем в центре данных компании.
    Пароли
    В WServer появились гранулированные политики паролей (Fine-Grained Password Policies, FGPP), с помощью которых можно назначать отличающиеся правила паролей группам пли пользователям в домене.
    В домене WServer пользователям необходимо изменять свои пароли каждые 42 дня. Пароль должен содержать как минимум семь символов, относящихся хотя бы к трем из четырех возможных типам:
    • символы в верхнем регистре: A-Z;
    • символы в нижнем регистре: а-z.;
    • цифры: 0-9;
    • другие символы, например $, #, @.

    На данном занятии мы рассмотрим, как реализовать политики паролей и блокировки на предприятии путем модификации объекта групповой политики Default Domain Controller.
    Чтобы повысить уровень безопасности домена, можно задать более строгие требования к паролям для учетных записей, назначаемых администраторам, записей, используемых такими службами, как Microsoft SQL Server, или для учетных записей, применяемых утилитой резервного копирования.
    Политика паролей домена конфигурируется объектом GPO, в область действия которого попадает домен. В узле Конфигурация компыотера\Политики\Конфигурация Windows\Параметры безопасности\Политики учетных записей\Политика паролей.

    RODC


    Новый тип контроллера домена — контроллер домена только для чтения RODC (Read-Only Domain Controller)
    Причины установки RODC:
    1. В филиалах не обеспечивается достаточный уровень безопасности для серверов и не хватает персонала для их поддержки. Проверка подлинности выполняется при первом входе пользователя на его компьютер утром. Билеты служб являются компонентом механизма проверки подлинности Kerberos, используемого доменами WServer. Билет служб — это аналог ключа, который контроллер домена выдает пользователю. С помощью этого ключа пользователь может подключиться к файловой службе и службе печати на файловом сервере. Когда пользователь в первый раз пытается получить доступ к конкретной службе, клиент пользователя запрашивает билет службы у контроллера домена. Поскольку в течение рабочего дня пользователи, как правило, подключаются к множеству служб, операции с билетами служб производятся регулярно. Операции проверки подлинности и билетов служб выполняются через соединение WAN между филиалом и главным узлом, в результате производительность филиала может значительно снизиться.
    2. В случае взлома или похищения контроллера домена опытный злоумышленник может идентифицировать подлинные пользовательские имена и пароли, что приведет к взлому целого домена. Вам придется, как минимум, сменить пароли учетных записей всех пользователей в домене.
    3. изменения в базе данных Active Directory на контроллере домена в филиале реплицируются на главный узел и все остальные контроллеры домена в среде. Поэтому повреждение контроллера домена в филиале создает угрозу целостности службы каталогов предприятия.
    4. Или, например, контроллеру домена в филиале может потребоваться поддержка нового драйвера устройства. Чтобы обеспечить такую поддержку на стандартном контроллере домена, нужно войти на него как член группы Администраторы. Команде поддержки в филиале не всегда следует назначать такой уровень полномочий.
    Контроллер RODC, размещенный в филиале, поддерживает копию всех объектов в домене и всех атрибутов, кроме таких секретов, как свойства паролей. Когда пользователь в филиале входит в домен, контроллер RODC получает запрос и направляет его на контроллер домена в главном узле для проверки подлинности. Для контроллера RODC можно отконфигурировать политику репликации паролей PRP (Password Replication Policy), которая разрешает кэширование пользовательских учетных записей на контроллере RODC. Если входящий пользователь включен в политику репликации паролей, контроллер RODC кэширует учетные данные этого пользователя, чтобы при следующем запросе проверки подлинности RODC мог решить эту задачу локально. В случае хищения RODC пароли придется изменить только тем пользователям, учетные записи которых кэшировались на данном RODC. Контроллеры домена с правом записи поддерживают список всех кэшированных учетных данных на отдельных контроллерах RODC. При удалении из AD учетной записи похищенного или взломанного контроллера RODC можно изменить пароли учетных записей всех пользователей, которые кэшировались на этом RODC.
    Контроллер RODC реплицирует изменения AD из контроллеров домена в главном узле. Репликация эта односторонняя (с пишущего контроллера домена на контроллер RODC). Изменения на контроллере RODC не реплицируются на остальные контроллеры домена.
    Все инициированные изменения вносятся не в саму реплику RODC, а в обычный КД, и только потом реплицируются назад. В отличие от резервных контроллеров домена (BDC), RODC можно настроить на хранение информации только об определенных объектах. Дело в том, что данные о пользователях и компьютерах на RODC-контроллере не хранятся и по умолчанию не кэшируются. Исключение составляет учетная запись самого компьютера RODC и данные пользователей, входящих в группу Allowed RODC Password Replication Group. Так что, членам групп Администраторы и Операторы сервера в доступе будет отказано.
    И наконец, в отличие от пишущих контроллеров домена, контроллеры RODC содержат локальную группу Администраторы. Персоналу поддержки можно предоставить все возможности технического обслуживания RODC без привилегий администраторов домена.

    Развертывание контроллера RODC


    Для установки RODC выполните следующие операции.
  • RODC необходим функциональный уровень леса не ниже WS2003. Утилита Adprep хранится в папке \Source\Adprep на установочном DVD-диске WServer. Скопируйте указанную папку на контроллер домена, играющий роль мастера схемы. Войдите на мастер схемы как член группы Администраторы предприятия, и введите команду adprep /rodcprep, если в лесу есть контроллеры доменов WS2003, обновляя существующий лес, чтобы включить в него контроллеры домена WServer. Эта команда конфигурирует разрешения, благодаря чему контроллеры RODC могут реплицировать разделы каталога приложений DNS.
    2. Убедитесь, что хотя бы один пишущий контроллер домена работает на функциональном уровне WServer.
    3. Установите RODC с флажками DNS и GC.
    На контроллере RODC можно установить ядро сервера. Следует применять команду Dcpromo.exe /unattend.
    Установку RODC также можно делегировать, чтобы пользователь — не администратор домена мог создать RODC, добавив в филиал новый сервер и запустив команду Dcpromo.exe. Чтобы делегировать установку RODC, предварительно создайте в подразделении Domain Controllers учетную запись компьютера для RODC и укажите учетные данные, которые будут использоваться для добавления RODC в домен. При создании контроллера RODC путем делегирования установки сервер должен быть членом рабочей группы, а не домена.

    Политика репликации паролей


    Политика репликации паролей контроллера RODC определяется двумя многозначными атрибутами учетной записи компьютера RODC: списками Разрешить и Запретить. В список Разрешить можно включать и группы пользователей. Приоритет имеет список запретов.
    Для управления политикой репликации паролей WServer в контейнере Users создаются 2 локальные группы безопасности в домене. Группа с разрешением репликации паролей RODC (Allowed RODC Password Replication Group) добавляется в список Разрешено на каждом новом контроллере RODC. По умолчанию в этой группе нет членов. Если на всех контроллерах RODC нужно кэшировать пользователей, введите этих пользователей в группу с разрешением репликации паролей RODC.
    Группа с запрещением репликации паролей RODC добавляется в список Запрещено на каждом новом контроллере RODC. По умолчанию эта группа включает учетные записи — члены таких групп, как Администраторы домена, Администраторы предприятия и Владельцы-создатели групповой политики (Group Policy Creator Owners).
    Не только пользователи вызывают проверку подлинности и билетов служб. Компьютеры в филиале также выполняют такие операции. Чтобы повысить производительность систем в филиале, разрешите контроллеру RODC филиала кэшировать учетные записи компьютеров.
    Для настройки политики репликации паролей RODC в подразделении Domain Controllers откройте свойства учетной записи компьютера RODC. На вкладке Политика репликации паролей можно просмотреть текущие параметры политики репликации паролей, а также добавить или удалить пользователей и группы. Если щелкнуть кнопку Дополнительно, откроется диалоговое окно Расширенная политика репликации паролей.
    В раскрывающемся списке в верхней части вкладки Использование политики можно выбрать один из двух отчетов для RODC. Например, Учетные записи, пароли которых хранятся в данном контроллере домена только для чтения. Отображает список учетных данных пользователей и компьютеров, которые в настоящее время кэшируются на контроллере RODC.
    На вкладке Результирующая политика (Resultant Policy) можно оценить действующую политику кэширования отдельного пользователя или компьютера. Щелкните кнопку Добавить, чтобы выбрать учетную запись пользователя или компьютера для оценки.
    С помощью диалогового окна Расширенная политика репликации паролей также можно предварительно заполнить учетные данные в кэше RODC. Если пользователь или компьютер есть в списке разрешения RODC, его учетные данные могут кэшироваться на RODC, но они не будут кэшироваться, пока в результате события проверки подлинности или билета службы контроллер RODC не выполнит репликацию этих учетных данных с пишущего контроллера домена. Например, предварительно заполнив учетные данные в кэше RODC для пользователей и компьютеров филиала, вы можете гарантировать локальное выполнение контроллером RODC операций проверки подлинности и билетов служб даже при первой проверке подлинности пользователя или компьютера. Чтобы предварительно заполнить учетные данные, щелкните кнопку Создать предварительные пароли (Prepopulate Passwords) и выберите соответствующих пользователей и компьютеры.

    Разделение административных ролей


    В небольших филиалах контроллер RODC может сочетаться в одной системе с ролью файлового сервера. В таком случае важно иметь возможность архивации системы.
    Контроллеры RODC поддерживают локальное администрирование путем так называемого разделения административных ролей. Каждый контроллер RODC поддерживает локальную базу данных групп, используемую для специфических административных целей. В эти локальные роли можно добавлять учетные записи пользователей домена для включения поддержки конкретного контроллера RODC.
    Разделение административных ролей можно отконфигурировать с помощью команды Dsmgmt.exe. Чтобы добавить пользователя в роль Администраторы контроллера RODC, выполните следующие действия.
    1. На контроллере RODC введите команду dsmgmt и нажмите Enter.
    2. Введите команду local roles и опять нажмите Enter.
    Чтобы получить список команд, в строку локальные роли (local roles) можно ввести знак вопроса ? и нажать клавишу Enter. Вы также можете ввести команду list roles и нажать Enter, чтобы извлечь список локальных ролей.
    3. Введите команду add_ имя пользователя Администраторы, указав имя входа пред-Windows 2000 пользователя домена, и нажмите клавишу Enter.
    Повторяя этот процесс, вы можете добавить других пользователей в различные локальные роли на контроллере RODC.
    Стандартные учетные записи пользователей не позволяют входить на контроллеры домена.

    Интеграция DNS с AD DS


    В сети WServer с AD DS каждое связанное устройство также будет связано с системой разрешения имен DNS.
    При загрузке компьютера, присоединенного к домену, выполняется стандартный процесс, который начинается с идентификации записей ресурсов SRV на DNS-сервере для определения ближайшего контроллера домена.
    Если компьютеру требуется локализовать контроллер в домене lucernepublishing.com, DNS-клиент отправляет запрос SRV следующего имени:
    _ldap._tcp.lucernepublishing.com.
    Затем DNS-сервер пересылает клиенту все записи, соответствующие этому запросу.
    В домене AD развертывание DNS-сервера, как правило, выполняется на контроллере домена. Развертывание DNS-серверов на контроллерах домена дает дополнительные возможности: безопасность, динамические обновления и репликацию AD среди множества DNS-серверов. Самый лучший способ развертывания DNS-сервера на контроллере домена — установка DNS-сервера одновременно с установкой контроллера домена.
    Интегрированная зона AD (AD Integrated zone, ADI) - При интеграции в AD зона DNS помещается в базу данных AD DS (файл с именем NTDS.dit) и реплицируется в каталоге вместе с другими данными.
    DNS-зона леса - Зона, которая содержит записи всего леса в структуре леса AD DS.

    Синдром раздвоения личности


    Одной из основных доктрин коммуникаций Интернета является сегрегация (отделение) внутренней сети от Интернета. Наиболее распространенным механизмом защиты является брандмауэр.
    Аналогичным образом в WServer, в доменных службах AD, нужно работать с двумя пространствами имен. Поскольку каталоги AD DS основаны на системе иерархии имен DNS, для именования лесов каталогов и содержащихся в них доменов нужно использовать правильно сформированное DNS-имя, которое часто называют полным доменным именем FQDN. В Интернете организации довольно часто используют одно имя.
    Например, в качестве потенциальных имен внутренних сетей в этой книге используются такие имена, как contoso.com и woodgrovebank.com. Это не означает, что нужно использовать именно их. Данные имена применяются в книге по причине того, что издательство разрешает использовать эти подлинные имена для представления фиктивных организаций. Однако для внутреннего использования в структуре каталогов AD DS того же имени, что и в Интернете, нужно реализовать разделенную службу DNS.
    Два именных пространства необходимы для выполнения двух задач через брандмауэр. Ваши пользователи должны иметь возможность использовать внутренние и внешние ресурсы с одинаковым именем. Если компания Contoso использует имя contoso.com во внутреннем и внешнем пространствах имен, ее администраторам DNS потребуется управлять разделением вручную, переключаясь между механизмами внутреннего и внешнего разрешения имен.
    Однако если компания Contoso использует имя contoso.com исключительно во внешних целях, а во внутреннем пространстве имен применяет такое же имя с другим расширением, например .net, администраторам DNS не потребуется что-либо делать для сегрегации именных пространств. Сам факт использования различных инструментов означает автоматическую сегрегацию имен и двух DNS-серверов, которые использовались бы для их поддержки. Потребуется лишь передать в Интернет стандартные именные ссылки, которые используются для любого имени, локализованного вне внутренней сети.
    Кроме того, компания Contoso может без труда купить и поддерживать любые возможные комбинации имени в Интернете, в том числе известные корни .com, .net, .info, .ms, .ws и т. д. Таким образом, она может использовать все свои имена для реализации, производства, тестирования и разработки любого леса для любых целей в пределах своих именных пространств, не занимая чужие пространства.
    Проблемы, часто возникающие в этой области, обычно связаны с владением службой DNS. По традиции сетевые операторы располагают ранними службами DNS, которые очень часто поддерживаются в средах, основанных не на Microsoft Windows. Однако Windows, и особенно службы AD DS, очень плотно интегрируются с DNS-службой Windows. Хотя Windows можно применять для работы и с другими серверами (не Windows), поступать таким образом не рекомендуется, поскольку при этом многократно возрастет объем работы.
    При использовании DNS-службы Windows и ее интеграции со службами AD DS среда автоматизируется. Без автоматики все приходится делать вручную, в результате чего конкретные компоненты не работают из-за некорректной или неполной конфигурации, назначаемой администраторами других систем (не Windows).
    В ситуации, когда требуется использовать две технологии DNS, лучше всего применять метод без разделения и задействовать два различных пространства имен, интегрировав внутреннее пространство имен с DNS-серверами Windows на контроллерах домена и просто связав два пространства имен с помощью стандартных механизмов разрешения имен DNS. В результате будет получена реализация с минимальной административной нагрузкой и гарантией постоянной работы всех служб (рис. 9-4).
    Более того, вам не нужно беспокоиться относительно пользователей. Если вы применяете другое внутреннее пространство имен, но хотите разрешить вход с помощью внешнего сетевого имени, такого, например, как contoso.com, достаточно добавить его в каталог в качестве UPN-суффикса (User Principal Name — основное имя пользователя). Системой DNS станет проще управлять, внутренняя сеть будет защищена от внешнего доступа, а пользователи не почувствуют разницы.

    Раздел приложений в WS2003


    Когда наши клиенты создавали леса по рекомендуемым методикам, используя корневой домен леса и один глобальный дочерний домен производства, мы обнаружили, что при создании корневого домена леса данные DNS корректно размещались в разделе приложений корневого домена леса, но при создании дочернего домена эти данные автоматически не сохранялись в каталоге дочернего домена. Это приводило к серьезным проблемам с данными DNS. Все наши клиенты использовали корневой домен леса из двух контроллеров, стараясь обеспечить максимальный уровень безопасности и контроля доступа к администрированию корневого домена леса. По этой причине контроллеры корневого домена леса всегда размещались в центральных узлах предприятия. Дочерний производственный домен широко распространялся и включал контроллеры в каждом удаленном узле с определенным числом пользователей.
    Поскольку данные DNS для дочернего домена реально вносились в раздел корневого домена леса, а не в дочерний раздел, для коммуникаций с контроллерами корневого домена леса каждому клиенту приходилось выполнять поиск DNS через соединения WAN. Однако если данные DNS хранились в каталоге и были доступны для контроллеров домена, их следовало размещать на локальных, а не на удаленном контроллере домена.
    Мы обнаружили, что после развертывания службы каталогов можем изменить область репликации данных DNS дочернего домена, но такие методы не соответствовали рекомендациям. Это означало, что нам нужно было найти способ хранения данных DNS в корректном размещении во время установки, а не после нее.
    Мы обратились к команде разработчиков Microsoft AD и сообщили, что в поведении DNS есть ошибка. Они согласились, что эту ошибку следует исправлять при установке, а не после нее. Дальнейшие исследования показали, что поскольку пространство имен дочернего домена является расширением пространства имен корневого домена, имя дочернего домена корректно разрешалось при проверках, выполняемых мастером установки AD.
    Это означало, что мастер хранит данные в корневом домене леса. Таким образом, мы не получили достаточно информации.
    В ходе последующих исследований выяснилось, что при создании делегирования DNS вручную перед созданием дочернего домена мастер корректно локализует данные в разделе дочернего домена, то есть делегирование вручную указывало пока еще не существующий сервер, так как дочерний домен еще не создан. Например, если у вас есть корневой домен treyresearch.com и планируется дочерний домен intranet.treyresearch.com, вы укажете делегирование на сервер имя_сервера.intranet.treyresearch.com. Поскольку сервера с таким именем не существует до тех пор, пока не будет создан дочернин домен, делегирование будет содержать ложные данные и должно называться ложным делегированием DNS.
    При запуске мастер находит этот сервер в DNS и пытается использовать его для разрешения DNS-имени дочернего домена. Разрешение не будет выполнено, в результате чего мастер установит DNS во время создания домена и создаст соответствующий раздел данных DNS.
    Мастер установки доменных служб AD теперь корректно создает делегирование для дочерних доменов. Многие типы реализации AD на основе WS2003 после установки не локализовали данные DNS в соответствующем разделе, и только администраторы, знающие о проблеме ложного делегирования, могли решить эту задачу. В WServer эта проблема устранена.

    Компоненты DNS в WServer


    При интеграции DNS в AD DS данные DNS можно хранить в различных местах базы данных каталогов, в том числе в разделе Domain каталога. Эта опция применяется для данных, представляющих сам домен. Например, дочерний домен в лесу обычно располагает данными, которые хранятся в его разделе Domain, чтобы все DNS-серверы в домене могли получать к ним доступ.
    Данные также можно хранить в разделах каталога приложений. В отличие от разделов домена, область репликации разделов каталога приложений является управляемой. Например, DNS-данные леса хранятся в разделе каталога приложений, который распространяется во всем лесу. По умолчанию DNS в WServer создает 2 раздела каталога приложений для управления данными DNS в каждом лесу. Эти разделы получают имена соответственно ForestDnsZones и DomainDnsZones. Кроме того, раздел DomainDnsZones создается в каждом дочернем домене леса для управления данными этого домена.
    С целью поддержки новой роли контроллера домена только для чтения DNS-сервер контроллера RODC предоставляет DNS-данные основных зон лишь с правом чтения. По традиции зоны только для чтения являются дополнительными зонами.
    И наконец, для защиты от подделки записей DNS теперь поддерживает добавление списков глобальной блокировки запросов. Когда клиенты используют такие протоколы, как WPAD (Web Proxy Automatic Discovery Protocol) или ISATAP (Intra-site Automatic Tunnel Addressing Protocol), и разрешают имена узлов с помощью DNS, то они становятся уязвимыми для злоумышленников, применяющих динамическое обновление для регистрации компьютеров, не являющихся официальными узлами.
    Протокол WPAD обычно используется веб-браузерами для автоматического обнаружения параметров сетевого прокси-сервера. Имитация этого адреса может перенаправлять пользователей на вредоносные серверы, представляющие собой официальные прокси-серверы и потенциально взламывающие сеть. Протокол передачи ISATAP обеспечивает совместную работу сетей IPv4 и IPv6, инкапсулируя пакеты IPv6 в формате IPv4 для пересылки через маршрутизаторы. Этот протокол не поддерживает динамическое обнаружение маршрутизаторов, а использует список потенциальных маршрутизаторов для идентификации потенциальных маршрутизаторов ISATAP. В случае взлома данного списка пакеты IPv6 могут маршрутизироваться на вредоносные маршрутизаторы и в свою очередь быть взломанными.
    Такие потенциальные уязвимости можно устранить путем блокирования списков запросов, которые содержат конкретные диапазоны адресов. В списки блокирования адресов включается только левая часть FQDN-имени. Когда DNS-сервер получает запрос с указанием этого имени, возвращается сообщение о том, что такой записи не существует. По умолчанию DNS-сервер генерирует указанный список при установке или обновлении существующей службы DNS.
    Если существует один из двух протоколов, он не будет блокироваться. Если протоколов не существует, они будут блокированы. Кроме того, в этот список можно добавлять свои имена для блокирования имен — в таком случае ими нельзя будет оперировать в сети.

    Интеграция в AD DS


    С учетом особых возможностей Windows всегда развертывайте DNS-сервер Windows одновременно с доменными службами AD DS. Для поддержки разрешения имен AD DS также можно использовать сторонний DNS-сервер, однако для его подготовки потребуется выполнить намного больше работы, чем при использовании сервера, встроенного в Windows. При использовании DNS-сервера Windows вместе с AD DS все содержимое DNS конфигурируется по умолчанию. Таким образом, установка DNS интегрируется мастером установки контроллера домена. При установке DNS вместе с AD DS реализуются несколько задач, которые обычно полностью прозрачны для администратора, запустившего мастер. Эти операции выполняются только во время создания леса, доменного дерева или нового домена в существующем лесу.
    Если службы AD DS развертываются для корневого домена леса, система DNS создает заполнители для зон прямого просмотра FLZ (Forward Lookup Zone), зон обратного поиска RLZ (Reverse Lookup Zone) и серверов условной пересылки CF (Conditional Forwarder). Затем DNS генерирует внутри FLZ 2 новые зоны. Первая из них служит контейнером для всего леса пространства имен, которое создается во время установки AD DS, и обычно получает имя _msdcs.имя_домёна. Кроме того, DNS создает внутри FLZ еще одну зону для самого корневого домена.
    Когда процесс AD DS создает доменное дерево в существующем лесу, перед этим он требует проведения делегирования вручную. Поскольку имя доменного дерева отличается от имени корневого домена (оно должно отличаться, потому что таково определение дерева в лесу), мастер не может самостоятельно создать делегирование. Если два именных пространства DNS отличаются, причем ни одно из них не уполномочено делегировать информацию для другого, возникает необходимость в делегировании вручную. Затем после создания делегирования мастер установки AD DS создает именное пространство DNS и сохраняет его соответственно в разделе каталогов нового доменного дерева.
    Когда процесс AD DS создает дочерний домен в существующем лесу, он автоматически создает делегирование в корневом домене высшего уровня, а затем сохраняет данные DNS дочернего домена в разделе дочернего домена.
    Чтобы удалить домен, нужно вновь запустить Мастер установки доменных служб AD и удалить роль контроллера домена, после чего можно удалить роль AD DS. Однако из-за отсутствия интерфейса доступа к мастеру для его запуска нужно открыть Dcpromo.ехе.
    При удалении роли контроллера домена, который является последним в домене, также удаляются созданные для него данные DNS. Во время удаления роли контроллера домена будет предложено удалить делегирование DNS, как показано на рис. 9-8. Если удаляется домен высшего уровня, такой, например, как корневой домен дерева или леса, установите этот флажок. В противном случае вы получите ошибку, поскольку мастер потребует учетные данные для удаления делегирования. Ввиду отсутствия делегирования корневого уровня (для имен .com, .net, .org и т. д.) вы не можете указать такие данные и делегировать корневой уровень. Однако для дочернего домена вы можете совершенно спокойно удалить делегирование DNS.
    Какой тип делегирования может быть автоматически удален мастером установки доменных служб AD? Мастер установки доменных служб AD поддерживает удаление любого делегирования. Это означает, что он удаляет делегирование дочерних доменов, но не может удалить делегирование высшего уровня, поскольку корневые серверы расположены в Интернете и у вас нет доступа к ним.

    Настройка и использование DNS


    Репликация конфигурируется автоматически с помощью системы репликации AD DS с множеством равноправных участников (Multimaster), и вам даже не нужно добавлять записи, поскольку все компьютерные системы не ниже Windows 2000 могут регистрировать и обновлять свои записи с помощью динамических обновлений DNS в AD DS.
    Конфигурация DNS-сервера по умолчанию не включает зоны обратного просмотра RLZ. Их нужно вручную добавлять. Кроме того его нужно настроить для поддержки очистки записей и автоматического удаления устаревших записей.
    Обязательно нужно создать как минимум две записи: Текст (TXT) и запись Ответственное лицо (Responsible Person) (RP). Эти записи будут использоваться для обновления записи SOA (Start Of Authority).

    Анализ безопасности роли DNS-сервера


    DNS-серверы в Интернете представляют большой интерес для злонамеренных пользователей. Чаще всего на эти серверы осуществляются атаки, провоцирующие отказ в обслуживании DoS, когда служба DNS переполняется огромным количеством запросов, в результате чего не может отвечать на подлинные запросы. Еще один распространенный тип атаки заключается в том, что злоумышленник пытается получить все данные DNS-сервера, чтобы использовать их для идентификации объектов в сети. Эта атака называется получением сетевых следов (footprinting the network). В еще двух типах атак осуществляются попытки модификации данных DNS-сервера и перенаправления пользовательских запросов с подлинного DNS-сервера на еще один DNS-сервер, который контролируется злоумышленниками. Обычно такие атаки предпринимаются путем модификации данных DNS в кэше DNS.
    При использовании неразделенного типа конфигурации DNS и интеграции DNS с AD DS во внутренней сети внутренние DNS-серверы менее уязвимы к атакам, поскольку не используют именное пространство совместно с внешним миром и поэтому защищены от внешнего доступа брандмауэрами, которые не разрешают внешним пользователям получать доступ к внутренним DNS-серверам. Это не означает, что внутренние серверы не нуждаются в защите. Всегда существует угроза того, что несанкционированный пользователь может подключиться к сети через проводное или беспроводное подключение. Поэтому рекомендуется тщательно проверять незнакомцев, прежде чем разрешить им доступ в сеть.
    Когда серверы размещены во внешней сети или в периметре сети, для них нужно обеспечить высокий уровень безопасности. Один из неплохих методов защиты состоит в использовании во внешней сети лишь дополнительного или подчиненного сервера. Затем можно отконфигурировать обновления зон только от известных источников, включенных в DNS.
    Во внутренних сетях свяжите роль DNS-сервера с ролью контроллера домена и отконфигурируйте только поддержку безопасных динамических обновлений. Регулярно проверяйте данные DNS и отслеживайте журналы событий DNS для быстрой идентификации потенциальных неполадок.

    Создание зон обратного просмотра


    В реализации DNS с интеграцией в AD зона обратного просмотра создается для каждой DNS-зоны домена. В лесу из множества доменов нужно создать зону RLZ для зоны корневого домена, всех дочерних доменов и всех доменных деревьев. Зоны обратного просмотра привязаны к конкретному доменному имени.
    Выберите тип Основная зона.
    На странице Имя зоны обратного просмотра (Reverse Lookup Zone Name) выберите IPv4 или Ipv6. Если вы используете IPv4 и IPv6, нужно создать две зоны. Имя зоны генерируется на следующей странице. Вид этой страницы зависит от используемой версии IP. Если вы используете IPv4, введите ID сети для зоны.
    Например, если вы используете в сети локальные адреса узла, можете ввести адресную область fе80::/64. При этом в секции Зоны обратного просмотра страницы автоматически генерируется имя зоны.
    Созданные зоны начинают обеспечивать поддержку управления записями при выполнении следующего динамического обновления в клиентских системах.

    Серверы пересылки и корневые ссылки


    По умолчанию DNS-сервер Windows использует для просмотра корневые ссылки. Это означает, что если пользователям нужно выполнить поиск в Интернете, DNS-серверы будут связываться с серверами имен. В небольших организациях такая модель вполне приемлема, поскольку даже если ваши DNS-серверы открывают себя, непосредственно связываясь с Интернетом,
    подключение инициируют именно ваши серверы. Внешние системы только реагируют на инициируемое подключение, но не могут инициировать его сами.
    Тем не менее в сетях с высоким уровнем безопасности вместо корневых ссылок могут применяться серверы пересылки. Например, в периметре сети можно разместить два независимых DNS-сервера и связать внутренние DNS-серверы с этими серверами через брандмауэры.
    Если серверы пересылки не отвечают, внутренние DNS-серверы будут напрямую связываться с Интернетом.
    Рекомендуется сохранить условную пересылку в AD и определить область репликации для пересылки.
    В предыдущем примере данные реплицируются только в производственный домен, так как их не нужно реплицировать во всем лесу. В других случаях может возникнуть необходимость в репликации этих данных во всем лесу.
    Отметим, что при создании условной пересылки для домена в узле Серверы условной пересылки (Conditional Forwarders) создается новый контейнер.

    DNS и DHCP


    При работе с динамической системой DNS и интеграции службы DNS в хранилище AD DS необходимо менять традиционные методы, используемые администраторами сети для настройки параметров DHCP каждого клиентского устройства с применением динамических адресов IPv4 или IPv6.
    По традиции сетевые администраторы указывают в параметрах DHCP сервера лишь два центральных DNS-сервера. Эти серверы обеспечивают все клиентские устройства адресами DNS, необходимыми для разрешения внешних и внутренних имен FQDN, поскольку в силу централизованной локализации серверов любому клиенту в удаленном узле придется выполнять просмотр DNS через соединение WAN.
    Однако в случае интеграции DNS в хранилище каталогов данные DNS становятся доступными на контроллерах домена, поэтому для предоставления служб проверки подлинности клиентов независимо от их расположения контроллеры домена распределяются в сети. Некоторые организации содержат контроллеры доменов, которые доступны в любой точке, где есть хотя бы 20 клиентов. С возможностями виртуализации серверов Hyper-V и с появлением контроллеров RODC теперь можно создавать сети, где преобладают контроллеры доменов. Это означает, что данные DNS только для чтения будут доступны в каждом удаленном узле пли филиале. Для поиска FQDN-имен клиенты могут использовать серверы в своем локальном узле.

    Репликации зон


    Зоны, интегрированные в AD, можно устанавливать только на контроллерах домена. С помощью хранилища, интегрированного в AD, DNS-клиенты могут отправлять обновления на любой DNS-сервер, интегрированный в AD. Затем эти обновления копируются с помощью репликации на другие DNS-серверы, интегрированные в AD.
    Области репликации зон:
    1. Для всех контроллеров домена в этом домене. Зона сохраняется в разделе домена. Каждый контроллер локального домена получит копию этой зоны независимо от наличия на нем установленного DNS-сервера. Ее следует применять для репликации данных DNS на компьютерах WS2000. Данные зоны, интегрированной в AD, хранятся в разделе домена вместе с остальными данными домена.
    2. На все контроллеры домена, указанные в области данного раздела каталога (То All Domain Controllers Specified In The Scope Of This Directory Partition). Зона сохраняется в созданном пользователем разделе каталога приложения, который указан в раскрывающемся списке. Чтобы контроллер домена попадал в область такого раздела каталога, нужно вручную указать этот контроллер домена в разделе.
    Область репликации созданной зоны можно изменить в любое время. Для этого на вкладке Общие щелкните кнопку Изменить напротив параметра репликации.

    Разделы каталога приложений


    Данные DNS, которые хранятся в базах данных каталогов AD DS, по умолчанию реплицируются вместе с данными каталога, с которыми они связаны. Однако для данных DNS можно определить настраиваемую область репликации. Например, данные DNS, принадлежащие корневому домену леса, должны быть доступны для всего леса. Управление областью репликации данных осуществляется с помощью разделов каталога приложений. Раздел каталога приложений — это структура данных в AD, которая контролирует область репликации содержащихся в них данных.
    По умолчанию контроллеры домена включают 2 раздела каталога приложений, зарезервированные для данных DNS: репликация раздела DomainDnsZones выполняется на всех контроллерах домена, также являющихся DNS-серверами в отдельном домене, а репликация раздела ForestDnsZones выполняется на всех контроллерах домена, также служащих DNS-серверами в каждом домене леса AD. В зоне есть раздел ForestDnsZones. Каждая зона содержит DomainDnsZones, репликация которого выполняется лишь в локальных доменах.
    Каждый из этих разделов каталога приложений получает имя в соответствии с именем FQDN дочернего домена DNS. Например, в домене AD с именем east.nwtraders.msft, корневым доменом которого в лесу AD является домен nwtraders.msft, встроенные разделы каталога приложений DNS получают FQDN-имена DomainDnsZones.east.nwtraders.msft и ForestDnsZones.nwtraders.msft.
    Итак, сервер DNS, при его установке вместе с AD DS, создает в лесу два раздела каталога приложений: один для данных леса и один в каждом домене для данных домена, однако в определенных обстоятельствах эти две области могут не соответствовать ситуации, особенно в комплексных лесах.
    Рассмотрим следующий сценарий. Ваш лес содержит три домена: корневой домен леса, глобальный дочерний производственный домен и домен для разработок. Вы создали домен для разработок, поскольку вашим разработчикам нужны особые права доступа и вы не хотите предоставлять им такие права в производственном домене. Все пользователи производственного домена, за исключением системных администраторов, обладают стандартным уровнем прав доступа. В домене для разработок вы можете предоставить разработчикам более высокий уровень прав доступа (создание, модификация и удаление объектов), поскольку этот домен никак не влияет на производственные операции.
    Вы создали по одной учетной записи для каждого разработчика. Эта учетная запись локализована в глобальном дочернем производственном домене и обладает стандартным уровнем прав доступа, однако путем наследования транзитивного доверия в каждом лесу разработчики могут использовать свои учетные записи из производственного домена для получения доступа к объектам в домене для разработок, где их учетные записи из производственного домена обладают более высоким уровнем прав доступа.
    По умолчанию разрешение имен между двумя дочерними доменами выполняется через корневой домен леса. Разработчики ежедневно получают доступ к этому домену, поэтому с целью ускорения разрешения имен вы создали настраиваемый раздел каталога приложений для совместного использования записей DNS производственным доменом и доменом разработчиков. Это означает, что, поскольку эти данные доступны в разделе, производственным DNS-серверам не потребуется разрешать имена домена разработчиков через корневой домен леса.

    Настраиваемые разделы


    Можно также создать настраиваемый или определяемый пользователем раздел. Затем можно отконфигурировать зону для хранения данных в этой новой структуре. По умолчанию новый раздел каталога приложений существует только на сервере, где создается, однако в этом разделе можно перечислить и другие серверы, чтобы туда копировались данные репликации его содержимого.
    Настраиваемые разделы каталога приложений создаются только в командной строке с помощью команды Dnscmd.exe. Однако GUI можно использовать для назначения уже созданных разделов. При желании все операции можно производить в командной строке. Чтобы иметь возможность создавать разделы каталога приложений, нужно быть членом группы Администраторы предприятия (Enterprise Admins), поскольку требуется полный доступ к лесу.
    Необходимо выполнить три задачи: создать раздел, включить в него DNS-серверы и назначить новому разделу зоны, область репликации которых нужно изменить. Введите следующую команду:
    dnscmd имя_dns_сервера /createdirectorypartition fqdn_имя_paздeлa
    В качестве имени_DNS_сервера введите FQDN-имя DNS-сервера или его IP-адрес. Если команда выполняется на том же сервере, где был создан раздел, вместо имени локального сервера можно использовать точку. Например, если вам нужно создать на машине SERVER10 новый раздел с именем partition01.treyresearch.net, введите следующую команду:
    dnscmd server10.treyresearch.net /createdirectorypartition partition01.treyresearch.net
    Включите сервер в этот раздел:
    dnscmd имя_dns_cepвepa /enlistdirectorypartition fqdn_имя_paздeлa
    Эту команду нужно выполнить на каждом DNS-сервере, который включается в раздел. Отметим, что сервер, используемый для создания раздела, включен в этот раздел по умолчанию. В предыдущем сценарии в раздел следует включить все DNS-серверы производственного домена, а также все DNS-серверы домена разработчиков. Например, чтобы включить в новый раздел partition01.treyresearch.net сервер дочернего домена SERVER30 в качестве дополнительного сервера, введите следующую команду:
    dnscmd server30.intranet.treyresearch.net /enlistdirectorypartition partition01.treyresearch.net
    Теперь вы можете изменить область репликации зон, которые хотите сделать доступными для членов нового раздела каталога приложений.
    В Диспетчере сервера вернитесь к узлу DNS-сервер, ПКМ имя зоны, область репликации которой хотите изменить, и примените команду Свойства. На вкладке Общие щелкните кнопку Изменить, чтобы изменить область репликации. В диалоговом окне Изменение области видимости зоны репликации (Change Zone Replication Scope) выберите область Для всех контроллеров домена в области данного раздела каталога (То Аll Domain Controllers In The Scope Of This Directory Partition) и щелкните раскрывающийся список, чтобы выбрать новый раздел.

    Контроллеры домена


    Контроллеры домена - серверы, играющие роль AD DS — в частности, запускающие службу Центр распространения ключей Kerberos (Kerberos Key Distribution Center, KDC), которая проверяет подлинность, а также другие службы AD. Мы рассмотрим компоненты AD уровня служб, начав с самих контроллеров домена.
    Благодаря AD лес и домен можно отконфигурировать с одним контроллером домена. Контроллеры домена обеспечивают функции, критически важные для идентификации и контроля доступа на предприятии. При отказе контроллера домена необходимо обеспечить дальнейшее функционирование службы. Поэтому в домене нужно установить хотя бы 2 контроллера.
    Вам, возможно, потребуется добавить контроллеры доменов в удаленные узлы либо создать новые домены или деревья в лесу AD.
    В документации WServer модели на основе ролей уделяется особое внимание. Поэтому рекомендуется добавить роль AD DS, а затем запустить команду Dcpromo.exe. Тем не менее вы просто можете запустить команду Dcpromo.exe. На первом этапе мастер обнаружит, что двоичные файлы AD DS (общие элементы данных для всех доменов AD) не установлены, и автоматически добавит роль AD DS.

    Подготовка к созданию нового леса системы WServer


    Перед установкой роли AD DS на сервере и повышением его ранга до контроллера домена нужно спланировать структуру AD. При создании контроллера домена потребуется некоторая информация, в частности такая:
    1. Домен должен иметь уникальное DNS-имя, например contoso.com, а также короткое имя, скажем CONTOSO (так называемое имя NetBIOS). Сетевой протокол NetBIOS использовался еще в первых версиях Microsoft Windows NT и все еще применяется некоторыми приложениями.
    2. Структуру DNS лучше всего реализовать для доменных зон с помощью службы DNS системы Windows, однако сторонняя служба DNS также может поддерживать домен Windows.
  • Для контроллеров домена требуются статические IP-адреса и маски подсети. В целях разрешения имен нужно сконфигурировать контроллер домена с использованием адреса DNS-сервера. В случае создания нового леса и запуска на контроллере домена DNS-службы Windows в качестве DNS-адреса можно указать собственный IP-адрес сервера. После установки DNS-структуры сервер сам может разрешать DNS-имена.
    Например Введите такие параметры конфигурации:
    IP-адрес: 10.0.0.11;
    маска подсети: 255.255.255.0;
    основной шлюз (Default Gateway): 10.0.0.11;
    предпочитаемый DNS-сервер (Preferred DNS Server): 10.0.0.11.
    4. Пользовательское имя и пароль учетной записи в группе Администраторы сервера, под которой вы изначально и попадёте в систему. Для учетной записи нужно назначить непустой пароль.
    5. Место установки хранилища данных (включая файл Ntds.dit) и системного тома (SYSVOL). По умолчанию эти хранилища создаются в переменной %SystemRoot% (например, C:\Windows) соответственно в папках NTDS и SYSVOL. При создании контроллера домена эти хранилища можно перенаправить на другие диски.
    Кроме этих существует много дополнительных параметров развертывания AD DS на предприятии. Более подробную информацию об этом можно найти в технической библиотеке системы WServer по адресу techneamkrosoftxom.
    В системе WServer возможна конфигурация на основе ролей с установкой только тех служб и компонент, которые нужны для выполняемых ролей сервера. Управлять сервером па основе ролей можно с помощью новой административной консоли Диспетчер сервера (Server Manager). Диспетчер сервера объединяет информацию, инструменты и ресурсы, необходимые для поддержки ролей сервера.
    После добавления роли AD DS на сервере устанавливаются файлы, необходимые для ее выполнения, но при этом сервер еще не становится контроллером домена. Мастер добавления ролей только инсталлирует файлы, необходимые для настройки и работы доменных служб на сервере, но не производит собственно установку доменных служб AD.
    В разделе Состояние роли (Roles Summary) домашней страницы Диспетчера сервера вы увидите сообщение об ошибке, помеченное красным кружком с белым крестиком. В разделе Доменные службы AD также появится сообщение. Обе ссылки открывают страницу роли доменных служб AD в диспетчере сервера. Сообщение напоминает о том, что надо запустить команду Dcpromo.exe.
    Если запустить команду Dcpromo.exe на сервере без установленной роли AD DS, то запустится Мастер установки доменных служб AD, который сконфигурует, инициализирует и запустит AD.
    Инсталляция версии WServer основана на образе, поэтому она выполняется значительно быстрее, чем для предыдущих версий Windows, хотя сама операционная система занимает больше места, чем более ранние версии. В процессе установки компьютер перезагрузится один или несколько раз.
    Чтобы открыть окно задач начальной настройки, используйте команду Oobe.exe.
    Первый контроллер домена в лесу должен быть сервером глобального каталога GC (Global Catalog) и не может быть контроллером домена только для чтения RODC (Read-Only Domain Controller).
    Появится предупреждение о назначении статического IP-адреса. Поскольку конфигурация IPv6 не описана в данном руководстве, в упражнении 2 для сервера не был назначен статический IРv6-адрес. В упражнении 2 вы назначили статический IPv4-aдpec, который будет использоваться в последующих упражнениях. В контексте текущего упражнения данное предупреждение можно проигнорировать.
    Появится предупреждение о том, что для этого DNS-сервера не будет делегирования. В контексте данного упражнения вы можете проигнорировать эту ошибку.
    В производственной среде файлы AD лучше всего хранить в трех отдельных томах, где нет приложений и других файлов, которые не имеют отношения к AD DS. Благодаря этому повысится производительность, а также эффективность архивации и восстановления.
    Обычный администратор превращается в администратора домёна, а администратор для режима восстановления служб каталогов — это отдельный администратор.

    Server Core


    Это минимальная установка, в которой нет даже графического пользовательского интерфейса Проводника Windows и компонента Microsoft .NET Framework. Инсталляцию ядра сервера можно администрировать удаленно с помощью инструментов GUI (Graphical User Interface), однако для локальной настройки и управления сервером нужно использовать инструменты командной строки.
    Ядро сервера (Server Core) WServer представляет собой минимальную установку системы Windows, которая занимает около 3 Гбайт на жестком диске и требует меньше 256 Мбайт оперативной памяти. Установка ядра сервера ограничивает роли и компоненты, которые можно добавлять, зато повышает уровень безопасности и управляемости сервера, снижая фронт его атаки.
    Кроме того, в ядре сервера ослабевает административная нагрузка, связанная с управлением сервером, поскольку сокращается потребность в обновлениях и технической поддержке.
    Ядро сервера (Server Core) поддерживает девять ролей сервера:
    • Доменные службы AD
    • AD LDS
    • DHCP-сервер
    • DNS-сервер
    • Файловые службы (File Services);
    • Сервер печати (Print Server);
    • Службы потокового мультимедиа (Streaming Media Services);
    • Веб-сервер (IIS) (Web Server (IIS)) — статический веб-сервер без возможности установить ASP.NET;
    • Hyper-V.

    Кроме того, в ядре сервера поддерживаются следующие дополнительные компоненты:
    • Средство отказоустойчивости кластеров (Microsoft Failover Cluster);
    • Балансировка сетевой нагрузки (Network Load Balancing);
    • Подсистема для UNIX-приложений (Subsystem for UNIX-based applications);
    • Архивация Windows (Windows Backup);
    • Многопутевой ввод-вывод (Multipath I/O);
    • Диспетчер съемных носителей (Removable Storage Management);
    • Шифрование диска BitLocker (Windows BitLocker Drive Encryption);
    • Службы SNMP;
    • WINS-сервер (Windows Internet Naming Service (WINS));
    • Клиент Telnet;
    • Качество обслуживания QoS.

    При установке системы WServer с загрузочного DVD начальный пароль учетной записи Администратор является пустым. При первом входе в систему вам будет предложено изменить пароль.
    Чтобы получить больше информации об этих командах, откройте командную строку и введите имя команды с параметром /?.
    Изменение пароля администратора
    При входе в систему с помощью сочетания клавиш Ctrl+Alt+Del будет предложено изменить пароль. Можно также ввести команду
    Net user administrator *
    Задать статическую конфигурацию IPv4
    Netsh interface ipv4
    Активация системы WS
    Cscript c:\windows\system32\slmgr.vbs -ato
    Присоединение к домену
    Netdom
    Добавление ролей, компонентов и средств в установку ядра сервера
    Ocsetup.exe, после чего нужно указать имя пакета либо компонента. Эти имена чувствительны к регистру
    Отображение установленных ролей, компонентов и возможностей
    Oclist.exe
    Включение удаленного рабочего стола
    Cscript c:\windows\system32\scregedit.wsf /AR 0
    Повышение ранга сервера
    до контроллера домена
    Dcpromo.exe
    Настройка DNS
    Dnscmd.exe
    Настройка DPS
    Dfscmd.exe
    Для добавления поддерживаемых ролей и компонентов ядра сервера используется команда Ocsetup.exe. Исключением из этого правила является роль доменных служб AD — для ее добавления и удаления используется команда Dcpromo.exe.

    Добавление роли AD DS ядру сервера


    Поскольку в установке ядра сервера (Server Core) нет компонента Мастер установки доменных служб AD (AD Domain Services Installation Wizard), требуется из командной строки запустить команду Dcpromo.ехе с параметрами настройки роли AD DS.
    Для всех сценариев конфигурации необходима дополнительная информация. Например, для повышения ранга сервера до уровня контроллера домена введите команду dcpromo.exe /?: Promotion .
    Список параметров автоматизированной установки можно найти по адресу technel2.microsoft.com.

    Добавление компьютера к домену


    В командную строку введите команду netsh interface ip set dnsserver "local area connection" static 192.168.0.1. После обновления командной строки введите команду netsh interface ipv6 set dnsseiver "local area connection"static fd00::1. Эти две команды откопфигурируют машину для поиска домена Nwtraders.msft путем запрашивания компьютера контроллера домена.

    Автоматизированная установка и файлы ответов


    Контроллер домена можно также добавить или удалить в окне командной строки с помощью автоматизированной (unattended) установки. Параметры автоматизированной установки содержат значения для мастера установки доменных служб AD. Например, параметр NewDomainDNSName указывает полное доменное имя FQDN для нового домена.
    Эти параметры можно указать в командной строке с помощью команды dcpromo /unattendОрtion:значение, например dcpromo /newdomaindnsname:contoso.соm. В качестве альтернативы параметры также можно указать в файле ответов автоматизированной установки. Файл ответов — это текстовый файл, содержащий секцию с заголовком [DCINSTALL], где в форме параметр=значение указаны параметры и их значения:
    [DCINSTALL]
    NewDomainDNSName=contoso.com
    Файл ответов вызывается добавлением пути к параметру unattend, например:
    dcpromo /unattend:"путь к файлу ответов"
    Например, если в файле ответов указан параметр NewDomainDNSName и в командной строке также используется параметр /NewDomainDNSName, приоритет получит значение в командной строке. Если необходимых значений нет ни в файле ответов, ни в командной строке, мастер установки доменных служб AD предложит указать параметр.
    На машине с установленным ядром сервера при запуске команды Dcpromo.exe мастер недоступен. В таком случае команда Dcpromo.exe вернет код ошибки.
    Чтобы получить полный список параметров, которые можно указать при автоматизированной установке AD DS:
    dcpromo /?[:операция]
    Укажите одну из перечисленных ниже операций.
    Promotion возвращает все параметры, которые можно использовать при создании контроллера домена.
    CreateDCAccount возвращает все параметры, которые можно использовать при создании предварительной учетной записи контроллера домена только для чтения (RODC).
    UseExistingAccount возвращает все параметры, которые можно использовать для прикрепления нового контроллера домена к предварительной учетной записи RODC.
    Demotion возвращает все параметры, которые можно использовать при удалении контроллера домена.
    Полное описание параметров Dcpromo и автоматизированной установки можно найти по адресу go.microsoJt.com/fwlink/7UnkID-101181.
    ПРИМЕЧАНИЕ Создание файла ответов
    При использовании интерфейса Windows для создания контроллера домена мастер установки доменных служб AD на странице Сводка ( Resume ) предоставляет опцию экспорта параметров в файл ответов. Если вам нужно создать файл ответов для использования в командной строке, например на компьютере с установленным ядром сервера (Server Core), эту опцию мастера можно использовать для генерирования файла ответов с корректными параметрами и значениями.

    Установка нового леса WServer


    При создании корневого домена нового леса нужно указать его имя NetBIOS, а также уровни леса и домена. Первый контроллер домена не может быть контроллером домена только для чтения и должен быть сервером глобального каталога. Если мастер установки доменных служб AD определит, что необходимо установить или отконфигурировать DNS, он автоматически выполнит эти операции.
    Файл ответов можно указать с помощью команды dcpromo /unattend: «путь к файлу ответов". Следующий пример файла ответов содержит минимальный набор параметров автоматизированной установки нового контроллера домена WServer в новом лесу:
    [DCINSTALL]
    ReplicaOrNewDomain=domain
    NewDomain=forest
    NewDomainDNSName=fully qualified DNS name
    DomainNetBiosName=domain NetBIOS name
    <
    <
    InstallDNS=yes
    DatabasePath="путь к папке в локальном томе"
    LogPath="путь к папке в локальном томе"
    SYSVOLPath="path to folder on a local volume"
    SafeModeAdminPassword=пароль
    RebootOnCompletion=yes
    Один или несколько параметров и значений автоматизированной установки можно также ввести в командной строке. Например, если вы не хотите указывать пароль режима восстановления служб каталогов (Directory Services Restore Mode) в файле ответов, не вводите значение, а вместо этого при запуске Dcpromo.exe укажите параметр /SafeModeAdminPassword:password.
    В командную строку также можно включить все параметры. В следующем примере первый контроллер создается в новом лесу, где не планируется установка контроллеров домена WS2003:
    dcpromo /unattend /installDNS:yes /dnsOnNetwork:yes
    /replicaOrNewDomain:domain /newDomain:forest
    /newDomainDnsName:contoso.com /DomainNetbiosName:contoso
    /databasePath:"e:\ntds" /logPath:"f:\ntdslogs" /sysvolpath:"g:\sysvol"
    /safeModeAdminPassword:пароль /forestLevel:3 /domainLevel:3
    /rebootOnCompletion:yes

    Установка первого контроллера домена WServer 2008 R2 в существующем лесу или домене WServer 2008


    Подготовка проводится исключительно в случае использования старых контроллеров. Если у тебя WServer 2008 R2, то WServer 2008 считается старым. В этом конкретном случае даётся 2 команды:
    adprep /forestprep
    Adprep /domainprep
    Схема - это определение атрибутов и классов объектов, которые могут существовать в домене. Она аналогична каталогу в том, что ее можно создать в других разделах каталогов.
    Вот как можно подготовить схему леса для WServer 2008:
    1. Войдите на компьютер, служащий мастером схемы, как член групп Администраторы предприятия, Администраторы схемы и Администраторы домена.
    2. Скопируйте содержимое папки \ Sources \Adprep с установочного DVD-диска WServer в папку на мастере схемы.
    3. Откройте окно командной строки и перейдите в папку Adprep
    4. Введите команду adprep /forestprep
  • Если вы планируете установить контроллер RODC в любом домене леса, введите команду adprep /rodcprep.
    В лесу W2000Server или WS2003 также можно использовать команду adprep /rodcprep. Ее не нужно запускать вместе с параметром /forestprep, но перед установкой первого контроллера RODC вы должны запустить ее и разрешить внести изменения в репликацию уровня леса. Adprep /rodcprep можно запустить с любого контроллера домена, если использовать учетные данные члена группы Администраторы предприятия. Adprep /rodcprep необходимо запустить перед установкой RODC в любом домене существующего леса с контроллерами WS2003 и W2000Server. Если лес состоит только из контроллеров доменов WServer, в запуске этой команды нет необходимости.
    Для выполнения операции потребуется некоторое время. После репликации изменений во всем лесу можно продолжать подготовку доменов для WServer. Чтобы подготовить домен Windows 2000 Server или WS2003 для включения WServer 2008, выполните следующие действия.
    1. Войдите на хозяин операций доменной инфраструктуры как член группы Администраторы домена.
    2. Скопируйте содержимое папки \Sources\Adprep с установочного DVD-диска WServer в папку мастера инфраструктуры.
    3. Откройте окно командной строки и перейдите в панку Adprep.
    4. Введите команду adprep /domainprep /gpprep и нажмите клавишу Enter. В WS2003 может появиться сообщение об ошибке, где говорится о необходимости в установке обновлений. Можете проигнорировать это сообщение.
    Перед установкой контроллера домена WServer 2008 разрешите репликацию изменения во всем лесу.
    При добавлении первого контроллера домена WServer 2008 в существующий лес нужно выполнить команду Adprep /forestprep. Перед добавлением первого контроллера домена WServer 2008 в существующий домен следует запустить команду Adprep /domainprep /gpprep.
    Перед установкой первого контроллера RODC в домене с контроллерами Windows 2000 Server или WS2003 необходимо запустить команду Adprep /rodcprep.

    Создание установочного носителя


    Вы можете снизить объем репликации, необходимый для создания контроллера домена, установив контроллер домена с помощью носителя установки. Вам потребуется носитель установки, который содержит архив Active Directory.
    В этом упражнении вы создадите носитель установки.
    1. Войдите на машину SERVER01 как Администратор.
    2. Откройте окно командной строки. Введите команду ntdsutil
    4. Введите команду activate instance ntds и нажмите клавишу Enter.
    5. Введите команду ifm и нажмите Enter.
    6. Введите знак вопроса ? и нажмите клавишу Enter, чтобы перечислить
    команды, доступные в режиме установки с носителя IFM (Installation From
    Media).
    7. Введите команду create sysvol dull c:\IFM и нажмите Enter.
    Файлы носителя установки будут скопированы в папку C:\Ifm.
    Устанавливаем роль AD DS и запускаем Мастер установки AD DS. Если в домене один контроллер и вы установите на странице Вас приветствует мастер установки доменных служб AD флажок Использовать расширенный режим установки (Use Advanced Mode Installation), то сможете отконфигурировать следующие дополнительные параметры.
    Установка с носителя IFM (Install From Media). По умолчанию во время выполнения мастера установки доменных служб AD новый контроллер домена реплицирует с других контроллеров домена все данные для всех разделов каталогов, которыми будет управлять. Для ускорения установки, в частности при медленных подключениях, можно использовать установочные носители, создаваемые существующими контроллерами домена. Новый контроллер домена может напрямую читать данные с установочного носителя, а затем реплицировать с других контроллеров домена только обновления.
    В WServer команда dcpromo /adv используется для указания дополнительных параметров установки. Чтобы применить команду Dcpromo.exe с параметрами командной строки для указания опций автоматизированной установки, можно использовать минимальный набор параметров, как показано в следующем примере:
    dcpromo /unattend /replicaOrNewDomain: replica
    /replicaDomainDNSName:contoso.com /installDNS:yes /confirmGC:yes
    /databasePath:"e:\ntds" /logPath:"f:\ntdslogs" /sysvolpath:"g:\sysvol"
    /safeModeAdminPassword:пароль /rebootOnCompletion:yes
    Если вы вошли на сервер, не используя доменную учетную запись, укажите также параметры userdomain и username. Далее показано содержимое файла ответов с минимальным набором параметров для установки дополнительного контроллера домена.
    [DCINSTALL]
    ReplicaOrNewDomain=replica
    ReplicaDomainDNSName=FQDN-имя присоединяемого домена
    UserDomain=FQDN-имя домена с учетной записью пользователя
    UserName=ДОМЕН\имя_пользователя (в группе Администраторы домена)
    Password=napoль пользователя, указанного в параметре UserName (* для открытия окна ввода пароля)
    InstallDNS=yes
    ConfirmGC=yes
    DatabasePath="путь к папке в локальном томе"
    LogPath="nyrb к папке в локальном томе"
    SYSVOLPath=" путь к папке в локальном томе"
    SafeModeAdminPassword=napоль
    RebootOnCompletion=yes

    Установка нового дочернего домена WServer


    Перед этим необходимо запустить команду adprep /forestprep. Затем установите службы AD DS, запустите Мастер установки доменных служб Active Directory и на странице Выберите конфигурацию развертывания (Choose A Deployment Configuration) щелкните опцию Существующий лес, а затем — опцию Создать новый домен в существующем лесу.
    Поскольку вы устанавливаете первый контроллер в домене, он не может быть контроллером RODC и устанавливаться с носителя. Если на странице приветствия установить флажок Использовать расширенный режим установки (Use Advanced Mode Installation), мастер откроет страницу Исходный контроллер домена (Source Domain Controller), где можно указать контроллер домена, чтобы реплицировать с него разделы конфигурации и схемы.

    Удаление контроллера домена


    Иногда может потребоваться отключить контроллер домена от сети для проведения капитального технического обслуживания либо навсегда удалить его. Делать это нужно корректно, чтобы удалить информацию об этом контроллере домена из AD.
    Для удаления контроллера домена используется команда Dcpromo.exe или GUI. При ее запуске на контроллере домена с помощью интерфейса Windows запустится Мастер установки доменных служб AD. Чтобы удалить роль AD DS в установке ядра сервера из командной строки, введите dcpromo.exe /?:Demotion. Откроется список параметров для операции понижения роли контроллера домена (можно с помощью файла ответов).
    При понижении роли контроллера домена требуется указать пароль, который будет назначен локальной учетной записи администратора сервера после выполнения этой операции.
    При удалении контроллера, подключенного к домену, метаданные леса дополняются информацией об удалении контроллера домена.
    Может выйти ошибка типа «указанное для этой репликации имя уже существует». Это может значить, что осуществляется попытка реплицировать администраторскую учётную запись, из-под которой производится понижение и которая совпадает с существующей именем, но не самой сущностью, т.к., вероятно была создана не в результате репликации, а вручную. Достаточно произвести понижение под другой администраторской учётной записью.
    Если контроллер домена требуется удалить без подключения к домену, нужно использовать параметр принудительного удаления команды Dcpromo.exe. Введите команду depromo /forceremoval, после чего запустится мастер установки AD DS для выполнения шагов процесса. Появятся предупреждения относительно ролей, управляемых контроллером домена. Прочитайте каждое предупреждение и щелкните кнопку Да. Предупреждения можно отключить с помощью параметра demotefsmo:yes команды Dcpromo.exe. После удаления контроллера домена необходимо вручную очистить метаданные леса. Информацию об очистке метаданных можно найти в статье 216498 базы знании Microsoft по адресу go.microsoft..com/fxolink/?LinkId=80481.

    Настройка хозяев операций


    В домене AD все контроллеры домена равноправны. Все они могут записывать изменения в базу данных и реплицировать их на другие контроллеры домена. Однако в любой топологии репликации со множеством равноправных участников определенные операции должны выполняться одной и только одной системой. В любой реплицируемой базе данных некоторые изменения должны производиться одной и только одной репликой, поскольку выполнять их всем равноправным участникам непрактично.
    Для этих операций и контроллеров домена, которые их выполняют, используется множество терминов:
    • мастеры, или хозяева операций;
    • роли мастеров операций;
    • отдельные роли мастеров;
    • роли мастеров операций FSMO (Flexible Single Master Operations)

    Отдельные операции мастеров соответствуют характеристикам любой реплицируемой базы данных. Все контроллеры домена AD могут выполнять отдельные операции мастеров. Контроллер домена, выполняющий операцию, является текущим владельцем маркера операции. Маркер операции и соответственно роль можно без труда перенести на еще один контроллер домена без перезагрузки. Чтобы уменьшить угрозу появления отдельных точек сбоев, маркеры операций можно распределить среди множества контроллеров домена.
    Доменные службы AD DS содержат 5 ролей мастеров операций. Для целого леса предусмотрены 2 роли:
  • именование доменов;
  • схема.
    При добавлении или удалении домена должен быть доступен мастер именования доменов, иначе при выполнении операции возникнет ошибка.
    Набор правил, называемый схемой, задает классы объектов и атрибуты, которые могут храниться в каталоге. Например, в каталоге AD можно хранить объекты пользователей, включающие их имена и пароли, поскольку схемой задан класс объектов user, два их атрибута, а также связь между классом объекта и атрибутами. Схема - определение классов атрибутов и объектов, поддерживаемых в AD. Контроллер домена, содержащий роль мастера схемы, отвечает за внесение всех изменений в схему леса. Все остальные контроллеры домена содержат реплики схемы только для чтения. Модификацию схемы или установку приложения, модифицирующего схему, рекомендуется выполнять на контроллере домена, управляющего ролью мастера схемы. В противном случае чтобы внести в схему изменения, их необходимо переслать мастеру схемы.
    В каждом домене предусмотрены 3 роли мастера:
    1. относительный идентификатор RID (Relative Identifier);
    2. инфраструктура;
    3. эмулятор PDC.
    RID
    Мастер RID участвует в генерировании идентификаторов безопасности (SID) для таких принципалов безопасности, как пользователи, группы и компьютеры. Идентификатор SID принципала безопасности должен быть уникальным. Поскольку учетные записи, а следовательно, и SID-идентификаторы может создавать любой контроллер домена, необходим механизм, гарантирующий уникальность SID-идентификаторов, генерируемых контроллером домена. Контроллеры домена AD генерируют SID-идентификаторы, назначая SID-идентификатору домена уникальный относительный RID-идентификатор. Мастер RID домена выделяет каждому контроллеру в домене пулы уникальных RID-идентификаторов.

    Мастер инфраструктуры


    В среде из множества доменов объекты в одних доменах часто ссылаются на объекты в других. Например, в группу могут входить члены из другого домена. Ее многозначный атрибут member содержит отличительные имена каждого члена. При перемещении или переименовании члена из другого домена мастер инфраструктуры домена группы соответствующим образом обновляет атрибут member группы. Мастер инфраструктуры — это что-то вроде устройства, отслеживающего членов группы из других доменов. При перемещении или переименовании этих членов в другом домене мастер инфраструктуры определяет изменения и вносит соответствующие поправки в членство в группах.
    Фантомы каталога
    При добавлении члена из другого домена в группу вашего домена к атрибуту member группы прикрепляется отличительное имя нового члена. Однако ваш домен не всегда имеет доступ к контроллеру домена члена группы, поэтому Active Directory создает объект-фантом, представляющий члена группы. Объект-фантом содержит только SID-идентификатор члена, отличительное имя DN (Distinguished Name) и глобальный уникальный идентификатор (GUID). В случае перемещения или переименования члена группы в его домене GUID-идентификатор члена не меняется, зато меняется его имя DN. При перемещении объекта в другой домен меняется и его SID-идентификатор.
    Мастер инфраструктуры периодически (каждые 2 дня по умолчанию) связывается с глобальным каталогом GC или контроллером домена члена группы и выполняет поиск всех объектов-фантомов с текущим именем DN объекта. Затем все изменения вносятся в атрибут member групп.
    Если просмотреть членство в группе с помощью оснастки Active Directory — пользователи и компьютеры после перемещения или переименования члена группы из другого домена и до обновления имен DN мастером инфраструктуры, в списке группы этого члена может не быть. Но несмотря на это член продолжает принадлежать к группе.
    Атрибут memberOf члена также связан с группой, поэтому атрибут memberOf и построенный атрибут tokenGroup не изменяются. Это не вредит безопасности: заметить временное несоответствие может лишь администратор, просматривающий членство в этой отдельной группе.

    Мастер PDC-эмулятор


    Роль PDC-эмулятора выполняет для домена множество важных функций.
    1. Участие в репликации обновлений паролей домена. При сбросе или изменении пароля пользователя контроллер домена, вносящий изменение, немедленно реплицирует это изменение на PDC-эмулятор. Эта особая репликация гарантирует, что контроллеры домена быстро узнают новый пароль. Перед отклонением попытки входа этот контроллер домена направляет запрос проверки подлинности на PDC-эмулятор, который проверяет корректность нового пароля и указывает контроллеру домена принять запрос входа. Это означает, что каждый раз при вводе пользователем неправильного пароля проверка подлинности направляется на PDC-эмулятор для получения второго заключения. Поэтому PDC-эмулятор должен быть всегда доступен для всех клиентов в домене. Его нужно установить на высокопроизводительном контроллере домена с быстрыми подключениями.
    2. Управление обновлениями групповой политики в домене. Если объект групповой политики GPO модифицируется на двух контроллерах домена примерно в одно и то же время, могут возникать конфликты между двумя версиями, которые нельзя разрешить при репликации GPO. Чтобы избежать таких конфликтов, PDC-эмулятор действует как точка фокуса всех изменений групповой политики. При открытии GPO редактор управления групповыми политиками GPME привязывается к контроллеру домена, выполняющему роль PDC-эмулятора. Поэтому все изменения объектов GPO по умолчанию вносятся на PDC-эмулятор.
    3. Обеспечение главного источника времени домена Службы Active Directory, Kerberos, репликации файлов FRS (File Replication Service) и DFS-R используют временные штампы, поэтому необходима синхронизация времени во всех системах домена. По умолчанию PDC-эмулятор в корневом домене леса служит ведущим источником времени для всего леса. PDC-эмулятор в каждом домене синхронизирует свое время с PDC-эмулятором корневого домена леса. Другие контроллеры домена синхронизируют время с PDC-эмулятором домена, а остальные члены домена — с предпочтительным контроллером домена. Эта иерархическая структура синхронизации реализована в службе Win32Time, гарантирующей временное соответствие. Синхронизируется универсальное глобальное время UTC (Universal Time Coordinate), а время, отображаемое для пользователей, меняется в соответствии с параметрами часового пояса компьютера.
    К СВЕДЕНИЮ Единственное изменение службы времени
    Настоятельно рекомендуется позволить Windows по умолчанию поддерживать свои внутренние механизмы синхронизации времени. Единственное изменение, которое необходимо внести, заключается в настройке PDC-эмулятора корневого домена леса для синхронизации с внешним источником времени. Если не указать источник времени для PDC-эмулятора, журнал событий Система будет содержать ошибки с соответствующими напоминаниями.
    4. Выполнение функций центрального браузера домена. При открытии окна Сеть в Windows отображается список рабочих групп и доменов, а при открытии рабочей группы или домена отображается список компьютеров. Эти два списка просмотра создаются службой обозревателя (Browser).
    В каждом сетевом сегменте ведущий обозреватель создает список просмотра с рабочими группами, доменами и серверами этого сегмента. Центральный обозреватель домена объединяет списки всех ведущих обозревателей, чтобы клиенты могли извлечь полный список просмотра.

    Размещение хозяев операций


    При создании корневого домена леса с первым контроллером домена все 5 ролей хозяев операций выполняет этот контроллер. По мере добавления контроллеров в домен можно переносить роли хозяев операций на другие контроллеры, чтобы балансировать нагрузку среди контроллеров домена или оптимизировать размещение отдельных хозяев операций. Далее приведены рекомендации о размещении ролей хозяев операций.
  • Хозяин схемы и хозяин именования доменов должны быть размещены на одном контроллере домена, который служит сервером глобального каталога GC. Эти роли редко используются, и контроллер домена, управляющий ими, должен быть хорошо защищен. Хозяина именования доменов необходимо разместить на сервере GC потому, что при добавлении нового домена хозяин должен гарантировать, что в лесу нет объекта с тем же именем, что у добавляемого домена. Частичная реплика GC содержит имя каждого объекта в лесу. Нагрузка этих ролей хозяев операций довольно мала, если в схему не вносятся модификации.
    2. Разместите роли RID и PDC-эмулятора на одном контроллере домена. Если из соображений балансировки нагрузки необходимо разместить эти роли на двух контроллерах домена, для этих двух систем нужно установить быстрое физическое подключение и создать в Active Directory явные объекты подключения, поскольку они — прямые партнеры по репликации. Они также должны быть прямыми партнерами по репликации с контроллерами домена, играющими роль резервных хозяев операций.
  • Если все контроллеры домена будут серверами глобального каталога, на них будет постоянно обновляться информация о каждом объекте в лесу, и роль хозяина инфраструктуры будет не нужна.
    Хозяина инфраструктуры следует разместить на контроллере домена, который не служит сервером GC, но физически подключен к серверу GC. Хозяин инфраструктуры должен располагать в AD явными объектами подключения к этому серверу GC, то есть они прямые партнеры по репликации. Хозяина инфраструктуры можно разместить на контроллере домена, который играет роль хозяина RID и PDC-эмулятора.
    В следующих подразделах мы рассмотрим перенос отдельных ролей хозяев операций с одних контроллеров домена на другие, что необходимо делать при долгих запланированных и незапланированных простоях хозяина операций. Определите план переноса операций на другие контроллеры домена на случай отключения одного хозяина операции от сети.

    Идентификация хозяев операций


    Для реализации плана размещения ролей нужно знать, какие контроллеры домена в настоящее время выполняют отдельные роли хозяев операций. Каждая роль отображается в административном инструменте Active Directory, а также в других средствах пользовательского интерфейса и командной строки. Для идентификации текущего хозяина каждой роли используйте следующие инструменты.
    1. оснастка Active Directory — пользователи и компьютеры. Щелкните домен ПКМ и примените команду Хозяева операций. Перейдите на вкладку PDC/RID/ Инфраструктура.
    2. Хозяин именования доменов/схемы: Active Directory — домены и доверие ПКМ корневой узел и примените команду Хозяин операций. Оснастку Схема Active Directory следует зарегистрировать перед созданием настраиваемой консоли ММС с этой оснасткой. Для этого в командную строку введите команду regsvr32 schmmgmt.dll.
    Для идентификации хозяев операций можно использовать несколько средств, включая следующие команды:
    ntdsutil
    roles
    connections
    connect to server FQDN_имя_контроллсра_домена:номер_порта
    quit
    select operation target
    list roles for connected server"
    quit
    quit
    quit
    dcdiag /test:knowsofroleholders /v
    netdom query fsmo

    Перенос ролей хозяев операций


    Отдельные роли хозяев операций можно без труда переносить. Если вы выводите из эксплуатации контроллер домена, выполняющий роль хозяина операций, перенесите ее на другой контроллер домена. Мастер установки доменных служб Active Directory попытается выполнить это задание автоматически, но вы должны подготовиться к отключению контроллера домена, перенеся его роли.
    Чтобы перенести роль хозяина операций, откройте административный инструмент, определяющий текущего хозяина (например, откройте AD — пользователи и компьютеры для переноса одной из трех ролей хозяев операций домена). Подключитесь к контроллеру домена, на который хотите перенести роль. Для этого ПКМ корневой узел оснастки и примените команду Сменить контроллер домена или Сменить контроллер домена Active Directory — в зависимости от используемой оснастки. Откройте диалоговое окно Хозяин операций, где указан контроллер домена, управляющий маркером роли хозяина операций. Щелкните кнопку Изменить, чтобы перенести роль на контроллер домена, к которому вы подключены. При переносе роли хозяина операций текущий и новый хозяева отключаются от сети. Переносится маркер, и новый хозяин немедленно начинает выполнять роль, а прежний хозяин сразу перестает выполнять ее. Для перемещения ролей хозяев операций рекомендуется использовать этот метод. Перед переносом роли рекомендуется проверить состояние репликации новой роли со старого хозяина роли.

    Ошибки распознавания хозяев операций


    Некоторые роли хозяев операций могут на время быть недоступны, прежде чем их отсутствие начнет создавать проблемы. Другие хозяева операций играют ключевую роль при ежедневных операциях на предприятии. Информацию о неполадках хозяев операций можно отыскать в журнале событий Служба каталогов (Directory Service).
    Однако вы часто будете сталкиваться с отказами хозяина операций при попытках выполнить функцию, управляемую хозяином. Например, в случае отказа хозяина RID вы не сможете создавать новые принципалы безопасности.

    Отзыв ролей хозяев операций


    При отказе контроллера домена, выполняющего отдельную роль хозяина операций, и невозможности вернуть систему в рабочее состояние, можно отозвать маркер операций. При отзыве роли новый хозяин назначается без удаления роли отказавшего хозяина.
    Отзыв роли — это радикальная мера, поэтому перед отзывом убедитесь в том, что он действительно необходим. Определите причину и допустимую продолжительность отключения хозяина операции от сети. Если хозяина операций можно отключить от сети на достаточный период времени, подождите.
    Время ожидания зависит от влияния отказавшей роли на среду.
    1. Отказ PDC-эмулятора. Эмулятор главного контроллера домена PDC (Primary Domain Controller) — это хозяин операций, недоступность которого скорее всего начинает влиять на операции и пользователей. Однако роль PDC-эмулятора можно отозвать на другой контроллер домена, а затем перенести ее обратно, когда исходная система, владеющая ролью, вновь будет подключена к сети.
    2. Отказ хозяина инфраструктуры. Такой отказ могут заметить
    администраторы, а не пользователи. Поскольку этот хозяин отвечает за обновление имен членов групп из других доменов, он может отображать временное несоответствие членства в группе, как описано ранее на этом занятии, но на само членство такое несоответствие не влияет. Роль хозяина инфраструктуры можно отозвать на еще один контроллер домена, а затем вернуть ее обратно, когда исходная система, владеющая ролью, вновь будет подключена к сети.
    3. Отказ хозяина RID В результате такого отказа контроллеры домена не могут создавать новые SID-идентификаторы и поэтому не позволяют создавать новые учетные записи для пользователей, групп или компьютеров.
    Но контроллеры домена получают достаточно большой пул RID-идентификаторов от хозяина RID, так что если вы не генерируете множество новых учетных записей, то некоторое время сможете обойтись без хозяина RID, пока он будет восстанавливаться в автономном режиме. Отзыв этой роли на другой контроллер домена будет радикальным решением. После отзыва роли хозяина RID контроллер домена, ранее выполняющий эту роль, нельзя вновь подключить к сети.
    4. Отказ хозяина схемы. Роль мастера схемы необходима только для внесения модификаций в схему непосредственно администратором при установке интегрированного приложения Active Directory, которое изменяет схему.
    В остальное время эта роль не требуется. Ее можно отключать от сети на сколь угодно долго, пока не понадобится внести изменения в схему. Отзыв этой роли на другой контроллер домена будет радикальным решением.
    После отзыва роли хозяина RID контроллер домена, ранее выполняющий эту роль, нельзя будет вновь подключить к сети.
    5. Отказ хозяина именования доменов. Эта роль необходима только при добавлении домена в лес или удалении домена из леса. Пока не требуется вносить такие изменения в инфраструктуру доменов, хозяин именования доменов может оставаться отключенным от сети неограниченное время.
    Отзыв этой роли на другой контроллер домена будет радикальным решением.
    После отзыва роли хозяина RID контроллер домена, ранее выполняющий эту роль, нельзя будет вновь подключить к сети.
    Хотя эти роли можно переносить с помощью административных инструментов, для отзыва роли необходимо использовать утилиту Ntdsutil.exe. Для отзыва роли хозяина операций выполните следующие действия.
    1. Запустите команду ntdsutil
    2. В строку ntdsutil запустите команду roles
    В следующем шаге устанавливается подключение к контроллеру домена, который будет выполнять роль отдельного хозяина операций.
    3. В строку fsmo maintenance введите команду connections и нажмите клавишу Enter.
    4. В строку server connections введите команду connect to server FQDN_имя_контроллера_домена, который будет играть эту роль и нажмите Enter. Ntdsutil сообщит о подключении к серверу.
    5. В строку server connections введите команду quit и нажмите клавишу Enter.
    6. В строку fsmo maintenance введите команду seize роль и нажмите Enter. Укажите одну из следующих ролей.
    A. Мастер схемы.
    Б. Мастер именования доменов.
    B. Мастер RID.
    Г. PDC.
    Д. Мастер инфраструктуры.
    7. В строку fsmo maintenance введите команду quit и нажмите клавишу Enter.
    8. В строку ntdsutil введите команду quit и нажмите Enter.

    Сайты и репликация

    Реплика


    Контроллеры домена WServer являются равноправными. Каждый из них поддерживает копию каталога, выполняет аналогичные службы для поддержки проверки подлинности принципалов безопасности, а изменения, внесенные на какой-либо один контроллер, будут реплицированы на все остальные. В домене следует установить несколько контроллеров, чтобы обеспечить непрерывную работу службы в случае отказа одного из них.
    В AD предполагается, что на предприятии используется 2 типа сетей: высокоскоростные и более медленные. Согласно концепции, изменение, внесенное в AD, должно немедленно реплицироваться на другие контроллеры домена по высокоскоростной сети, в которой вносилось изменение. Однако изменение не обязательно сразу реплицировать через более медленную, дорогостоящую и нестабильную ссылку на еще один сайт. Вместо этого можно управлять репликацией через сетевые сегменты предприятия с менее быстрыми подключениями, чтобы оптимизировать производительность, снизить затраты на контроль пропускной способности.
    Стэнд: два контроллера домена — SERVER01 и SERVER02 в домене contoso.com.
    Ключевые особенности репликации AD:
    1. Разбиение хранилища данных на разделы.
    2. Автоматическое генерирование эффективной и надежной топологии репликации. По умолчанию AD конфигурирует эффективную топологию двухсторонней репликации, чтобы потеря любого контроллера домена не воспрепятствовала репликации. Эта топология автоматически обновляется при добавлении и удалении контроллеров доменов, а также при их перемещении между сайтами.
    3. Репликация на уровне атрибутов. При модификации атрибута объекта реплицируется лишь этот атрибут и минимальный набор метаданных для его описания. Репликация объекта выполняется только при его создании.
    4. Отдельный контроль над внутриузловой репликацией и репликацией между узлами.
    5. Конфликты обнаружения и управления. В редких ситуациях атрибут модифицируется на двух различных контроллерах доменов во время одной репликации. В таком случае эти два изменения будут конфликтовать друг с другом. В AD имеются алгоритмы разрешения, подходящие практически для любой ситуации.
    Репликация FRS, применяемая в предыдущих версиях Windows и поддерживаемая в WServer для обеспечения обратной совместимости, уязвима, и ее неполадки довольно сложно устранять. Механизм DFS-R обеспечивает более стабильную и детальную репликацию содержимого %SystemRoot%\SYSVOL. Чтобы воспользоваться преимуществами этой функции, все контроллеры доменов должны использовать версию WServer.
    Доменное пространство имен DFS (распределённая файловая система - Distributed File System) создается после развертывания домена AD по адресу \\domain\SYSVOL.
    SYSVOL содержит сценарии входа, шаблоны GPT и другие ресурсы, необходимые для поддержки работоспособности домена AD и управления им. В идеале папка SYSVOL должна быть согласована на всех контроллерах домена. Но время от времени в GPO и сценарии входа вносятся изменения, причем они должны эффективно реплицироваться на все контроллеры домена. В предыдущих версиях Windows для репликации содержимого SYSVOL среди контроллеров домена использовалась служба репликации файлов RFS. Репликация RFS имеет ограничения пропускной способности и производительности, которые могут привести к прерыванию работы службы.
    Поскольку папка SYSVOL играет ключевую роль в поддержке работоспособности и функциональности домена, Windows не предоставляет механизм для мгновенного преобразования репликации SYSVOL из FRS в DFS-R. При миграции на DFS-R создается параллельная структура SYSVOL. После успешного размещения параллельной структуры клиенты перенаправляются в нее как в системный том домена, а после успешного выполнения этой операции можно исключить репликацию FRS.

    Сайты и подсети


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

    Сайты и ссылки


    Сетевая инфраструктура в AD представлена объектами, которые называются сайтами (узлами) и ссылками. Сетевые размещения и ссылки вместе составляют сетевую инфраструктуру. Сайт (или узел) AD - высокоскоростной сегмент сети на предприятии. В случае определения сайта контроллеры домена внутри узла реплицируют изменения практически мгновенно. Репликацию между сайтами можно выполнять по графику. Сайты соединены ссылками — сетевыми подключениями, основой которых могут быть как удаленные коммутируемые подключения, так и волоконно-оптические линии связи.
    Нужно также знать свойства и роли сайтов в AD, чтобы понимать едва уловимую разницу между сайтами AD и сетевыми сайтами. Сайты AD — это объекты в каталоге, в частности в контейнере Configuration (CN=Configuration, DC=корневой домен леса). Эти объекты используются для выполнения двух задач управления службами:
  • управление трафиком репликации. Сайты доменных служб AD являются основным компонентом службы каталогов, поддерживающим локализацию и репликацию службы. В этой главе речь пойдет о создании распределенной службы каталогов, которая поддерживает контроллеры домена в сегментах сети, разделенных дорогостоящими, медленными или нестабильными подключениями, о размещении контроллеров, а также об управлении репликацией и использованием служб. Однако сайты также играют важную роль в средах с интенсивными подключениями, поскольку они позволяют управлять локализацией служб — то есть клиент выбирает среди множества серверов, на которых доступна служба, наиболее эффективный.
  • локализация служб. Во время входа клиенты Windows автоматически направляются на контроллер домена в своем узле, а если этот контроллер недоступен, — на контроллер домена в еще одном узле, который может выполнять проверку подлинности. Другие службы также можно локализовать. Например, служба пространств имен распределенной файловой системы DFS Namespaces является локализованной. Поскольку клиенты обычно знают, в каком узле находятся, то для того, чтобы использовать преимущества структуры сайтов AD, в перечень служб можно добавить любую распределенную службу.

    Планирование сайтов


    Нужно тщательно распланировать структуру сайтов AD (они могут не соответствовать сетевым узлам). Сайт AD может включать несколько сетевых узлов или являться подсетью отдельного сетевого узла. Рассмотрим два сценария.
    1. В вашей компании есть два удаленных офиса, в каждом из которых вы размещаете контроллер домена. Между офисами установлено высокоскоростное подключение. Для повышения производительности необходимо отконфигурировать один сайт AD для обоих офисов.
    2. Предприятие расположено в большом здании с хорошими коммуникациями. В отношении репликации предприятия можно использовать один сайт, однако вы хотите, чтобы клиенты применяли распределенные службы на своем местоположении и конфигурируете множество сайтов для поддержки локализации служб.
    Каждый лес AD содержит не менее одного сайта. При создании леса с первым контроллером домена создается по умолчанию сайт, которому присваивается имя Default-First-Site-Name. Дополнительные сайты нужны ещё и в следующих ситуациях:
  • трафик запросов каталогов является основанием для размещения контроллера домена;
  • репликацию между контроллерами домена необходимо контролировать.

    Создание сайтов


    Управление сайтами и репликацией осуществляется с помощью оснастки AD — сайты и службы. Для определения сайта AD создается объект класса site. Объект сайта представляет собой контейнер, который управляет репликацией для контроллеров домена в сайте. При этом также создается один или несколько объектов подсетей. Объект подсети определяет диапазон IP-адресов и привязан к одному сайту. Но сайт может быть связан с несколькими подсетями.
    Локализация служб осуществляется в том случае, если IP-адрес клиента можно связать с сайтом через связь между объектом подсети и объектом сайта.
    Чтобы создать объект сайта, ПКМ узел Sites в оснастке AD — сайты и службы и выполните команду Создать сайт. В открывшемся диалоговом окне Новый объект — Сайт, введите имя сайта и выберите связь. В окне доступна лишь связь сайтов по умолчанию DEFAULTIPSITELINK — до тех пор, пока не будут созданы дополнительные связи сайтов.
    Сайт Default-First-Site-Name рекомендуется переименовать и назначить ему имя, соответствующее топологии сети. Поскольку имена сайтов регистрируются в DNS, следует использовать совместимые с DNS имена без специальных символов и пробелов.
    Сайты имеет смысл использовать только в том случае, когда клиент или сервер знает, к какому сайту принадлежит. Как правило, для этого IP-адрес системы связывается с сайтом, и эту связь получают объекты подсети. Чтобы создать объект подсети, в оснастке AD — сайты и службы ПКМ узел Subnets и выполните команду New Subnet. Откроется диалоговое окно Новый объект — Подсеть.
    В производственной среде нужно определить каждую подсеть IP как объект подсети AD. Если IP-адрес клиента не включен в диапазон подсети, клиент не определит, к какому сайту AD oн принадлежит, в результате чего могут возникать проблемы производительности и функциональности. Нe забывайте о магистральных подсетях, а также подсетях, используемых для удаленного доступа, таких как виртуальные частные сети.

    Контроллеры доменов в сайтах


    При создании леса AD первый контроллер домена автоматически размещается в объекте сайта Default-First-Site-Name. По умолчанию дополнительные контроллеры домена будут добавляться в сайты с учетом их IP-адресов в соответствующие подсети. Однако Мастер установки доменных служб AD позволяет указать еще один сайт. Сайт всегда содержит контейнер Servers с объектом для каждого контроллера домена и должен содержать лишь контроллеры домена, а не серверы. Для контроллера домена можно также предварительно создать в корректном сайте объект сервера, щелкнув ПКМ контейнер Servers в соответствующем сайте и выполнив команду Сервер в меню Создать. И наконец, контроллер домена можно переместить после установки в корректный сайт, щелкнув ПКМ сервер и выполнив команду Переместить. Рекомендуется поместить его в объект сайта, который связан с IP-адресом.
    Если контроллер домена содержит несколько сетевых адаптеров, он может принадлежать только одному сайту. Если сайт не содержит контроллер домена, пользователи все равно смогут входить в домен, а их запросы входа будут обрабатываться контроллером домена в соседнем сайте или еще одним контроллером в домене.

    Записи расположения службы


    Контроллер, добавляемый в домен, извещает о своих службах, создавая в DNS записи Расположение службы (SRV, Service Locator). В отличие от записей А, записи SRV сопоставляют службы с именами хостов. Контроллер домена также информирует о своей способности выполнять проверку подлинности и предоставлять доступ к каталогу, регистрируя записи Kerberos и LDAP-записи SRV. Эти SRV-записи добавляются в несколько папок внутри DNS-зон леса. Первая папка _tcp находится внутри зоны домена и содержит SRV-записи для всех контроллеров в домене. Вторая папка привязана к сайту, где расположен контроллер домена (путь к ней: _sites\имя_caйта\_tcp). Записи Kerberos и LDAP-записи SRV для контроллера SERVER02.contoso.com на его сайте _site\BRANCH\_tcp представлены на рис. 11-6. В зоне также есть папка первого уровня _tcp. SRV-записи создаются в узлах сайтов внутри DNS-зон домена и леса.
    Эти же записи регистрируются еще в нескольких местах зоны _msdcs.Имя_домена, например в _msdcs.contoso.com. Указанная зона содержит записи служб контроллеров доменов Microsoft (Microsoft Domain Controller Services). Символы подчеркивания являются требованием документации RFC 2052.
    Рис. 11-6. Записи SRV для SERVER02 в сайте BRANCH
    Далее перечислены сведения, содержащиеся в записи расположения служб.
    1. Имя и порт службы. Эта часть SRV-записи указывает службу с фиксированным портом, который не всегда должен быть общеизвестным. Записи SRV в Server 2008 включают записи LDAP (порт 389), Kerberos (порт 88), протокол Kerberos Password (KPASSWD, порт 464) и служб глобального каталога GC (порт 3268).
    2. Протокол. В качестве транспорта для службы используется протокол TCP или UDP. Одна служба может использовать оба протокола в отдельных SRV-записях. Например, записи Kerberos регистрируются для обоих протоколов TCP и UDP. Клиенты Microsoft используют только TCP, однако клиенты UNIX могут применять UDP.
    3. Имя узла. Это имя соответствует записи узла (А) сервера, управляющего службой. Когда клиент запрашивает службу, DNS-сервер возвращает SRV-запись и связанные записи (А), чтобы клиенту не нужно было посылать отдельный запрос для разрешения IP-адреса службы.
    Имя службы в SRV-записи указано в соответствии со стандартной иерархией DNS, где компоненты разделены точками. Например, служба Kerberos контроллера домена может быть зарегистрирована следующим образом:
    kerberos._tср.Имя_сайта._sites.Имя_домена
    При чтении этой SRV-записи справа налево, как и в случае с другими DNS-записями, мы получаем следующее:
    • имя_домена: домен или зона, например contoso.com;
    • _sites: все сайты, зарегистрированные в DNS;
    • имя_сайта: сайт контроллера домена, регистрирующий службу;
    • _tcp: все службы TCP сайта;
    • kerberos: центр распространения ключей Kerberos (Kerberos Key Distribution Center, KDC), использующий протокол TCP.

    Поиск контроллеров домена клиентами


    Представим клиента Windows, который только что присоединился к домену. Клиент не знает, где искать контроллер домена, а потому запрашивает его путем опроса папки _tcp, которая, как вы помните, содержит SRV-записи всех контроллеров в домене. Сервер DNS возвращает список всех соответствующих контроллеров домена, после чего клиент пытается связаться со всеми этими контроллерами. Первый, который отвечает клиенту, анализирует IP-адрес, перекрестные ссылки на объекты подсетей и сообщает клиенту, к какому сайту тот принадлежит. Клиент сохраняет имя сайта в реестре, а затем опрашивает все контроллеры домена в папке _tcp сайта. Сервер DNS возвращает список всех контроллеров домена в сайте. Далее клиент пытается связаться со всеми, и первый ответивший контроллер домена выполняет проверку подлинности клиента.
    Клиент определяет этот контроллер домена как близлежащий, и впоследствии будет пытаться проходить проверку подлинности именно на нем. Если контроллер домена недоступен, клиент вновь опрашивает папку _tcp сайта и пытается связаться со всеми контроллерами домена в узле. А что происходит, когда клиент является мобильным? Представим, что этот компьютер проходит проверку подлинности в узле BRANCH1, а затем пользователь переносит компьютер в узел BRANCH2. При запуске компьютер попытается связаться с предпочитаемым контроллером домена в узле BRANCH1, который определит, что IP-адрес клиента связан с сайтом BRANCH2, и сообщит клиенту новый сайт, к которому тот принадлежит.

    Покрытие сайтов


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

    Глобальный каталог и разделы каталогов приложений


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

    Хранилище данных AD


    Структура AD DS хранит свои объекты идентификации в каталоге на контроллерах домена. Каталог состоит из одного файла Ntds.dit, который по умолчанию находится в папке %SystemRoot%\Ntds на контроллере домена. В этом отдельном файле и содержатся разделы каталога, или контексты именования (Naming Context , NC). Каждый раздел каталога хранит объекты с отдельной областью и специальным назначением. База данных состоит из нескольких разделов каталогов:
  • схемы. Определяет классы объектов и их атрибуты для целого каталога.
  • конфигурации. Содержит объекты, представляющие логическую структуру леса, включая домены, а также физическую топологию, включая сайты, подсети и службы.
  • GC
  • домена. Содержит данные об объектах (например, пользователях, группах и компьютерах) и все объекты домена внутри домена (включая пользователей, группы, компьютеры и контейнеры групповой политики (GPC)). Реплицируется на все контроллеры в домене, но не реплицируется на контроллеры в других доменах.
    Каждый контроллер домена поддерживает копию, или реплику, нескольких разделов и содержит минимум 3 реплики: раздел своего домена, конфигурацию и схему. Разделы конфигурации и схемы затем реплицируются на все контроллеры доменов в лесу.
    По традиции эти полные реплики включают все объекты и атрибуты с возможностью записи на каждом контроллере домена. Однако контроллер RODC в WServer поддерживает реплику лишь с правом чтения всех объектов в контекстах именования конфигурации, схемы и домена. В то же время определенные атрибуты, в частности пользовательские пароли, не реплицируются на контроллер RODC, если политика контроллера RODC не разрешает такую репликацию. На контроллеры RODC также никогда не реплицируются атрибуты, являющиеся секретными данными домена и леса.

    Анализ разделов каталога приложений


  • Запомните имя DC=DomainDnsZones, DC=contoso, DC=com раздела DomainDnsZones.
  • ПКМ узел ADSI Edit - Connect To.
  • Щелкните опцию Выберите или введите различаемое имя пли контекст именования (Select Or Type A Distinguished Name Or Naming Context).
  • В комбинированное поле введите имя DC=DomainDnsZones,DC=contoso,DC=com. Щелкните ОК.
  • В дереве консоли выберите элемент Контекст именования по умолчанию (Default Naming Context) и разверните его.
  • Выберите и разверните контейнер DC=DomainDnsZones,DC=contoso, DC-com.
  • Выберите и разверните контейнер CN=MicrosoftDNS.
  • Выберите контейнер DC=contoso.com.
  • Проанализируйте объекты в этом контейнере. Сравните их с записями DNS домена contoso.com.

    Глобальный каталог


    Представим себе лес с двумя доменами, каждый из которых содержит два контроллера. Контроллеры в домене Б не поддерживают информацию об объектах в домене А, поэтому контроллер в домене Б может не ответить на запрос объектов в NC домена А.
    Для выполнения таких задач используется глобальный каталог (GC) — раздел, который хранит информацию о каждом объекте в лесу. Когда пользователь в домене Б выполняет поиск объекта домена А, результаты запроса предоставляет глобальный каталог. Для оптимизации эффективности GC содержит лишь поднабор атрибутов, которые используются для поиска среди доменов. По этой причине глобальный каталог GC также называют частичным набором атрибутов (Partial Attribute Set, PAS). В отношении поддержки поиска глобальный каталог можно сравнить с типом индекса для хранилища данных AD DS.
    Глобальный каталог, значительно повышающий эффективность службы каталога, необходим для таких приложений, как Microsoft Exchange Server и Microsoft Office Outlook. Каталог GC обслуживается только одним контроллером домена, и в идеале каждый контроллер домена должен быть сервером GC.
    Глобальный каталог — еще один раздел, который нужно реплицировать. В одном лесу из 1 домена при настройке всех контроллеров домена как серверов, GC не требует нагрузки, поскольку все контроллеры домена уже поддерживают полный набор атрибутов для всех объектов домена и леса. В лесу из множества доменов дополнительная нагрузка связана с репликацией изменений частичного набора атрибутов в других доменах. Однако многие организации считают, что механизм репликации Active Directory достаточно эффективен для репликации GC без значительного влияния на сети, и ее преимущества компенсируют это негативное влияние. Если все контроллеры домена отконфигурировать как серверы GC, то больше не понадобится определять расположение хозяина операций инфраструктуры, поскольку эта роль не нужна в домене, все контроллеры которого являются серверами глобального каталога.
    В частности, рекомендуется конфигурировать сервер GC на контроллере домена в узле, где выполняются следующие условия:
    1. чтобы выполнить запросы каталога, задействованное приложение нередко использует порт 3268 глобального каталога;
    2. подключение к серверу GC является медленным и нестабильным;
    3. этот сайт содержит компьютер Exchange Server.
    При создании первого домена в лесу первый контроллер домена конфигурируется как сервер глобального каталога. Глобальный каталог также можно добавить или удалить с контроллера домена с помощью оснастки Active Directory — сайты и службы. Разверните сайт, откройте контейнер Servers внутри сайта и разверните объект сервера контроллера домена. ПКМ узел NTDS Settings и выполните команду Свойства. На вкладке Общие установите/сбросьте флажок Глобальный каталог.
    Серверы GC повышают производительность запросов каталога, поддержпт вход и предоставляют данные для таких приложений, как Exchange Server.

    Кэширование членства в универсальных группах


    В универсальные группы включаются пользователи и группы из множества доменов в лесу. Членство в универсальных группах реплицируется в глобальном каталоге. При входе пользователя данные его членства в универсальных группах извлекаются с сервера глобального каталога.
    Если глобальный каталог недоступен, членство в универсальных группах также недоступно. Универсальная группа применяется для того, чтобы запретить пользователю доступ к ресурсам — в таком случае система Windows не позволит ему проходить проверку подлинности в домене. Если пользователь раньше уже входил на компьютер, он может применить для входа кэшированные учетные данные, однако доступ к сетевым ресурсам будет запрещен. Таким образом, складывается следующая ситуация: если сервер GC недоступен, пользователи не смогут входить в сеть и получать доступ к сетевым ресурсам.
    В сайтах без серверов GC пользователи не всегда имеют возможность войти в сеть, если контроллер домена не может связаться с сервером GC в еще одном сайте.
    Такая проблема не возникает, если каждый контроллер домена является сервером глобального каталога. Однако при ограниченной репликации и невозможности назначить контроллер домена сервером GC для успешного входа можно включить кэширование членства универсальных групп (Universal Group Membership Caching, UGMC). При настройке такого кэширования контроллер домена в филиале получит данные членства универсальных групп из глобального каталога для пользователя, впервые вошедшего в сеть, и на неопределенный период кэширует эту информацию, обновляя данные членства универсальных групп каждые 8 часов. Таким образом, если сервер GC окажется недоступным, контроллер домена использует кэшированные данные членства универсальных групп, чтобы пользователь смог войти в сеть.
    Поэтому на контроллерах домена в сайтах с ненадежной связью с сервером GC рекомендуется сконфигурировать UGMC. Откройте оснастку Active Directory - сайты и службы и в дереве консоли выберите нужный сайт. Свойства NTDS Site Settings (рис. 11-8), установите флажок Разрешить кэширование членства в универсальных группах (Enable Universal Group Membership Caching) и укажите GC, с которого будет выполняться обновление кэша членства в универсальных группах.
    Создате сайт и установите кэширование. При выполнении этих действий в производственной среде потребовалось бы создать хотя бы один объект подсети, связанный с сайтом, и установить контроллер домена в новом сайте.
    Если сайт не содержит сервер GC, для него можно отконфигурировать кэширование членства в универсальных группах, чтобы запросы входа пользователей не отклонялись случае недоступности сервера глобального каталога.

    Разделы каталога приложений


    AD поддерживает разделы каталога приложений (РКП) — секции хранилища данных, которые содержат объекты, необходимые для работы приложения или службы вне ядра служб AD DS. В отличие от других разделов вы можете нацеливать разделы приложений для репликации на конкретных контроллерах домена. По умолчанию они не реплицируются на все контроллеры доменов.
    РКП предназначены для поддержки приложений служб каталогов и могут содержать объект любого типа, за исключением принципалов безопасности (пользователи, компьютеры или группы безопасности).
    Поскольку они реплицируются лишь по мере надобности, разделы каталога приложений обеспечивают преимущества отказоустойчивости, доступности и производительности, оптимизируя трафик репликации.
    Самый простой способ понять концепцию РКП — проанализировать его разделы, поддерживаемые DNS-сервером Microsoft. Когда создается зона, интегрированная в Active Directory, записи DNS реплицируются между DNS-серверами с помощью раздела каталога приложений.
    Раздел и его объекты DNS-записей реплицируются лишь на те контроллеры домена, которые выполняют роль DNS-серверов.
    РКП в лесу можно просмотреть с помощью оснастки Редактирование ADSI (ADSI Edit). ПКМ корневой узел оснастки и выполните команду Подключение к (Connect To). В раскрывающемся списке Выберите известный контекст именования (Select A Well Known Naming Context) выберите контекст Configuration и щелкните ОК. Разверните контейнер Конфигурация и папку, представляющую раздел конфигурации, а затем выберите в дереве консоли папку CN=Partitions. На панели сведений будут отображены разделы хранилища данных AD DS (рис. 11-9).
    Рис. 11-9. Разделы в лесу contoso.com
    Обратите внимание на два раздела приложений ForestDnsZones и DomainDnsZones (см. рис. 11-9). Большинство разделов создаются приложениями, которым они необходимы. В качестве примеров можно привести DNS и интерфейс прикладного программирования для телефонии TAPI (Telephony Application Programming Interface). Члены группы Администраторы предприятия (Enterprise Admins) также могут вручную создавать разделы каталога приложений с помощью утилиты Ntdsutil.exe.
    Раздел приложений может быть добавлен в любом месте соответствующего именного пространства леса. Например, разделы DNS с отличительными именами DC=DomainDnsZones, DC=contoso, DC=com добавлены как дочерние разделы в раздел домена DC=contoso, DC=com. Раздел приложений также может являться дочерним разделом еще одного раздела приложений или новым деревом в лесу.
    В принципе для управления разделом каталога приложения, его данными и репликацией можно использовать средства этого приложения. Например, при простом добавлении интегрированной зоны Active Directory в DNS-сервер выполняется автоматическая настройка контроллера домена для получения реплики раздела DomainDns. С помощью таких инструментов, как Ntdsutil.exe и Ldp.exe, можно непосредственно управлять разделами каталога приложений.
    Важно систематизировать разделы каталога приложений до того, как будет удален контроллер домена. Если он управляет разделом каталога приложений, вы должны оценить назначение раздела, требуется ли он для всех приложений и является ли последней репликой, поскольку в таком случае удаление контроллера домена приведет к полной потере всей информации раздела. Хотя мастер установки доменных служб Active Directory предлагает удалить разделы каталога приложений, все же рекомендуется выполнять это вручную.
    Разделы каталога приложений уникальны, поскольку их можно реплицировать на конкретные контроллеры доменов в лесу. Зоны DNS, интегрированные в Active Directory, хранятся в разделах приложений.

    Настройка репликации


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

    Объекты подключений


    КД реплицирует изменения с еще одного контроллера благодаря объектам подключения AD DS, которые отображаются в AD сайты и службы как объекты в контейнере NTDS Settings объекта сервера контроллера домена. Объект подключения - это путь репликации от одного контроллера домена к другому и представляет репликацию лишь входящего трафика. Репликация в AD — это не что иное, как технология извлечения информации. На рис. 11-10 показано, что объект подключения в SERVER02 конфигурирует репликацию с SERVER01 на SERVER02. В данном примере контроллер SERVER02 является нижестоящим партнером по репликации, контроллер SERVER01 — вышестоящим. Репликацию между двумя контроллерами домена можно включить принудительно, ПКМ объект подключения и выполнив команду Реплицировать сейчас (Replicate Now).
    Пути репликации, построенные между контроллерами доменов объектами подключений, образуют в лесу топологию репликации. Active Directory создает по умолчанию двухстороннюю топологию, так что и случае отказа одного контроллера домена репликация будет продолжена и бесперебойном режиме. Эта топология также гарантирует не больше 3 прыжков между 2-мя любыми контроллерами доменов.
    Объект подключения генерируется автоматически. На каждом контроллере домена компонент Active Directory под названием КСС (Knowledge Consistency Checker) позволяет автоматически генерировать и оптимизировать репликацию между контроллерами доменов внутри сайта. Процесс КСС оценивает контроллеры доменов в сайте и создает объекты подключений для построения двухсторонней топологии из 3 прыжков. Если контроллер домена добавляется или удаляется из сайта или не отвечает на запросы, КСС динамически переформирует топологию, добавляя и удаляя объекты подключений.
    Чтобы назначить постоянные пути репликации, рекомендуется создать объекты подключений вручную (они не удаляются службой КСС). Локализуйте объект сервера нижестоящего партнера по репликации, то есть контроллера домена, который будет получать изменения от исходного контроллера домена. В объекте сервера ПКМ контейнер NTDS Settings и выполните команду Создать подключение доменных служб Active Directory. В диалоговом окне Поиск: Контроллеры домена AD выберите вышестоящего партнера по репликации и щелкните ОК.
    Внутри сайта объекты подключений нужно создавать лишь в некоторых случаях. Один из таких случаев - cледует выбрать контроллеры доменов в качестве резервных хозяев операций на случай переноса или отзыва роли хозяина операций. Резервный хозяин операций должен быть прямым партнером по репликации с текущим хозяином операций. Таким образом, если контроллер домена DC01 является хозяином RID, а контроллер домена DC02 - системой, которая возьмет на себя роль хозяина RID, то в DC02 необходимо создать объект подключения для непосредственной репликации с DC01.

    Репликация внутри сайта


    Репликация выполняется после установки объектов подключений между контроллерами домена в сайте.

    Уведомление


    Рассмотрим сайт, показанный на рис. 11-10. Когда контроллер SERVER01 вносит изменение в раздел, он запрашивает изменение для репликации своим партнерам. Контроллер SERVER01 по умолчанию ожидает 15 с, прежде чем уведомит своего первого партнера по репликации SERVER2 об изменении. Уведомление — это процесс: вышестоящий партнер информирует своего нижестоящего партнера о доступности изменения. По умолчанию SERVER01 ожидает 3 с, а потом отправляет уведомление дополнительным партнерам. Эти задержки, которые называются исходной задержкой уведомления и последующей задержкой уведомления, предназначены для дифференцирования трафика репликации внутри сайта.
    Получив уведомление, нижестоящий партнер SERVER02 запрашивает изменения с контроллера SERVER01, а агент репликации каталога DRA (Directory Replication Agent) отправляет атрибут с SERVER01 на SERVER02. Контроллер SERVER02 получает это изменение от SERVER01 и вносит его в свой каталог (оно еще не считается реплицированным). Контроллер SERVER02 запрашивает изменение для репликации своим нижестоящим партнерам по репликации.
    Нижестоящим партнером SERVER02 по репликации является SERVER03. Через 15 с SERVER02 уведомляет SERVER03 о новом изменении. Контроллер SERVER03 вносит реплицированное изменение в свой каталог, а затем уведомляет своих нижестоящих партнеров. Изменение выполнило два прыжка: с SERVER01 на SERVER02, а затем с SERVER02 на SERVER03. Топология репликации гарантирует не более 3 прыжков, прежде чем будет получено изменение всеми контроллерами домена. Это означает, что после трех прыжков (каждый выполняется приблизительно 15 с) изменение будет полностью реплицировало в сайте (для этого понадобится примерно 1 мин).

    Опрос


    Контроллер SERVER01 может долго не получать изменения для своих реплик, в частности во время отключения. В таком случае его нижестоящий партнер по репликации SERVER02 не будет получать уведомления от SERVER01. Кроме того, SERVER01 может быть отключен от сети без возможности посылать уведомления на SERVER02. Поэтому контроллеру SERVER02 нужно знать, что его вышестоящий партнер в сети просто не содержит никаких изменений.
    Для этой цели используется так называемый процесс опроса. Нижестоящий партнер по репликации связывается с вышестоящим и запрашивает изменения в очереди для репликации. По умолчанию интервал опроса для репликации внутри сайта составляет 1 ч. Частоту опроса можно отконфигурировать (правда, это не рекомендуется делать) в свойствах объекта подключения, щелкнув кнопку Изменить расписание.
    Не получив ответа на многократные попытки опроса, нижестоящий партнер запускает процесс КСС для проверки топологии репликации. Если вышестоящий сервер действительно отключен от сети, топология репликации перестраивается в соответствии с этим изменением.

    Связи сайтов


    КСС предполагает, что внутри сайта все контроллеры домена могут связаться друг с другом. Он строит внутриузловую топологию репликации, не зависящую от реальных сетевых подключений. Однако сетевые пути между сайтами, по которым должна выполняться репликация, можно назначать, создавая объекты связей сайтов, каждая из которых содержит один или несколько сайтов. Для репликации между сайтами генератор топологии между сайтами ISTG (InterSite Topology Generator ), который является компонентом КСС, создает объекты подключений между серверами в каждом сайте.
    Связи сайтов представляют доступные пути для репликации. Отдельная связь сайтов не управляет используемыми сетевыми маршрутами. При создании связи сайтов и добавлении к ней сайтов Active Directory может выполнять репликацию между этими сайтами. Генератор ISTG создает объекты подключений, а эти объекты определяют реальный путь репликации. Хотя топология репликации, построенная генератором ISTG, эффективно реплицирует Active Directory, она может оказаться неэффективной в текущей сетевой топологии.
    При создании леса создается один объект связи сайтов DEFAULTIPSITELINK. По умолчанию каждый новый добавленный сайт связывается с помощью DEFAULTIPSITELINK.

    Пример


    Рассмотрим организацию с центром данных в главном офисе HEADQUARTERS и тремя филиалами, каждый из которых подключен к центру данных посредством выделенной связи. Вы создаете сайты для каждого филиала Сиэтл, Амстердам и Пекин. Топология сети и сайтов показана на рис. 11-11.
    Рис. 11-11. Сетевая топология и отдельная связь сайтов
    Поскольку все четыре сайта включены в одну связь сайтов, Active Directory может выполнять репликацию всех сайтов друг на друга. Это означает, что Сиэтл реплицирует изменения из Амстердама, Амстердам — из Пекина, а Пекин — из главного офиса HEADQUARTERS, который, в свою очередь, реплицирует изменения из Сиэтла. Трафик репликации в сети перетекает по этим нескольким путям репликации из одного филиала в другой через главный офис. С такой связью сайтов нет необходимости создавать централизованную топологию репликации в виде звезды (hub-and-spoke), даже если реальная топология сети является таковой.
    Поэтому рекомендуется вручную создать связи сайтов в соответствии с физической топологией сетей. В предыдущем примере можно было бы создать три связи сайтов:
  • HEADQUARTERS-AMS, включающая сайты главного офиса и в Амстердаме;
  • HEADQUARTERS-SEA, включающая сайты главного офиса и в Сиэтле;
  • HEADQUARTERS-РЕК, включающая сайты главного офиса и Пекина.
    Затем связь DEFAULTIPSITELINK можно удалить.
    После создания связей сайтов генератор ISTG начнет использовать топологию для построения репликации между сайтами с подключением ко всем сайтам. Для настройки путей репликации между сайтами автоматически конструируются объекты подключений.

    Транспортные протоколы репликации


    В оснастке Active Directory — сайты и службы связи сайтов содержатся в контейнере IP, который находится в контейнере Inter-Site Transports. Изменения реплицируются между контроллерами домена с использованием одного нз двух протоколов:
    1. Протокол DS-RPC (Directory Service Remote Procedure Call, DS-RPC) Отображается в оснастке как IP. Протокол IP используется для репликации внутри сайтов и по умолчанию является предпочтительным протоколом для репликации между сайтами. В целом для всей репликации между узлами используется протокол IP.
    2. Протокол ISM- SMTP (Inter-Site Messaging-Simple Mail Transport Protocol). Этот протокол также называется протоколом SMTP и используется только в том случае, если сетевые подключения между сайтами являются нестабильными и не всегда доступными. Очень немногие организации задействуют для репликации SMTP, поскольку для этого протокола необходимо конфигурировать и управлять центром сертификации СА. Кроме того, репликация SMTP не поддерживается для разделов доменов. Другими словами, SMTP нельзя использовать для репликации контекста именования доменов. Так что если сайт использует SMTP для репликации данных на предприятии, то он должен охватывать весь домен. Необходимо помнить самое главное: два сайта, которые могут выполнять репликацию только с помощью протокола SMTP, должны быть отдельными доменами в лесу.

    Мостовые серверы


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

    Предпочитаемые мостовые серверы


    Вы также можете назначить один или несколько предпочитаемых мостовых серверов. Откройте свойства объекта сервера в оснастке Active Directory Sites And Services, выберите протокол передачи IP и щелкните кнопку Add. Для сайта можно отконфигурировать несколько предпочтительных серверов-плацдармов, однако в качестве плацдарма будет использоваться только один сервер.
    Важно понимать, что в случае назначения одного или нескольких мостовых серверов и их недоступности другой сервер не выбирается автоматически и репликация не выполняется для сайта, даже если в нем есть серверы, которые могут выполнять роль плацдармов. В идеале предпочтительные мостовые серверы конфигурировать не следует, однако из соображений производительности роль мостового сервера можно назначать контроллерам доменов с достаточными системными ресурсами. Требования брандмауэра также могут регламентировать назначение отдельного сервера в качестве плацдарма, не разрешая Active Directory самостоятельно выбирать и переназначать мостовые серверы.

    Репликации между сайтами


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

    Транзитивность связей сайтов


    По умолчанию связи сайтов являются транзитивными. Если использовать предыдущий пример, то в случае связывания сайтов в Амстердаме и главном офисе, а также сайтов в главном офисе и Сиэтле сайты в Амстердаме и Сиэтле будут связаны транзитивно. Теоретически это означает, что генератор ISTG может создать объект подключения непосредственно между мостовым сервером в Сиэтле и сервером-плацдармом в Амстердаме, опять-таки в обход централизованной сетевой топологии в виде звезды (hub-and-spoke).
    Чтобы отключить транзитивность связи сайтов, откройте свойства передачи IP в контейнере Inter-Site Transports и сбросьте флажок Установить мост для всех связей сайтов (Bridge All Site Links). Прежде чем выполнить эту операцию в производственной среде, просмотрите технические ресурсы о репликации Windows Server в технических библиотеках Microsoft TechNet по адресу technet.microsoft.com. При отключении транзитивности может возникнуть необходимость в перепостроении мостов для связей сайтов.

    Мосты связей сайтов


    Мост связи сайтов соединяет две или несколько связей сайтов, создавая транзитивную связь. Мосты связей сайтов необходимы только в том случае, если вы сбросите флажок Установить мост для всех связей сайтов (Bridge All Site Links) в окне свойств транспортного протокола. Помните, что по умолчанию эта транзитивность связей сайтов включена, и мосты связей сайтов не оказывают никакого эффекта.
    На рис. 11-14 показано, как используется мост связи сайтов в лесу с отключенной транзитивностью связей сайтов. При создании моста связи сайтов AMS-HEADQUARTERS-SEA, включающей связи сайтов HEADQUARTERS-AMS и HEADQUARTERS-SEA, эти две связи сайтов становятся транзитивными, то есть между контроллером домена в Амстердаме и контроллером домена в Сиэтле можно установить подключение репликации.
    Рис. 11-14. Мост связи сайтов, включающий связи HEADQUARTERS-AMS и HEADQUARTERS-SEA

    Стоимость связи сайтов


    Стоимость связей сайтов, которая используется для управления потоком трафика репликации по нескольким маршрутам, можно отконфигурировать, чтобы указать самую быструю, стабильную или наиболее предпочтительную связь.
    Для медленных подключений указывается более высокая стоимость, а для быстрых связей используется низкая стоимость. Репликация Active Directory выполняется через подключение с самой низкой стоимостью.
    По умолчанию для всех связей сайтов конфигурируется стоимость 100.
    Чтобы изменить ее, откройте свойства связи сайтов.
    Вернемся к предыдущему примеру и представим, что связь создана между сайтами в Амстердаме и Пекине (рис. 11-16). Такую связь сайтов можно отконфигурировать для репликации между контроллерами доменов в этих двух сайтах, если связи с главным офисом недоступны. Эта топология конфигурируется, к примеру, как часть плана на случай аварийного отказа.
    При использовании стоимости 100 по умолчанию для связи сайтов AMS-РЕК изменения Active Directory будут реплицироваться непосредственно между Амстердамом и Пекином. Если назначить для связи сайтов стоимость 300, изменения будут реплицироваться между Амстердамом и главным офисом, а затем между главным офисом и Пекином со стоимостью 200 вместо использования прямой связи сайтов AMS-PEK со стоимостью 300.
    Рис.11-16. Связи сайтов и стоимость

    Периодичность


    Репликация между сайтами основана исключительно на опросе. В ней не пользуются уведомлеления. По умолчанию каждые 3 ч мостовой сервер выполняет опрос вышестоящих партнеров по репликации для определения доступных изменений. Этот интервал репликации слишком велик для организаций, которые часто вносят изменения в каталог для репликации. Интервал опроса для каждой связи сайтов можно изменять. Откройте свойства связи сайтов и измените значение в поле Реплицировать каждые (Replicate Every).
    Минимальный интервал опроса составляет 15 мин. Это означает, что при использовании конфигурации репликации Active Directory по умолчанию изменение, внесенное в каталог в одном сайте, будет несколько минут ожидать репликации на контроллеры домена в еще одном сайте.
    По умолчанию репликация выполняется 24 ч в сутки. Однако время репликации между сайтами можно ограничить, изменив атрибуты расписания связи сайтов. Откройте окно свойств связи сайтов и щелкните кнопку Изменить расписание. В открывшемся диалоговом окне Расписание для (Schedule For) можно указать время выполнения репликации через эту связь.
    Планировать расписание репликации связи сайтов следует очень осторожно. Окна доступности репликации в расписании могут не перекрываться, в результате чего и репликация не будет выполняться. Обычно рекомендуется не конфигурировать доступность связи сайтов. Если вам не требуется расписание связи сайтов, в свойствах транспортного протокола IP установите флажок Игнорировать расписания ( Ignore Schedules): все расписания репликации связи сайтов будут игнорироваться и репликация будет выполняться 24 ч в сутки по всем связям сайтов.

    Мониторинг репликации


    В частности, для отчетности и анализа репликации используются 2 мощных инструмента: Диагностика репликации Repadmin.exe и Диагностика службы каталогов Dcdiag.exe (Directory Service Diagnostics). Подробные сведения о них можно найти в справке и поддержке.

    Repadmin.exe


    Инструмент диагностики репликации Repadmin.exe (Replication Diagnostics) — это средство командной строки, позволяющее генерировать отчеты о состоянии репликации на каждом контроллере домена. Информация, генерируемая инструментом Repadmin.exe, поможет выявить потенциальную проблему прежде, чем в лесу возникнут неполадки репликации. Метаданные репликации можно детализировать на различных уровнях, чтобы просмотреть конкретные объекты и атрибуты, а также идентифицировать, где и когда проблемное изменение было внесено в Active Directory. Инструмент Repadmin.exe применяется даже для создания топологии репликации и принудительной репликации между контроллерами доменов.
    Далее показан базовый синтаксис этой утилиты:
    repadmin команда аргументы...
    Инструмент Repadmin.exe поддерживает множество команд, выполняющих специфические задачи. Для большинства команд необходимо указать параметры. Многие команды используют параметр DSA_LIST, который является лишь сетевой меткой (имя DNS или NetBIOS либо IP-адрес) контроллера домена. Далее описаны некоторые задачи отслеживания репликации, которые можно выполнять с помощью инструмента Repadmin.exe.
    1. Отображение партнеров контроллера домена по репликации. Для отображения подключений репликации контроллера домена введите команду repadmin /showrepl DSA_LIST. По умолчанию инструмент Repadmin.exe отображает лишь входящие подключения между сайтами. Чтобы отобразить исходящие подключения, добавьте в команду аргумент /repsto.
    2. Отображение объектов подключений контроллера домена. repadmin /showconn DSA_LIST.
    3. Отображение метаданных об объекте, его атрибутах и репликации Для получения полной картины репликации вы можете проанализировать объект на двух различных контроллерах домена и определить атрибуты, которые реплицируются и не реплицируются. Введите команду repadmin /showobjmeta DSA_LIST Объект, где параметр DSA_L1ST указывает запрашиваемый контроллер домена. (Для указания всех контроллеров можно использовать символ звездочки [*].) В качестве параметра Объект укажите уникальный идентификатор объекта, как, например, его отличительное имя (Distinguished Name, DN) или GUID-идентифпкатор.
    С помощью инструмента Repadmin.exe можно также вносить изменения в инфраструктуру репликации. Далее описаны некоторые задачи управления, которые выполняются с помощью этой утилиты.
    1. Запуск службы КСС. Введите команду repadmin /kcc, чтобы запустить службу КСС для перерасчета топологии входящей репликации сервера.
    2. Repadmin.exe можно использовать для принудительного включения репликации между исходным и конечным контроллерами домена. Для этого введите команду repadmin /replicate Конечный_контроллер Исходный_контроллер Контекст_именования.
    3. Синхронизация контроллера домена со всеми партнерами по репликации.
    Введите команду repadmin /syncall DSA /А /е, чтобы синхронизировать контроллер домена со всеми его партнерами, включая партнеров на других сайтах.

    Dcdiag.exe


    Dcgiag.exe выполняет много тестов и генерирует отчеты по общему состоянию работоспособности репликации и безопасности AD DS. Запущенная сама по себе, команда Dcdiag.exe выполняет лишь быстрые тесты и выводит их результаты в отчетах. Если же запустить команду Dcdiag.exe /с, будет выполнен практически каждый тест. Результаты тестов можно перенаправить в файлы различных типов, включая XML.
    Выполнение одного или нескольких тестов можно также назначить с помощью параметра /test:Имя_теста. Далее описаны тесты, непосредственно связанные с репликацией.
    1. FrsEvent Создается отчет об ошибках операций в системе репликации файлов (File Replication System, FRS).
    2. DFSREvent Создается отчет обо всех ошибках операций в системе
    репликации DFS (DFS-R).
    3. Intersite. Выполняется проверка ошибок, которые могут препятствовать репликации между контроллерами доменов или задерживать ее.
    4. KccEvent. Идентифицируются ошибки КСС.
    5. Replications. Определяется, была ли своевременной репликация между контроллерами доменов.
    6. Topology. Проверяется подключение ко всем контроллерам доменов в топологи репликации.
    7. VerifyReplicas. Проводится проверка инициализации всех разделов каталога приложений на всех контроллерах, управляющих репликами.

    Домены и леса


    Стенд: два контроллера домена, SERVKR01 и SERVER02, в домене contoso.com.

    Функциональные уровни домена и леса


    Домен и лес с контроллером WServer может работать на старых функциональных уровнях. Например, на функциональном уровне WServer для репликации SYSVOL можно использовать DFS-R. Простого обновления всех контроллеров до WServer недостаточно: вы должны повысить функциональный уровень домена. Для этого применяется оснастка Active Directory — домены и доверие (Active Directory Domain And Trusts). ПКМ домен и примените команду Изменение режима работы домена ( Raise Domain Functional Level). Затем выберите функциональный уровень WServer и щелкните кнопку Повысить (Raise). Повышение функционального уровня домена — необратимая операция.
    Функциональный уровень домена также можно повысить с помощью оснастки Active Directory — пользователи и компьютеры. ПКМ домен или корневой узел и выполните команду Изменение режима работы домена.
    Функциональный уровень связан только с операционными системами контроллеров домена, а на рядовых серверах и рабочих станциях можно использовать почти любые ОС.
    Если все домены работают на функциональном уровне WS2003, этот же уровень можно назначить лесу. Существуют функциональные уровни леса с WS2003 по WServer.
    Подняв функциональный уровень всех доменов до WS2003, ПКМ корневой узел оснастки AD — домены и доверие/Изменение режима работы леса. В раскрывающемся списке Выбор доступного функционального уровня леса выберите режим WServer и щелкните кнопку Повысить. Повышать функциональный уровень домена может администратор домена. Чтобы повысить функциональный уровень леса, необходимо быть членом группы Администраторы домена в корневом домене леса или членом группы Администраторы предприятия.
    Функциональный уровень леса Windows 2000 является основным функциональным уровнем по умолчанию. В режиме работы леса Windows 2000 домены могут работать в любом поддерживаемом режиме. Функциональный уровень леса можно повысить после повышения режима работы всех доменов до соответствующего функционального уровня.

    Управление множеством доменов и доверительными связями


    Домен. Для создания домена AD необходим один или несколько контроллеров. Домен представляет собой административную единицу, внутри которой совместно используются определенные возможности и характеристики. Прежде всего, контроллеры домена реплицируют раздел хранилища данных, который помимо всего прочего содержит данные идентификации пользователей, групп и компьютеров домена. Поскольку все контроллеры домена поддерживают одно хранилище объектов идентификации, то любой такой контроллер может проверить подлинность всякого объекта идентификации в домене. Кроме того, домен является областью действия административных политик. Такие политики, конфигурируемые в одном домене, влияют на все учетные записи в нем и не оказывают влияния на учетные записи в других доменах. Объекты в базе данных AD можно изменять на любом контроллере домена, и такие изменения реплицируются на все остальные такие контроллеры. Поэтому в сетях, где не поддерживается репликация всех данных среди контроллеров домена, может потребоваться более одного домена, чтобы управлять репликацией поднаборов объектов идентификации.
    Лес (термин, присущий только AD) - набор из одного либо нескольких доменов AD. Первый установленный в лесу домен называется корневым. Лес содержит единственное описание сетевой конфигурации и один экземпляр каталога схемы. Это единственный замкнутый экземпляр каталога, то есть данные не реплицируются за его пределы. Поэтому лес задаёт периметр безопасности.
    Дерево. Пространство доменных имен DNS в лесу содержит деревья леса.
    Если домен является дочерним для другого домена, то эти два домена интерпретируются как дерево. Например, если лес treyresearch.net содержит два домена treyresearch.net и antarctica .treyresearch.net, то последние образуют непрерывную область именного пространства DNS и представляют одно дерево. Если же домены treyresearch.net и proseware.com не образуют непрерывной области в пространстве имен DNS, то они представляют два дерева. Деревья составляются из DNS-имен доменов в лесу.
    На рис. 1-2 показан лес AD компании Trey Research, который поддерживает небольшую полярную станцию в Антарктиде. Поскольку связь между Антарктикой и штаб-квартирой дорогостоящая, медленная и ненадежная, то полярная станция сконфигурирована как отдельный домен. Лесу назначено DNS-нмя treyresearch.com. Домен Antarctica с именем antarctica.treyresearch.net в именном пространстве DNS интерпретируется в доменном дереве как дочерний домен.
    Инфраструктура Active Directory обычно состоит из леса или даже нескольких лесов с множеством доменов, так что может понадобиться перемещать объекты между доменами или полностью реструктурировать модель доменов.

    Выделенный корневой контроллер домена


    На начальном этапе использования AD рекомендовалось создавать выделенный корневой домен леса. Назначение выделенного корневого домена состоит в администрировании инфраструктуры леса. По умолчанию он содержит одного хозяина операций леса. Корневой домен также содержит уязвимые группы, такие как Администраторы предприятия, Администраторы схемы, которые могут оказывать влияние на весь лес. Теория заключалась в том, что выделенный корневой домен леса повышает безопасность этих функций уровня леса. Выделенный контроллер домена также не устареет и обеспечит более простую передачу владения. В соответствии с этими старыми рекомендациями один глобальный дочерний домен содержит все объекты: пользователи, группы, компьютеры и т. д. Пример такой структуры показан на рис. 12-3.

    Лес из одного домена


    На многих предприятиях больше не создается выделенный корневой домен, поскольку рекомендуется проектировать лес из одного домена. Универсального дизайна для каждой организации не существует.
    Причины таких изменений в рекомендациях:
    1. С любым лесом из множества доменов связаны риски и затраты, которые описаны далее. Для одного домена требуется меньше оборудования, а кроме того, снижается стоимость и степень определенных рисков.
    2. Пока еще нет инструментов, которые позволяли бы предприятию «подрезать и прививать» деревья Active Directory. Иными словами, вы не можете отрезать домен от дерева и трансплантировать его в лес еще одного предприятия. Если бы это было возможно, в выделенном корневом домене леса, который используется для переноса доменов внутри леса и между лесами, не было бы смысла.
    3. Внутри одного домена можно реализовать безопасность с наименьшим уровнем привилегий, которая обеспечивает не меньший (а то и больший) уровень защиты, как и лес с выделенным корнем и дочерним доменом.
    Поэтому проектирование доменов следует начать с леса из одного домена.

    Леса с множеством доменов


    В некоторых сценариях необходим лес из множества доменов. Его не рекомендуется создавать лишь для отражения организационной структуры бизнеса. Эта структура (отделения, департаменты и офисы) со временем будет изменяться.
    Логическая структура службы каталогов не должна основываться исключительно на организационных характеристиках.
    Доменную модель нужно вывести на основе характеристик самих доменов.
    Определенные свойства домена влияют на все объекты в домене, и если их постоянный эффект не соответствует требованиям бизнеса, нужно создавать дополнительные домены. Далее описаны характеристики домена.
    1. Отдельный раздел домена, реплицируемый на все контроллеры домена
    Контекст именования доменов, содержащий объекты пользователей, компьютеров, групп, политик и других доменных ресурсов, реплицируется на каждый контроллер в домене. Для разбиения репликации из соображений сетевой топологии необходимо создавать отдельные домены. Репликация Active Directory является невероятно эффективной и может поддерживать большие домены через подключения с минимальной пропускной способностью.
    Если определенные требования бизнеса ограничивают репликацию определенных данных в размещения с контроллерами доменов, следует либо перестать хранить эти данные в разделе домена, либо создать отдельные домены с целью сегрегации репликации. В таких случаях следует также убедиться, что эти данные не реплицируются глобальным каталогом GC (Global Catalog).
    2. Отдельная политика Kerberos Параметры политики Kerberos по умолчанию в AD DS подходят для большинства предприятий. Для определения
    отдельных политик Kerberos требуются отдельные домены.
    3. Отдельное именное пространство DNS Домен Active Directory использует отдельное доменное имя DNS. Если используется множество доменных имен, то необходимо множество доменов. Однако прежде чем выполнить моделирование доменов службы каталогов на основе требований к DNS-именам, следует учесть затраты и риски, связанные с поддержкой множества доменов.
    Домены, работающие на функциональных уровнях ниже WServer, поддерживают только одну политику паролей и блокировки учетных записей. Поэтому в предыдущих версиях Windows для поддержки множества политик паролей приходилось создавать множество доменов. Эта проблема решена в WServer, поскольку на функциональном уровне можно создавать гранулированные политики паролей.
    При добавлении доменов в лес повышается административная нагрузка и затраты на оборудование. Каждый домен должен поддерживаться хотя бы двумя контроллерами, которые нужно резервировать, защищать и контролировать. Для поддержки доступа к ресурсам доменов на географически распределенном предприятии может потребоваться еще больше контроллеров доменов.
    Дополнительные домены придется создавать для перемещения пользователей между доменами, а этот процесс намного сложней, чем перемещение пользователей между подразделениями. Общие объекты групповой политики и параметры управления доступом потребуется дублировать в каждом домене.
    Мы перечислили лишь некоторые затраты и сложности, связанные со средой из множества доменов. Поддержка множества доменов также влечет за собой дополнительные риски, большинство из которых связано с тем, что домен не определяет периметр безопасности — его определяет лес. Внутри леса администраторы могут причинить ущерб на уровне леса. Существует несколько категорий уязвимости, используя которые, взломанная административная учетная запись или администратор с вредоносными намерениями может инициировать отказ в обслуживании пли нарушить целостность леса.
    Например, администратор в любом домене может создавать универсальные группы, членство в которых реплицируется глобальным каталогом. При создании множества универсальных групп и постоянном заполнении атрибута member чрезмерный объем репликации может привести к отказу в обслуживании на контроллерах в других доменах. Администратор в любом домене также может восстановить устаревший архив каталога, в результате чего могут возникнуть повреждения леса.
    Леса из множества доменов чаще всего создаются в связи с требованиями к репликации контекста именования доменов.
    В лесу из множества доменов имеет смысл создать выделенный корневой домен леса как пустой домен, чтобы он обеспечивал корень доверия для леса.

    Множество деревьев


    Дерево определяется как непрерывное именное пространство DNS. В случае с множеством доменов можно определить для этих доменов непрерывное именное пространство DNS и сформировать отдельное дерево, как показано на рис. 12-4 вверху, либо определить несмежное пространство имен DNS, сформировав таким образом множество деревьев, как показано на рис. 12-4 внизу.

    Непрерывность бизнес-процессов каталогов


    Нужно прежде всего обеспечить поддержку и защиту каталогов и хранилища данных, а также организовать надлежащее управление производительностью каталогов. Доступность, которая является третьей задачей, встроена в операционную модель AD DS. Все контроллеры доменов, кроме контроллеров RODC, могут поддерживать репликацию среди множества равноправных участников. Помещая 2 или несколько контроллеров в один домен, вы тем самым обеспечиваете высокую готовность службы. Отказоустойчивость контроллера домена из 2 машин работать, естественно, не будет. Точнее, будет работать до первой попытки репликации. Процессом поддержки доступности служб каталогов управляют простые правила развертывания.
    Роли контроллера домена и DNS-сервера идеальны для виртуализации с помощью Microsoft Virtual Server 2005 R2 или Hyper-V.

    Административные средства AD DS


    Для выполнения операций, связанных с администрированием AD DS и DNS, можно использовать различные инструменты. В табл. 13-2 приведен список распространённых инструментов, которые применяются для выполнения административных задач, а также указано расположение этих инструментов. Описанные инструменты применяются для сервиса, а не администрирования данных. Многие из этих средств также можно использовать при работе со службами облегченного доступа к AD (AD LDS), поскольку в них применяется тот же код ядра, как и в AD DS.
    Расположение
    AD —
    домены и доверие
    Администрирование доверительных
    отношений, функционального уровня леса и домена, а также суффиксов основных имен пользователей
    Программная группа Администрирование (Administrative Tools)
    Схема Active
    Directory
    Модифицирует схему каталогов AD DS или экземпляров AD LDS. Для использования этой оснастки нужно
    вначале зарегистрировать
    библиотеку Schmmgmt.dll с помощью
    команды Regsvr32.exe
    Настраиваемая консоль ММС
    AD —
    сайты и службы
    Конфигурирует и управляет
    областями действия репликации
    каталогов AD DS и экземпляров AD LDS
    Программная группа
    Администрирование
    AD —
    пользователи
    и компьютеры
    Конфигурирует и управляет
    доменными ролями FSMO, а также компонентами RODC
    Редактирование ADSI
    Запрашивание, просмотр и редактирование объектов и атрибутов каталогов
    CSVDE.exe
    Импортирует данные в каталоги AD DS или экземпляры AD LDS
    Командная строка
    DCDiag.exe
    Выполняет диагностику каталогов AD DS и экземпляров AD LDS
    Dcpromo.exe
    Добавляет и удаляет службу каталогов
    Главное меню (Start),
    Поиск
    DFSRadmin.exe
    Управляет репликацией распределенной файловой системы (Distributed File System Replication),
    которая используется в лесу
    в полном режиме работы Windows
    Server 2008
    Командная строка
    Диспетчер DNS
    Выполняет общую поддержку DNS-серверов
    Программная группа Администрирование
    (Administrative Tools)
    и Диспетчер сервера
    (Server Manager)
    Dnscmd.exe
    Управляет всеми аспектами
    DNS-серверов
    Командная строка
    DSACLS.exe
    Управляет списками контроля доступа объектов каталогов
    Dsadd.exe
    Добавляет типы объектов (пользователи, группы, компьютеры)
    Dsamain.exe
    Монтирует резервные или мгновенные копии хранилища Active Directory (файл .dit) для идентификации
    их содержимого

    Автономная техническая поддержка


    Значительное отличие AD DS от предыдущих версий состоит в трансформации роли контроллера домена в управляемую службу. В предыдущих версиях WS роль контроллера домена была монолитной, то есть для того, чтобы остановить службу, приходилось полностью выключать контроллер домена, и для технического обслуживания базы данных Ntds.dit, содержащей хранилище каталогов, контроллер домена требовалось перезагружать в режиме восстановления служб каталогов (Directory Services Repair Mode). По этой причине отсутствовал способ автоматизации операций технической поддержки базы данных. В результате большинство администраторов доменов вообще никогда не выполняли задачи технической поддержки баз данных, а такой подход неприемлем в управлении системами.
    Все базы данных работают по одним и тем же принципам. Когда добавляется новая запись, база данных предоставляет дополнительное пространство для хранения информации, связанной с записью. Однако при удалении записи выделенное пространство не возвращается — необходимо выполнить операции по сжатию базы данных. Служба AD DS выполняет некоторые автоматические операции сжатия, однако они не восстанавливают утерянное пространство внутри базы данных, а всего лишь перемещают данные с целью ускорения доступа. Чтобы восстановить утерянное пространство, базу данных необходимо переключить в автономный режим и запустить последовательно операции сжатия и дефрагментации.
    И все же в WServer служба AD DS является управляемой, то есть ее можно запускать и останавливать, как и все остальные службы Windows Server. Таким образом, чтобы выполнить операции технической поддержки, контроллер домена больше не нужно перезагружать в режиме восстановления служб каталогов. Кроме того, поскольку служба AD DS теперь ведет себя точно так же, как и любая внутренняя служба, для нее с помощью основных инструментов командной строки можно писать сценарии с целью автоматизации операций дефрагментации и сжатия.
    Отметим, что для остановки службы AD DS контроллер домена должен связаться с еще одним контроллером домена, на котором запущена данная служба, иначе остановить работу службы AD DS невозможно. Служба AD DS автоматически проверяет, имеется ли в наличии хотя бы один доступный контроллер домена, поскольку в противном случае никто не сможет войти в сеть.

    Использование встроенных механизмов защиты каталогов


    Каждая учетная запись, которая хранится в базе данных AD DS, — уникальный объект, поскольку привязана к уникальному идентификатору безопасности SID (Security Identifier). Это означает, что удаленную учетную запись нельзя просто воссоздать заново. Хотя повторно созданная учетная запись на глаз ничем не отличается от исходной, для AD DS она является абсолютно другим объектом и, следовательно, не дублирует свойства и атрибуты ранее удаленного объекта. Членство в группах, пароли, параметры атрибутов и другие свойства будут иными. По этой и другим причинам рекомендуется переназначать учетные записи, а не создавать их заново при изменении пользователями своего расположения в сети. Автоматическое переназначение записи означает, что новый пользователь получит те же права, что и предыдущий обладатель учетной записи. При повторном создании учетной записи достаточно идентифицировать все права доступа, необходимые для данной роли в сети, а при создании учетной записи выполняется намного больше операций.
    Благодаря модели репликации с равноправными участниками данные, содержащиеся в каталоге, достаточно надежно сохраняются, поскольку изменение в одном месте автоматически реплицируется во все остальные места. Тем не менее эта же модель репликации иногда создает проблемы. Если оператор по ошибке удалит объект, то этот объект будет удален и во всем каталоге, а чтобы восстановить его, нужна резервная копия. Однако в AD DS можно восстанавливать информацию без использования архивов, для чего и предусмотрены следующие 3 компонента.
    • Новый компонент аудита доступа к AD DS, который записывает старые и новые значения и позволяет вернуть исходное значение после модификации свойств объекта.
    • Контейнер памятника. Каждый объект, удаляемый из каталога, на определенный период времени оставляет памятник. Пока данные объекта хранятся в контейнере памятника, объект можно восстановить.
    • Возможности архивации и восстановления Windows Server.

    По умолчанию любой новый объект в AD DS можно защитить от удаления в процессе создания. Каждый раз эту защиту для объекта следует включать самому. При создании объектов с помощью командных файлов или в процессе миграции защита от удаления не включается, пока вы сами не назначите защиту в процессе создания. Отметим, что для таких контейнеров, как подразделения, защита включена по умолчанию, поскольку они формируют часть структуры каталогов. После включения защиты вы уже не сможете случайно удалить объект. Кроме того, его нельзя будет перемещать из одного места в другое.
    Эта опция защиты запрещает два разрешения доступа для группы Все (Everyone): Запретить удаление (Deny Delete) и Запретить удаление поддерева Помните, что в AD DS запрет доступа заменяет все разрешения доступа. Для перемещения или удаления защищенного объекта необходимо сбросить флажок защиты от случайного удаления.

    Аудит изменений каталогов


    При выполнении аудита изменений каталогов в WServer каждый раз при модификации объектов записываются старое и новое значения атрибута. Кроме того, поскольку политика аудита в WServer регистрирует 4 подкатегории доступа к службе, ее можно назначать на более детальном уровне, чем в предыдущих версиях Windows Server. Изменения атрибутов контролируются подкатегорией Изменения службы каталогов (Directory Service Changes). Эта политика регистрирует операции создания, модификации, перемещения и восстановления объектов. В журнале событии служб каталогов (Directory Services Event Log) каждой операции присваивается определенный код.
    Благодаря этому компоненту журнал событий преобразуется в систему хранения записей об изменениях каталога, позволяя поддерживать множество записей об изменениях, внесенных в каталог. Эту функцию также удобно использовать для исправления некорректно выполненных модификаций.
    При модификации объекта в журнал записываются два события. В нервом из них указывается старое значение, во втором — новое. Эти события используются для отмены некорректных модификаций.

    Защита с помощью архивации и восстановления Windows Server

    Теневые копии


    Если программе архивации (включая систему архивации данных WServer и сторонние приложения) нужен доступ к файлу, используемому в текущий момент другим приложением, компонент Volume Shadow Copy создает теневую копию файла в его текущем состоянии и предоставляет доступ к этой теневой копии. Поскольку теневые копии хранят лишь изменения файлов, требования к размеру хранилища значительно снижаются. В проводнике Windows ПКМ том и примените Настроить теневые копии.
    Теневыми копиями можно управлять в командной строке с помощью инструмента VSSAdmin. Например, для создания теневой копии тома С:\ запустите от имени администратора следующую команду:
    vssadmin create shadow /For=C:
    Чтобы просмотреть хранилище, выделенное для теневых копий, запустите команду:
    vssadmin list shadowstorage
    Для просмотра доступных теневых копий и времени их создания запустите команду:
    vssadmin list shadows
    Эта команда перечисляет идентификаторы теневых копий, которые нужно использовать для обращения к ним. Например, для обращения к теневой копии с идентификатором следует запустить команду:
    vssadmin revert shadow /

    Система архивации данных WServer


    У WSBackup возможностей архивации из сети нет. Для архивации с помощью GUI-системы WServer нельзя использовать подключенные сетевые диски, а только такие пишущие носители, как переносные жесткие диски. Кроме того, в WServer для архивации также включена поддержка виртуальных жестких дисков VHD. Все VHD хранятся в централизованном месте на одном переносном диске. Таким образом, вы сможете комбинировать резервные копии на одном диске, не используя множество переносных дисков, по одному для каждой защищенной системы. Система архивации данных WServer копирует весь том диска (например, том с установленной системой Windows) в файл .vhd на втором локальном диске. После архивации можно восстановить весь том или отдельные файлы из него. Если система Windows не запускается (например, по причине отказа системного тома), компьютер можно запустить из резервной копии, наладить и запустить операционную систему меньше чем за час. Версия Microsoft Virtual Server 2005 R2 SP1 содержит инструмент командной строки VHDMount для монтирования файлов .vhd, чтобы можно было просмотреть их содержимое. Эта утилита обеспечивает великолепный способ извлечения файлов из архива WS без инсталляции Virtual Server 2005 R2 SP1.
    В случае выделения для Windows Server Backup локального диска и достижения им своего предела система архивации будет автоматически перезаписывать старые данные резервных копий.
    При использовании удаленной общей папки в ней может быть сохранена только одна резервная копия, и каждое резервное копирование полностью ее переписывает.
    Добавь компоненты. Теперь вы можете получить доступ к Системе архивации WS из папки Администрирование меню Пуск или запустить инструмент архивации wbadmin из командной строки или сценария.
    При разовой архивации на странице Укажите дополнительный параметр оставьте параметр по умолчанию Копирующая архивация VSS (VSS Сору Backup) для защиты файлов журнала VSS, которые могут использоваться другими приложениями архивации. Если вы не используете еще одно приложение для архивации данных, выберите опцию Полная архивация VSS (VSS Full Backup).
    Система Windows создает в корне носителя архивов папку WindowsImageBackup. Внутри нее создается папка с текущим именем компьютера. Затем создается папка Catalog, содержащая файлы GlobalCatalog и BackupGlobalCatalog, а также папка "Backup ---» содержащая файл образа диска .vhd. В состав этой подпапки входит набор файлов XML с хронологией резервного копирования, каталогом и деталями системной конфигурации носителя, а также один или более файлов VHD (Virtual Hard Disk — виртуальный жесткий диск), которые представляют собой практически точные копии подвергавшихся архивации томов сервера.
    После запуска Мастера расписания архивации конечный диск с резервными копиями не будет отображаться в Проводнике Windows. Задание архивации находится в узле Диспетчере сервера\Конфигурация\Планировщик заданий\Библиотека планировщика заданий\Microsoft\Windows\Backup. Для выполнения архивации это задание вызывает инструмент Wbadmin.
    Установка компонента в WS Core:
    cd \
    Start /w ocsetup.exe WindowsServerВасkup

    AD


    Использование специальных инструментов для получения доступа к данным памятников в каталоге не всегда является оптимальным методом восстановления данных. Например, объекты, восстанавливаемые из контейнеров памятников, содержат не все исходные атрибуты. Поэтому, для того чтобы восстановить объект, нужно заранее знать содержимое и атрибуты, назначенные объекту перед удалением. При восстановлении данных из архива и их повторном назначении в каталоге сразу восстанавливаются все атрибуты объекта. Однако усложняется сам процесс восстановления.
    Кроме того, в предыдущих версиях WSвосстановление объектов в AD DS выполнялось фактически наугад, поскольку перед восстановлением нельзя было просмотреть объекты внутри набора архивных данных.
    Восстановить разные наборы архивов на различных контроллерах доменов по-прежнему нельзя и невозможно просмотреть содержащиеся в них данные.
    В WServer появилась новая утилита AD DS Database mounting, которая позволяет просмотреть содержимое набора архивных данных перед восстановлением.
    В AD выполняется несколько операций архивации и восстановления.
    1. Архивирование всего сервера, включая его операционную систему.
    2. Архивирование лишь данных состояния системы (System State Data), включая информацию о конфигурации сервера и хранилище Ntds.dk.
    3. Восстановление неполномочных данных, то есть данных, которые будут добавлены на контроллер домена и обновлены в процессе репликации с равноправными участниками, когда контроллер домена будет вновь подключен к сети. И восстановление полномочных данных, то есть информации, которая будет добавлена на контроллер домена и обновит все остальные контроллеры доменов в процессе репликации с равноправными участниками, когда контроллер домена будет вновь подключен к сети.
    4. Установка контроллера домена с носителя IFM (Install From Media). Используется копия файла Ntds.dit с еще одного контроллера домена, и таким образом снижается объем трафика репликации, необходимой для создания контроллера домена в процессе установки.
    Существует несколько способов применения наборов архивных данных при работе с контроллерами доменов WServer.
    Резервные копии не являются изолированными. В совокупности они содержат критически важные тома. Далее приведен список томов на контроллере домена:
  • системный;
  • загрузочный;
  • с общим ресурсом SYSVOL;
  • с базой данных AD DS;
  • с журналами AD DS.
    1. Архивацию можно выполнять автоматически и вручную.
    2. Резервные копии нельзя создавать на магнитных лентах или в динамических томах, а только на сетевых дисках, переносных жестких дисках, отконфигурированных как основные тома, а также на DVD и CD.
    3. Архивировать отдельные файлы невозможно, так как система архивации WSподдерживает лишь полную архивацию томов.
    4. Операторы архива не могут создавать резервные копии по расписанию. В WServer этой привилегией располагают лишь члены локальной группы Администраторы. В большинстве случаев это означает членство в группе Администраторы домена на контроллерах домена.
    5. В случае выхода сервера из строя для восстановления системы необходимо использовать локальную копию среды восстановления Windows Recovery Environment (WinRE). Среду восстановления WinRE можно установить локально или загрузить с установочного носителя WServer.
    Для того чтобы упростить процесс восстановления создаваемых контроллеров доменов, воспользуйтесь следующими рекомендациями.
    1. Запустите контроллер домена как одноцелевой сервер и не добавляйте на этот сервер никакие другие роли, за исключением DNS.
    2. Запускайте контроллеры домена как виртуальные машины в среде Hyper-V системы WServer. Контроллеры доменов являются идеальными кандидатами на виртуализацию в Hyper-V, поскольку для управления входом в сеть им в основном требуются полоса пропускания сети и возможности обработки. Даже если домен содержит тысячи пользователей, для входа которых в сеть по утрам и выхода вечером требуются ресурсы процессоров, рекомендуется выполнить виртуализацию контроллеров домена и назначить им больше ресурсов.
    3. Не храните на контроллере домена другие данные, несмотря даже на то, что базу данных AD DS и журналы можно хранить в отдельных томах, если база данных AD DS содержит очень много объектов.
    4. Преобразуйте установочный носитель Windows в файл ISO и обеспечьте к нему доступ для хостов Hyper-V на случай восстановления контроллеров домена. В качестве альтернативы установите на каждом созданном контроллере домена среду восстановления WinRE. Для этого вам потребуется инструментарий WAIK (Windows Automation Installation Kit).
  • Обеспечьте защиту пароля режима восстановления служб каталога (Directory Services Restore Mode). Этот пароль должен использоваться для восстановления данных на контроллере домена и для него необходимо обеспечить защиту.
    Например, в инфраструктуре WServer 2008 R2 Active Directory, AD DS обладает собственным набором одиночных точек отказа, каковыми являются ее роли FSMO (Flexible Single Master Operations — гибкие операции с одним мастером). Эти роли выполняют эксклюзивную функцию для всего леса Active Directory или для какого-нибудь одного домена, и если контроллер домена, на котором развернута роль AD DS, дает сбой, роли FSMO становятся недоступными. Хотя роли FSMO являются одиночными точками отказа, процесс восстановления контроллера домена все равно может быть очень простым и безболезненным при условии разработки должного плана по их резервному копированию и восстановлению.

    Архивация данных состояния системы


    На сервере с ролью AD DS имеются следующие данные состояния системы:
    • реестр;
    • база данных COM-Class Registration;
    • загрузочные файлы;
    • системные файлы под защитой системы Windows Resource Protection;
    • база данных доменных служб AD (AD DS);
    • каталог SYSVOL.

    При установке других ролей сервера данные состояния системы будут включать первые 4 объекта из числа перечисленных, а также следующие файлы:
    • для AD CS — файл базы данных AD CS;
    • для компонента Кластер отказоустойчивости (Failover Cluster) — файл с информацией о службе кластера;
    • для роли Веб-сервер — файлы конфигурации IIS.

    Информация о состоянии системы играет важную роль, так как ее нельзя захватить с помощью системы архивации Windows Server. Зато ее можно восстановить, поскольку система архивации WS поддерживает три режима восстановления:
    • полное восстановление сервера;
    • восстановление лишь данных состояния системы;
    • восстановление отдельных файлов и папок.

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

    Создание наборов данных для установки с носителя


    Если вам нужно защитить лишь данные состояния системы, воспользуйтесь утилитой командной строки Ntdsutil.exe. Для этого в Ntdsutil.exe необходимо применить переключатель IFM, чтобы захватить информацию в процедуру установки с носителя (Install From Media). Если установка предназначена для контроллера RODC, утилита автоматически отсечет «секреты» AD DS от данных, чтобы создать безопасный носитель установки.
    При размещении контроллеров домена в крупных сетях для создания исходного содержимого каталога можно использовать переносной носитель — это избавляет от необходимости выполнять репликацию содержимого каталога во время установки контроллеров домена и позволяет не занимать полосу пропускания. Для этого применяется процедура IFM (Install From Media). Чтобы создать носитель, необходимо выполнить команду Ntdsutil.exe с дополнительной командой IFM. Носитель для установки можно создать только с помощью инструмента Ntdsutil.exe.
    Интерпретатор командной строки Ntdsutil.exe можно использовать интерактивно или с помощью командной строки, которая предоставляет все опции. В табл. 13-4 описаны различные доступные опции в подкоманде IFM интерпретатора Ntdsutil.exe
    Тип контроллера домена
    Опция
    Описание
    Пишущий контроллер домена
    Create Full конечная_папка
    Создает носитель для стандартного контроллера домена или экземпляра AD LDS в конечной папке
    RODС
    Create RODС конечная папка
    Создает безопасный носитель для контроллера RODC в конечной папке
    Пишущий контроллер домена с данными SYSVOL
    Create SYSVOL Full конечная_папка
    Создает в конечной папке носитель для стандартного контроллера домена вместе с папкой SYSVOL
    Контроллер RODC с данными SYSVOL
    Create SYSVOL RODC конечная_папка
    Создает в конечной папке носитель для контроллера домена RODC вместе с папкой SYSVOL

    Полная разовая архивация системы


    Полная архивация системы выполняется двумя способами: интерактивно и в качестве запланированного задания. В обоих случаях можно использовать графический интерфейс или командную строку. Начнем с графического интерфейса. Прежде чем создать резервные копии, необходимо установить систему архивации данных Windows Server. Чтобы подключиться к Server Core, на панели действий используйте опцию Подключение к другому компьютеру.
    1. Войдите на контроллер домена с использованием учетных данных администратора домена и в программной группе Администрирование (Administrative Tools) запустите средство Система архивации данных Windows Server
    2. На панели Действия щелкните Однократная архивация (Backup Once ). Запустится Мастер однократной архивации (Backup Once Wizard).
    3. Если мастер запущен впервые, выберите опцию Другие параметры (Different Options) и щелкните Далее, а в противном случае выберите Те же параметры (The Same Options).
    4. Выберите рекомендуемый параметр Весь сервер (Full Server)
    Отметим, что вы также можете указать параметр Настраиваемый (Custom), однако в таком случае будут исключены лишь некоторые тома, а не папки. Помните, что ваши контроллеры домена должны быть одноцелевыми серверами, следовательно, нет необходимости исключать какие-либо тома. Но если вы выполняете архивацию на локальный диск, этот том нужно исключить из архивации. Отметим, что при использовании настраиваемого параметра можно установить флажок Включить восстановление системы (Enable System Recovery), и все данные, необходимые для полного восстановления системы, будут захвачены автоматически.
    Вы можете указать DVD, CD, локальные диски, локально подключенные переносные жесткие диски, а также общие сетевые ресурсы.
    5. На странице Укажите дополнительный параметр (Specify Advanced Option) выберите параметр Полная архивация VSS (VSS Full Backup) и щелкните Далее.
    Параметр копирующей архивации по умолчанию не удаляет файлы журналов из томов и используется только в случае применения в системе еще одного продукта архивации, такого как Microsoft Data Protection Manager. Эти файлы потом часто применяются другим инструментом архивации. Если система архивации данных WSявляется единственным средством архивации, задействуйте полную архивацию VSS.
    Выполняется в командной строке с помощью утилиты Wbadmin.exe. Для полной установки командную строку нужно запустить от имени администратора:
    wbadmin start backup -allcritical -backuptarget:место_размещения - quiet
    При использовании параметра -quiet нет необходимости вводить букву Y, чтобы продолжить операцию.
    Чтобы инициировать архивацию диска С на диске L, в командной строке запустите от имени администратора следующую команду:
    wbadmin start backup -backupTarget:L: -include:C: -quiet
    Чтобы выполнить архивацию состояния системы, введите команду Wbadmin с параметрами start systemstaterecovery.
    В состав WServer 2008 R2 включено несколько командлетов PowerShell для управления программой Windows Server Backup. Эти командлеты PowerShell устанавливаются с опцией командной строки средства Windows Server Backup. В отличие от утилиты wbadmin.ехе, командлеты PowerShell для Windows Server Backup предлагают более высокую гибкость при управлении удаленными системами. Большая часть прежних исполняемых файлов командной строки теперь заменены командлетами PowerShell, и администраторам следует учитывать это при разработке и документировании задач резервного копирования.
    Одной из функций, не включенных в текущий набор командлетов, является возможность выполнения восстановления данных. Его по-прежнему нужно выполнять с помощью оснастки ММС или утилиты командной строки wbadmin.ехе.

    Планирование архивации


    GUI:
    1. Войдите на контроллер домена как администратор домена и в программной группе Администрирование щелкните Система архивации данных Windows Server. Щелкните команду Расписание архивации (Backup Schedule).
    2. Выберите тип конфигурации Весь сервер (рекомендуется). В GUI-мастере планирования архивации при использовании настраиваемого параметра нельзя применить опцию Включить восстановление системы.
    3. Когда вы щелкнете Далее, мастер сообщит, что конечный диск будет отформатирован. Щелкните Да. Системе архивации данных WServer необходим монопольный доступ к конечному устройству. Поэтому при создании резервной копии по расписанию диск должен быть отформатирован.
    4. На странице Метка конечного диска (Label Destination Disk) нужно запомнить метку, которую использует система архивации данных Wserver для этого диска. При замене дисков нужно знать, на каком из них хранятся резервные копии. Этот диск необходимо соответственно пометить.
    Эту операцию также можно выполнить в командной строке с помощью утилиты Wbadmin.exe. В таком случае командную строку необходимо запустить от имени администратора и использовать несколько команд. Начните с идентификации ID конечного диска:
    wbadmin net disks >diskidentifers.txt
    Откроется список всех подключенных к системе дисков. Для локализации диска команда Wbadmin.exe использует идентификаторы дисков или глобальные уникальные идентификаторы GUID. Для захвата GUID-идентификатора диска введите команду:
    notepad diskidentifiers.txt
    Выделите идентификатор нужного диска, включая скобки, и скопируйте его в буфер обмена. Теперь вы можете создать расписание. Введите следующие команды:
    wbadmin enable backup -addtarget: id_диска -schedule:время -include:исходные_диски
    В качестве id диска введите скопированный GUID-идентификатор. Укажите время запуска архивации в 24-часовом формате НН:ММ. Если архивацию нужно выполнять несколько раз в сутки, укажите время каждого запуска, разделяя вводимые значения запятыми. В качестве исходных дисков укажите буквы дисков, которые требуется защитить.
    < -schedule:21:00,06:00 -included:C:
    Данную процедуру можно использовать для генерирования командных файлов, создающих эти задания, однако результаты необходимо поместить в текстовый файл, иначе вы не получите метки для переносных дисков.
    Отметим, что при каждом запуске архивации конечный диск будет форматироваться заново. Если необходимо более детальное расписание или вы хотите выполнять архивацию ежедневно, а не еженедельно, можете модифицировать эту задачу в Планировщике заданий, создав ее с помощью утилиты Wbadmin.exe.

    Активное восстановление


    Наборы архивных данных восстанавливают лишь те данные, которые они содержат. Поэтому процедуру восстановления важно протестировать в самых различных сценариях.
    При работе с контроллером домена используются несколько сценариев восстановления:
    1. восстановление неполномочных данных в каталоге с целью снижения объема репликации, необходимой для обновления контроллера домена, который некоторое время был отключен от сети;
    2. восстановление полномочных данных по причине повреждения данных в каталоге;
    3. восстановление всего контроллера домена из архива.
    Хотя в WServer службой AD DS можно управлять так же, как и другими службами, данные системы нельзя восстановить на работающем контроллере домена, необходимо перезагрузить сервер и запустить среду восстановления WinRE либо перезагрузить сервер в режиме восстановления служб каталогов (Directory Services Restore Mode DSRM). Каждый метод поддерживает различные процедуры восстановления: режим DSRM восстановление данных в каталоге, а среда восстановления WinRE — восстановление целой системы.
    Кроме того, можно выполнить принудительную перезагрузку в режиме DSRM, изменив порядок запуска в загрузочном файле операционной системы. Для этого выполняется команда Bcdedit.exe. Чтобы изменить порядок загрузки, откройте командную строку от имени администратора и введите:
    bededit /set safeboot dsrepair
    Затем для стандартного запуска сервера введите такую команду:
    bededit /deletevalue safeboot
    Если операцию требуется выполнить только один раз, проще использовать клавишу F8 в процессе загрузки системы.
    Помните, что для периодической смены пароля DSRM вначале необходимо загрузить систему в режиме DSRM, а затем использовать стандартные методы изменения пароля. Войдите в систему с помощью учетной записи и пароля DSRM.

    Восстановление из полного архива


    Предыдущие версии файлов можно восстановить из архива или последней теневой копии, выполнив следующие действия.
    В Проводнике Windows щелкните правой кнопкой мыши файл, который хотите восстановить, и примените команду Восстановить прежнюю версию. Откроется диалоговое окно свойств с выбранной вкладкой Предыдущие версии.
    Из архива: на странице Выберите тип восстановления выберите одну из следующих трех опций:
    • Файлы и папки
    • Приложения Система архивации данных WSможет регистрировать данные приложений. Эта опция позволяет выборочно восстанавливать такие данные.
    • Тома Позволяет восстановить весь том, но том операционной системы восстановить с помощью этой опции нельзя.

    Если файлы полной резервной копии сервера находятся на переносном диске, подключите его к серверу, прежде чем начать процесс восстановления. В противном случае потребуется перезагрузить сервер. Если эти файлы находятся на сетевом диске, запомните путь к нему. Кроме того, вам понадобится установочный DVD-диск WServer. Полное восстановление сервера можно выполнять с помощью графического интерфейса или командной строки.
    Для полного восстановления сервера с помощью графического интерфейса выполните следующее (эта процедура применима к полной установке и инсталляции ядра сервера (Server Core)).
    1. Загрузитесь с DVD-диска. Щелкните ссылку Восстановление системы. В диалоговом окне Параметры восстановления системы щелкните пустое место, чтобы снять выделение операционных систем для восстановления.
    2. В секции выбора средства восстановления выберите восстановление Windows Complete PC. Если архив хранится на удаленном сервере, в окне предупреждения щелкните кнопку Отмена.
    4. Выберите опцию Восстановить другой архив (Restore A Different Backup). Если архив хранится на локальном компьютере, выберите размещение архива. Если архив хранится в общем сетевом ресурсе, щелкните кнопку Дополнительно и выберите опцию Поиск архива в сети. Выберите архив для восстановления.
    5. Если вы хотите заменить все данные во всех томах, на странице Выберите тип восстановления архива (Choose How To Restore The Backup) выберите опцию Форматировать и создать разделы дисков (Format And Repartition Disks).
  • Чтобы в процессе восстановления не были удалены или заново созданы тома, выберите опцию Исключить диски, укажите, какие диски хотите исключить из процесса восстановления, и щелкните ОК.
    Система Windows восстановит архив, переписав восстанавливаемые тома.
    Для полного восстановления сервера с помощью командной строки выполните следующие действия (эта процедура применяется как к полной установке, так и к машине с ядром сервера (Server Core)).
    1. Всё также как для GUI
    2. В секции выбора средства восстановления выберите инструмент Командная строка.
    3. В командной строке введите команду diskpart
    4. В командной строке diskpart введите команду list vol
    Идентифицируйте в списке том, который соответствует расположению полной резервной копии сервера, которую вы хотите восстановить. Буквы дисков в среде восстановления WinRE необязательно соответствуют внешнему оформлению томов в WServer.
    8. Введите команду exit и нажмите клавишу Enter.
    9. В командной строке Sources введите приведенную ниже команду и нажмите клавишу Enter:
    whadmin get versions -backuptarget:диск -machine:имя_сервера
    Например, для перечисления доступных резервных копии на диске D
    компьютера SERVER10 введите такую команду:
    wbadmin get versions -backuptarget:D: -machine:SERVER10
    Запомните информацию идентификатора версии, поскольку в следующей команде потребуется указать точное имя.
    10. В командной строке введите
    wbadmin start systemstaterecovery -version:время -backuptarget:диск
    -machine:имя_сервера -quiet
    Например, для восстановления состояния системы из архива, датированного 15 февраля 2008 года и расположенного на диске D компьютера SERVER10, введите такую команду:
    wbadrnin start sysrecovery -version:02/15/2008-19:38 -backuptarget:d:
    -machine:server10 -restoreallvolumes -quiet
    При использовании параметра -quiet отпадает необходимость в подтверждении операции.
    11. После завершения процесса восстановления сверните окно команды и в диалоговом окне Параметры восстановления системы щелкните кнопку Перезагрузка. Сервер должен перезагрузиться и запуститься в стандартном режиме.

    Службы облегченного доступа к каталогам


    (AD Lightweight Directory Services). Роль AD LDS является, по сути, независимой версией службы AD. Ее называют также режимом приложений AD (AD Application Mode, ADAM).Она обеспечивает поддержку приложений каталогов. Компонент AD LDS фактически является поднабором AD DS, поскольку оба компонента основаны на одном коде ядра. Каталог AD LDS хранит и реплицирует только данные приложений. Его часто используют приложения, которым необходимо хранилище каталогов, но не требуется реплицировать информацию на все контроллеры доменов. Кроме того, службы AD LDS дают возможность развернуть настраиваемую схему для поддержки приложения без модификации схемы AD DS. Роль AD LDS облегченная. Она поддерживает множество хранилищ данных в одной системе, чтобы каждое приложение можно было развернуть с собственным каталогом, схемой, назначенным облегченным протоколом доступа к каталогам LDAP (Lightweight Directory Access Protocol), портами SSL и журналом событий приложения. Роль AD LDS не зависит от служб AD DS, поэтому ее можно использовать в автономной среде либо рабочей группе. Однако в доменных средах эта роль может использоваться службами AD DS для проверки принципалов безопасности системы Windows (пользователей, групп и компьютеров). Кроме того, роль AD LDS можно применять для реализации служб проверки подлинности в открытых сетях (например, в экстрасети). При использовании данной роли в такой ситуации угроза безопасности меньше, чем при использовании AD DS. Из пяти различных технологий AD в WServer AD LDS больше всего похожи на доменные службы AD DS. Дело в том, что службы AD LDS представляют собой всего лишь поднабор функций AD DS. Обе службы используют один код ядра и предоставляют практически одинаковый набор компонентов.Службы сертификации AD и инфраструктура открытых ключейMicrosoft реализовала поддержку сертификатов и в своем браузере Internet Explorer, и в сервере IIS, разработала собственный сервер сертификатов, а также продукты, которые позволяют хранить сертификаты пользователя, его закрытые ключи и пароли защищенным образом. Организации могут использовать службы сертификации AD CS, чтобы создать центр сертификации для выдачи цифровых сертификатов, которые привязывают объект идентификации пользователя, устройства либо службы к соответствующему частному ключу. Сертификаты можно использовать для проверки подлинности пользователей, компьютеров и веб-приложений, поддержки проверки подлинности смарт-карт, а также для поддержки таких приложений:
    • защищенных беспроводных сетей,
    • виртуальных частных сетей VPN,
    • протоколов для обеспечения защиты данных (IPsec),
    • шифрующей файловой системы EFS (Encrypting File System),
    • цифровых подписей и многих других.

    AD CS предоставляют эффективный и безопасный способ выдачи сертификатов и управления ими. С их помощью можно делать это для внешних сообществ. В таких случаях следует связать службы AD CS с каким-нибудь известным внешним центром сертификации (СА), который подтвердит вашу подлинность. Во внутренних сетях службы AD CS можно интегрировать со службами AD DS, чтобы пользователи и компьютеры автоматически получали сертификаты.
    AD DS, будучи каталогом сетевой операционной системы (NOS), изначально предназначены для проверки подлинности и авторизации в пределах корпоративной сети, службы AD CS, как и остальные три технологии AD, предоставляют эти службы во внутренней и внешней сетях (рис. 15-1).
    Сертификат содержит имя сервера, название организации и центра сертификации, который выдал сертификат. Сертификат SSL работает с браузером, поскольку такие обозреватели, как Microsoft Internet Explorer и Firefox, уже содержат список доверенных центров сертификации, которые управляют процессом сертификации (рис. 15-2). Список доверенных центров сертификации автоматически обновляется механизмами обновления ОС. В Vista и WServer это обновление управляется параметром групповой политики, который но умолчанию отключен. В предыдущих версиях Windows обновление Доверенные корневые сертификаты (Trusted Root Certificates) являлось компонентом Windows, доступ к которому можно было получить через панель управления.
    При выдаче собственных сертификатов на компьютеры пользователей, которые будут их применять, необходимо включить нашу организацию в качестве доверенного центра сертификации. Это можно сделать на компьютерах пользователей в вашей организации, поскольку вы ими управляете, однако для других пользователей выполнение этой задачи становится проблематичным. В этом одна из причин создания такой архитектуры PKI. По сути, каждый член инфраструктуры открытых ключей находится в иерархической цепочке, которая заканчивается центром сертификации высшего уровня. Этот центр сертификации в конечном счете отвечает за все включенные в цепочку сертификаты. Например, если вы получаете сертификат от своей организации, которая, в свою очередь, получила свой главный сертификат от доверенного коммерческого центра сертификации, как показано на рис. 15-3, ваш сертификат автоматически станет доверенным, поскольку каждый браузер уже доверяет этому коммерческому центру сертификации. Следовательно, внешний центр сертификации должен использовать строгую программу подтверждения подлинности. В противном случае он недолго продержится на рынке.
    Список доверенных центров сертификации в Vista и WServer обновляется параметрами групповой политики, которые включены по умолчанию.
    Стенд:
    SERVER01 контроллер домена contoso.com.
    WServer Enterprise Edition с именем SERVER03, являющийся рядовым сервером в домене contoso.com. Эта машина будет управлять центрами сертификации AD CS. В идеале, на компьютер также следует добавить диск D для хранения данных AD CS. Рекомендуется выделить для этого диска 10 Гбайт.
    WServer Enterprise Edition с именем SERVER04, являющийся рядовым сервером в домене contoso.com. Эта машина будет управлять выдачей сертификатов AD CS. На компьютер также следует добавить диск D для хранения данных AD CS. Рекомендуется выделить для этого диска 10 Гбайт.
    Этих машин будет достаточно для эффективного тестирования базовой установки и конфигурации AD CS. Для тестирования всех возможностей AD CS требуется пять компьютеров, но большинство читателей не располагают такими возможностями.
    С помощью AD CS в WServer можно поддерживать следующие сценарии с использованием сертификатов.
    1. Возможность шифровать все удаленные подключения. В WServer добавлены подключения VPN: IPSec и SSTP (Secure Sockets Tunnelling Protocol). Оба типа подключений используют сертификаты для проверки подлинности начальной и конечной точек коммуникации. В WServer включена поддержка стандартного протокола безопасности электронной почты (Secure Multipurpose Internet Mail Extensions, S/ MIME ).
    2. Возможность защитить все данные от фальсификации с помощью AD RMS в WServer можно защитить от подделки и несоответствующего использования всю генерируемую информацию.
    На веб-сайте Microsoft TechNet содержится намного больше информации об инфраструктуре PKI в WS2003, чем в WServer.

    Компоненты службы AD CS


    Центры сертификации. Поскольку структура PKI построена в виде иерархии, службы AD CS поддерживают корневые и дочерние центры сертификации СА (Certification Authority). Корневой центр сертификации выдает сертификаты подчиненным центрам сертификации, позволяя им выдавать сертификаты пользователям, компьютерам и службам.
    Подчиненный центр сертификации может выдавать сертификаты только в случае подлинности своего собственного сертификата. По истечении срока действия этого сертификата подчиненный СА должен запросить обновление сертификата в своем корневом СА. В связи с этим сроки действия корневых СА часто намного больше, чем у подчиненных СА. В свою очередь, срок действия сертификатов подчиненных центров сертификации обычно больше, чем сроки действия сертификатов пользователей, компьютеров и служб.
    Подача заявок АС в Веб. С помощью подачи заявок в Веб пользователи могут подключаться к СА через веб-обозреватель для запроса сертификатов, подачи заявок для смарт-карт и получения списков отзыва сертификатов CRL. Системы, использующие PKI, опрашивают серверы СА для получения списков CRL каждый раз при предъявлении сертификата.
    Сетевой ответчик.
    Служба подачи заявок сетевых устройств Устройства, которые используют низкоуровневые операционные системы, например маршрутизаторы и коммутаторы, также могут принимать участие в инфраструктуре PKI через службу NDES (Network Device Enrollment Service) с помощью протокола SCEP (Simple Certificate Enrollment Protocol), разработанного компанией Cisco Systems, Inc. Эти устройства обычно не участвуют в каталоге AD DS и поэтому не располагают учетными записями AD DS.
    Эти 4 компонента формируют ядро службы AD CS в WServer.

    Независимые СА и центры сертификации предприятия


    Службы AD CS поддерживают два типа СА:
    Автономные СА - центр сертификации, который необязательно интегрировать в службу каталогов. Независимые центры сертификации устанавливаются на рядовых или независимых серверах (в рабочей группе). Клиентами независимого СА необязательно могут быть члены каталога AD DS.
    Автономные центры сертификации часто используются в качестве внутренних корневых СА. Выдача и подтверждение сертификатов выполняются вручную, а сами сертификаты основаны на стандартных шаблонах, которые нельзя модифицировать.
    В качестве примеров можно привести корневые центры сертификации и СА, локализованные в периметре сети и предоставляющие услуги в Интернете.
    СА предприятия - центр сертификации, интегрируемый в службу каталогов AD DS и в связи с этим автоматически выпускают и подтверждают сертификаты, запрашиваемые членами каталога.
    Расширенные шаблоны таких сертификатов можно редактировать в соответствии с требованиями. Все ключи шифрования защищены с помощью интеграции каталогов.
    Табл. 15-1. Сравнение независимых СА и центров сертификации предприятий
    Компонент
    Независимый
    Предприятие
    Публикация конфигурации СА в каталогах доменных служб AD
    Опциональная
    Обязательная
    Интеграция данных сертификатов СА с лесами AD DS
    Опциональная (выполняется вручную)
    Обязательная и автоматическая
    Обязательная и автоматическая, с включением списков Delta CLR
    Публикация CLR в лесах AD DS
    Публикация леса AD DS, назначаемая на уровне шаблона как его атрибут
    Нет данных
    Поддерживается
    Подача заявок в Веб для запроса и подтверждения сертификатов
    Поддерживается
    Поддерживается
    ММС-консоль управления сертификатами (Certificate Microsoft Management Console) для запроса и подтверждения сертификатов
    Нет данных
    Поддерживается
    Запросы сертификатов через HTTP и HTTPS
    Поддерживается
    Поддерживается
    Запросы сертификатов через удаленный вызов процедур (Remote Procedure Call, RPC) в модели DCOM (Distributed Component Object Model)
    Нет данных
    Режим по умолчанию
    Шаблоны V1 с настраиваемыми идентификаторами объектов (Object Identifier, OID) в качестве источника сертификатов
    По умолчанию
    Нет данных
    Настраиваемые шаблоны V2 и V3 как источник сертификатов. Шаблоны также можио дублировать
    Нет данных
    По умолчанию
    Ввод данных пользователем в процессе создания сертификата
    Вручную
    Данные извлекаются из AD DS.
    Поддерживаемые методы подачи заявок
    Автоматически или в режиме очереди для всех шаблонов
    Автоматически или в режиме очереди и применяется на основе шаблона
    Процесс подтверждения сертификата
    Вручную
    Вручную или автоматически проверяются подлинность и контроль доступа AD DS
    Публикация сертификатов
    Вручную для клиента или СА. Можно
    выполнять в AD DS, но только через настраиваемый модуль политики
    Зависит от типа сертификата и параметров шаблона, однако может
    выполняться автоматически в хранилищах
    сертификатов клиента
    и публиковаться в AD DS
    Публикация сертификатов и управление с помощью AD DS
    Нет данных
    Поддерживается
    Параметры развертывания
    Контроллер домена, рядовой и независимый сервер
    Только контроллер домена или рядовой сервер

    Иерархия центров сертификации


    Поскольку иерархия СА основана на цепочке сертификатов, при взломе любого корневого СА или центра сертификации высшего уровня автоматически взламываются все его сертификаты. Обычно для безопасности создается связанная иерархия СА и члены высшего уровня связанной архитектуры отключаются от сети.
    Следует также учесть размер и географическое распределение сети. Кроме того, необходимо идентифицировать доверительную связь между центрами сертификации и обладателями сертификатов. Помните, что сертификат каждый раз необходимо подтверждать с помощью списка CLR или сетевого ответчика. Поэтому для использования сертификатов требуются сетевые коммуникации.
    1. Единая связанная иерархия с одним корневым центром сертификации создается только в тех случаях, когда корневые СА нельзя взломать ни при каких обстоятельствах (центра сертификации предприятия, раздающего сертификаты, нет).
    2. Иерархия из двух уровней с корневым центром сертификации и подчиненными СА для защиты корневого СА создается, когда для организации не нужно создавать более сложную иерархию. В этой модели корневой центр сертификации можно отключить от сети для защиты.
    3. Иерархия из 3 уровней с корневым СА, промежуточными СА и СА выдачи сертификатов создается в тех случаях, когда для СА выдачи сертификатов требуется более высокий уровень безопасности и готовности, а административная модель, популяция пользователей и географическая область требуют создания дополнительного уровня. Часто в этой модели для поддержки различных политик в разных средах используется множество промежуточных центров сертификации. При использовании этой модели отключите от сети корневой и промежуточные центры сертификации для обеспечения их безопасности.
    4. Более трех уровней рекомендуется создавать только в очень сложных средах, где требуются самый высокий уровень безопасности и постоянная защита инфраструктуры СA.
    Как видите, чем больше уровней в иерархии, тем выше уровень сложности процессов управления и администрирования. Однако по мере усложнения иерархии также нужно повышать уровень безопасности. Чаще всего для развертывания AD CS используется архитектура из двух или нескольких уровней. По этой причине данные СA являются отличными кандидатами на виртуализацию с помощью Hyper-V в WServer.
    По возможности, используйте смарт-карты для входа администраторов в сеть. После установки службы AD CS эти имена изменить нельзя, а использоваться они длительное время. После установки СА независимый центр сертификации нельзя преобразовать в СА предприятия, и наоборот. Старайтесь хранить роль сервера AD CS отдельно от всех остальных ролей, за исключением роли DNS.
    Книги посвященные версии WS2003 можно использовать для любой версии Windows.
    Вы не станете выдавать сертификат Джону, пока не будете уверены, что сертификат запрашивается именно Джоном. Сторонние центры сертификации для такой идентификации используют несколько типов процессов, в самом строгом из которых официальный представитель СА должен посетить лицо, запрашивающее сертификат. Для дальнейшей защиты сертификат можно хранить на смарт-карте. Затем ответственность за безопасность сертификата несет лицо, которому передается маркер безопасности на смарт-карте.
    Однако в случае планирования автоматической подачи заявок в центры сертификации предприятия необходимо гарантировать соответствующую идентификацию пользователей перед предоставлением им доступа в сеть.
    Обычно сертификаты содержат по 2 ключа — открытый и частный.
    Второе соображения связано с временем жизни сертификатов. Например, вы можете использовать интервал 10 лет для всех уровней архитектуры, то есть назначить 10 лет на каждом уровне. В архитектуре из трех уровней используйте 30 лет для корневого СА, 20 — для промежуточных и 10 — для СА выдачи сертификатов. Затем выдаваемым сертификатам можно назначить срок действия год или 2. Установка именно такого времени жизни сертификатов в иерархии обусловливается тем, что по истечении срока действия сертификата сервера также заканчивается время жизни всех подчиненных сертификатов.
    И наконец, вы должны распланировать и подготовить правила и требования сертификации (Certificate Practice Statement, CPS), которые основываются на политиках сертификации. Политики определяют обязанности организации по выдаче всех типов сертификатов. Правила CPS должны быть общедоступны для внутренних и внешних пользователей СА. Обычно доступ к правилам предоставляется в Интернете или интрасетях.
    По умолчанию клиенты не доверяют самозаверяющим сертификатам. Поэтому вам придется вручную конфигурировать этот сертификат на каждом клиентском компьютере.

    Установка AD CS


    Процесс установки AD CS более сложный, чем инсталляция служб AD облегченного доступа к каталогам (AD LDS). Причина заключается в выборе между независимым АС и центром сертификации предприятия (Enterprise СА) и последующих выборах на основе исходного.
    Требования:
    1. Мультипроцессорные системы, поскольку они ускоряют процесс распространения сертификатов.
    2. Минимальный объем оперативной памяти, поскольку RAM практически не влияет на обработку сертификатов. Для виртуальной машины можно выделить 512 Мбайт памяти.
    3. Отдельные диски для хранилища сертификатов. В идеале, нужен хотя бы один диск данных, на котором будет храниться БД. Серверы, издающие сертификаты для крупных сообществ, также должны располагать жесткими дисками для файлов журналов.
    4. Длина ключа влияет на использование процессоров и диска. Для коротких ключей требуется более высокая нагрузка диска, для длинных — больше ресурсов процессоров и меньше диска. Используйте ключи средних размеров для обеспечения оптимальной производительности серверов.
    В случае использования физических систем применяйте уровень RAID с целью балансировки между стабильностью и производительностью.
    5. Роль AD CS нельзя установить на Server Core и в системах Itanium. Первое означает, что при установке центров сертификации в периметре сети сервер следует блокировать с помощью Мастера настройки безопасности.
    В табл. 15-3 описаны поддерживаемые компоненты в каждом выпуске WServer.
    Итак, нужен лес AD DS как минимум с корневым доменом. Рекомендуется также добавить дочерний производственный домен.
    На компьютере с СА выдачи сертификатов необходимо установить IIS (AD CS автоматически добавляет IIS). Оба компьютера должны быть членами производственного домена.
    Корневому СА требуются как минимум два диска, а СА выдачи сертификатов — 3: для хранения базы данных сертификатов и ее журналов.
    6. Клиентские компьютеры (в идеале — Vista) - для запроса и получения сертификатов.

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


    Создадим 2-ярусную архитектуру AD CS. Для выполнения упражнений нужно подготовить хотя бы три виртуальных сервера, как описано в начале этой главы. Сначала создадим независимый корневой центр сертификации на SERVER03. Также требуется запустить контроллер SERVER01 домена, рядовым членом которого является SERVER03.
    1. Войдите на машину SERVER03 как администратор домена. На самом деле вам нужны лишь права доступа локального администратора, однако для выполнения данного упражнения следует использовать разрешения доступа администратора домена.
    2. Диспетчер сервера/Добавить роли/Центр сертификации/Автономный ЦС (Standalone)
    3. На странице Задание типа ЦС (СА Туре) выберите тип Корневой ЦС (Root СА).
    4. Создать новый закрытый ключ. Однако если вы переустанавливаете СА из-за системного сбоя, нужно использовать существующий ключ, который был сгенерирован во время исходной установки корневого СА. Кроме того, если вы создавали корневой СА для связывания с внешним сторонним СА, следует выбрать последний параметр и использовать ключ стороннего СА. Чтобы получить доступ к этой опции, перед инсталляцией AD CS этот ключ нужно установить на сервере. Для установки сертификата используйте инструкции стороннего СА.
    5. На странице Настройка шифрования для ЦС (Cryptography For СА) выберите рекомендуемого поставщика службы шифрования CSP (Cryptographic Service Provider). Выберите длину ключа 2048. Выберите алгоритм хэширования sha1 для подписи сертификатов, выдаваемых этим СА. Кроме того, установите флажок Использовать надежные средства защиты закрытого ключа, предоставленные CSP (Use Strong Private Key Protection Features Provided By This CSP).
    На этой странице есть несколько опций.
    а) Поставщики служб шифрования (CSP) представляют собой механизмы, которые будут использоваться программным API-интерфейсом приложения Microsoft Crypto для генерирования пары ключей этого корневого СА. CSP могут быть аппаратными и программными. Например, поставщик RSA#Microsoft Software Key Storage Provider является программным, а поставщик RSA#Microsoft Smart Card Key Storage Provider — аппаратным.
    б) Длина ключа в знаках определяет длину ключей в паре. На странице доступны 4 значения длины. Помните: чем длиннее ключ, тем больше мощностей потребуется серверу для его обработки и расшифровки.
    в) Алгоритмы хэширования используются для генерирования и назначения хэш-значения ключей в паре. Поскольку они назначаются ключам, при подделке ключа будет изменено хэш-значение и ключ станет недействительным. Хэш-значения обеспечивают дальнейшую защиту ключей.
    г) Последняя опция на этой странице обеспечивает дальнейшую защиту корневого СА, поскольку для его использования необходимы административные права доступа.
    7. На странице Задание имени ЦС введите имя Contoso-Root-CA, оставьте общее имя и суффикс по умолчанию. Вы используете это имя, поскольку оно вкладывается в каждый подчиненный сертификат, выдаваемый по цепочке.
    8. На странице Установить срок действия (Set Validity Period) выставьте значение 20 лет.
    9. На странице Настройка БД сертификатов укажите место хранения базы данных сертификатов и ее журнала. Поскольку этот корневой СА нужно отключить от сети и использовать только с целью генерирования сертификатов для СА, выдающих сертификаты по цепочке, базу данных и ее журнал нужно поместить на диск D. Создайте папку CertData. Для журналов создайте на диске D папку с именем CertLogs.
    Отметим, что вы больше не сможете изменить имя этого сервера, пока предварительно не удалите службы AD CS. Поэтому не следует использовать имя сервера в имени СА.
    Корневой центр сертификации установлен. Вернитесь к Диспетчеру сервера и просмотрите результаты установки. Например, на странице результатов установки роли AD CS должно быть перечислено событие с кодом 103, как показано на рис. 15-6. В этом событии указано, что имя центра сертификации будет добавлено в контейнер Центры сертификации (Certificate Authority) домена AD DS. В нем также указана команда, с помощью которой можно просмотреть информацию в каталоге после добавления имени.
    Отключите этот центр сертификации от сети после обновления цикла групповой политики для обеспечения дальнейшей защиты сервера. Теперь можете приступать к установке первого центра выдачи сертификатов. Для обеспечения высокой готовности инфраструктуры AD CS нужно установить несколько центров выдачи сертификатов, однако установка каждого СA выполняется одним и тем же способом.

    Установка AD CS в качестве СА предприятия, выдающего сертификаты


    Запустите машины SERVER01, SERVER03 и SERVER04.
    1. Войдите на машину SERVER04 как администратор домена. На самом деле вам нужны лишь права доступа локального администратора, однако для выполнения данного упражнения следует использовать разрешения доступа администратора домена.
    2. Роль Службы сертификации Active Directory. Службы ролей - Центр сертификации, Служба сетевого ответчика (Online Responder). При выборе сетевого ответчика также потребуется добавить роль IIS вместе с необходимыми службами. Щелкните кнопку Добавить необходимые службы роли (Add Required Role Services).
    Вы не выбрали службу подачи заявок в ЦС через Интернет (СА Web Enrollment), поскольку имеем дело с внутренним СА предприятия, а для распространения сертификатов среди пользователей и устройств центры сертификации предприятия задействуют AD DS. Если вы установили этот СА во внешней сети, можете включить подачу заявок через Интернет, чтобы пользователи могли запрашивать сертификаты в вашем СА.
    Вы не можете сейчас установить службу подачи заявок на сетевые устройства (Network Device Enrollment Service, NDES), поскольку службы AD CS не поддерживают одновременную установку СА и NDES. Чтобы установить NDES, после установки СА нужно применить команду Добавить службы ролей.
    4. Тип установки - Предприятие. Тип ЦС (Specify СA Туре) - Подчиненный ЦС (Subordinate СА).
    5. На странице Установка закрытого ключа (Set Up Private Key) выберите параметр Создать новый закрытый ключ. Т.е. подчинённый ЦС сам создаёт ключ для его дальнейшего подтверждения сертификатом от корневого ЦС. Сертификат — это подтверждение ключа.
    6. На странице Настройка шифрования для ЦС задайте параметры по умолчанию.
    7. На странице Задание имени ЦС введите имя ContosoIssuing-CA01, оставьте суффикс имени по умолчанию.
    8. На странице Запрос сертификата из родительского ЦС выберите параметр Сохранить запрос сертификата в файл и позднее отправить вручную в родительский ЦС.
    9. Просмотрите параметры установки веб-сервера (IIS). На странице выбора служб ролей веб-сервера просмотрите необходимые службы.
    Подчиненный центр сертификации нельзя использовать до тех пор, пока не будет выдан сертификат корневого СА.

    Получение и установка сертификата для центра выдачи сертификатов


    Обычно эту процедуру нужно выполнять в автономном режиме с помощью съемного устройства хранения, однако в данном упражнении вы используете общую папку для передачи запроса сертификата и самого сертификата после его получения.
    1. На SERVER04 на диске С создайте новую папку Temp с общим доступом.
    2. Общий доступ к файлу-Все/Уровень разрешений-Соавтор
    3. Скопируйте в папку Temp запрос сертификата, сгенерированный в папке Документы.
    4. На машине SERVER03 откройте консоль Центр сертификации. В панели дерева консоли ЦС ПКМ имя корневого СА, щелкните задачу Выдать новый запрос ( Submit New Request). В диалоговом окне Открыть файл запроса (Open Request File) перейдите в адресную строку и введите адрес \\SERVER04\Temp. В панели дерева перейдите в узел Запросы в ожидании ( Pending Request), ПКМ ожидающий запрос в панели сведений, выберите Все задачи и щелкните задачу Выдать ( Issue ).
    6. В панели дерева перейдите в узел Выданные сертификаты (Issued Certificates), в панели сведений ПКМ выданный сертификат и выполните команду Открыть.
    7. В диалоговом окне Сертификат перейдите на вкладку Сведения и щелкните кнопку Копировать в файл в нижней части диалогового окна. Запустится Мастер экспорта сертификата. Далее.
    8. Выберите сначала Cryptographic Message Syntax Standard — PKCS #7 Certificates (P7B), затем — опцию Включить по возможности все сертификаты в путь сертификации (Include All Certificates In The Certification Path If Possible) и щелкните кнопку Далее.
    Существует несколько поддерживаемых форматов.
    а) Формат Distinguished Encoding Rules (DER) Encoded Binary X.509 часто используется для компьютеров не на платформе Windows. Файлы сертификации создаются в формате CER.
    б) Формат Base-64 Encoded X.509 поддерживает формат S/MIME, применяемый для пересылки защищенной электронной почты по Интернету. На серверах этот формат обычно используется для операционных систем не на платформе Windows. Файлы сертификации создаются в формате CER.
    в) Формат Cryptographic Message Syntax Standard (PKCS #7) используется для пересылки сертификатов и их пути в цепочке с одного компьютера на другой. Данный формат использует файловый формат Р7В.
    г) Формат Personal Information Exchange (PKCS #12) также используется для передачи сертификатов и их пути в цепочке с одного компьютера на другой, однако этот формат также поддерживает передачу закрытого ключа вместе с открытым. Данный формат использует файловый формат PFX.
    д) Настраиваемый формат Microsoft Serialized Certificate Store следует использовать для переноса корневых сертификатов с одного компьютера на другой. Использует файловый формат SST.
    9. В диалоговом окне Экспортируемый файл (File To Export) щелкните кнопку Обзор и сохраните сертификат в папке \\SERVER04\Temp. Задайте для файла имя Issuing-CA01.p7b и щелкните кнопку Сохранить.
    10. SERVER04/Диспетчеру сервера и в панели дерева выберите элемент Contoso-Issuing-CA01 в папке Роли\Службы сертификации AD. ПКМ элемент Contoso-Issuing-CA01, выберите Все задачи и щелкните задачу Установить сертификат ЦС. Перейдите к папке C:\Temp, выберите сертификат и щелкните кнопку Открыть. Сертификат будет импортирован на сервер.
    12. ПКМ имя сервера, выберите Все задачи и щелкните задачу Запуск службы.
    Ваш центр выдачи сертификатов теперь может выдавать сертификаты. Сохраните переданный сертификат в безопасном месте.

    Установка службы NDES


    Для установки службы NDES потребуется особая учетная запись пользователя. Создайте учетную запись домена и добавьте ее в группу IIS_IUSRS на каждом сервере, который управляет этой службой. Например, вы можете задать для этой учетной записи имя NDESService. Опять-таки, это упражнение необходимо выполнять на машине SERVER04, однако для создания учетной записи пользователя вначале нужно использовать машину SERVER01.
    1. Войдите на машину SERVER01 как администратор домена, запустите оснастку Active Directory — пользователи и компьютеры. Создайте следующую структуру подразделений: Contoso.com\Admins\Service Identities. ПКМ подразделение Service Identities, примените команду Создать, а затем выберите объект Пользователь. Задайте для пользователя имя NDESService, которое используйте для входа и в качестве имени входа пред-Windows 2000. Щелкните кнопку Далее. Назначьте учетной записи строгий пароль. Сбросьте флажки Требовать смену пароля при следующем входе в систему (User Must Change Password At Next Logon) и Срок действия пароля не ограничен (Password Never Expires).
    2. Вернитесь к машине SERVER04 и войдите как администратор домена и запустите Диспетчер сервера.
    3. Разверните узел Конфигурация\Локальные пользователи и группы\Группы. Дважды щелкните группу IIS_IUSRS. Добавьте в эту группу учетную запись NDESService и щелкните ОК.
    4. В панели дерева Диспетчера сервера/ПКМ узел Службы сертификации Active Directory и примените команду Добавить службы ролей.
    5. На странице Выбор служб ролей установите флажок. Служба подачи заявок на сетевые устройства (Network Device Enrollment
    Service). В установку IIS при этом также необходимо добавить компонент Проверка подлинности Windows (Windows Authentication).
    6. Щелкните кнопку Добавить необходимые службы роли (Add Required Role Sen-ices) и щелкните кнопку Далее.
    7. На странице Задание учетной записи пользователя (Specify User Account) щелкните кнопку Выбрать пользователя (Select User), введите имя NDESService и пароль и щелкните ОК.
    8. На странице Задание данных центра регистрации (Specify Registration Authority Information) нужно указать информацию для центра регистрации или центра, выдающего сертификаты сетевых устройств и управляющего ими. Введите имя Conroso-MSCEP-RA01, в появившемся списке выберите свою страну и оставьте все остальные поля данных пустыми. Щелкните кнопку Далее (Next).
    Обычно нужно указать всю обязательную и опциональную информацию, однако в данном упражнении следует оставить поля пустыми.
    9. На странице Настройка шифрования для центра регистрации (Configure Cryptography For Registration Authority) оставьте параметры по умолчанию и щелкните кнопку Далее.
    Помните, что длина ключей влияет на использование процессоров.
    Используйте длину ключей из 2048 знаков, если на среду не наложены строгие ограничения безопасности.
    10. На странице Службы ролей веб-сервера просмотрите список необходимых служб.
    Служба NDES установлена и готова к работе. Установка сервера выдачи сертификатов завершена.

    Настройка и использование AD CS


    После развертывания серверов нужно настроить их конфигурацию для выдачи и управления сертификатами пользователей и устройств. В том числе, чтобы сетевой ответчик отвечал на запросы, необходимо завершить настройку конфигурации сетевого ответчика, для поддержки подачи заявок на сетевые устройства необходимо завершить настройку конфигурации службы NDES центра выдачи сертификатов.
    Чтобы завершить настройку конфигурации центра выдачи сертификатов, нужно выполнить следующие действия.
    1. Создать конфигурацию для отзыва сертификатов.
    2. Настроить и персонализировать шаблоны сертификатов, делая акцент на следующих факторах.
    а) Если для защиты данных используется EFS, сертификаты необходимо отконфигурировать для работы с EFS. Кроме того, также нужно распланировать агента восстановления или агента, который сможет восстанавливать данные в случае утери пользователем ключа EFS.
    б) Если сертификаты используются для защиты беспроводных сетей, необходимо отконфигурировать сертификаты последних. Для этого нужно использовать строгую проверку подлинности и шифровать все коммуникации между беспроводными устройствами.
    в) Если для поддержки двухфакторной проверки подлинности используются смарт-карты, необходимо отконфигурировать сертификаты последних.
    г) Для защиты веб-сайтов и электронной торговли необходимо отконфигурировать сертификаты веб-сервера. Этот тип сертификатов также можно использовать для защиты контроллеров доменов и шифрования всех входящих и исходящих коммуникаций последних.
    д) Настройка параметров подачи заявок и отзыва сертификатов.
    Все эти действия выполняются непосредственно в центре выдачи
    сертификатов или удаленно на рабочей станции с помощью средств удаленного администрирования сервера RSAT (Remote Server Administration Tools).

    Настройка отзыва сертификатов СА


    Типы конфигурации отзыва сертификатов описаны в консоли Центры сертификации.
    Конфигурация отзыва центров выдачи сертификатов включает несколько компонентов. Первым является перечень точек распространения списка отзыва сертификатов (Certificate Revocation List, CRL), вторым — перекрытие между CRL и разностными CRL (Delta CRL), отправляемыми в ответ на запросы. Третий компонент — расписание, используемое для публикации списков CRL.
    1. укажите точки распространения списков отзыва сертификатов CLR;
    а) Войдите на сервер центра выдачи сертификатов как локальный администратор. Запустите консоль Центр сертификации. ПКМ имя центра выдачи сертификатов и примените команду Свойства.
    б) В диалоговом окне свойств перейдите на вкладку Расширения и убедитесь, что в раскрывающемся списке Выберите расширение выбрано расширение Точка распространения списков отзыва (CLR Distribution Point (CDP)). Кроме того, должны быть установлены флажки Опубликовать CLR по данному адресу (Publish CRLs To This Location) и Публикация разностных CLRs по адресу (Publish Delta CRLs То This Location).
    Если вы внесли изменения в конфигурацию центра сертификации, потребуется остановить и перезапустить службу AD CS.
    2. Теперь приступайте к настройке периодов перекрытия CLR и разностных CLR (Delta CLR). Разностный CLR содержит только сертификаты, отозванные с момента публикации последнего регулярного CLR, что позволяет сократить размеры CLR. Для этого используется утилита Certutil.exe.
    а) На сервере центра выдачи сертификатов откроите командную строку от имени администратора. Например, вы можете задать период перекрытия CLR 24 ч и период публикации разностных CLR 12 часов. Для этого введите следующие команды:
    certutil -setreg ca\CRLOverlapUnits 24
    certutil -setreg ca\CRLOverlapPeriod hours
    certutil -setreg ca\CRLDeltaOverlaplUnits 12
    certutil -setreg ca\CRLDeltaOverlapPeriod hours
    Значение указывает период перекрытия, а единицами являются минуты, часы или дни.
    б) Откройте консоль Центр сертификации и щелкните правой кнопкой мыши
    имя сервера центра выдачи сертификатов, чтобы остановить и перезапустить службу.
    3. отконфигурируйте расписание публикации списков CLR.
    ПКМ контейнер Отозванные сертификаты (Revoked Certificates) и примените команду Свойства. В Параметры публикации CLR (CLR Publishing Parameters) отконфигурируйте интервалы публикации CLR и разностных CLR (Delta CLR).
    По умолчанию задаются значения соответственно 1 неделя и 1 день. Если планируется интенсивное использование сертификатов и требуется обеспечивать высокую готовность списков CLR, уменьшите оба значения. В противном случае оставьте значения но умолчанию.
    На вкладке Просмотр списков отзыва сертификатов (View CLRs) можно также просмотреть существующие списки отзыва сертификатов. Щелкните ОК.
    Конфигурация отзыва сертификатов задана.
    Сценарий. Управление отзывом сертификатов
    Злоумышленник создал корневой сертификат, подписывает им ПО организации и продаёт сотрудникам. Что нужно предпринять?
    Идите с этой информацией к руководству, которое должно немедленно принять меры, чтобы двое бывших сотрудников перестали продавать сертификаты с прикрепленным именем Contoso. Кроме того, персонал отдела продаж должен инициировать некоторые операции с клиентами по предупреждению и устранению отказов. Наличие на рынке программного обеспечения не от компании Contoso, но с сертификатами Contoso, может значительно повредить репутации компании.
    Нужно отозвать сертификаты.
    Затем необходимо опубликовать список отзыва сертификатов CKR (Certificate Revocation List). Дли этого используется папка Отозванные сертификаты (Revoked Certificates) в консоли Центр сертификации. К сожалению, даже при немедленной публикации этого нового списка CLR клиенты не обновят свои списки CLR до следующего запуска процесса обновления, что зависит от их конфигурации обновления.
    И наконец, ваша организация должна сделать официальное заявление о утерянных сертификатах. Все клиенты Contoso должны знать об угрозе и проверять каждый получаемый сертификат с именем Contoso, пока похищенные сертификаты не будут отозваны. (см рис Публикация CRL)

    Настройка и персонализация шаблонов сертификатов


    Центры сертификации предприятия применяют шаблоны версий 2 и 3. Эти шаблоны можно конфигурировать и персонализировать. Чтобы подготовить шаблоны к использованию, вначале необходимо отконфигурировать каждый шаблон, который будет использоваться, а затем после настройки развернуть каждый шаблон в центрах сертификации. После этого шаблоны можно использовать для выдачи сертификатов.
    1. Войдите на сервер центра выдачи сертификатов как администратор домена\Диспетчер сервера\Роли\СS AD\Шаблоны сертификатов.
    2. Отметим, что по умолчанию вы подключены к контроллеру домена. При работе с шаблонами нужно подключиться к контроллеру домена для публикации шаблонов в AD DS. Если вы не подключены, используйте для этого команду Подключиться к другому контроллеру домена, доступному для записи в панели Действия.
    Теперь вы можете создавать необходимые шаблоны.
    3. Выберите исходный шаблон, щелкните его правой кнопкой мыши, примените команду Скопировать шаблон (Duplicate Template) и, если вы не работаете со смешанной иерархией PKI, всегда следует выбирать WServer.
    4. Задайте имя для нового шаблона, настройте его и сохраните параметры.
    Настройте шаблоны в соответствии со следующими инструкциями.
    а) Для создания шаблона EFS выберите исходный шаблон Базовое шифрование EFS (Basic EFS). Особое внимание уделите архивации ключей на вкладке Обработка запроса (Request Handling) и установите флажок Архивировать закрытый ключ субъекта (Archive Subject Encryption Private Key). Кроме того, используйте шифрование для передачи ключа центру сертификации. Хранение архива закрытых ключей обеспечивает их защиту в случае утери пользователями. На вкладке Имя субъекта (Subject Name) можно добавить информацию, например альтернативное имя субъекта.
    б) Если вы планируете использовать EFS, необходимо также создать шаблон агента восстановления EFS (EFS Recovery Agent). Продублируйте его для WServer. Опубликуйте сертификат агента восстановления в Active Directory. Отметим, что срок действия сертификата агента восстановления намного дольше, чем срок действия самого сертификата EFS. Кроме того, используйте на других вкладках свойств те же параметры, которые были назначены дубликату Базовое шифрование EFS.
    Информацию о реализации EFS можно найти в официальном документе «Workine With The Encrypting File System» по адресу http://www.reso-net.com/articles.aspPin-8 в разделе «Advanced Public Key Infrastructures».
    в) Если вы планируете использовать беспроводные сети, создайте шаблон сервера сетевой политики (Network Policy Server, NPS). Как правило, шаблон создается и конфигурируется для автоматической подачи заявок. Затем новые сертификаты будут назначены при следующем обновлении параметров групповой политики серверов NPS. В качестве исходных для нового шаблона NPS используйте шаблоны RAS и IAS-сервера. Опубликуйте шаблон в Active Directory. Перейдите на вкладку Безопасность и выберите группы серверов RAS и IAS, чтобы назначить разрешения Автоматическая подача заявок (Autoenroll) и Заявка (Enroll).
    г) Если вы собираетесь войти в сеть с помощью смарт-карты, создайте дубликаты шаблонов Вход со смарт-картой (Smartcard Logon) и Пользователь со смарт-картой (Smartcard User) для WServer. Задайте им соответствующие имена и опубликуйте шаблоны в Active Directory.
    Для этих сертификатов не применяется автоматическая подача заявок, поскольку для распределения самих смарт-карт среди пользователей необходимы станции подачи заявок на смарт-карты.
    д) Если вы хотите защитить веб-серверы или контроллеры домена, создайте дубликаты шаблонов проверки подлинности веб-сервера (Web Server) и контроллера домена (Domain Controller Authentication). He используйте шаблон Контроллер домена (Domain Controller), поскольку он предназначен для предыдущих версий операционной системы. Продублируйте шаблоны для WServer, опубликуйте их в Active Directory и проверьте другие свойства.
    В конфигурацию каждого шаблона часто включаются дополнительные типы активности, не обязательно связанной с AD CS. Просмотрите справку AD CS в Интернете и изучите типы активности в зависимости от публикаций каждого типа сертификата.
    Теперь на основе этих персонализированных шаблонов необходимо выдать шаблоны центру сертификации для выдачи сертификатов.
    5. Диспетчер сервера\Роли\CS AD\Имя_ЦС\Шаблоны сертификатов. Чтобы выдать шаблон, щелкните правой кнопкой контейнер Шаблоны сертификатов, примените команду Создать и щелкните опцию Выдаваемый шаблон сертификата (Certificate Template То Issue).
    6. В диалоговом окне Включение шаблонов сертификатов (Enable Certificate Templates) нажмите клавишу Ctrl, выделите все шаблоны, которые хотите выдать, как показано на рис. 15-8.

    Подача заявок


    Теперь вы можете приступать к настройке подачи заявок. Для этого используется групповая политика (например Default Domain Policy). Параметры для пользователя и компьютера, как правило, не применяются в одном объекте групповой политики.
    1. Конфигурация компьютера\Политики\Конфигурация Windows\Пapaмeтpы безопасности\Политики открытого ключа\Клиент служб сертификации: автоматическая подача заявок (Certificate Services Client — Auto-Enrollment).
    2. Включите эту политику и установите флажок Обновлять сертификаты с истекшим сроком действия или в состоянии ожидания и удалять отозванные сертификаты (Renew Expired Certificates, Update Pending Certificates, And Remove Revoked Certificates).
    3. Установите флажок Обновлять сертификаты, использующие шаблоны сертификатов, если вы для этой цели уже выдали несколько сертификатов. (при работе с шаблоном EPS это действие почему то не производится)
    Для пользователей — аналогично. Отметим, что для пользователей в политике можно установить флажок Уведомлять об окончании срока действия (Expiration Notification).
    4. Вернитесь к центру выдачи сертификатов в Диспетчер сервера, чтобы выбрать значение по умолчанию, которое будет использовать центр выдачи сертификатов при получении запросов сертификатов. В узле AD CS щелкните ПКМ имя сервера с центром выдачи сертификатов и примените команду Свойства/Модуль политики/Свойства. Для автоматической выдачи сертификатов установите флажок Следовать параметрам, установленным в шаблоне сертификата, если они применимы, иначе автоматически выдавать сертификат ( Follow The Settings In The Certificate Template, If Applicable. Otherwise, Automatically Issue The Certificate).

    Cетевой ответчик


    Сетевой ответчик - служба предназначена для обработки запросов подтверждения сертификатов через протокол OCSP (Online Certificate Status Protocol). Сетевые ответчики являются новым компонентом WServer и работают намного быстрей и эффективней, чем списки CLR. Сетевые ответчики часто являются альтернативой или дополнением к спискам CLR, которые поддерживают процесс отзыва сертификатов. Сетевые ответчики Microsoft соответствуют стандартам RFC 2560 для OCSP.
    С помощью сетевого ответчика системе, применяющей PKI, нет необходимости получать полный список CLR для запроса подтверждения конкретного сертификата. Для определения подлинности дочернего ЦА мы, естественно, не можем обмениваться с родительским сервером приватными ключами. Сетевой ответчик шифрует запрос подтверждения и определяет подлинность сертификата. При определении состояния запрошенного сертификата ответчик пересылает обратно зашифрованный ответ, содержащий информацию для запрашивающей стороны.
    Для подписи ответов на запросы сетевые ответчики должны использовать сертификаты OCSP. Эти сертификаты шифруют содержимое отклика сетевого ответчика.
    Узел Сетевой ответчик (Network Responder или Online Responder, OR) в диспетчере сервера также содержит дочерний узел Конфигурация массива (Array Configuration). Чтобы обеспечить высокую готовность службы, в эту конфигурацию массива можно добавлять другие сетевые ответчики.
    Для работы в массиве все эти сертификаты должны быть доверенными. Конфигурация отзыва позволяет другим членам массива доверять каждому отдельному СА в массиве.
    Каждый сетевой ответчик использует собственный сертификат для процедуры подтверждения. Каждая конкретная конфигурация отзыва поддерживает конкретную пару ключей сертификации и публикуется для каждого сетевого ответчика в массиве. Для обновления сертификата сетевого ответчика нужно обновить его конфигурацию отзыва.
    Нужно отконфигурировать и установить сертификат Подписывание отклика OCSP, а затем отконфигурировать для его поддержки расширение Сведения о шаблоне сертификата (Authority Information Access). После этого нужно назначить данный шаблон для центра сертификации и выполнить подачу заявки системы для получения сертификата.
  • Войдите на сервер выдачи сертификатов, используя учетную запись с правами локального администратора. Диспетчер сервера\Роли\Службы сертификации AD\Шаблоны сертификатов (имя сервера).
    2. ПКМ шаблон Подписывание отклика OCSP (OCSP Response Signing) и примените команду Скопировать шаблон.
    3. Установите флажок Опубликовать сертификат в AD.
    4. На вкладке Безопасность добавьте тип объектов Компьютер с правами доступа Чтение, Заявка (Enroll) и Автоматическая подача заявок (Autoenroll).
    Теперь для поддержки сетевого ответчика необходимо отконфигурировать расширение Доступ к сведениям о центрах сертификации (Authority Information Access).
    5. Диспетчер сервера\Роли\Службы сертификации Active Directory\имя_ЦC (Issuing CA servernnme)\Свойства\Расширения, щелкните раскрывшийся список Выберите расширение и укажите в нем расширение Доступ к сведениям о центрах сертификации (Authority Information Access, AIA).
    6. Укажите, откуда пользователи могут получить сертификат этого центра сертификации. В данном случае выберите размещение, начинающееся с HTTP://. Установите флажки Включать в AIA-расширение выданных сертификатов (Include In The AIA Extension Of Issued Certificates) и Включать в расширения протокола OCSP (Include In The Online Certificate Status Protocol (OCSP) Extension).
    Отметим, что для применения данного изменения нужно независимо от вышеуказанных действий перезапустить службу.
    7. В дереве под именем сервера ПКМ Шаблоны сертификатов и примените команду Создать\Выдаваемый шаблон сертификата (Certificate Template To Issue). В диалоговом окне Включение шаблонов сертификатов (Enable Certificate Templates) выберите созданный ранее шаблон Подписывание отклика OCSP. Новый шаблон отобразится на панели сведении.
    8. Для назначения шаблона серверу перезагрузите последний.
    9. Теперь необходимо проверить назначение сертификата OCSP серверу. Для этого используется оснастка Сертификаты. По умолчанию она отсутствует в консоли, поэтому нужно создать новую консоль. Выберите оснастку Сертификаты и щелкните кнопку Добавить. Выберите учетную запись компьютера и щелкните кнопку Далее. Выберите управление локальным компьютером и щелкните кнопку Готово.
    10. Разверните узел Сертификаты\Личное\Сертификаты (Certificates\Personal\Certificates) и убедитесь, что этот контейнер содержит новый сертификат OCSP. Если сертификат отсутствует, установите его вручную. Для этого щелкните правой кнопкой мыши папку Сертификаты в контейнере Личное и примените команду Запросить новый сертификат.
    11. На странице Подача заявок на сертификаты (Certificate Enrollment) щелкните кнопку Далее. Выберите новый сертификат OCSP и щелкните кнопку Подать заявку (Enroll).
    12. На следующей странице щелкните стрелку вниз прямо под названием Сведения, а затем кнопку Просмотр сертификата. Просмотрите содержимое вкладок сведений о сертификате.
    13. Щелкните кнопку Готово, чтобы завершить эту часть операций.
    14. ПКМ Сертификат, выберите опции Все задачи и примените задачу Управление закрытыми ключами (Manage Private Keys).
    15. На вкладке Безопасность щелкните кнопку Размещение и выберите имя локального сервера. Введите имя Сетевая служба и щелкните кнопку Проверить имена, разрешите право Полный доступ.
    Ваш сетевой ответчик готов предоставлять данные, необходимые для подтверждения сертификатов.

    Добавление конфигурации отзыва сертификатов в сетевой ответчик


    Поскольку каждый центр сертификации, являющийся сетевым ответчиком в массиве, располагает собственным сертификатом, для каждого СА также необходима конфигурация отзыва сертификатов. Конфигурация отзыва обслуживает запросы пар ключей и сертификатов конкретного центра сертификации. Кроме того, конфигурацию отзыва для центра сертификации необходимо обновлять при каждом обновлении его пары ключей. Чтобы создать конфигурацию отзыва сертификатов, выполните следующие действия.
    1. Войдите на сервер с центром выдачи сертификатов, используя доменную
    учетную запись с правами локального администратора.
    2. Диспетчер сервера\Роли\Службы сертификации Active Directory\Ceтeвoй ответчик\Конфигурация отзыва (Revocation Configuration). ПКМ контейнер Конфигурация отзыва и примените команду Добавить конфигурацию отзыва.
    Поскольку каждая конфигурация отзыва привязывается к отдельному центру сертификации, в имя конфигурации имеет смысл включить имя центра сертификации, например RCSERVER04.
    3. На странице Выберите расположение сертификата ЦС укажите, откуда будет загружаться сертификат. Вы можете выбрать загрузку из Active Directory, локального хранилища сертификатов или файла.
    4. Щелкните параметр Выберите сертификат для существующего ЦС предприятия.
    Теперь сетевой ответчик должен подтвердить, что издатель сертификата, которым в данном случае является корневой центр сертификации, располагает подлинным сертификатом. Вы можете выполнять поиск сертификатов путем обзора сертификатов СА, опубликованных в Active Directory, или выполнять их поиск по имени компьютера.
    5. Поскольку корневой центр сертификации отключен от сети, выберите Active Directory и щелкните кнопку Обзор. Локализуйте сертификат для корневого СА.
    После выбора сертификата мастер загрузит шаблоны подписи сетевого ответчика.
    6. На странице Выбрать сертификат подписи (Select A Signing Certificate) необходимо выбрать метод подписи, поскольку сетевой ответчик подписывает все отклики для клиентов. Доступны три опции:
    а) при автоматическом выборе сертификат будет загружаться из ранее созданного шаблона OCSP;
    б) сертификат для подписи можно выбрать вручную;
    в) при выборе опции Сертификат ЦС используется сертификат самого центра сертификации.
    7. Выберите опцию Автоматически выбрать сертификат подписи (Automatically Select A Signing Certificate), а для сертификата подписи OCSP выберите параметр Автозаявка (Auto-Enroll).
    8. Выберите центр подачи заявок и щелкните ОК.
    Будет автоматически выбран ранее подготовленный шаблон.
    Щелкните кнопку Далее.
    Теперь мастер инициирует поставщика отзыва. Если мастер по каким-либо причинам пе может найти поставщика, его следует добавить вручную.
    9. Щелкните кнопку Поставщик (Provider), а затем щелкните кнопку Добавить под секцией Базовые CRL. Например, вы можете
    использовать следующий адрес HTTP: http://localhosе/ca.crl .
    10. Щелкните ОК. Повторите эту операцию для разностных CRL (Delta CRLs) и укажите тот же HTTP-адрес. Щелкните ОК.
    Поскольку вы получаете сертификат из Active Direcrtory, для адреса указанного поставщика мастер автоматически использует формат ldар://. Для получения информации и хранилища каталогов AD DS службы AD CS используют протокол LDAP.
    11. Щелкните кнопку Готово, чтобы завершить настройку отзыва.
    Повторите эту процедуру для каждого центра сертификации, который является сетевым ответчиком.
    Пример:
    Вы уже настроили сертификаты Подписывание отклика OCSP, расширение Доступ к сведениям центров сертификации и перезагрузили сервер. Теперь вы собираетесь проверить автоматическую загрузку этого сертификата на сервер. Вы создали настраиваемую консоль с оснасткой Сертификаты, однако при просмотре сертификатов в узле Личное (Personal) компьютера оснастка не открылась. Вы решили импортировать сертификат вручную, однако при использовании мастера запроса нового сертификата (Request New Certificate Wizard) обнаружилось, что доступны не все сертификаты. В чем причина?
    A. Некорректно заданы свойства безопасности шаблона сертификата. Некорректно заданы права доступа к шаблонам сертификатов. Чтобы вручную загрузить сертификаты на сервер, учетная запись пользователя должна иметь разрешение на отзыв. Кроме того, сервер, на который загружается сертификат, также должен иметь разрешение на отзыв. Для настройки прав доступа шаблон необходимо создать и выдать заново.
    B. На этом сервере нельзя загрузить сертификат Подписывание отклика OCSP. Вам необходимо иметь возможность загрузки сертификата OSCP на этот сервер, поскольку он служит сетевым ответчиком.
    C. Этот сертификат не нужно загружать вручную. Он будет загружен автоматически при следующем обновлении групповой политики.
    Неправильный: Сертификат с разрешением автоматической подачи заявок должен загружаться автоматически, а его загрузке вручную могут препятствовать только права доступа.

    Использование и управление AD CS


    Управление службами роли Службы сертификации Active Directory осуществляется с помощью оснасток ММС.
    ПРИМЕЧАНИЕ Установка оснасток без инсталляции AD CS
    Все оснастки можно установить с помощью диспетчера
    сервера, выбрав инструменты AD CS в средствах удаленного администрирования сервера RSAT (Remote Server Administration Tools).
    Служба AD CS предоставляет много информации в журнале событий
    (Event Log). Самые распространенные события центров сертификации AD
    CS перечислены в табл. 15-5.
    Категория
    Управление доступом AD CS
    Код события
    39,60,92
    Описание
    Связаны с недостаточным или несоответствующим использованием разрешений доступа
    AD CS и AD DS
    24,59, 64,91,93,94, 106,107
    Связаны с доступом (чтение или запись) объектов AD DS
    Запрос сертификации AD CS (обработка подачи заявок)
    3,7,10,21,22,23, 53,56,57,79,80,97, 108,109,128,132
    Отсутствует один элемент для успешной подачи заявки: подлинный сертификат СА, шаблоны сертификатов с соответствующей конфигурацией, учетные записи клиентов или запросы сертификатов
    Центр сертификации и цепочка подтверждения сертификатов AC CS
    27,31,42,48,49, 51,58, 64,100,103, 104,105
    Связаны с доступностью, подлинностью и цепочкой подтверждения сертификата СА
    Обновление центра сертификации AD CS
    111,112,113,114, 115,116,117,118,119,120,121,122, 123,125,126
    Связаны с обновлением центров сертификации из предыдущих версий Windows до WServer и могут содержать опции или компоненты конфигурации, которые нужно реконфигурировать
    Перекрестная сертификация AD CS
    99,102
    Связаны с сертификатами СА, созданными с целью установления доверия между исходным сертификатом и обновленным корнем
    Доступность баз данных AD CS
    17
    Связаны с ошибками доступа к базе данных AD CS
    Обработка модуля выхода AD CS
    45,46
    Связаны с функциями публикации модуля выхода или отправкой уведомлений по электронной почте
    Архивация и восстановление ключей AD CS
    81,82,83,84,85,86,87,88, 96,98,127
    Связаны с сертификатами агента обновления ключей, сертификатами и ключами обмена данными (XCHG) или отсутствием одного либо всех этих компонентов
    Доступность счетчиков производительности AD CS
    110
    Связаны с невозможностью запуска счетчиков производительности
    Обработка модуля политики AD CS
    9,43,44,77,78
    Связаны с проблемами обнаружения модуля политики
    Доступность ресурсов AD CS
    15,16,26,30,33,34, 35,38,40,61,63, 89,90
    И, Связаны с доступностью системных ресурсов и компонентов операционной системы
    Параметры реестра AD CS
    5,19, 20, 28,95
    Связаны с повреждением или удалением параметров конфигурации реестра
    Сетевой ответчик AD CS
    16,17,18,19, 20,21, 22, 23, 25, 26, 27, 29, 31,33,34, 35
    Связаны с зависимостями службы сетевого ответчика
    Одним из самых удобных инструментов управления AD CS является утилита Certutil.exe, которая поддерживает практически все операции в центре сертификации и позволяет автоматизировать задачи технической поддержки и администрирования.
    Одним из самых удобных инструментов в инфраструктуре AD CS является средство PKI предприятия в узле Службы сертификации Active Directory диспетчера сервера или утилита PKIView в командной строке. Инструмент PKI предприятия можно использовать для управления активностью AD CS. По сути, PKI предприятия содержит представление о состоянии развертывания AD CS и позволяет просматривать всю иерархию PKI в сети, а также детализировать сведения отдельных центров сертификации с целью идентификации ошибок конфигурации или операции в инфраструктуре PKI.
    Средство PKI предприятия в основном используется в качестве представления диагностики и работоспособности, поскольку отображает операционные данные о членах иерархии PKI. Кроме того, PKI предприятия можно быстро привязать к каждому СА, щелкнув имя последнего правой кнопкой мыши и применив команду Управление ЦС. Запустится консоль Центр сертификации нацеленного СA.
    В панели Действия (Actions) также можно открыть консоли Управление шаблонами и Управление контейнерами (Manage AD Containers ). С помощью последней консоли можно просмотреть перечень всех команд в каталоге, которые используются для хранения сертификатов архитектуры PKI, как показано на рис. 15-9.
    Используйте PKI предприятия для визуальной проверки состояния
    работоспособности PKI. С помощью различных значков можно немедленно получить обратную связь с каждым компонентом в инфраструктуре. Зеленый цвет значка означает, что компонент работоспособен, желтый указывает на незначительные неполадки, а красный свидетельствует о возникновении серьезной проблемы.

    Архивация AD CS


    В Диспетчере сервера\Роли\Службы сертификации Active Directory и откройте узел с именем СА. Щелкните правой кнопкой мыши имя сервера, выберите опцию Все задачи и примените команду Архивация ЦС. Запустится Мастер архивации центра сертификации. На странице Архивируемые элементы (Items To Back Up) выберите элементы для архивации:
    а) опция Закрытый ключ и сертификат ЦС обеспечивает защиту сертификата данного сервера;
    б) опция База данных сертификатов и журнал БД (Certificate Database And Certificate Database Log) обеспечивает защиту сертификатов, которыми управляет СА. Вы также можете выполнять инкрементную архивацию базы данных.
    Отметим, что конечная папка должна быть пустой. Назначьте для архива строгий пароль.
    В командной строке также можно выполнять автоматическую архивацию, используя утилиту Certutil.exe с соответствующими переключателями архивации и восстановления базы данных.
    Более подробную информацию об использовании утилиты CertutiLexe для архивации и восстановления можно найти но адресу http://support.microsoft.com/kb/185195 .
    Для восстановления информации используйте Мастер восстановления центра сертификации (Certification Authority Restore Wizard). Щелкнув правой
    кнопкой мыши имя сервера, выберите опцию Все задачи и примените задачу Восстановление ЦС. Мастер сразу потребует остановить службу центра сертификации перед запуском операций восстановления. После остановки службы откроется страница приветствия мастера. Выберите элементы для восстановления.
    После завершения операции восстановления мастер предложит перезагрузить службу AD CS.

    Службы управления правами Active Directory


    Службы управления правами Active Directory (AD Rights Management Services, RMS) предназначены для расширения внутренней сети. Однако в данном случае речь идет о расширении интеллектуальной собственности.
    Люди, начиная работать с компьютером, испытывают определенные сложности с цифровым управлением правами DRM (Digital Rights Management). Когда компьютеры только появились, производители программного обеспечения предпринимали много усилий по защите своих программ от похитителей. Даже в настоящее время одни производители требуют использовать аппаратные ключи для запуска своего программного обеспечения, другие применяют веб-процессы подтверждения. Например, выпустив Vista, корпорация Microsoft ввела новую схему лицензирования со службой KMS (Key Management Server) для подтверждения лицензированных версий Microsoft Windows.

    Службы федерации Active Directory

    Службы федерации AD


    AD Federation Services — партнерские отношения. С помощью служб AD FS организация может расширить инфраструктуру IDA на множестве платформ, включая среды Windows и другие, а также обеспечить для доверенных партнеров защиту прав идентификации и доступа вне периметра безопасности. В среде федерации организации поддерживают и контролируют собственные объекты идентификации, однако могут также безопасно проектировать объекты и принимать их из других организаций. Пользователи проходят проверку подлинности в одной сети, но могут получать доступ к ресурсам в другой.
    Этот процесс называется единым входом SSO (Single Sign-On). Роль AD FS поддерживает партнерские отношения, поскольку она дает различным организациям возможность получать общий доступ к приложениям в экстрасети, при этом используя для реальной проверки подлинности свои внутренние структуры AD DS. С этой целью данная роль расширяет внутреннюю структуру AD DS во внешний мир через TCP/IP-порты (Transmission Control Protocol/Internet Protocol) 80 (HTTP) и 443 (Secure HTTP либо HTTPS). Обычно роль AD FS размещена вдоль периметра сети. Службы AD FS могут использовать роль AD CS для создания доверенных серверов, а также роль AD RMS для обеспечения внешней защиты интеллектуальной собственности.

    Литература


    Материалы, которые вошли целиком (с поправками):
  • Экзамен 70-642. Проектирование сетевой инфраструктуры WS2008. Тони Нортроп Дж. К. Макин 1 издание 2011
    Полностью (с поправками) вошли только главы 1-5, остальной материал использовался пока частично.
  • kb.atraining.ru/qos-windows-nt
  • technet.microsoft.com/ru-ru/library/hh831679.aspx
  • www.xakep.ru/post/16580/
    Материалы, которые использовались:
    1. Моримото Р., Ноэл М., Драуби О., Мистри Р., Амарис К. - Microsoft Windows Server 2008 R2. Полное руководство 2011
    2. Макин Дж., Десаи А. Учебный курс Microsort. MCTS (экзамен 70-643). Развертывание и настройка WServer 2008. 2008г.
    3. Журнал Хакер 146, 122 номера
    4. Знакомство с WServer 2008 Митч Таллоч 2008.
    5. Finn A. WServer 2012 Hyper-V Installation and Configuration Guide 2013.
    • .ODT Laadi alla originaalfail 724 lk · .odt · 3 allalaadimist
    Vasakule Paremale
    Windows vene keeles #1 Windows vene keeles #2 Windows vene keeles #3 Windows vene keeles #4 Windows vene keeles #5 Windows vene keeles #6 Windows vene keeles #7 Windows vene keeles #8 Windows vene keeles #9 Windows vene keeles #10 Windows vene keeles #11 Windows vene keeles #12 Windows vene keeles #13 Windows vene keeles #14 Windows vene keeles #15 Windows vene keeles #16 Windows vene keeles #17 Windows vene keeles #18 Windows vene keeles #19 Windows vene keeles #20 Windows vene keeles #21 Windows vene keeles #22 Windows vene keeles #23 Windows vene keeles #24 Windows vene keeles #25 Windows vene keeles #26 Windows vene keeles #27 Windows vene keeles #28 Windows vene keeles #29 Windows vene keeles #30 Windows vene keeles #31 Windows vene keeles #32 Windows vene keeles #33 Windows vene keeles #34 Windows vene keeles #35 Windows vene keeles #36 Windows vene keeles #37 Windows vene keeles #38 Windows vene keeles #39 Windows vene keeles #40 Windows vene keeles #41 Windows vene keeles #42 Windows vene keeles #43 Windows vene keeles #44 Windows vene keeles #45 Windows vene keeles #46 Windows vene keeles #47 Windows vene keeles #48 Windows vene keeles #49 Windows vene keeles #50 Windows vene keeles #51 Windows vene keeles #52 Windows vene keeles #53 Windows vene keeles #54 Windows vene keeles #55 Windows vene keeles #56 Windows vene keeles #57 Windows vene keeles #58 Windows vene keeles #59 Windows vene keeles #60 Windows vene keeles #61 Windows vene keeles #62 Windows vene keeles #63 Windows vene keeles #64 Windows vene keeles #65 Windows vene keeles #66 Windows vene keeles #67 Windows vene keeles #68 Windows vene keeles #69 Windows vene keeles #70 Windows vene keeles #71 Windows vene keeles #72 Windows vene keeles #73 Windows vene keeles #74 Windows vene keeles #75 Windows vene keeles #76 Windows vene keeles #77 Windows vene keeles #78 Windows vene keeles #79 Windows vene keeles #80 Windows vene keeles #81 Windows vene keeles #82 Windows vene keeles #83 Windows vene keeles #84 Windows vene keeles #85 Windows vene keeles #86 Windows vene keeles #87 Windows vene keeles #88 Windows vene keeles #89 Windows vene keeles #90 Windows vene keeles #91 Windows vene keeles #92 Windows vene keeles #93 Windows vene keeles #94 Windows vene keeles #95 Windows vene keeles #96 Windows vene keeles #97 Windows vene keeles #98 Windows vene keeles #99 Windows vene keeles #100 Windows vene keeles #101 Windows vene keeles #102 Windows vene keeles #103 Windows vene keeles #104 Windows vene keeles #105 Windows vene keeles #106 Windows vene keeles #107 Windows vene keeles #108 Windows vene keeles #109 Windows vene keeles #110 Windows vene keeles #111 Windows vene keeles #112 Windows vene keeles #113 Windows vene keeles #114 Windows vene keeles #115 Windows vene keeles #116 Windows vene keeles #117 Windows vene keeles #118 Windows vene keeles #119 Windows vene keeles #120 Windows vene keeles #121 Windows vene keeles #122 Windows vene keeles #123 Windows vene keeles #124 Windows vene keeles #125 Windows vene keeles #126 Windows vene keeles #127 Windows vene keeles #128 Windows vene keeles #129 Windows vene keeles #130 Windows vene keeles #131 Windows vene keeles #132 Windows vene keeles #133 Windows vene keeles #134 Windows vene keeles #135 Windows vene keeles #136 Windows vene keeles #137 Windows vene keeles #138 Windows vene keeles #139 Windows vene keeles #140 Windows vene keeles #141 Windows vene keeles #142 Windows vene keeles #143 Windows vene keeles #144 Windows vene keeles #145 Windows vene keeles #146 Windows vene keeles #147 Windows vene keeles #148 Windows vene keeles #149 Windows vene keeles #150 Windows vene keeles #151 Windows vene keeles #152 Windows vene keeles #153 Windows vene keeles #154 Windows vene keeles #155 Windows vene keeles #156 Windows vene keeles #157 Windows vene keeles #158 Windows vene keeles #159 Windows vene keeles #160 Windows vene keeles #161 Windows vene keeles #162 Windows vene keeles #163 Windows vene keeles #164 Windows vene keeles #165 Windows vene keeles #166 Windows vene keeles #167 Windows vene keeles #168 Windows vene keeles #169 Windows vene keeles #170 Windows vene keeles #171 Windows vene keeles #172 Windows vene keeles #173 Windows vene keeles #174 Windows vene keeles #175 Windows vene keeles #176 Windows vene keeles #177 Windows vene keeles #178 Windows vene keeles #179 Windows vene keeles #180 Windows vene keeles #181 Windows vene keeles #182 Windows vene keeles #183 Windows vene keeles #184 Windows vene keeles #185 Windows vene keeles #186 Windows vene keeles #187 Windows vene keeles #188 Windows vene keeles #189 Windows vene keeles #190 Windows vene keeles #191 Windows vene keeles #192 Windows vene keeles #193 Windows vene keeles #194 Windows vene keeles #195 Windows vene keeles #196 Windows vene keeles #197 Windows vene keeles #198 Windows vene keeles #199 Windows vene keeles #200 Windows vene keeles #201 Windows vene keeles #202 Windows vene keeles #203 Windows vene keeles #204 Windows vene keeles #205 Windows vene keeles #206 Windows vene keeles #207 Windows vene keeles #208 Windows vene keeles #209 Windows vene keeles #210 Windows vene keeles #211 Windows vene keeles #212 Windows vene keeles #213 Windows vene keeles #214 Windows vene keeles #215 Windows vene keeles #216 Windows vene keeles #217 Windows vene keeles #218 Windows vene keeles #219 Windows vene keeles #220 Windows vene keeles #221 Windows vene keeles #222 Windows vene keeles #223 Windows vene keeles #224 Windows vene keeles #225 Windows vene keeles #226 Windows vene keeles #227 Windows vene keeles #228 Windows vene keeles #229 Windows vene keeles #230 Windows vene keeles #231 Windows vene keeles #232 Windows vene keeles #233 Windows vene keeles #234 Windows vene keeles #235 Windows vene keeles #236 Windows vene keeles #237 Windows vene keeles #238 Windows vene keeles #239 Windows vene keeles #240 Windows vene keeles #241 Windows vene keeles #242 Windows vene keeles #243 Windows vene keeles #244 Windows vene keeles #245 Windows vene keeles #246 Windows vene keeles #247 Windows vene keeles #248 Windows vene keeles #249 Windows vene keeles #250 Windows vene keeles #251 Windows vene keeles #252 Windows vene keeles #253 Windows vene keeles #254 Windows vene keeles #255 Windows vene keeles #256 Windows vene keeles #257 Windows vene keeles #258 Windows vene keeles #259 Windows vene keeles #260 Windows vene keeles #261 Windows vene keeles #262 Windows vene keeles #263 Windows vene keeles #264 Windows vene keeles #265 Windows vene keeles #266 Windows vene keeles #267 Windows vene keeles #268 Windows vene keeles #269 Windows vene keeles #270 Windows vene keeles #271 Windows vene keeles #272 Windows vene keeles #273 Windows vene keeles #274 Windows vene keeles #275 Windows vene keeles #276 Windows vene keeles #277 Windows vene keeles #278 Windows vene keeles #279 Windows vene keeles #280 Windows vene keeles #281 Windows vene keeles #282 Windows vene keeles #283 Windows vene keeles #284 Windows vene keeles #285 Windows vene keeles #286 Windows vene keeles #287 Windows vene keeles #288 Windows vene keeles #289 Windows vene keeles #290 Windows vene keeles #291 Windows vene keeles #292 Windows vene keeles #293 Windows vene keeles #294 Windows vene keeles #295 Windows vene keeles #296 Windows vene keeles #297 Windows vene keeles #298 Windows vene keeles #299 Windows vene keeles #300 Windows vene keeles #301 Windows vene keeles #302 Windows vene keeles #303 Windows vene keeles #304 Windows vene keeles #305 Windows vene keeles #306 Windows vene keeles #307 Windows vene keeles #308 Windows vene keeles #309 Windows vene keeles #310 Windows vene keeles #311 Windows vene keeles #312 Windows vene keeles #313 Windows vene keeles #314 Windows vene keeles #315 Windows vene keeles #316 Windows vene keeles #317 Windows vene keeles #318 Windows vene keeles #319 Windows vene keeles #320 Windows vene keeles #321 Windows vene keeles #322 Windows vene keeles #323 Windows vene keeles #324 Windows vene keeles #325 Windows vene keeles #326 Windows vene keeles #327 Windows vene keeles #328 Windows vene keeles #329 Windows vene keeles #330 Windows vene keeles #331 Windows vene keeles #332 Windows vene keeles #333 Windows vene keeles #334 Windows vene keeles #335 Windows vene keeles #336 Windows vene keeles #337 Windows vene keeles #338 Windows vene keeles #339 Windows vene keeles #340 Windows vene keeles #341 Windows vene keeles #342 Windows vene keeles #343 Windows vene keeles #344 Windows vene keeles #345 Windows vene keeles #346 Windows vene keeles #347 Windows vene keeles #348 Windows vene keeles #349 Windows vene keeles #350 Windows vene keeles #351 Windows vene keeles #352 Windows vene keeles #353 Windows vene keeles #354 Windows vene keeles #355 Windows vene keeles #356 Windows vene keeles #357 Windows vene keeles #358 Windows vene keeles #359 Windows vene keeles #360 Windows vene keeles #361 Windows vene keeles #362 Windows vene keeles #363 Windows vene keeles #364 Windows vene keeles #365 Windows vene keeles #366 Windows vene keeles #367 Windows vene keeles #368 Windows vene keeles #369 Windows vene keeles #370 Windows vene keeles #371 Windows vene keeles #372 Windows vene keeles #373 Windows vene keeles #374 Windows vene keeles #375 Windows vene keeles #376 Windows vene keeles #377 Windows vene keeles #378 Windows vene keeles #379 Windows vene keeles #380 Windows vene keeles #381 Windows vene keeles #382 Windows vene keeles #383 Windows vene keeles #384 Windows vene keeles #385 Windows vene keeles #386 Windows vene keeles #387 Windows vene keeles #388 Windows vene keeles #389 Windows vene keeles #390 Windows vene keeles #391 Windows vene keeles #392 Windows vene keeles #393 Windows vene keeles #394 Windows vene keeles #395 Windows vene keeles #396 Windows vene keeles #397 Windows vene keeles #398 Windows vene keeles #399 Windows vene keeles #400 Windows vene keeles #401 Windows vene keeles #402 Windows vene keeles #403 Windows vene keeles #404 Windows vene keeles #405 Windows vene keeles #406 Windows vene keeles #407 Windows vene keeles #408 Windows vene keeles #409 Windows vene keeles #410 Windows vene keeles #411 Windows vene keeles #412 Windows vene keeles #413 Windows vene keeles #414 Windows vene keeles #415 Windows vene keeles #416 Windows vene keeles #417 Windows vene keeles #418 Windows vene keeles #419 Windows vene keeles #420 Windows vene keeles #421 Windows vene keeles #422 Windows vene keeles #423 Windows vene keeles #424 Windows vene keeles #425 Windows vene keeles #426 Windows vene keeles #427 Windows vene keeles #428 Windows vene keeles #429 Windows vene keeles #430 Windows vene keeles #431 Windows vene keeles #432 Windows vene keeles #433 Windows vene keeles #434 Windows vene keeles #435 Windows vene keeles #436 Windows vene keeles #437 Windows vene keeles #438 Windows vene keeles #439 Windows vene keeles #440 Windows vene keeles #441 Windows vene keeles #442 Windows vene keeles #443 Windows vene keeles #444 Windows vene keeles #445 Windows vene keeles #446 Windows vene keeles #447 Windows vene keeles #448 Windows vene keeles #449 Windows vene keeles #450 Windows vene keeles #451 Windows vene keeles #452 Windows vene keeles #453 Windows vene keeles #454 Windows vene keeles #455 Windows vene keeles #456 Windows vene keeles #457 Windows vene keeles #458 Windows vene keeles #459 Windows vene keeles #460 Windows vene keeles #461 Windows vene keeles #462 Windows vene keeles #463 Windows vene keeles #464 Windows vene keeles #465 Windows vene keeles #466 Windows vene keeles #467 Windows vene keeles #468 Windows vene keeles #469 Windows vene keeles #470 Windows vene keeles #471 Windows vene keeles #472 Windows vene keeles #473 Windows vene keeles #474 Windows vene keeles #475 Windows vene keeles #476 Windows vene keeles #477 Windows vene keeles #478 Windows vene keeles #479 Windows vene keeles #480 Windows vene keeles #481 Windows vene keeles #482 Windows vene keeles #483 Windows vene keeles #484 Windows vene keeles #485 Windows vene keeles #486 Windows vene keeles #487 Windows vene keeles #488 Windows vene keeles #489 Windows vene keeles #490 Windows vene keeles #491 Windows vene keeles #492 Windows vene keeles #493 Windows vene keeles #494 Windows vene keeles #495 Windows vene keeles #496 Windows vene keeles #497 Windows vene keeles #498 Windows vene keeles #499 Windows vene keeles #500 Windows vene keeles #501 Windows vene keeles #502 Windows vene keeles #503 Windows vene keeles #504 Windows vene keeles #505 Windows vene keeles #506 Windows vene keeles #507 Windows vene keeles #508 Windows vene keeles #509 Windows vene keeles #510 Windows vene keeles #511 Windows vene keeles #512 Windows vene keeles #513 Windows vene keeles #514 Windows vene keeles #515 Windows vene keeles #516 Windows vene keeles #517 Windows vene keeles #518 Windows vene keeles #519 Windows vene keeles #520 Windows vene keeles #521 Windows vene keeles #522 Windows vene keeles #523 Windows vene keeles #524 Windows vene keeles #525 Windows vene keeles #526 Windows vene keeles #527 Windows vene keeles #528 Windows vene keeles #529 Windows vene keeles #530 Windows vene keeles #531 Windows vene keeles #532 Windows vene keeles #533 Windows vene keeles #534 Windows vene keeles #535 Windows vene keeles #536 Windows vene keeles #537 Windows vene keeles #538 Windows vene keeles #539 Windows vene keeles #540 Windows vene keeles #541 Windows vene keeles #542 Windows vene keeles #543 Windows vene keeles #544 Windows vene keeles #545 Windows vene keeles #546 Windows vene keeles #547 Windows vene keeles #548 Windows vene keeles #549 Windows vene keeles #550 Windows vene keeles #551 Windows vene keeles #552 Windows vene keeles #553 Windows vene keeles #554 Windows vene keeles #555 Windows vene keeles #556 Windows vene keeles #557 Windows vene keeles #558 Windows vene keeles #559 Windows vene keeles #560 Windows vene keeles #561 Windows vene keeles #562 Windows vene keeles #563 Windows vene keeles #564 Windows vene keeles #565 Windows vene keeles #566 Windows vene keeles #567 Windows vene keeles #568 Windows vene keeles #569 Windows vene keeles #570 Windows vene keeles #571 Windows vene keeles #572 Windows vene keeles #573 Windows vene keeles #574 Windows vene keeles #575 Windows vene keeles #576 Windows vene keeles #577 Windows vene keeles #578 Windows vene keeles #579 Windows vene keeles #580 Windows vene keeles #581 Windows vene keeles #582 Windows vene keeles #583 Windows vene keeles #584 Windows vene keeles #585 Windows vene keeles #586 Windows vene keeles #587 Windows vene keeles #588 Windows vene keeles #589 Windows vene keeles #590 Windows vene keeles #591 Windows vene keeles #592 Windows vene keeles #593 Windows vene keeles #594 Windows vene keeles #595 Windows vene keeles #596 Windows vene keeles #597 Windows vene keeles #598 Windows vene keeles #599 Windows vene keeles #600 Windows vene keeles #601 Windows vene keeles #602 Windows vene keeles #603 Windows vene keeles #604 Windows vene keeles #605 Windows vene keeles #606 Windows vene keeles #607 Windows vene keeles #608 Windows vene keeles #609 Windows vene keeles #610 Windows vene keeles #611 Windows vene keeles #612 Windows vene keeles #613 Windows vene keeles #614 Windows vene keeles #615 Windows vene keeles #616 Windows vene keeles #617 Windows vene keeles #618 Windows vene keeles #619 Windows vene keeles #620 Windows vene keeles #621 Windows vene keeles #622 Windows vene keeles #623 Windows vene keeles #624 Windows vene keeles #625 Windows vene keeles #626 Windows vene keeles #627 Windows vene keeles #628 Windows vene keeles #629 Windows vene keeles #630 Windows vene keeles #631 Windows vene keeles #632 Windows vene keeles #633 Windows vene keeles #634 Windows vene keeles #635 Windows vene keeles #636 Windows vene keeles #637 Windows vene keeles #638 Windows vene keeles #639 Windows vene keeles #640 Windows vene keeles #641 Windows vene keeles #642 Windows vene keeles #643 Windows vene keeles #644 Windows vene keeles #645 Windows vene keeles #646 Windows vene keeles #647 Windows vene keeles #648 Windows vene keeles #649 Windows vene keeles #650 Windows vene keeles #651 Windows vene keeles #652 Windows vene keeles #653 Windows vene keeles #654 Windows vene keeles #655 Windows vene keeles #656 Windows vene keeles #657 Windows vene keeles #658 Windows vene keeles #659 Windows vene keeles #660 Windows vene keeles #661 Windows vene keeles #662 Windows vene keeles #663 Windows vene keeles #664 Windows vene keeles #665 Windows vene keeles #666 Windows vene keeles #667 Windows vene keeles #668 Windows vene keeles #669 Windows vene keeles #670 Windows vene keeles #671 Windows vene keeles #672 Windows vene keeles #673 Windows vene keeles #674 Windows vene keeles #675 Windows vene keeles #676 Windows vene keeles #677 Windows vene keeles #678 Windows vene keeles #679 Windows vene keeles #680 Windows vene keeles #681 Windows vene keeles #682 Windows vene keeles #683 Windows vene keeles #684 Windows vene keeles #685 Windows vene keeles #686 Windows vene keeles #687 Windows vene keeles #688 Windows vene keeles #689 Windows vene keeles #690 Windows vene keeles #691 Windows vene keeles #692 Windows vene keeles #693 Windows vene keeles #694 Windows vene keeles #695 Windows vene keeles #696 Windows vene keeles #697 Windows vene keeles #698 Windows vene keeles #699 Windows vene keeles #700 Windows vene keeles #701 Windows vene keeles #702 Windows vene keeles #703 Windows vene keeles #704 Windows vene keeles #705 Windows vene keeles #706 Windows vene keeles #707 Windows vene keeles #708 Windows vene keeles #709 Windows vene keeles #710 Windows vene keeles #711 Windows vene keeles #712 Windows vene keeles #713 Windows vene keeles #714 Windows vene keeles #715 Windows vene keeles #716 Windows vene keeles #717 Windows vene keeles #718 Windows vene keeles #719 Windows vene keeles #720 Windows vene keeles #721 Windows vene keeles #722 Windows vene keeles #723 Windows vene keeles #724
    Punktid 100 punkti Autor soovib selle materjali allalaadimise eest saada 100 punkti.
    Leheküljed ~ 724 lehte Lehekülgede arv dokumendis
    Aeg2013-09-27 Kuupäev, millal dokument üles laeti
    Allalaadimisi 3 laadimist Kokku alla laetud
    Kommentaarid 0 arvamust Teiste kasutajate poolt lisatud kommentaarid
    Autor olegpetrov Õppematerjali autor
    Kontrollitud
    PDF TXT
    Kasutamine Windows keskkonnas DNS süsteemi. Artikkel Vene keeles 2013.a.
    Windows vene keel

    Kasutatud allikad

    Sarnased õppematerjalid

    Jeffrey Moore Crossing Kuristik-Kuidas tuua tehnoloogia massitootesse
    36
    rtf

    Jeffrey Moore Crossing Kuristik. Kuidas tuua tehnoloogia massitootesse

    Сначала компании этого не понимают. Два известнейших примера нынешнего лидерства 4 Издана на русском языке: Паккард В. Тайные манипуляторы. М.: Смысл, 2004. 8 на рынке – первый компьютер Macintosh и первая версия Windows – были откровенно слабыми и требовали существенных переделок, прежде чем достигли стремительного сегодняшнего успеха. И это стало возможным, потому что Apple и Microsoft поддерживали тесные контакты со своими клиентами и другими участниками рынка персональных компьютеров.

    Tehnoloogia
    õÄõ EDI
    10
    docx

    �õÄõ��� EDI

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

    Kategoriseerimata
    õÄõ EDI
    10
    docx

    �õÄõ��� EDI

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

    Kategoriseerimata
    Võlaoigus
    72
    doc

    Võlaoigus

    1 Tallinna Majanduskool Võlaõigus I.Samohvalova Tallinn, 2014 2 ОБЩИЕ ПОЛОЖЕНИЯ. Обязательственные отношения – это правовые отношения, из которых вытекает обязательство одного лица (обязанное лицо или должник) совершить в пользу другого лица (управомоченное лицо или кредитор) определенное действие или не совершить его (т.е. исполнить обязательство) и право кредитора требовать от должника исполнения обязательства. Обязательственные отношения могут возникать: 1. из договор?

    Vene keel
    áõ üõý----ý-- ýþý õ-þý--
    31
    doc

    áõ�üõý����� ��ý�� ��ýþý�õ �þý����

    1 Содержание Введение 3 Глава 1.Сегментация рынка. Осноные понятия. Разновидности и методы сегментирования 1.1.Осноные понятия 5 1.2. Разновидности и методы сигментирования 9 Глава 2.Основные критерии и признаки сегментирования рынка 2.1. Критерии и признаки сегментирования рынка 11 2.2. Сегментирование рынка по группам потребителей 14 2.3. Сегментирование рынка по группам продуктов 18 Глава 3.Этапы и оценка эффективности с?

    Avaliku sektori ökonoomika
    Füüsika eksami vastused
    36
    docx

    Füüsika eksami vastused

    1.Электростатика — раздел учения об электричестве, изучающий взаимодействие неподвижных электрических зарядов. Между одноимённо заряженными телами возникает электростатическое (или кулоновское) отталкивание, а между разноимённо заряженными — электростатическое притяжение. Явление отталкивания одноименных зарядов лежит в основе создания электроскопа — прибора для обнаружения электрических зарядов. В основе электростатики лежит закон Кулона. Этот закон описывает взаимодействие точечных электрических зарядов. 1.1.Электрическое по?

    Vene keel
    Ehitusjäätmete käitlemine
    38
    docx

    Ehitusjäätmete käitlemine

    TALLINNA TEHNIKAÜLIKOOL Virumaa Kolledž RAH3170 Keskkonnakaitse Dmitri Timoškin 124445 RDBR 22 Ehitusjäätmete käitlemine Referaat Õppejõud: lektor A. Zguro Kohtla-Järve 2013 СОДЕРЖАНИЕ ВВЕДЕНИЕ.............................................................................................................................3 1. СТРОИТЕЛЬНЫЕ ОТХОДЫ...........................................................................................4 1.1. Применение строительных отходов 4 1.2. Использование строительных переработанных отходов 5 2. ЗАКОНОДАТЕЛЬСТВО В ЭСТОНИИ..........................................

    Vene keel
    legkaya atletika fizicheskaya kultura
    92
    doc

    legkaya atletika fizicheskaya kultura

    МИНИСТЕРСТВО СПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «Российский государственный университет физической культуры, спорта, молодежи и туризма (ГЦОЛИФК)» Кафедра Теории и методики легкой атлетики Гридасова Е.Я., Мальцева Л. И., Аракелян Е.Е. ЛЕГКАЯ АТЛЕТИКА Курс лекций для студентов РГУФКСМиТ, обучающихся по направлению подготовки 49.03.01 – Физическая культура Москва – 2019

    Inimese füsioloogia


    Rohkem sarnaseid



    Kommentaarid (0)

    Kommentaarid sellele materjalile puuduvad. Ole esimene ja kommenteeri



    Kõik kommentaarid



    Info
    K & V
    Mäng
    Eraõpetajad
    Meist
    Kuidas saada punkte?
    KKK
    Reklaam
    Uudistevoog
    Sitemap
    Kontakt
    Saada kiri
    kiri@annaabi.ee
    Telefon: +372-569-80010
    Aadress: Tiskrevälja 33, Tallinn
    OÜ LOLSOL. Registrikood: 11450433
    Kasutustingimused
    Privaatsustingimused
    Sõnastikud
    Inglise Soome Saksa Vene Hispaania Prantsuse Rootsi Itaalia Ladina Taani Esperanto
    Püsiühendus(es)
    Facebook Instagram Twitter Reddit
    Sellel veebilehel kasutatakse küpsiseid. Kasutamist jätkates nõustute küpsiste ja veebilehe üldtingimustega Nõustun