Internet Information Services 6.0

Административный инструментарий

Административный инструментарий


Управление службами IIS может выполняться как локально, так и удаленно. Согласно концепции Microsoft, администратор может осуществлять управление всеми экземплярами служб IIS, развернутыми в корпоративной сети, с одной рабочей станции. В качестве основного административного инструмента администратор может использовать оснастку Internet Information Services (IIS) Manager. В случае, когда соединение с сервером устанавливается через Интернет или через брандмауэр, администратор может использовать утилиту Remote Administration (HTML) (Удаленное администрирование (HTML)). Данная утилита доступна через интернет-браузер и позволяет настраивать различные свойства узлов. Однако необходимо помнить о том, что, хотя утилита Remote Administration (HTML) и предоставляет большинство возможностей оснастки, отдельные операции с ее помощью не могут быть выполнены.

Утилита Remote Administration (HTML) может быть использована только для управления службами IIS 6.0. Оснастка Internet Information Services (IIS) Manager может использоваться для управления IIS версий 4.0, 5.0, 5.1 и 6.0. Чтобы иметь возможность использования утилиты Remote Administration (HTML), администратор должен вручную выполнить установку на сервере этого компонента IIS.
Для удаленного управления IIS можно также использовать возможности служб терминалов (Terminal Services). Удаленное управление может производиться с компьютера под управлением любой ОС, для которой существует клиент служб терминалов Microsoft, при этом на удаленном компьютере не нужно устанавливать никакие средства администрирования IIS.

Администрирование служб IIS

Администрирование служб IIS


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

Администрирование служб WWW и FTP

Администрирование служб WWW и FTP


В рамках одного экземпляра служб IIS может быть создано несколько веб-и/или FTP-сайтов (узлов), при этом можно применять разные подходы:

определив один адрес для всех сайтов, выделить для каждого из сайтов разные номера портов;

использовать несколько IP-адресов, назначенных одному сетевому адаптеру;

назначить разные доменные имена для одного IP-адреса и одного сетевого адаптера.

Предположим, что в корпоративной интрасети системный администратор установил на сервере компании систему Windows Server 2003 со службами IIS и создал единственный узел по умолчанию, который имеет адрес http://information. Системный администратор может создать два дополнительных информационных узла, по одному для каждого отдела, например, для отдела продаж (Sales) и для отдела закупок (Purchase).
Хотя оба узла расположены на одном компьютере (Information), они являются автономно функционирующими узлами (сайтами). Эти узлы имеют раздельные настройки защиты, как если бы они находились на разных компьютерах, поскольку каждый узел имеет собственные параметры доступа и настройки разрешений по администрированию. Кроме того, административные задачи могут быть распределены между членами каждого отдела.

В данном разделе мы подробно

Архитектура IIS 6.0


В данном разделе мы подробно рассмотрим архитектуру IIS 6.0. Однако, прежде чем перейти к обсуждению основных компонентов US и механизмов их взаимодействия, рассмотрим концепцию многоуровневых приложений, предлагаемую разработчикам корпорацией Microsoft.

Архитектура трехуровневых систем на базе служб Microsoft

Рисунок 16.1. Архитектура трехуровневых систем на базе служб Microsoft

Дополнительные механизмы

Дополнительные механизмы


Часто может потребоваться динамически изменять содержание узла после того, как содержание было затребовано, но до передачи его браузеру, US включает две возможности, которые обеспечивают эту функциональность — серверные включения (Server-Side Includes, SSI) и Microsoft Active Server Pages (ASP) — для создания сценариев-посредников.
Используя SSI. можно выполнять ряд действий — от динамического отображения текущего времени на странице до выполнения заданных системных команд каждый раз, когда запрашивается данный ресурс (страница). SSI-команды, называемые директивами, указываются на странице в процессе ее разработки. Когда страница запрашивается, веб-сервер анализирует синтаксис всех директив на странице, а затем выполняет их. Наиболее часто используется директива включения, что позволяет включать содержимое файла внутрь страницы. Например, если требуется, чтобы в заголовок страницы вставлялась реклама, можно при помощи SSI включить исходный текст рекламы. Чтобы модифицировать рекламу, нужно изменить только файл, содержащий исходный текст рекламы. Для применения SSI не нужно знать язык создания сценариев — синтаксис директив очень прост.
ASP-страницы — серверная среда создания сценариев, позволяющая динамически изменять содержимое узла. Хотя технология ASP предназначена прежде всего для разработки веб-приложений, она предоставляет много возможностей для создания более простых в управлении узлов. Например, с помощью ASP можно отслеживать посещение узла пользователями (их атрибуты — IP-адрес, тип браузера, назначенные cookies и т. п.) или настраивать содержимое узла под возможности браузера. Однако, в отличие от SSI, ASP требует применения языка создания сценария, например VBScript или JScript.

Формы запросов

Формы запросов


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

Длинная форма и краткие запросы. Большинство операторов в языке запросов имеет полную форму и соответствующую ей краткую. Например, Sdocauthor — краткое имя свойства Author, в то время как {prop name=DocAuthor} — длинная форма.

Символы режима в кратких запросах. В кратких запросах следующие символы указывают режим (табл. 16.7).

Функционирование службы NNTP

Функционирование службы NNTP


Служба NNTP реализует поддержку клиент-серверного протокола Network News Transfer Protocol (NNTP), при этом она выступает в роли сервера, а программа Microsoft Outlook Express — пример типичного клиента.
Клиенты подключаются к службе NNTP по протоколу TCP/IP. Обычно по умолчанию при нормальном подключении используется TCP-порт 119, для шифрованных SSL-подключений — TCP-порт 563.

Инструментарий для создания вебстраниц

Инструментарий для создания веб-страниц


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

Microsoft FrontPage 2002. Удобный, простой и мощный инструмент создания страниц и публикации их в сети. Обладает возможностями WYSIWYG (What You See Is What You Get, принцип "что видишь — то и получишь", т. е. визуальное создание с непосредственным отображением результата), тесно интегрирован с Microsoft Office XP и со службами IIS.

Преобразование в HTML. Привлекательная альтернатива созданию страниц — преобразование существующих документов в документы HTML. Применяя к файлам текстового процессора и электронных таблиц конвертер, можно сразу помещать такого рода страницы в сети, на вебсервере. Многие программы обработки текстов, например Microsoft Word XP (2002), имеют встроенные возможности для преобразования документов в формат HTML. Однако большинство конвертеров только добавляет тэги форматирования HTML к тексту, плохо сохраняя первоначальный вид документов. Конвертеры — удобные средства, они особенно полезны, если планируется публиковать большую часть существующей документации, которая не нуждается в частом изменении.

Текстовый редактор. Страницы можно создавать почти в любом стандартном текстовом редакторе, например, в Notepad (Блокнот), вводя тэги HTML и содержимое страниц, сохраняя в файле, а затем открывая их в браузере для предварительного просмотра. Некоторые опытные пользователь и предпочитают этот метод, потому что он обеспечивает более тонкий контроль форматирования страниц и позволяет применять последние технологические новшества Интернета.

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

Рисунок 16.4. Использование мастера Configure Your Server Wizard для установки служб IIS


Мастер предложит активизировать механизм ASP.NET и серверные расширения FrontPage 2002 (Рисунок 16.4). Затем мастер самостоятельно выполнит установку необходимых компонентов IIS и их начальную настройку.
Установка IIS с помощью утилиту Add or Remove Programs ориентирована на опытных администраторов, которые хотят установить только те компоненты IIS, которые действительно необходимы для решения стоящих перед ними задач. В окне утилиты нажмите кнопку Add/Remove Windows Components, чтобы запустить одноименный мастер. В первом окне мастера необходимо выбрать пункт Application Server (Сервер приложений) и нажать кнопку Details (Подробно). В открывшемся окне нужно установить флажок в строке Internet Information Services (IIS). При необходимости администратор может выбрать, какие именно компоненты IIS должны быть установлены, нажав кнопку Details (Подробно). Ниже перечислены компоненты IIS, которые предлагаются для установки.

Background Intelligent Transfer Service (BITS) Server Extensions (Серверные расширения BITS). Серверные расширения BITS представляют собой механизм фоновой передачи файлов и диспетчер очередей, позволяющий управлять качеством сервиса применительно к службе WWW.

Common files (Общие файлы). Базовые файлы, необходимые для функционирования всех компонентов IIS.

File Transfer Protocol (FTP) Service (Служба FTP). Выбор данного компонента позволяет установить в составе IIS службу FTP.

FrontPage 2002 Server Extensions (Серверные расширения FrontPage 2002). Компонент позволяет осуществлять управление веб-сайтами с помощью инструмента разработки Microsoft FrontPage 2002.

Internet Information Services Manager (Диспетчер служб IIS). Устанавливает оснастку ММС, которая используется для управления всеми компонентами IIS.

Internet Printing (Печать через Интернет). Компонент позволяет осуществлять управление принтерами через HTTP.

NNTP Service (Служба NNTP). Выбор данного компонента позволяет установить в составе IIS службу NNTP.

SMTP Service (Служба SMTP). Выбор данного компонента позволяет установить в составе IIS службу SMTP.

World Wide Web Service (Веб-сервер). Выбор данного компонента позволяет установить в составе IIS службу WWW.

Ключевые компоненты IIS

Ключевые компоненты IIS


В рамках операционной системы одни процессы, ассоциированные с отдельными компонентами IIS, функционируют в пользовательском режиме (user mode), а другие в режиме ядра (kernel mode).

Драйвер HTTP.sys. Функционирует в режиме ядра операционной системы, осуществляя прослушивание протокола HTTP. Данный драйвер является частью сетевой подсистемы Windows Server 2003, являясь, тем не менее, ключевым компонентом IIS 6.0. Каждый веб-сайт, созданный в рамках IIS, регистрируется драйвером HTTP.sys, который перенаправляет веб-запросы от пользователей процессам, функционирующим в пользевательском режиме. Аналогичным образом HTTP.sys возвращает пользователям ответы на их запросы.

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

Рабочие процессы. Рабочий процесс представляет собой приложение, функционирующее в пользовательском режиме. Рабочий процесс реализуется в виде запускаемого файла W3vvp.exe и контролируется компонентом управления и мониторинга службы WWW. Рабочие процессы используют драйвер HTTP.sys для взаимодействия с клиентами (получение запросов и передача запрашиваемых данных).

Процесс Inetinfo.exe. Данный процесс функционирует в пользовательском режиме. Этот процесс обеспечивает работу служб FTP, SMTP, NNTP и отвечает за поддержание метабазы IIS. В случае, когда службы IIS 6.0 функционируют в режиме изоляции IIS 5.0 (IIS 5.0 isolation mode), процесс Inetinfo.exe обеспечивает работу одиночного рабочего процесса.

Концепция многоуровневых приложений

Концепция многоуровневых приложений


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

представление данных;

бизнес-логика;

службы хранения данных.

Уровень представления данных включает всю работу с пользователем. На этом уровне пользователи могут не только взаимодействовать с приложением, вводить данные и просматривать результаты запросов, но и управлять манипулированием данными и их форматированием после того, как они попадают на клиентскую сторону. В веб-технологии задачи уровня представления данных выполняет браузер.
Службы хранения данных обеспечиваются различными структурированными хранилищами информации (серверами БД, например, Microsoft SQL Server, Oracle) или неструктурированными хранилищами (Microsoft Exchange, Microsoft Queue Messaging), которые управляют и обеспечивают доступ к данным из приложения. Отдельный запрос может потребовать использования одного или более хранилищ данных.
Между этими двумя уровнями находится область для разработки распределенных приложений. Уровень бизнес-логики задает правила управления обработкой приложений, соединяет пользователя на одном конце с данными на другом.
Трехуровневая архитектура изолирует каждый сегмент функциональных возможностей. Представление не зависит от правил обработки и бизнес-логики, которая, в свою очередь, является отдельной от данных. Эта модель требует намного больше затрат на анализ и проектирование, но значительно уменьшает расходы на техническую поддержку и сопровождение и, в конечном счете, увеличивает функциональную гибкость. На Рисунок 16.1 представлена схема, которая описывает технологии Microsoft, обслуживающие различные уровни в системах с новой архитектурой.

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

Рисунок 16.20. Настройка производительности службы индексирования


Закрыв диалоговое окно Indexing Service Usage (Применение службы индексирования), необходимо запустить службу индексирования, выбрав команду Start (Пуск) в меню Action (Действие).

Назначение и основные возможности

Назначение и основные возможности


Служба индексирования (Indexing Service) — стандартная служба, реализованная в Windows Server 2003, осуществляет индексирование файлов на локальном жестком диске, а также на общедоступных дисководах в сети. Также ее можно использовать для индексирования документов, хранящихся на сайтах, реализованных с помощью служб IIS. Выполнять поиск можно по индексу слова в содержании файлов или в свойствах файлов. Служба индексирования возвращает список всех документов, которые соответствуют критериям поиска.
Служба индексирования создана для непрерывной работы и не требует специального сопровождения. После того как она установлена, все действия осуществляются автоматически, включая создание индексов, обновление индексов и их восстановление в случае аварийного отказа, если произошел сбой питания. Служба индексирования безотказно работает в средах, критических по параметрам надежности и доступности, где сервер должен функционировать 24 часа в сутки и 7 дней в неделю.
Служба индексирования может индексировать:

файлы HTML;

текстовые файлы;

файлы Microsoft Office;

файлы почты Интернета;

любые другие файлы, для которых имеется фильтр документа.

Новые функциональные возможности служб Windows Media

Новые функциональные возможности служб Windows Media


В Windows Server 2003 реализованы службы Windows Media Services 9.0. В рамках данной версии разработчики сделали множество изменений и реализовали новые функциональные возможности. Эти возможности перечислены в табл. 16.10.

Новые возможности ASP

Новые возможности ASP


Active Server Pages (ASP) представляет собой основной механизм разработки веб-ориентированных приложений для IIS. ASP были дополнены возможностями, которые делают более легким применение ASP для разработчиков сценариев и веб-приложений. Кроме того, в архитектуре ASP произошел ряд существенных изменений, позволивших улучшить безопасность и производительность компонентов IIS.
Прежде всего, следует отметить тот факт, что поддержка ASP отключена по умолчанию. Чтобы иметь возможность размещать ASP-сценарии на вебсервере под управлением Windows Server 2003, администратор должен вручную разрешить на данном сервере механизм ASP.
Перечислим новые функциональные возможности, появившиеся в рамках IIS 6.0 ASP:

поддержка UTF-8. Поддержка формата LJTF-8 расширена для всех атрибутов и методов встроенных объектов ASP;

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

кэширование популярных файлов. Механизм ASP выполняет кэширование наиболее часто используемых файлов. Кэш размещается в оперативной памяти и при необходимости самые старые файлы из кэша сохраняются на диске;

поддержка формата UNC. Разработчики могут использовать в ASP-сценариях ссылки на ресурсы в формате UNC (ссылка вида \\<имя_хоста>\<имя_общей_папки>);

расширенная поддержка СОМ+-служб. В рамках IIS 6.0 расширены возможности использования СОМ+-служб в ASP-приложениях;

интеграция с XML. Язык extensible Markup Language (XML, Расширяемый язык разметки) позволяет легко описывать сложные структуры данных и совместно использовать информацию в клиентских и серверных приложениях. Новый синтаксический анализатор XML, включенный в Internet Explorer версии 4.0 и выше, сделал возможным создание ASP-приложений, позволяющих веб-серверу обмениваться форматированными данными XML с Internet Explorer и другими браузерами или с любыми другими серверами, имеющими поддержку XML.

Новые возможности

Новые возможности


Новые функциональные возможности и улучшения, реализованные разработчиками в архитектуре службы IIS 6.0, следует рассматривать в следующих аспектах:

улучшение стабильности служб;

улучшение защищенности служб;

улучшение производительности;

расширение возможностей служб IIS, предоставляемых разработчику;

расширение возможностей служб IIS, предоставляемых администратору.

Далее мы рассмотрим каждое из этих направлений более подробно.

Общедоступный виртуальный сервер новостей

Общедоступный виртуальный сервер новостей


Может потребоваться несколько телеконференций с различной тематикой на общедоступном сервере новостей. Например, зарегистрированным пользователям некоторого продукта требуется одна конференция, а потенциальным покупателям, только собирающимся сделать свой выбор, — другая.
Цель: Уменьшить затраты на поддержку пользователей и улучшить клиентскую службу, предоставив клиентам быстрый свободный доступ к информации и технической поддержке.
Программные компоненты: Microsoft Windows Server 2003, Microsoft Internet Information Services (IIS), Microsoft Internet Mail and News или Microsoft Outlook Express.
Среда: Интернет.
Установка: Разрешить анонимный доступ; использовать DNS или WINS для разрешения имени; обеспечить доступ через брандмауэр (при его наличии).
Прочие аспекты: Необходимо рассмотреть возможность организации модерируемых (редактируемых специально назначенным человеком, так называемым "модератором") конференций, чтобы предотвратить публикацию некорректных, технически неправильных статей. Это может ограничить возможность клиентов помочь друг другу, если персонал поддержки недоступен в настоящий момент.
Функционирование: Если службы IIS уже используются, то для обеспечения технической поддержки через публикацию технической информации на вебсервере можно просто добавить поддержку телеконференций на том же компьютере. Если планируется активно использовать сервер телеконференций, можно расположить службу NNTP на отдельном компьютере.
Можно создать отдельную телеконференцию для каждого продукта, для которого требуется техническая поддержка, или создать несколько телеконференций для каждого продукта, одну для каждой темы поддержки.
URL-адреса для телеконференций будут иметь стандартные форматы (см. выше).
Чтобы обеспечить наискорейшую отдачу от телеконференций, персонал поддержки клиентов должен достаточно часто читать статьи в телеконференциях и быстро отвечать на вопросы. Одним из удобных средств может оказаться публикация часто задаваемых вопросов (Frequently Asked Questions, FAQ) и ответов на них.
Результат: Клиенты получают более эффективную поддержку и, следовательно, в большей степени удовлетворены применяемыми продуктами, т. к. они имеют непосредственный доступ к самой свежей информации, касающейся этих продуктов. Производительность труда у персонала поддержки будет выше, т. к. теперь не нужно много раз отвечать на один и тот же вопрос.

Обзор служб Internet Information Services (IIS)

Обзор служб Internet Information Services (IIS)


Набор служб Интернета (IIS) традиционно позиционировался Microsoft как одна из важнейших составляющих серверного программного обеспечения. Начиная с Windows 2000, службы IIS поставляются непосредственно в составе операционной системы (ранее они поставлялись в виде дополнительного пакета, расширяющего возможности операционной системы). В Windows Server 2003 реализована новая, шестая версия служб IIS (далее IIS 6.0), реализующая принципиально новый подход Microsoft к построению защищенных и многоплатформенных интернет-приложений.
Службы IIS базируются на ряде открытых стандартов Интернета, перечень которых с кратким описанием дается в табл. 16.1.

Окно свойств службы NNTP

Рисунок 16.12. Окно свойств службы NNTP


Виртуальный сервер, который создается по умолчанию на сервере после инсталляции службы, — Default NNTP Virtual Server. Служба NNTP может состоять из одного или большего количества виртуальных серверов NNTP.
Чтобы просмотреть или изменить свойства виртуального сервера NNTP, необходимо в пространстве имен утилиты выбрать требуемый виртуальный сервер NNTP и в меню Action (Действие) выполнить команду Properties (Свойства). Затем перейдите на требуемую вкладку в диалоговом окне (Рисунок 16.12) и измените нужные опции по необходимости.

Оснастка Component Services

Рисунок 16.18. Оснастка Component Services

Оснастка Internet Information Services (IIS) Manager

Оснастка Internet Information Services (IIS) Manager


Оснастка Internet Information Services (IIS) Manager (Рисунок 16.5) представляет собой инструмент администрирования IIS, который доступен из меню Start | Administrative Tools | Internet Information Services (IIS) Manager (Пуск | Администрирование | Диспетчер информационных служб Интернета).
Также она включена в состав оснастки Computer Management (Управление компьютером).

Рисунок 16.5. Оснастка Internet Information Services (IIS) Manager

Оснастка Internet Information

Рисунок 16.11. Оснастка Internet Information Services (IIS) Manager — управление службой NNTP

Интеграция со службой индексирования. Служба NNTP поддерживает полнотекстовое индексирование содержания и индексирование по свойствам групп новостей.

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

анонимный доступ (anonymous access). Разрешает любому пользователю доступ к группе новостей, не требует указания имени пользователя или пароля;

стандартное расширение безопасности NNTP (Standard Secure NNTP extension). Требует, чтобы пользователь предоставил имя пользователя и пароль, которые посылаются по сети открытым текстом;

протокол вызова/ответа Windows (Windows Challenge/Answer Protocol). Требует, чтобы пользователь предоставил имя пользователя и пароль, которые передаются в шифрованном виде для безопасной передачи по сети. Этот протокол требует использования клиентского программного обеспечения Microsoft Internet Mail and News (или Outlook Express);

протокол SSL (Secure Sockets Layer). Чтобы защитить информацию, передаваемую через общую сеть, служба NNTP поддерживает шифрование SSL, которое включает проверку подлинности клиентов и серверов.

Оснастка POPS Service

Рисунок 16.17. Оснастка POPS Service

Оснастка управления службой индексирования

Рисунок 16.19. Оснастка управления службой индексирования


Запустите оснастку Computer Management (Управление компьютером). В пространстве имен оснастки разверните узел Services and Applications | Indexing Service (Службы и приложения Служба индексирования). Для настройки производительности службы индексирования необходимо остановить службу, выбрав в меню Action (Действие) пункт Stop (Стоп). Затем в меню Action (Действие) выберите пункт All Tasks | Tune Performance (Все задачи | Настройка производительности).
В открывшемся окне Indexing Service Usage (Применение службы индексирования) выберите вариант, наиболее соответствующий способу использования службы индексирования на данном компьютере. Если выбран вариант пользовательской настройки — Customize (Настроить), необходимо нажать одноименную кнопку. В диалоговом окне Desired Performance (Производительность индексации) (Рисунок 16.20) необходимо переместить ползунок Indexing (Построение индекса) в сторону Lazy (Отложенное) для менее интенсивного индексирования или в сторону Instant (Немедленное) для скорейшего индексирования новых и измененных документов. Отложенное индексирование использует меньшее количество ресурсов компьютера; а немедленное — столько ресурсов, сколько возможно. Ползунок Querying (Скорость обработки запросов) необходимо переместить в сторону Low load (Низкая), если ожидается обработка малого количества запросов одновременно, или High load (Высокая), если ожидается обработка большого количества запросов одновременно. Обработка с низкой скоростью использует меньшее количество ресурсов, а с высокой, соответственно, — большее.

Оснастка Windows Media Services

Рисунок 16.24. Оснастка Windows Media Services

Основные возможности

Основные возможности


Служба NNTP проста в управлении, поскольку содержит удобные инструменты и поддерживает тесную интеграцию с Windows Sewer 2003. Ниже перечислены основные возможности службы NNTP.

Поддержка стандартов Интернета. Служба NNTP поддерживает Network News Transport Protocol (NNTP, Сетевой протокол передачи новостей), который предназначен для связи клиента с сервером, а также для связи двух серверов. Служба NNTP поддерживает популярные расширения NNTP и полностью совместима с другими клиентами и серверами NNTP. Кроме того, служба NNTP поддерживает многочисленные форматы, включая:

Multipurpose Internet Mail Extension (MIME);

язык разметки гипертекста HTML;

формат изображений GIF;

формат изображений JPEG.

Простота администрирования. Администрирование службы NNTP осуществляется посредством оснастки Internet Information Services (IIS) Manager. С помощью этой оснастки управление службой NNTP осуществляется в пределах одной ЛВС. Этот инструмент позволяет управлять всеми компонентами IIS, используя единый интерфейс (Рисунок 16.11).

Интеграция со службами Windows Server 2003. Служба NNTP полностью использует преимущества стандартных инструментов администрирования Windows Server 2003 для текущего контроля производительности и отслеживания событий. При инсталляции службы NNTP устанавливается набор счетчиков для системного монитора (System Monitor). Все состояния службы NNTP и сообщения об ошибках записываются в журналы событий и могут просматриваться при помощи оснастки Event Viewer (Просмотр событий). Служба NNTP также включает поддержку протокола SNMP. Служба NNTP управляет доступом к группам новостей, используя списки ACL системы безопасности Windows Server 2003. Устанавливая разрешения на каталог, который содержит группу новостей, можно управлять доступом к этой группе новостей. Можно также разрешить анонимный доступ, при этом доступ к группе новостей будет предоставлен всем.

Основы работы

Основы работы


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

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

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

Инкрементный просмотр также выполняется, если система теряет уведомления об изменениях. Это может случиться, если изменилось большое количество документов, и буфер Windows Server 2003, используемый для получения уведомлений об изменениях, переполняется. Инкрементный просмотр, так же как и полный просмотр, можно принудительно запустить в любое время.
Для каждого документа, который будет проиндексирован, служба индексирования выполняет следующие действия:
1. Используя соответствующий документу фильтр, считывает документ, извлекает из него значения свойств документа и выделяет содержание. Сохраняет значения свойств документа и путь к документу в индексе.
2. Разбивает поток предложений на отдельные слова. Для того чтобы разбить текст на слова, служба индексирования использует процедуры, соответствующие языку документа — английскому, немецкому, японскому и т. д.
3. Удаляет незначащие слова — предлоги, междометия, вспомогательные глаголы и т. д.
4. Сохраняет оставшиеся слова и путь к документу в индексе.
5. Сохраняет значения выбранных свойств документа в кэше свойств.
Фильтры — программные компоненты, которые "понимают" структуру файла соответствующего типа, например, документа Microsoft Word или HTML. Фильтр извлекает содержание и значения свойств и посылает их ядру индексации.
Служба индексирования поставляется с фильтрами для отдельных популярных типов файлов, созданных, например, приложениями Microsoft Office. Фильтры для файлов, созданных в других приложениях, часто можно получить от поставщиков соответствующего программного обеспечения.

Переадресация запросов

Переадресация запросов


Когда браузер запрашивает страницу с узла, веб-сервер ищет страницу по заданному URL и возвращает ее браузеру. Когда страница перемещается внутри узла, не всегда можно исправить все связи, которые ссылаются на старый URL-адрес страницы. Чтобы удостовериться в том, что браузеры смогут найти страницу по новому URL, можно заставить веб-сервер предоставлять браузеру новый URL. Браузер использует новый URL, чтобы запросить эту страницу снова. Этот процесс называется переадресацией запроса браузера или переадресацией на другой URL. Переадресация запроса о получении страницы подобна переадресации в почтовой службе. Переадресация гарантирует, что письма и пакеты, отправленные по предыдущему адресу вашего проживания, будут доставлены по новому адресу.
Переадресация URL полезна (см., например, переключатель A redirection to a URL на Рисунок 16.10), когда узел подвергается переделкам и нужно сделать часть узла (каталог) временно недоступной, или когда было изменено имя виртуального каталога и нужно заставить браузеры обращаться не к файлам в исходном виртуальном каталоге, а к тем же самым файлам в новом виртуальном каталоге.

Подготовка к установке

Подготовка к установке


Перед установкой служб IIS может потребоваться дополнительное конфигурирование системы.

Поиск информации с помощью службы индексирования

Поиск информации с помощью службы индексирования


При поиске информации запрос посылается службе индексирования. Служба индексирования, просматривая индекс, ищет документы, соответствуюшие критериям запроса, и возвращает список соответствующих запросу документов пользователю (или приложению, пославшему запрос). В дополнение к запросу по содержанию можно сделать запрос по свойствам файлов. Эти свойства включают: размер файла, даты создания и изменения, имя файла, авторов файла и т. д. Можно, например, сделать запрос по текстовым свойствам (имя файла и автор) и числовым свойствам (размер и дата изменения). Можно также сделать запрос по всем свойствам элементов ActiveX, включая пользовательские свойства документов Microsoft Office.
Поиск документов может быть выполнен одним из трех способов:

с помощью команды Search | All files and folders (Найти | Файлы и папки) меню Start (Пуск);

используя веб-страницу для передачи запроса на выполнение через службы IIS. Для веб-доступа владелец или администратор узла создает вебстраницу (документ HTML), из которой можно посылать на выполнение запросы. Страница может быть настроена для упрощения ввода и улучшения вида запросов и поиска информации по различным критериям. Автор страницы может также задавать отдельные индексы или части индексов, по которым нужно производить поиск. Результаты поиска возвращаются в виде веб-страницы;

при помощи оснастки Indexing Service. Форма запроса может быть включена в каждый каталог в службе. При помощи этой формы можно выполнять любой вид запросов, используя все возможности языка запросов. Чтобы открыть форму запроса, запустите оснастку Indexing Service, выберите требуемый каталог и узел Query the Catalog (Опрос каталога). Форма запроса появится в результирующей панели оснастки.

Правила составления запросов

Правила составления запросов


Имеются пять видов запросов:

свободные текстовые запросы;

запросы-фразы;

запросы сопоставления с образцом;

относительные запросы;

векторно-пространственные запросы.

Правила, относящиеся к запросам всех видов:

в запросах не различаются строчные и прописные буквы;

можно искать любое слово, если оно не содержится в списке исключений;

для того чтобы использовать специальные символы в запросе (типа &, |, ^, # и $), нужно заключить запрос в кавычки;

Значения даты и времени имеют одну из двух форм: yyyy/mmdd hh:mm:ss или yyyy-ram-dd hh:mm:ss. Первые два символа года и полного времени могут быть опущены. Если опускаются первые два символа года, дата интерпретируется как находящаяся в интервале между 1930 и 2029 гг. Трехзначное число миллисекунд может быть задано после секунд. Все даты и времена задаются в UTC (Universal Coordinated Time, Скоординированное всемирное время). Пример задания времени: 1993/П/7 12:04:23:123.

Дата и время относительно текущей даты и времени могут быть выражены со знаком "минус" (-), за которым следует одна или более пар "целое число-единица". Единицы задаются так: у — число лет, q — число кварталов (три месяца), гп — число месяцев, w — число недель, d — число дней, h — число часов, п — число минут из — число секунд. Числовые значения могут быть заданы в десятичном или в шестнадцатеричном виде. Шестнадцатеричные значения предваряются символами "0х".
Для поиска слова или фразы в заданном свойстве можно использовать оператор CONTAINS. Если оператор не задан, по умолчанию считается заданным оператор CONTAINS.
Следующие запросы эквивалентны:

@DocTitle "Что-то важное";

@DocTitle CONTAINS "Что-то важное".

Можно использовать булевы операторы AND, OR и NOT как в запросах на вхождение в содержимое, так и в запросах по свойствам. Оператор NEAR может применяться только в запросах по содержимому документов. Операторы в запросах могут быть записаны как в полной, так и в краткой форме (табл. 16.8).

ы использования сервера NNTP

Примеры использования сервера NNTP


Рассмотрим несколько типовых сценариев развертывания NNTP-сервера в корпоративной сети.

Примеры запросов

Примеры запросов


В табл. 16.9 приведены примеры разнообразных запросов.

Проигрыватель Windows Media Player

Рисунок 16.25. Проигрыватель Windows Media Player

Просмотр статей

Просмотр статей


Для просмотра статей в телеконференциях, опубликованных при помощи службы NNTP, необходимо использовать программу-клиент чтения новостей, например Microsoft Outlook Express.
Первый шаг при просмотре статей в телеконференции — получение списка доступных телеконференций (Рисунок 16.14). Клиент подключается к службе NNTP и запрашивает список доступных телеконференций. Служба NNTP принимает запрос, аутентифицирует пользователя, обращающегося к телеконференциям, проверяет его права, а затем посылает клиенту список всех доступных телеконференций.

Рисунок 16.14. Просмотр статей


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

Публикация статей

Публикация статей


Для передачи статьи телеконференции через службу NNTP следует использовать программу-клиент новостей, например Microsoft Outlook Express. Клиент подключается к NNTP и запрашивает публикацию переданной статьи в одной или более телеконференциях. Служба NNTP устанавливает соединение, принимает запрос и проверяет права пользователя на публикацию статьи в указанных телеконференциях (Рисунок 16.13). Служба NNTP затем публикует статью в телеконференциях и модифицирует индекс телеконференции.

Рисунок 16.13. Публикация статей

Распределенная архитектура интернетприложений

Распределенная архитектура интернет-приложений


Компания Microsoft разработала технологию Windows Distributed interNet Application Architecture (Windows DNA, Распределенная архитектура интернет-приложений Windows), полностью интегрирующую многоуровневую модель разработки с веб-технологией. Технология Windows DNA определяет каркас для создания решений, которые удовлетворяют требованиям корпоративных вычислений, Интернета, интрасетей и глобальной электронной торговли, уменьшая при этом издержки на общую разработку и развертывание системы.
В архитектуре Windows DNA стандартные службы на базе Windows выполняют определенные задачи на каждом уровне в многоуровневом решении, обеспечивая интерфейс пользователя и навигацию, бизнес-логику и хранение данных. Различные службы интегрированы при помощи Common Object Model (COM, Общая объектная модель). Службы, используемые в Windows DNA, включают: Dynamic HTML (Динамический HTML), Active Server Pages (Активные серверные страницы, ASP), компоненты COM, Microsoft Transaction Server, службу Active Directory, службы безопасности Windows Server 2003, Microsoft Message Queue Services (MSMQ, Службы очереди сообщений) и компоненты доступа к данным Microsoft.
Архитектура Windows DNA создана с применением открытых протоколов и общедоступных интерфейсов, что облегчает организациям задачу интеграции новых систем с продуктами третьих фирм. Обеспечивая промышленные стандарты Интернета, Windows DNA упрощает работы по внедрению новых технологий для разработчиков. На Рисунок 16.2 представлена схема, которая иллюстрирует технологии — составные части Windows DNA.

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

Расширение возможностей служб IIS, предоставляемых разработчику


Наиболее существенным изменением в архитектуре служб IIS, предоставившим разработчикам новые возможности, стала реализация в IIS 6.0 поддержки технологии ASP.NET. Эта технология фактически представляет собой универсальную платформу для построения распределенных корпоративных веб-приложений, работающих как часть Microsoft .NET Framework.

Следует заметить, что ASP.NET не поддерживается 64-разрядными версиями Windows Server 2003.
Помимо ASP.NET, в рамках IIS 6.0 реализована поддержка таких набирающих популярность интернет-стандартов, как XML и SOAP. Разработчики могут использовать серверные сценарии для динамической публикации содержимого веб-сайтов. Для написания серверных сценариев разработчики могут использовать технологии ASP или CGI.

Расширение возможностей служб IIS, предоставляемых администратору


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

Разрешение механизмов динамической

Разрешение механизмов динамической публикации содержимого веб-узлов


Ранее уже неоднократно отмечался тот факт, что в Windows Server 2003 компания Microsoft реализует новый подход к развертыванию служб IIS. Службы IIS не устанавливаются по умолчанию в ходе инсталляции операционной системы, и даже в случае принудительной установки большинство механизмов IIS находятся в "заблокированном" состоянии. В первую очередь это касается механизмов динамической публикации содержимого веб-узлов (таких как ASP, ASP.NET, WebDAV и др.).
Чтобы разрешить использование того или иного механизма, необходимо в пространстве имен оснастки Internet Information Services (IIS) Manager выбрать контейнер Web Service Extensions. В правом окне выберите расширение, которое требуется активизировать, и в зависимости от вида этого окна (Extended или Standard) или нажмите кнопку Allow (Разрешить), или выберите команду Allow в контекстном меню нужного расширения (Рисунок 16.7). Соответственно, для того, чтобы запретить использование расширения, необходимо нажать кнопку Prohibit (Запретить).

Рисунок 16.7. Разрешение механизмов динамической публикации содержимого веб-узлов

Разрешение прямого редактирования метабазы

Разрешение прямого редактирования метабазы


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

Рисунок 16.8. Разрешение прямого редактирования метабазы


При этом все произведенные изменения немедленно вступают в силу. По умолчанию редактирование содержимого базы данных запрещено. Разрешить эту возможность администратор может при помощи оснастки Internet Information Services (IIS) Manager. В окне свойств объекта, ассоциированного с сервером, на котором запущены службы IIS, необходимо установить флажок Enable Direct Metabase Edit (Разрешить прямое редактирование ме-табазы) (см. Рисунок 16.8).

Развертывание службы электронной почты

Развертывание службы электронной почты


Службы электронной почты не устанавливаются по умолчанию в ходе инсталляции операционной системы Windows Server 2003. При необходимости администратор должен установить эти службы самостоятельно. В окне утилиты Add or Remove Programs необходимо нажать кнопку Add/Remove Windows Components, чтобы запустить одноименный мастер. В списке компонентов (Рисунок 16.16) следует установить флажок в строке E-mail Services (Службы электронной почты) и нажать кнопку Next (Далее). Мастер произведет копирование необходимых файлов и выполнит конфигурирование установленной службы. При этом по умолчанию также ставится компонент РОРЗ Service Web Administration, позволяющий администрировать службу по протоколу HTTP с помощью утилиты Remote Administration (HTML).

Если предварительно не была выполнена установка службы SMTP, то она автоматически устанавливается в ходе развертывания служб электронной почты.

Режимы изоляции процессов

Режимы изоляции процессов


IIS 6.0 может функционировать в одном из двух режимов изоляции процессов:

режим изолированных рабочих процессов;

режим изоляции US 5.0.

В каждом из этих режимов службы IIS задействуют драйвер HTTP.sys для взаимодействия с пользователями по протоколу HTTP, однако принципы функционирования IIS в этих режимах различаются. Режим изолированных рабочих процессов (worker processes isolation mode) в полной мере использует архитектуру IIS 6.0. Режим изоляции /IS 5.0 используется в том случае, когда веб-приложение использует специфические функциональные возможности предыдущих версий IIS.
Режим изолированных рабочих процессов является наиболее предпочтительным режимом функционирования IIS, поскольку этот режим обеспечивает приложениям наилучшую производительность. Кроме того, данный режим обеспечивает более высокий уровень безопасности, поскольку в данном режиме рабочие процессы работают с полномочиями сетевой службы (учетная запись NetworkService). В случае режима изоляции IIS 5.0 рабочий процесс работает с полномочиями локальной системы (учетная запись LocalSystem).

Службы IIS 6.0 не могут одновременно работать в двух режимах. Если приложения требуют различных режимов изоляции процессов, администратор должен реализовать их на различных серверах.

Служба электронной почты (РОРЗ)

Служба электронной почты (РОРЗ)


В Windows Sewer 2003 реализована поддержка протокола РОРЗ. Эту возможность обеспечивает Служба электронной почты (E-mail Services). Протокол РОРЗ в совокупности со службой SMTP позволяет использовать сервер Windows Sewer 2003 для организации простейшей, но полнофункциональной системы обмена сообщениями электронной почты. При этом протокол SMTP оговаривает только транспортный механизм обмена (рассматриваются только механизмы доставки, но не чтения почтовых сообщений). То есть все полученные сообщения помещаются в некоторое хранилище. Для каждого получателя сообщение хранится в индивидуальных папках. По аналогии с обычной почтой, эти папки получили название почтовых ящиков (mailbox). Протокол РОРЗ представляет собой механизм извлечения пользователями сообщений из хранилища. Сообщения хранятся в почтовых ящиках до тех пор, пока пользователи не извлекут их оттуда (посредством протокола РОРЗ).
Для работы со службой электронной почты, реализованной в Windows Server 2003, пользователи могут использовать любого почтового клиента, поддерживающего протокол РОРЗ (например, Microsoft Outlook Express). Почтовый клиент устанавливает соединение с сервером по протоколу РОРЗ и подключается к требуемому почтовому ящику. В ходе выполнения подключения клиент должен пройти процедуру аутентификации, предоставив информацию об учетной записи пользователя и соответствующем ей пароле. После подключения пользователь может извлечь некоторые или все сообщения, содержащиеся в его почтовом ящике на сервере. При этом выгрузка может проходить как в режиме перемещения (выгружаемые сообщения удаляются из почтового ящика на сервере), так и в режиме копирования (копии сообщений остаются на сервере).

Следует заметить, что протокол РОРЗ предполагает передачу данных (в том числе и информацию о полномочиях пользователя) по сети в открытом незашифрованном виде. Поэтому в случае необходимости администратору следует подумать об использовании протокола IPSec. Применение протокола IPSec позволяет создать защищенный туннель между клиентом и сервером.
В терминологии протокола SMTP существует понятие почтового домена (e-mail domain). Почтовый домен определяет логическую принадлежность получателя к некоторой общности. Порядок записи имени почтового домена подчиняется правилам, определенным для доменных имен DNS. В совокупности имя получателя и почтовый домен образуют адрес электронной почты, который должен быть уникален в рамках всего пространства имен DNS. Например для получателя lex, принадлежащего к почтовому домену ayan.ru, адрес электронной почты будет следующим: lex@ayan.ru

Служба NNTP

Служба NNTP


В составе служб IIS 6.0 реализована Служба NNTP, позволяющая построить серверы новостей в интрасети или Интернете. В данном разделе описываются особенности ее развертывания в корпоративной сети.

Служба SMTP

Служба SMTP


В Windows Server 2003 Службу SMTP характеризуют следующие особенности:

поддержка стандартных протоколов Интернета. Служба SMTP обеспечивает полную поддержку протокола Simple Mail Transfer Protocol, SMTP (Простой протокол электронной почты) и совместима с почтовыми клиентами SMTP;

масштабируемость. Служба SMTP поддерживает сотни одновременных клиентских соединений при конфигурации с одним сервером. Можно также настроить использование множества доменов для одного сервера;

улучшенная безопасность. Служба SMTP поддерживает протоколы безопасной передачи почты на транспортном уровне;

прямая доставка и извлечение почты. Служба SMTP поддерживает размещение всех входящих сообщений непосредственно в каталоге %SystemDisk%\Inetpub\mailroot\Drop. Это позволяет использовать службу SMTP для приема почты других приложений. В дополнение к передаче сообщений через порт TCP-приложения могут использовать каталог %SystemDisk%\Inelpub\mailroot\Pickup. После форматирования сообщения служба SMTP осуществляет его доставку.

Службы Интернета

Службы Интернета


Internet Information Services версии 6.0 (IIS) - набор базовых служб Интернета в составе Windows Server 2003, в число которых входят: службы WWW, FTP SMTP, NNTP и ряд дополнительных служб. Службы IIS предоставляют множество новых возможностей, которые могут превратить систему Windows Server 2003 в мощную платформу для распределенных сетевых приложений. Службы IIS объединены при помощи стандартного интерфейса администрирования и общих методов управления. Следует заметить, что подробное рассмотрение всего набора служб IIS заслуживает отдельной книги. Службы IIS могут быть рассмотрены как с позиции администратора -человека, отвечающего за настройку и корректную работу служб, так и с позиции разработчика - человека, который создает приложения, ориентированные на работу с данными службами. Хотелось бы сразу оговориться, что наше рассмотрение служб IIS будет вестись исключительно с позиции администратора. В данной главе мы постараемся дать обзор служб IIS, описать новые возможности, открывающиеся перед администраторами и разработчиками, а также описать процесс развертывания в корпоративной сети служб IIS Также будут рассмотрены и другие службы, использующие веб-технологии или позволяющие на базе систем Windows Server 2003 строить распределенные сетевые системы.

Службы компонентов

Службы компонентов


Службы компонентов (Component Services) обеспечивают разработку и развертывание распределенных клиент-серверных приложений типа онлайновых бизнес-приложений и приложений электронной коммерции, имеющих веб-интерфейс. Службы компонентов используют технологию СОМ+ и обеспечивают такие функциональные возможности, как автоматическая поддержка целостности данных на основе транзакций, зашита информации, основанная на ролях, доступ к различным СУБД, службам очередей сообщений (например, MSMQ) и другим приложениям.
Службы компонентов полностью интегрированы с другими компонентами и службами Windows Server 2003. Интеграция со службами Internet Information Services и Active Server Pages упрощает создание приложений в среде Интернет/и нтрасети. Интеграция с кластерными службами повышает отказоустойчивость. Интеграция со службой обработки очередей сообщений (MSMQ) обеспечивает надежную, постоянную связь между приложениями.
Возможности Microsoft Transaction Server (MTS) были объединены с "классической" технологией СОМ и образовали технологию СОМ+, которая интегрирована в операционную систему Windows Server 2003. Оснастка ММС для управления СОМ+ — Component Services (Службы компонентов) располагается в меню Administrative Tools (Администрирование).
В состав служб компонентов входит переработанный инструмент управления, реализованный в виде оснастки ММС, с помощью которого можно устанавливать пакеты MTS в СОМ+ (Рисунок 16.18). Ранее для этого применялись специальные инструменты MTS. Сразу после установки пакета можно использовать такие новые возможности СОМ+, как базы данных, хранящиеся в оперативной памяти (In-Memory DataBase, 1MDB), или новая система поддержки событий.

Службы очереди сообщений

Службы очереди сообщений


Службы очереди сообщений (Microsoft Message Queuing Services, MSMQ) — сервис, входящий в стандартную поставку Windows Server 2003.
С помощью MSMQ приложения, работающие в разное время, могут связываться через разнородные сети и системы, способные временно работать автономно. Приложения посылают сообщения MSMQ и используют очереди MSMQ — это позволяет быть уверенным, что сообщение рано или поздно достигнет адресата. MSMQ обеспечивает гарантированную доставку сообщений, интеллектуальную маршрутизацию, защиту и передачу сообщений, основанную на приоритетах.
При помощи MSMQ конечные пользователи могут связываться через автономные сети и системы, вне зависимости от текущего состояния поддерживающих связь приложений и систем. При помощи MSMQ разработчики могут сосредоточиться на программировании бизнес-логики, а не решать проблемы работы с сетями, поскольку MSMQ обеспечивает гарантированную доставку. Администраторы систем при помощи MSMQ могут эффективно управлять большими, сложными сетями очередей сообщений.
Программные продукты с такими возможностями часто называют программным обеспечением поддержки очередей сообщений, программным обеспечением с промежуточным накоплением или средствами среднего уровня, ориентированными на сообщения (MOM, Message-Oriented Middleware).
Особенности и возможности службы MSMQ перечислены ниже.

Интеграция со службами Windows Server 2003. Поддерживается служба Active Directory, в которой хранятся отдельные объекты MSMQ. Клиенты MSMQ могут напрямую обращаться к каталогу для получения необходимой информации (используя протокол LDAP).

Доставка сообщений по HTTP. В рамках MSMQ 3.0 реализован новый протокол (основанный на XML-сообщениях), позволяющий осуществлять доставку сообщений при помощи протокола HTTP.

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

Отправка сообщения множеству получателей. Одно сообщение может быть адресовано нескольким получателям. Перечень получателей сообщения может быть определен в рамках объекта каталога, ассоциированного со списком рассылки (distribution list). Доставка сообщений нескольким получателям реализуется при этом на низком уровне. В частности могут быть задействованы механизмы группового вещания.

Поддержка рабочих групп. Механизм MSMQ может быть развернут в рамках рабочей группы (т. е. без образования домена).

Гарантированная доставка. Сообщения помещаются в хранящуюся на диске очередь, что обеспечивает гарантированную доставку сообщений.

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

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

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

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

Широкая интеграция систем. Приложения MSMQ могут выполняться на целом ряде аппаратных платформ, выпускаемых сторонними производителями.

Безопасность. MSMQ поддерживает механизмы безопасности: управление доступом, аудит, шифрование и аутентификацию. Управление доступом реализовано с применением системы безопасности Windows Server 2003 и цифровых подписей. Аудит реализован при помощи службы регистрации событий Windows Server 2003. Шифрование и аутентификация (использование цифровых подписей) обеспечиваются при помощи механизмов открытых и закрытых ключей.

Прикладной интерфейс MSMQ позволяет разрабатывать приложения MSMQ на языке С или C++. MSMQ также включает элементы управления СОМ, которые можно применять для создания приложений MSMQ в Microsoft Visual Java (VJ), Visual Basic (VB) или любых других приложений-контейнеров СОМ (например, Microsoft Access или Borland/Inprise Delphi). При помощи Microsoft ASP и Microsoft IIS можно интегрировать MSMQ-приложение с веб-страницами и формами, содержащими элементы управления СОМ. При помощи MAPI Transport Provider и Exchange Connector можно интегрировать приложение MSY1Q с формами Exchange и клиентами MAPI. Транспорт MSMQ RPC можно применять для создания надежных приложений, использующих вызовы RPC.

Службы Windows Media

Службы Windows Media


Службы Windows Media Services в составе Windows Server 2003 — это группа служб, которые предназначены для передачи клиентам аудио- и видеоинформации при помощи одноадресного и группового вещания. Службы Windows Media используются также для передачи файлов клиентам.
Поставляемое содержимое может быть создано, приобретено у поставщика или передаваться с телевизионных камер и микрофонов. В последнем случае его называют живым потоком (live stream).
Пользователи могут обращаться к поставляемому содержимому через Интернет, через корпоративную или образовательную интрасеть или через специализированные группы, которые получают содержимое в выделенной сети или в интрасети.
Службу можно применять для различных целей, например для распространения информации, для организации информационных, развлекательных и маркетинговых узлов, для обучения, управления и т. д.

Сопоставление MIME

Сопоставление MIME


Стандарт MIME (Multipurpose Internet Mail Extensions) предоставляет программам просмотра (браузерам) возможность определения формата файла и корректного его отображения. Зарегистрированные типы файлов, которые установлены по умолчанию в Windows Server 2003, перечислены в окне MIME Types (Типы файла), доступном на вкладке Internet Information Services Manager в диалоговом окне свойств данного компьютера в окне оснастки Internet Information Services (IIS) Manager.
Сопоставления (map) MIME могут быть настроены на уровне компьютера, на уровне сайта, на уровне виртуального каталога, на уровне каталога или на уровне файлов. Отображения MIME на уровне компьютера определяются в окне свойств объекта, ассоциированного с ним. Для настройки отображении MIME на других уровнях нужно использовать вкладку HTTP Headers (Заголовки HTTP) окна свойств соответствующего объекта. Для открытия окна свойств в пространстве имен оснастки необходимо в контекстном меню соответствующего объекта выбрать пункт Properties (Свойства).

Отображения MIME, заданные на уровне компьютера, не отменяют автоматически установки на более низких уровнях.

Состав служб Windows Media

Состав служб Windows Media


В составе служб Windows Media присутствует четыре компонента (Рисунок 16.23).

Windows Media Services. Эти службы предназначены для передачи звуковой и видеоинформации при помощи одноадресного и группового вещания клиентам.

Компонент, обеспечивающий регистрацию клиентов группового вещания (Multicast and Advertisement Logging Agent).

Windows Media Services snap-in. При помощи данной оснастки (Рисунок 16.24) администратор может управлять службами Windows Media как на локальном сервере, так и на удаленных серверах. Чтобы управлять несколькими серверами, нужно добавить их к списку; после этого можно подключаться к серверу, которым необходимо управлять.

Веб-администратор служб Windows Media (Windows Media Services Administrator for the Web). Данный компонент представляет собой набор вебстраниц, которые отображаются в окне браузера Microsoft Internet Explorer и позволяют удаленно управлять службами-компонентами Windows Media.

Создание вебузла

Создание веб-узла


Сначала нужно создать веб-узел и указать, в каких каталогах хранятся публикуемые документы. Веб-сервер не может опубликовать документы, которые находятся вне пределов указанных каталогов. Первым шагом в развер-тывании веб-узла является задание организационной структуры файлов. После этого, используя оснастку Internet Information Services (IIS) Manager, нужно задать, какие каталоги являются частью узла.
Если необходимо опубликовать информацию немедленно, не тратя время на создание структуры каталогов узла, и все файлы расположены на одном и том же жестком диске, можно просто скопировать публикуемые файлы в основной каталог по умолчанию — %SystemDisk%\Inetpub\wwwroot. Для FTP-узла файлы требуется скопировать в каталог %SystemDisk%\Inetpub\ ftproot. Пользователи сети смогут обращаться к этим файлам, вводя URL-адрес http://<имя_сервера>/<имя_файла>.

Средства администрирования служб электронной почты

Средства администрирования служб электронной почты


Для управления службами электронной почты администратор может использовать специальную оснастку РОРЗ Service (Рисунок 16.17). Эта оснастка устанавливается в ходе развертывания службы электронной почты и может быть использована для управления всеми экземплярами (серверами) службы РОРЗ, функционирующими в корпоративной сети. С помощью указанной оснастки можно управлять почтовыми доменами, почтовыми ящиками, а также выполнять настройку таких параметров службы РОРЗ, как используемая схема аутентификации получателей, используемый TCP-порт, а также уровень протоколирования событий, связанных с работой службы. Для удаленного администрирования может использоваться утилита Remote Administration (HTML).

В составе Windows Server 2003 поставляется специальная утилита командной строки Winpop.exe, которая также может быть использована для управления службой электронной почты (РОРЗ Service). Эта утилита командной строки может быть использована в тех ситуациях, где применение оснастки неоправданно или не позволяет решить стоящих перед администратором задач (например, при создании пакетных заданий). Для получения информации о синтаксисе утилиты Winpop.exe необходимо в режиме командной строки набрать winpop help.

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

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


Оснастка Internet Information Services (IIS) Manager может выполнять все задачи по администрированию службы NNTP, она требует подключения через ЛВС. При ее использовании нужно раскрыть узел Default NNTP Virtual Server (Виртуальный NNTP-сервер по умолчанию) (см. Рисунок 16.11).
Управлять виртуальным сервером NNTP с помощью оснастки Internet Information Services (IIS) Manager можно и с удаленного компьютера, если он находится в той же ЛВС, что и служба NNTP. Однако этот компьютер должен работать под управлением Windows Server 2003, и на нем должны быть установлены средства администрирования Windows Server 2003.

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


Управление службой SMTP осуществляется с помощью оснастки Internet Information Services (IIS) Manager, которая может также использоваться для выполнения всех задач по администрированию служб IIS и требует подключения через ЛВС. Для настройки параметров службы SMTP необходимо в пространстве имен оснастки выбрать узел Default SMTP Virtual Server (Виртуальный SMTP-сервер по умолчанию) (Рисунок 16.15).

Структура почтового хранилища

Структура почтового хранилища


Вся приходящая почта размещается в специальном почтовом хранилище (mail store). По умолчанию почтовое хранилище располагается в папке %SystemDisk%\Inetpub\mailRoot\Mailbox. Хранилище представляет собой совокупность папок. Эти папки организуются в соответствии с определенным принципом. Организация сообщений осуществляется на уровне почтовых доменов и почтовых ящиков. Как уже упоминалось ранее, почтовый ящик представляет собой папку, в которую помещаются все приходящие на определенного получателя сообщения. В рамках хранилища почтовые домены представляют собой папки, в которых помещаются принадлежащие к ним почтовые ящики. Например, путь к содержимому почтового ящика получателя lex, принадлежащего к почтовому домену ayan. ru, будет следующим: \inetpub\mailroot\mailbox\ayan.ru\lex. rnbx\

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

Структуры данных службы NNTP

Структуры данных службы NNTP


Статьи телеконференций в службе NNTP хранятся в одной или в нескольких группах иерархических каталогов. Каждая телеконференция имеет собственный каталог, а каждая статья хранится как файл в этом каталоге.
Основной каталог по умолчанию — %SystemDisk%\\netpub\nntpfile\root, его можно переназначить на вкладке свойств основного каталога виртуального сервера NNTP. Можно создавать дополнительные иерархии каталогов на других дисках или на других компьютерах, создавая виртуальные каталоги.
Каталог телеконференции имеет то же имя, что и сама телеконференция. Служба NNTP автоматически создает требуемые каталоги, когда создается новая телеконференция. Например, телеконференция, названная sample.test, хранится в подкаталоге \sample\test относительно корневого каталога, т. е. в каталоге %SystemDisk%\Inetpub\nntpfile\root\sample\test. Все файлы статей телеконференций имеют расширение nws.
Служба NNTP также создает файлы, в которых хранятся темы размещенных в телеконференции статей. Эти файлы имеют расширение xix. Служба NNTP создает один файл для каждых 128 статей в телеконференции.
Служба NNTP также поддерживает множество внутренних файлов структуры данных с расширениями hsh, hdr, lst и txt. Заданное по умолчанию расположение этих файлов — %SystemDisk%\Inetpub\nntpfile. Нельзя изменять или удалять эти файлы. Средства восстановления службы NNTP исправляют эти файлы, если они были случайно удалены или повреждены.

Свойства и наследование свойств

Свойства и наследование свойств


Свойства — это параметры, которые могут быть настроены для конкретного узла (сайта). Например, можно использовать оснастку Internet Information Services (IIS) Manager для того, чтобы изменить номер порта TCP для сервера (по умолчанию — 80). Свойства видны в окнах свойств узла (см. Рисунок 16.9) и хранятся в базе данных, которая называется метабазой (metabase).
В процессе инсталляции IIS различным свойствам и параметрам присваиваются значения по умолчанию. Можно использовать настройки по умолчанию для 1IS или настраивать эти параметры, чтобы адаптировать функциональность сервера к потребностям сети. Можно также обеспечить дополнительные функции, улучшить производительность, а также изменить настройки защиты, внося изменения в настройки по умолчанию.
Свойства могут быть установлены на уровне узлов, на уровне каталогов или на уровне файлов. Параметры настройки на более высоких уровнях (например, на уровне узлов) автоматически используются (наследуются) более низкими уровнями (например, уровнем каталогов), но все могут редактироваться раздельно на более низком уровне. Если свойство было изменено для отдельного узла, каталога или файла, а затем будет произведен возврат к значению по умолчанию, то автоматическая настройка не отменит индивидуальную настройку. При выполнении такого рода действий администратор получит предупреждающее сообщение, и ему нужно будет ответить на вопрос, хочет ли он изменить настройку для отдельного узла, каталога или файла, чтобы она соответствовала новым значениям по умолчанию.
Некоторые свойства имеют значение, которое представляет собой список. Например, значение свойства "Документ, используемый по умолчанию" (Default Document) — список документов, которые будут загружены, когда пользователь не задает файл в URL. Пользовательские сообщения об ошибках, управление доступом по TCP/IP, отображение MIME — примеры свойств, которые хранятся в виде списка. Хотя эти списки состоят из нескольких записей, IIS рассматривает список как единое целое. Если список редактируется для каталога, а затем производится глобальная замена на уровне узла, список на уровне каталога полностью заменяется новым списком, полученным с уровня узла; списки не объединяются. Если содержимое свойства-списка редактируется на низком уровне (например, на уровне каталога или файла), то это свойство отображает как значения, определенные на этом уровне, так и значения, унаследованные с высоких уровней.
Фильтры отображаются в виде списка, но обрабатываются не как список. Если фильтры добавляются на уровне узлов, то новые фильтры объединяются со списком фильтров от управляющего уровня. Если два фильтра имеют одинаковые установки приоритетов, фильтр с управляющего уровня загружается перед фильтром с уровня узла.
Если создается несколько веб- или FTP-узлов, можно редактировать значения по умолчанию (Рисунок 16.9) таким образом, чтобы каждый узел, который создается, наследовал пользовательские значения узлов по умолчанию (Default Web Site и Default FTP Site — Веб-узел по умолчанию и FTP-узел по умолчанию).

Свойства вебузла создаваемого по умолчанию

Рисунок 16.9. Свойства веб-узла, создаваемого по умолчанию

Поддержка протокола HTTP реализована на

Таблица 16.1.Стандарты Интернета, реализованные в IIS 6.0

Стандарт	Описание
HTTP 1.1	Поддержка протокола HTTP реализована на уровне ядра операционной системы. В том числе поддерживается механизм сжатия HTTP (HTTP compression). Этот механизм обеспечивает более компактную передачу данных между веб-сервером и клиентами, которые поддерживают получение сжатой информации. Механизм также выполняет сжатие и кэширование статических файлов. По требованию может выполнять сжатие динамически сгенерированных файлов
WebDAV	Дает возможность авторам веб-страниц удаленно редактировать, перемещать или удалять файлы, изменять параметры файлов, каталоги и параметры каталогов на сервере при помощи административных утилит, работающих по протоколу HTTP
SMTP	Протокол SMTP регламентирует процесс обмена сообщениями между сетевыми хостами. В составе IIS реализована служба SMTP, позволяющая системам Windows Server 2003 выступать в качестве агента пересылки почты (Mail Transfer Agent, MTA). Служба SMTP, реализованная в IIS, может стать базой для развертывания почтового сервера
NNTP	Протокол NNTP регламентирует процесс обмена сообщениями новостей. В составе IIS реализована служба NNTP, позволяющая системам Windows Server 2003 выступать в качестве сервера новостей
FTP	Протокол FTP регламентирует процесс передачи файлов по сети. В IIS 6.0 реализована служба FTP-сервера. Для каждого пользователя может быть создан собственный FTP-каталог. Соответственно, данный пользователь может действовать только в пределах своего каталога (другие каталоги, включая их содержимое, он не видит). Для FTP может быть также установлено несколько различных кодовых страниц. Помимо этого, IIS поддерживают докачку по протоколу FTP. Теперь при получении файла по протоколу FTP можно произвести повторную докачку с места, на котором был прерван предыдущий сеанс
PICS рейтинг	Данный стандарт описывает методику оценки содержимого веб-сайта с точки зрения наличия материалов сексуального характера, насилия и ненормативной лексики

Мы говорим об IIS, как о наборе базовых служб Интернета. IIS 6.0 включает в свой состав пять служб:

служба WWW (World Wide Web Publishing service);

служба FTP (File Transfer Protocol service);

служба SMTP (Simple Mail Transfer Protocol service);

служба NNTP (Network News Transfer Protocol service);

служба администрирования IIS (IIS Admin service).

Новые функциональные

Таблица 16.10. Новые функциональные возможности Windows Media Services 9.0

Функциональная возможность	Описание
Расширение функциональности службы Windows Media	Администратор может расширить функции служб Windows Media путем установки специальных модулей (plug-in)
Расширенные возможности создания точек публикации	Точки публикации представляют собой точки доступа к потоковым данным. Клиенты получают доступ к потоковым данным на сервере, подключаясь к точкам публикации. Службы Windows Media поддерживают два вида точек публикации: по требованию и широковещательные. Windows Server 2003 предоставляет администратору широкие возможности управления точками публикации
Гибкое управление списками воспроизводимых файлов (playiists)	Для каждой точки публикации может быть определен список воспроизводимых файлов. Администратор может изменять как состав списка, так и параметры отдельных файлов, входящих в него, без прерывания процесса доставки
Гибкая архитектура обработки событий	Появилась возможность управления событиями на стороне сервера посредством механизма Windows Management Instrumentation (WMI) и протокола SNMP
Механизм быстрой доставки (Fast Streaming)	В предыдущих версиях Windows Media скорость доставки потоковых данных являлась постоянной величиной. В Windows Media Services 9.0 администратор может управлять скоростью доставки с помощью целого ряда механизмов
Улучшенный алгоритм доставки пакетов	Отправляемые пакеты хранятся в течение 10 секунд в специальном буфере, что позволяет ускорить процесс их повторной отправки в случае возникновения ошибок доставки
Управление процессом упаковки данных	Размер пакета может изменяться в зависимости от условий передающей среды. Это позволяет администратору организовать процесс доставки потоковых данных наиболее эффективным образом
Поддержка протокола IPv6	В рамках Windows Media Services 9 реализована поддержка протокола IPv6, который может использоваться для организации процесса доставки потоковых данных
Поддержка протокола IGMPvS	Реализована поддержка протокола IGMPvS, который может использоваться для организации процесса доставки потоковых данных посредством группового вещания

Отдельно следует отметить изменения, произошедшие в Windows Media Services 9.0 по сравнению с предыдущими версиями (Windows Media Services 4.x). Эти изменения перечислены в табл. 16.11.

Сравнение Windows

Таблица 16.11. Сравнение Windows Media Services 4.x и Windows Media Services 9.0

Windows Media Services 4.x	Windows Media Services 9.0
Формат *.asf	В новой версии Windows Media Services реализованы два новых расширения файлов: wma и wmv. Эти расширения позволяют клиенту узнать какого рода информация передается (аудио или видео соответственно). Тем не менее, формат передачи данных остается неизменным
ASFRoot	WMRoot
Протокол MSDB	Этот протокол доставки потоковых данных больше не поддерживается. Вместо него рекомендуется использовать протокол HTTP или RSTP
Программы (programs)	Вместо программ передачи используется понятие списка воспроизводимых файлов (playlists)
Службы Windows Media Station Service, Windows Media Unicast service, Windows Media Program Service, Windows Media Monitor Service	Эти службы реализованы в рамках одного компонента Windows Media Services

Функциональные возможности

Таблица 16.2. Функциональные возможности, улучшающие стабильность служб IIS

Функциональная возможность	Описание
Режимы функционирования	Службы IIS могут функционировать в одном из двух режимов: режим изолированных рабочих процессов и режим совместимости с IIS 5.O. В режиме изолированных рабочих процессов (worker process isolation mode) каждое веб-приложение может выполняться в отдельном рабочем процессе. При этом рабочие процессы приложений запускаются отдельно от основного процесса WWW-службы (inetinfo.exe), что позволяет избежать остановки других приложений в ситуации, когда одно из приложений отказывает или зависает
Множество пулов приложений	Данная возможность доступна только в режиме изолированных рабочих процессов. Под пулом приложений понимается конфигурация, связывающая один или несколько приложений с одним или несколькими рабочими процессами. Проблемы, вызванные ошибками в одном из пулов приложений, не воздействуют на приложения в других пулах
Ограничение длины очереди пула приложений	Администратор может ограничить длину очереди для пула приложений. Сервер начнет отклонять новые запросы в случае превышения некоторого заданного числа запросов, поступающих определенному пулу приложений. Благодаря этому механизму администратор может предотвратить истощение ресурсов сервера
Очереди на уровне ядра	Механизм, функционирующий на уровне ядра IIS, помещает все запросы, адресованные отказавшему пулу приложений, в специальную очередь. Поскольку пулы приложений могут выполняться в контексте различных рабочих процессов, служба WWW может инициировать новый процесс для обслуживания запросов из этой очереди
Мониторинг состояния процессов	Служба WWW может выполнять мониторинг состояния рабочих процессов. В случае возникновения проблем служба способна прервать процесс или заменить его другим. В качестве варианта отказавший процесс может быть "изолирован" от пула приложений. Поскольку его работа не прерывается, разработчики и администратор могут выполнить диагностику проблемы
Отслеживание времени простоя рабочего процесса	Администратор может контролировать процесс использования системных ресурсов, определив для рабочих процессов допустимое время простоя (idle timeout). По истечении этого времени процесс будет остановлен
Защита от быстрого отказа	Администратор может активизировать механизм, который отключает пул приложений в ситуации, когда в рамках данного пула происходит множество последовательных ошибок
Утилизация рабочих процессов	Службы IIS могут быть сконфигурированы таким образом, чтобы периодически перезапускать рабочие процессы. Тем самым гарантируется освобождение системных ресурсов и удаление неактивных рабочих процессов. Перезапуск может быть поставлен в зависимость от периода времени, в течение которого процесс активен, количества обработанных запросов, либо выполняться через определенные промежутки времени

Функциональные возможности

Таблица 16.3. Функциональные возможности, улучшающие защищенность служб IIS

Функциональная возможность	Описание
Цифровая аутентификация	Данный механизм аутентификации представляет собой более защищенный вариант базовой аутентификации. В отличие от последней, предполагающей передачу информации о пароле открытым текстом, в процессе цифровой аутентификации передается хэшированный пароль. Для хэширования применяется алгоритм MD5. Использование механизма цифровой аутентификации описано в рамках протокола HTTP 1.1, поэтому для его использования требуется, чтобы браузер поддерживал этот стандарт
Безопасное взаимодействие	Для реализации защищенного канала передачи данных между клиентом и сервером могут быть использованы механизмы Security Socket Layer версии 3.0 (SSL) и Transport Layer Security (TLS). Эти механизмы могут быть также применены для организации проверки подлинности участников соединения
Шлюзовое серверное шифрование (Server-Gated Cryptography, SGC)	Это расширение протокола SSL, которое позволяет финансовым учреждениям, использующим службы IIS в экспортном варианте, применять мощное 128-разрядное шифрование. Возможности SGC встроены в службы IIS, однако, чтобы использовать SGC, требуется специальный сертификат SGC
Возможность выбора криптографических алгоритмов	Механизм SSL является надежным способом организации защищенного взаимодействия. Однако процесс шифрования сетевого трафика между клиентом и сервером приводит к существенной нагрузке на процессорную подсистему. IIS позволяет администратору выбрать поставщика криптографических услуг (Cryptographic Service Provider, CSP) в соответствии со стоящими перед ним задачами. Например, можно задействовать аппаратные устройства, выполняющие шифрование данных или использовать CSP стороннего производителя
Настраиваемые полномочия рабочих процессов	Администратор может сконфигурировать пулы приложений (а соответственно и связанные с ними рабочие процессы) таким образом, чтобы они выполнялись в контексте учетной записи, обладающей полномочиями меньшими, чем учетная запись LocalSystem. Это позволяет сократить риск от возможных атак
Мастера безопасности	В составе IIS реализованы специальные мастера, упрощающие выполнение задач администрирования сервера. Это мастер Web Server Certificate Wizard, упрощающий процесс создания запросов на получение сертификатов и управление циклом жизни сертификата, а также мастер CTL Wizard, используемый для настройки списков доверия сертификатов (Certificate Trust List, CTL). Список CTL представляет собой перечень центров авторизации или поставщиков сертификатов (Certificate Authorities, CA), получивших доверие, для заданного каталога. CTL особенно полезен для поставщиков услуг Интернета (ISP), которые держат на своем сервере много веб-узлов клиентов и должны хранить различные утвержденные списки центров авторизации для каждого узла
Совместимость с протоколом Kerberos v5	Службы IIS полностью интегрированы с моделью безопасности Kerberos, реализованной в Microsoft Windows Server 2003
Управление развертыванием служб IIS через механизм групповых политик	Используя механизм групповых политик, администратор может запретить пользователям развертывание службы IIS в рамках домена
Управление правами доступа рабочих процессов	Рабочие процессы в рамках IIS запускаются в контексте учетной записи пользователя с ограниченными правами доступа. Это позволяет снизить риск, связанный с возможными атаками
Защита ASP	Все встроенные ASP-функции вызываются в контексте учетной записи, обладающей ограниченными правами доступа
Ограничение на запуск исполняемых файлов	Запуск большинства исполняемых файлов, расположенных в системной папке, разрешен ограниченному кругу лиц (например, членам группы Administrators)
Управление обновлениями	В рамках IIS реализована возможность применения обновлений (патчей) без необходимости остановки служб IIS
Защита от записи для содержимого веб-сайта	По умолчанию анонимным пользователям запрещено выполнение операции записи при работе с веб-сайтами
Ограничение на объем закачиваемых данных	Администратор имеет возможность ограничения объема данных, которые могут быть закачаны на сервер
Контроль переполнения буфера	Рабочий процесс способен обнаружить переполнение буфера и прервать программу, виновную в этом
Управление доступом к исходному коду сценариев	Администратор может устанавливать разрешения на доступ к исходным кодам сценариев. По умолчанию это разрешение отключено
Суб-аутентификация	Механизмы суб-аутентификации (позволяющие использовать механизмы аутентификации сторонних приложений) по умолчанию отключены в IIS 6.0

Технологии и механизмы

Таблица 16.4. Технологии и механизмы, улучшающие производительность служб IIS

Функциональная возможность	Описание
Реализация поддержки протокола HTTP на уровне ядра операционной системы	Поддержка протокола HTTP реализована на уровне ядра Windows Server 2003 в качестве специального драйвера -HTTP.sys (сами службы IIS функционируют на пользовательском уровне). Этот драйвер обрабатывает все входящие HTTP-запросы. Обработка запросов на уровне ядра операционной системы позволяет повысить эффективность функционирования веб-приложений
Размещение части ASP-кэша на жестком диске	ASP-кэш служит для размещения ASP-шаблонов, используемых в процессе обработки ASP-сценариев. Использование кэша позволяет повысить эффективность обработки сценариев. По умолчанию в кэше может быть размещено не более 250 шаблонов. Если приложения интенсивно используют ASP-сценарии, количество шаблонов может быть значительно большим. В IIS 6.0 часть ASP-кэша может быть размещена на жестком диске
Асинхронная обработка CGI-сценариёв	IIS реализует асинхронное выполнение CGI-сценариев
Трассировка для оценки нагрузки на приложение	Администратор может активизировать механизм трассировки, позволяющий выполнить оценку нагрузки на некоторое приложение
Централизованное протоколирование	Множество веб-сайтов могут использовать для протоколирования один общий журнал. При этом информация в этот журнал записывается в двоичном неформатированном виде
Управление качеством обслуживания (QoS)	Под качеством обслуживания в данном случае понимается набор требований к сети, обуславливающих возможность передачи данных в определенном темпе. IIS 6.0 предоставляет администратору возможность управлять качеством обслуживания, устанавливая ограничения на количество подключений, периоды простоя, длину очереди пулов приложений и регулируя процесс использования полосы пропускания
Мониторинг нагрузки на процессор	Используя специальную утилиту, поставляемую в составе IIS, администратор может автоматизировать мониторинг нагрузки на процессорную подсистему. Утилита может автоматически останавливать процесс, чересчур интенсивно использующий процессорную подсистему. Эта утилита также может быть использована для нахождения неэффективных CGI-сценариев, чересчур интенсивно использующих процессор
Контроль полосы пропускания	Администратор может выделить для работы служб IIS определенную часть доступной полосы пропускания канала. Этот шаг позволит зарезервировать часть имеющейся полосы пропускания для работы других важных приложений (например, электронной почты)
Поддержка больших объемов ОЗУ	IIS 6.0 может поддерживать кэш емкостью до 64 Гбайт (для архитектуры х86)

Функциональные возможности

Таблица 16.5. Функциональные возможности, расширяющие возможности администрирования IIS

Функциональная возможность	Описание
Хранение содержимого метабазы в текстовом формате	Метабаза хранится в виде двух текстовых файлов Metabase.xml и MBSchema.xml. Такой формат хранения содержимого метабазы позволяет администратору выполнять конфигурирование служб IIS вручную, посредством любого текстового редактора
История изменений метабазы	Система сохраняет историю изменений содержимого метабазы, сохраняя в специальной папке старые версии. Благодаря этому администратор может выполнить откат ее изменений, восстановив при необходимости старую версию. Каждая версия идентифицируется по специальному номеру, на который можно сослаться в процессе восстановления метабазы
Возможность изменения метабазы в онлайновом режиме	Поскольку метабаза хранится в виде текстового файла, администратор может выполнять ее изменение непосредственно в онлайновом режиме, т. е. в процессе работы служб IIS. Все произведенные изменения вступают в силу немедленно
Возможность создания резервной копии метабазы	Реализованный в системе API-интерфейс позволяет осуществлять резервное копирование и восстановление метабазы
Возможность экспорта/импорта конфигурации сайтов и приложений	Разработчики могут реализовать в своих приложениях возможность импорта/экспорта отдельных фрагментов содержимого метабазы
Изоляция РТР-содержимого на уровне пользователей	Администратор имеет возможность создать для отдельных пользователей FTP-каталоги. При этом пользователь не может выйти выше своего каталога по иерархии (другими словами — не видит каталогов других пользователей). В пределах своего каталога пользователь может создавать, удалять, копировать файлы и подкаталоги. Данная функциональная возможность может оказаться наиболее полезной для интернет-провайдеров
Поддержка серверных расширений FrontPage 2002	В составе IIS 6.0 реализована поддержка серверных расширений FrontPage 2002, позволяющих осуществлять разработку веб-сайтов и управление виртуальными веб-серверами непосредственно из среды разработки FrontPage 2002
Административные сценарии командной строки	Административные сценарии могут использоваться для решения многообразных задач по управлению службами IIS. Сценарии могут применяться, в частности, для автоматизации процессов управления
П ротоколирование в формате UTF-8	Службы IIS 6.0 регистрируют информацию о посещениях в журналах в формате UTF-8. Использование этого формата позволяет осуществлять запись в журнал информации не только на английском языке, но и на национальных языках
Возможность удаленного администрирования служб IIS	В Windows Server 2003 реализовано множество механизмов и инструментов, позволяющих выполнять удаленное администрирование различных компонентов операционной системы, в том числе и служб IIS. Удаленное управление службами IIS может быть выполнено при помощи специальной утилиты Remote Administration (HTML)

Примеры соответствия

Таблица 16.6. Примеры соответствия между физическим местоположением файлов, псевдонимом и URL-адресом

Физическое местоположение на диске (компьютере)	Псевдоним	Путь URL
c:\wwwroot	Домашний каталог (нет псевдонима)	http://infoserver
\\Server2\info\Data	Data	http://infoserver/Data
c:\wwwroot\Schedule	Нет	http://infoserver/Schedule
c:\wwwroot\Products	Нет	http://infoserver/Products
d:\samples\documents	Text	http://infoserver/text

Как виртуальные, так и физические каталоги (каталоги без псевдонима) видны в оснастке Internet Information Services (IIS) Manager.

Для простого веб-узла не требуется создание виртуальных каталогов. Можно просто разместить все файлы в основном каталоге узла. Если нужно построить сложный узел или задать различные URL для различных частей узла, можно добавлять виртуальные каталоги по необходимости.

Режим запроса в краткой форме

Таблица 16.7. Режим запроса в краткой форме

Символ	Режим
@	Запрос на поиск фразы (эквивалент {phrase})
#	Запрос с регулярным выражением (эквивалент {regex})
$	Свободный текстовый запрос (эквивалент {freetext})

Полная и краткая формы операторов

Таблица 16.8. Полная и краткая формы операторов

Оператор	Длинная форма	Краткая форма
AND	AND	&
NOT	AND NOT	|
OR	OR	& !
NEAR	NEAR	Near, ~

Следует заметить, что булевы операторы доступны только в английском написании.

Булевы операторы рассматриваются в следующем порядке: NOT, AND и NEAR, OR.
Для свободных текстовых запросов можно указывать группу слов или законченное предложение. Служба индексирования находит документы, которые лучше всего соответствуют словам и фразам в свободном текстовом запросе. Булевы операторы и подстановочные символы в таком запросе игнорируются. Чтобы искать фразу, ее нужно или заключить в кавычки, или предварить тэгом (phrase). Слова в запросе на поиск фразы должны встретиться в документе в указанном порядке, без пропуска слов.
Для запросов сопоставления с образцом служба индексирования выбирает документы, соответствующие образцу, который задается пользователем. В такого рода запросах используются маски (wildcards), запросы, задающие словоформы, регулярные выражения и операторы отношений.
В относительных запросах для поиска документов, свойства которых лежат в некотором диапазоне, можно использовать операторы отношения: больше, меньше, равно, не равно и т. п.
Векторно-пространственные запросы предназначены для поиска документов, которые соответствуют списку слов и фраз. Документы, которые возвращаются после выполнения векторно-пространственного запроса, не обязательно соответствуют каждому термину в запросе. Ранг каждого документа указывает, насколько хорошо документ соответствует запросу. Можно задавать весовые коэффициенты, чтобы управлять относительной важностью терминов для получения результата. Допустимые значения весов находятся в диапазоне от 0,0 до 1,0.

Примеры запросов

Таблица 16.9. Примеры запросов

Чтобы найти	Полная форма	Краткая форма	Результат
Заданное значение	{prop name=DocAuthor } = Иван Иванов {/prop}	@DocAuthor = Иван Иванов	Документы, созданные Иваном Ивановым
Значение, начинающееся с заданного префикса	{prop name=DocAuthor } { гедех}Иван * { /regex } { /prop }	#DocAuthor Иван*	Документы, чье свойство "автор" начинается с "Иван"
Файлы с расширением из числа заданных	{prop name=f ilename} { regex} * . I (doc | , txt | , wri | ) { /regex} { /prop}	#f ilename *. | (doc|, txt | , wri | )	Файлы с расширениями doc, txt или wri
Документы, измененные после некоторой даты	{prop name=write} > 99/7/18 11:05:00 { /prop}	@write > 99/7/18 11:05:00	Документы, измененные после 18 июля 1 999 года, в 11:05 по UTC
Документы, измененные после относительной даты	{prop name=write} > -2d4h {/prop}	@write > -2d4h	Документы, измененные в пределах последних 52 часов

Технологии Windows DNA

Рисунок 16.2. Технологии Windows DNA

Технология ASP NET

Технология ASP.NET


Технология ASP.NET является развитием Active Server Page (ASP). Данная технология представляет собой универсальную платформу для разработки веб-приложений корпоративного уровня. ASP.NET предлагает новую модель программирования и инфраструктуру, которые позволяют разрабатывать защищенные и масштабируемые решения. В ASP.NET следует отметить следующие функциональные возможности:

возможности администрирования. Параметры, определяющие конфигурацию ASP.NET, хранятся в текстовом файле. Это позволяет выполнять изменение конфигурации ASP.NET посредством любого текстового редактора. Все произведенные изменения вступают в силу немедленно;

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

простота развертывания. Развертывание ASP.NET-приложений выполняется путем копирования файлов приложения в специальную папку на веб-сервере. Перезапуск веб-сервера при этом не требуется;

высокая производительность. ASP.NET имеет дело со скомпилированным кодом. Благодаря этому ASP.NET получает возможность эффективно использовать различные механизмы оптимизации кода (например, механизмы раннего связывания или оптимизация под конкретную платформу);

гибкое кэширование. ASP.NET может выполнять кэширование страниц данных (как страницу целиком, так и ее часть) в соответствии с нуждами приложения;

поддержка национальных языков. Поскольку ASP.NET использует Unicode, разработчики имеют обширные возможности для применения в своих приложениях национальных алфавитов;

поддержка мобильных устройств. Microsoft заявляет, что ASP.NET поддерживается любым браузером, запущенным на любом устройстве;

доступность и масштабируемость. ASP.NET разрабатывалась в расчете на использование в крупных кластерных системах. Реализованные в рамках IIS 6.0 механизмы позволяют гарантировать высокую степень доступности приложений. Если с процессом, в рамках которого выполняется приложение, возникнут проблемы, система самостоятельно запустит новый процесс, который возьмет на себя задачи обслуживания запросов пользователей;

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

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

совместимость с существующими ASP-приложениями. Развертывание ASP.NET в рамках IIS не влияет на функционирование уже работающих ASP-приложений. ASP-приложения и ASP.NET-приложения могут сосуществовать на одном сервере, не мешая друг другу.

Требования к конфигурации компьютера

Требования к конфигурации компьютера


Минимальная аппаратная конфигурация для службы индексирования — та же, что и для Windows Server 2003. Однако индексация и работа механизмов поиска зависят от количества и размера документов, которые будут проиндексированы, интенсивности поступления поисковых запросов и сложности запросов. На работу службы также влияет мощность компьютера. Компьютер с минимальной аппаратной конфигурацией для Windows Server 2003 хорошо обрабатывает запросы, если число одновременных запросов не слишком высоко. Для маленькой организации этого может оказаться достаточно, но для большой организации, обслуживающей много пользователей, рекомендуется более мощная конфигурация.
Если документов много, а памяти для работы службы не хватает, производительность системы может серьезно понизиться. Если компьютер при функционировании службы работает медленно, можно попробовать настроить производительность службы (см. ниже). Можно улучшить производительность службы и компьютера в целом, увеличивая общий объем оперативной памяти и объем памяти, выделенный для кэша свойств (property cache). Более быстрый процессор увеличивает скорость индексации и обработки запросов.
Полный объем документов, которые будут проиндексированы, и тип файловой системы также влияют на объем дискового пространства, требуемого для хранения данных службы индексирования. В файловой системе FAT пространство, необходимое для каталога, плюс временное рабочее пространство, приблизительно равно 30% объема индексируемого текста. В файловой системе NTFS требуется пространство, приблизительно равное 15% объема индексируемого текста.

Улучшение производительности

Улучшение производительности


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

Улучшение стабильности служб

Улучшение стабильности служб


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

Улучшение защищенности служб

Улучшение защищенности служб


В составе IIS 6.0 реализован целый ряд механизмов и технологий, увеличивающих защищенность веб-приложений и оперируемых ими данных. Одно из коренных отличий служб IIS 6.0 от предыдущих версий (с точки зрения системы безопасности) заключается в том, что эти службы не инсталлируются по умолчанию непосредственно в ходе установки операционной системы. При необходимости администратор должен вручную выполнить процесс установки компонентов IIS. Тем самым сокращается количество уязвимых мест сервера под управлением Windows Server 2003 (ведь по статистике большинство атак на Windows 2000-серверы использовали уязвимости в службах IIS). Следует заметить, что службы IIS, устанавливаемые по умолчанию, зачастую просто выпадали из внимания администраторов (особенно тех, кто имел недостаточный опыт работы). Новый подход гарантирует, что службы будут устанавливаться только тогда, когда они действительно необходимы.
Другим новшеством явилось то, что даже в случае ручной установки компонентов служб IIS по умолчанию включается поддержка только статических механизмов публикации материалов. Механизмы динамической публикации содержимого веб-сайтов (такие как ASP, XML, WebDAV и другие технологии) по умолчанию отключены. Администратор должен вручную разрешить использование механизмов динамической публикации. Кроме того, обязательным условием является наличие отображений используемых расширений на соответствующие приложения. В противном случае будет возвращаться ошибка 404 (ресурс не обнаружен).
Сведения о новых функциональных возможностях IIS 6.0, обуславливающих улучшение безопасности решений на его базе, приведены в табл. 16.3.

Управление информационным наполнением вебузла

Управление информационным наполнением веб-узла


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

Управление службой индексирования

Управление службой индексирования


Управление службой индексирования осуществляется при помощи специальной оснастки Indexing Service on Local Machine (Рисунок 16.19).

Управление службой MSMQ

Управление службой MSMQ


Управление MSMQ на локальном компьютере осуществляется при помощи оснастки Computer Management (Управление компьютером). В пространстве имен этой оснастки необходимо выбрать узел Service and Applications | Message Queuing (Службы и приложения | Очередь сообщений). Основное управление объектами MSMQ в организации осуществляется с применением оснастки Active Directory Users and Computers (Active Directory — пользователи и компьютеры). Для управления MSMQ в организации:
1. Запустите оснастку Active Directory Users and Computers.
2. В меню View (Вид) выберите пункт Users, Groups and Computers as Containers (Пользователи, группы и компьютеры как контейнеры), а затем в том же меню выберите пункт Advanced Features (Дополнительные функции).
3. В пространстве имен оснастки найдите нужный домен, затем подразделение, наконец, нужный компьютер, на котором установлена MSMQ, щелкните правой кнопкой мыши на узле msmq и в контекстном меню выберите пункт Properties (Свойства).

Управление SMTPсервером с помощью

Рисунок 16.15.Управление SMTP-сервером с помощью оснастки Internet Information Services (IIS) Manager

Установка компонентов службы Windows Media

Рисунок 16.23. Установка компонентов службы Windows Media


В качестве клиента служб Windows Media может выступать программа Windows Media Player (Проигрыватель Windows Media) (Рисунок 12.25), получающая и воспроизводящая потоковые данные с сервера. Эти потоковые данные могут включать видеоинформацию, звук, изображения, URL и сценарии.

Установка MSMQ

Установка MSMQ


Чтобы добавить или удалить службу MSMQ, на панели управления запустите утилиту Add or Remove Programs (Установка или удаление программ) и воспользуйтесь мастером Windows Components Wizard. Из списка предлагаемых компонентов выберите Application Server (Сервер приложений) и нажмите кнопку Details (Подробно). В открывшемся окне установите флажок в строке Message Queuing (Очереди сообщений) (Рисунок 16.21). Нажмите кнопку Next (Далее) и следуйте командам мастера.

Установка служб IIS

Установка служб IIS


Как уже было сказано ранее, по соображениям безопасности службы I1S не устанавливаются по умолчанию непосредственно в ходе инсталляции операционной системы. В случае необходимости администратор должен вручную выполнить установку необходимых компонентов IIS при помощи мастера установки компонентов Windows (Add/Remove Windows Components Wizard).

Установка служб очереди сообщений

Рисунок 16.21. Установка служб очереди сообщений


При необходимости администратор может выбрать, какие именно компоненты службы очередей сообщений будут установлены на сервере. Для этого, выбрав строку Message Queuing, необходимо нажать кнопку Details и установить флажки около нужных компонентов (Рисунок 16.22).

Установка службы электронной почты

Рисунок 16.16. Установка службы электронной почты

Утилита Remote Administration (HTML)

Утилита Remote Administration (HTML)


Для управления свойствами служб IIS в Remote Administration (HTML) используется узел, который в оснастке Internet Information Services (IIS) Manager в списке узлов отображается как Web Sites | Administration. При установке IIS данному узлу по умолчанию назначаются номера портов TCP 8099 и SSL 8098. Узел отвечает на запросы веб-браузеров независимо от того, к какому доменному имени (из связанных с данным компьютером) происходит обращение при совпадении номера порта, который добавляется в конце к имени узла. Если используется базовая (basic) аутентификация, то от администратора при подключении к административному узлу будут запрошены имя пользователя и пароль. Только члены группы Administrators (Администраторы) могут использовать данный административный узел.
Хотя HTML-версия диспетчера служб Интернета (Рисунок 16.6) реализует большинство функциональных возможностей оснастки IIS, версия с использованием HTML предназначена для удаленного управления по медленным коммутируемым линиям. В ней не поддерживается, например, щелчок правой кнопкой мыши. Многие из знакомых кнопок на панели или заголовки вкладок отображаются в виде гиперссылок в левой панели окна браузера.

Рисунок 16.6. Утилита Remote Administration (HTML)


Утилита Remote Administration (HTML) может быть установлена только на NTFS-раздел.
Утилита Remote Administration (HTML) по сути представляет собой веб-приложение, доступ к которому осуществляется через Internet Explorer no URL https://<имя_сервера>:8098, где в качестве имя_сервера указывается реальное доменное имя компьютера, на котором функционируют службы IIS. В процессе загрузки утилиты администратор должен будет пройти процесс аутентификации. Только в случае успешного завершения этого процесса утилита будет загружена.

Виртуальные каталоги

Виртуальные каталоги


Чтобы публиковать информацию из любого каталога, который не содержится внутри корневого каталога, нужно создать виртуальный каталог. Виртуальный каталог — это каталог, который не содержится в корневом каталоге, но для клиента он выглядит так, как если бы он был частью корневого каталога.
Виртуальный каталог имеет псевдоним, т. е. имя, которое веб-браузеры используют для обращения к этому каталогу. Поскольку псевдоним обычно короче полного пути каталога, пользователям его удобнее вводить. Псевдоним безопаснее; пользователи не знают, где файлы физически расположены на сервере, и не могут использовать эту информацию для изменения этих файлов. Псевдонимы упрощают перемещение каталогов в узле. Не изменяя URL-адрес каталога, можно изменить отображение между псевдонимом и физическим местоположением каталога.
Предположим, что для публикации информации в сети установлен узел infoserver. В табл. 16.6 показано соответствие между физическим местоположением файлов и URL, по которому файлы доступны.

Виртуальный сервер новостей для

Виртуальный сервер новостей для внутренних корпоративных целей


Общение важно для любой группы людей, работающих вместе. Во многих организациях трудно заставить всех членов группы применять средства совместной работы на постоянной основе. Телеконференции могут решить проблемы общения и взаимодействия людей. Они дают возможность любому в группе читать или помещать свою информацию. Просто также найти нужную информацию по заданной тематике, поскольку статьи организованы в виде тематических потоков. В отличие от электронной почты, телеконференции обеспечивают механизм легкого архивирования информации для справочных целей.
Цель: Улучшить возможности взаимодействия между членами отдела, работающими над проектом, и усовершенствовать организацию хранения и архивирования информации.
Состав программного обеспечения: Microsoft Windows Server 2003, Microsoft Internet Information Services (IIS), Microsoft Internet Mail and News или Microsoft Outlook Express.
Среда: Сеть на базе Microsoft Windows.
Установка: Установить службу NNTP — компонент IIS.
Прочие аспекты: Чтобы использовать телеконференции в качестве информационного архива, необходимо запретить удаление статей с истечением времени и производить периодическую архивацию информации.
Функционирование: Выполнение функций поддержки нескольких телеконференций в пределах организации потребует не очень больших ресурсов со стороны сервера. Можно использовать любой компьютер, работающий под управлением Windows Server 2003. Поскольку служба NNTP работает по стандартному протоколу NNTP, сотрудники могут иметь доступ к телеконференциям, используя любое клиентское программное обеспечение, поддерживающее NNTP, однако предпочтительно работать с Microsoft Internet Mail and News и Outlook Express — клиентами, которые обеспечивают дополнительные функции защиты, если есть потребность в таких функциях. Сервер и клиенты должны поддерживать TCP/IP.
URL для телеконференций будет иметь следующие форматы:

news://сервер/телеконференция news://сервер/телеконференция/статья
где сервер — имя или IP-адрес сервера NNTP, телеконференция — имя телеконференции, а статья — необязательный идентификатор конкретной статьи.
В зависимости от того, насколько конфиденциальными будут статьи, можно настраивать параметры защиты для телеконференции. Если информация доступна любому в организации и сеть защищена брандмауэром, можно разрешить анонимный вход. Для большей защиты можно использовать штатные средства безопасности Windows Server 2003, которые применяются к каждому пользователю телеконференции. Можно ограничить доступ к каталогам телеконференций для определенных учетных записей. Служба NNTP управляет защитой, используя учетные записи Windows Server 2003 и соответствующие разрешения.
Результат: Работа членов отдела упростится. Сотрудники смогут читать и публиковать статьи, содержащие информацию по проекту, на сервере новостей. Для обсуждения деталей проекта не потребуются личные встречи, отнимающие время.

Вкладка Services окна свойств встроенного брандмауэра

Рисунок 16.3. Вкладка Services окна свойств встроенного брандмауэра


Прежде всего, если в системе Windows Server 2003 активизирован встроенный брандмауэр, администратор должен выполнить его настройку, чтобы разрешить обращение пользователей к службам IIS. В противном случае пользователи не смогут получить к ним доступа, поскольку соответствующие пакеты будут отбрасываться брандмауэром.
Для настройки брандмауэра откройте окно свойств интересующего сетевого подключения и перейдите на вкладку Advanced (Дополнительно). Нажмите кнопку Settings (Настройки) и в открывшемся окне перейдите на вкладку Services (Службы) (Рисунок 16.3). На этой вкладке отметьте службы, доступ к которым будет разрешен внешним пользователям.

Выбор компонентов служб очереди сообщений

Рисунок 16.22. Выбор компонентов служб очереди сообщений


Сначала нужно установить сервер MSMQ на контроллере домена Windows Server 2003 (в группе серверов, объединенных территориально), а затем можно устанавливать программное обеспечение MSMQ на других компьютерах.

Выполнение установки

Выполнение установки


Установка служб IIS может быть выполнена двумя способами: при помощи утилиты Add or Remove Programs, расположенной на панели управления, или при помощи мастера Configure Your Server Wizard. Этот мастер предлагает самый простой способ установки служб IIS. На странице Server Role (Роль сервера) (см. Рисунок 1.22) необходимо выбрать пункт Application server (IIS, ASP.NET) и нажать кнопку Next (Далее).

Задание домашнего каталога

Задание домашнего каталога


Каждый веб- или FTP-узел должен иметь корневой (домашний) каталог. Домашний каталог — отправная точка для организации информационной структуры публикуемых страниц. Он содержит домашнюю страницу или индексный файл, который является стартовой страницей узла и содержит ссылки на другие страницы на узле. Домашний каталог привязывается к имени домена узла или к имени сервера.

Рисунок 16.10. Задание домашнего каталога


Например, если имя домена узла — www.myfirm.com и корневой каталог — \Webserver\MyFirm, то браузер, обращаясь по URL http://www.myfirm.com, получит файлы из корневого каталога. В интрасети, если имя сервера — infoserver, то браузер, обращаясь по URL http: //infoserver, получит доступ к файлам в корневом каталоге.
Корневой каталог по умолчанию создается при установке служб IIS, а также при создании нового веб-узла. Корневой каталог можно изменять (Рисунок 16.10).

Internet Information Services 6.0

Атрибуты

Атрибуты


Каждый объект каталога состоит из набора атрибутов (attributes), каждый из которых содержит частичку информации, характеризующей объект. Так, например, в качестве атрибутов экземпляра класса "пользователь" могут выступать имя и фамилия пользователя, а также имя сопоставленной ему учетной записи. В документации Microsoft часто называет атрибутами свойства (properties) объекта. Атрибуты могут быть обязательными (mandatory) или необязательными (optional). Значения обязательных атрибутов должны быть явно определены в процессе создания объекта.
С каждым атрибутом в схеме связано понятие синтаксиса (syntax), который, по своей сути, является характеристикой атрибута. Синтаксис определяет тип значения атрибута (число, строка), порядок следования байтов и правила сравнения (matching rules), используемые для сравнения атрибутов данного типа. Служба каталога Active Directory допускает добавление описаний новых атрибутов и изменение существующих. Однако добавление новых синтаксисов, так же как и изменение существующих, запрещается. Определяя новый атрибут, администратор может только выбрать необходимый синтаксис из списка уже существующих.

Дерево и лес доменов

Рисунок 18.1. Дерево и лес доменов


Первое созданное в лесу доменов дерево является корневым деревом. Корневое дерево используется для ссылки на лес доменов. Первый созданный в дереве домен называется корневым доменом дерева (tree root domain), который используется для ссылки на данное дерево. Совершенно очевидно, что корневой домен является определяющим для всего дерева.
Соответственно, первый домен, созданный в лесу доменов, называется корневым доменом леса (forest root domain). Корневой домен леса играет очень важную роль, связывая деревья, образующие лес доменов, воедино и поэтому не может быть удален. В частности, он хранит информацию о конфигурации леса и деревьях доменов, его образующих.
Особое внимание необходимо уделить вопросу именования доменов и, в частности, корневого домена. Для корневого домена лучше всего использовать доменное имя второго уровня. Как будет показано ниже и в следующей главе, именно домены второго уровня используются механизмом маршрутизации доменных суффиксов (в случае взаимодействия двух лесов доменов).

Доменная структура Active Directory

Доменная структура Active Directory


Понятие домена является ключевым для Active Directory. Домены выступают в качестве основного средства формирования пространства имен каталога. Другие уровни формирования структуры каталога сосредотачиваются либо на административной иерархии, либо на физической структуре сети.

Домены

Домены


Операционные системы Windows традиционно использовали понятие "домена" для логического объединения компьютеров, совместно использующих единую политику безопасности. Домен традиционно выступает в качестве основного способа создания областей административной ответственности. Как правило, каждым доменом управляет отдельная группа администраторов. В Active Directory понятие домена было расширено. Перечислим задачи, которые могут быть решены путем формирования доменной структуры.

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

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

Разграничение доступа к объектам. Каждый домен реализует собственные настройки безопасности (включая идентификаторы безопасности и списки контроля доступа). Разнесение пользователей в различные домены позволяет эффективно управлять доступом к важным ресурсам. С другой стороны, применение доверительных отношений (trust relationships) позволяет обеспечить пользователям одного домена доступ к ресурсам других доменов.

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

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

Ограничение размера копии кaталога. Каждый домен Active Directory может содержать до миллиона различных объектов. Тем не менее, реально использовать домены такого размера непрактично. Следствием большого размера домена является большой размер копии каталога. Соответственно, огромной оказывается нагрузка на серверы, являющиеся носителями подобной копии. Администратор может использовать домены как средство регулирования размера копии каталога.

Доверительные отношения между лесами доменов

Доверительные отношения между лесами доменов


Процесс создания отношений между лесами доменов заслуживает особого внимания. Организация взаимодействия двух лесов доменов, соединенных между собой отношениями доверия, имеет свои специфические моменты.
Рассмотрим процесс аутентификации пользователей. Когда пользователь запрашивает доступ к ресурсам домена, расположенного в доверенном лесе доменов, активизируется механизм, получивший название маршрутизации суффиксов (name suffix routing). Этот механизм работает только с доменными именами второго уровня (такими, например, как khsu.ru, ayan.ru). Домены третьего уровня (например, kit.khsu.ru) и ниже механизмом маршрутизации суффиксов не поддерживаются. Механизм маршрутизации суффиксов гарантирует, что все запросы аутентификации, адресуемые домену второго уровня, будут маршрутизироваться соответствующему домену.
Дочерние домены, подключаемые к доменам второго уровня, наследуют от них информацию, необходимую для маршрутизации суффиксов. Поэтому они также смогут выполнить маршрутизацию запроса на аутентификацию пользователя.

Доверительные отношения

Доверительные отношения


Доверительные отношения (trusts) представляют собой связь, устанавливаемую между доменами, позволяющую пользователям одного домена аутентифицироваться контроллером другого домена. Наличие механизма доверительных отношений позволяет организовывать совокупность доменов в некоторую структуру. В этой структуре домены связываются между собой определенным образом отношениями доверия.
Доверительные отношения реализуются в рамках механизма аутентификации. Суть доверительных отношений между двумя доменами сводится к тому, что доверяющий домен (trusting domain) доверяет процесс аутентификации доверенному домену (trusted domain). Пользователь, аутентифицированный доверенным доменом, может получить доступ к ресурсам в доверяющем домене.
Механизм аутентификации NTLM, реализованный в рамках архитектуры Windows NT, допускает создание только односторонних доверительных отношений. Если администратору было необходимо установить между доменами отношения взаимного доверия, он должен был создать доверительные отношения в обе стороны.
Служба каталога Active Directory допускает создание как односторонних, так и двусторонних доверительных отношений. Так же как и в случае Windows NT, односторонние доверительные отношения реализуются посредством механизма аутентификации NTLM. Двусторонние доверительные отношения строятся на основе протокола аутентификации Kerberos v5 и обладают свойством транзитивности.
Транзитивность доверительных отношений предполагает сквозную аутентификацию пользователей в цепочке доменов, связанных между собой подобными отношениями. Например, если домен А доверяет домену В, а домен В доверяет домену С, то между доменами А и С автоматически устанавливаются доверительные отношения (эти отношения неявные). Односторонние доверительные отношения NTLM не обладают свойствами транзитивности. Для создания отношений полного доверия между пятью доменами необходимо будет установить двадцать односторонних доверительных отношений. Аналогичного результата можно добиться при помощи всего лишь четырех двусторонних транзитивных доверительных отношений.

Для использования доверительных отношений не имеет значения, какой механизм аутентификации используется клиентом. Даже если клиент не поддержи- ' вает протокол Kerberos, он может быть аутентифицирован через двусторонние доверительные отношения.
Архитектура Windows Server 2003 позволяет использовать доверительные транзитивные отношения как для соединения доменов в пределах одного леса, так и для соединения разных лесов доменов. Кроме того, могут быть установлены доверительные отношения между различными областями Кег-beros (Kerberos realms).
Все поддерживаемые типы доверительных отношений перечислены в табл. 18.1.

Физическая структура каталога

Физическая структура каталога


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

Глобально уникальные идентификаторы

Глобально уникальные идентификаторы


Отличительное имя однозначно определяет объект в каталоге. Однако перемещение объекта или его переименование (равно как и переименование любого из контейнеров, внутри которых данный объект содержится) приводит к изменению его отличительного имени. Это может привести к неправильной работе приложений, использующих отличительные имена для уникальной идентификации объектов. Задача уникальной и однозначной идентификации объекта может быть решена посредством введения специального атрибута, значение которого не менялось бы при переименовании или перемещении объекта. В службе каталога Active Directory обеспечение уникальности объектов достигается посредством глобально уникального идентификатора (Global Unique Identifier, GLJID), представляющего собой 128-разрядное число.
Глобально уникальный идентификатор генерируется непосредственно в момент создания объекта в каталоге и является одним из обязательных атрибутов, который не может быть изменен ни при каких обстоятельствах. В случае изменения отличительного имени глобально уникальный идентификатор остается неизменным, определяя конкретный объект каталога. Это свойство глобальных идентификаторов можно использовать при разработке приложений, работающих с объектами каталога.

Групповые политики

Групповые политики


В настоящее время практически любой производитель системного программного обеспечения встает перед проблемой снижения общей стоимости владения системой (total cost ownership). Эта проблема заключается в том, что развитие и связанное с этим усложнение технологий приводит к увеличению затрат на администрирование. В таких условиях корпорации вынуждены либо постоянно увеличивать штат администраторов, либо упрощать процесс управления за счет отказа от тех или иных сервисов и технологий.
Каждый разработчик подходит к решению этой проблемы по-своему. Компания Microsoft традиционно предлагает целый набор решений, позволяющих упростить процесс управления сетевыми ресурсами, а следовательно снизить общую сумму административных затрат.
Одной из проблем, встающих перед системным администратором, является проблема формирования индивидуального окружения пользователей. Начиная с Windows 2000, для формирования окружения пользователей используется механизм групповых политик (group policy). Под групповой политикой понимается совокупность параметров и настроек системы, определяющая конкретное окружение пользователя. Администратор может использовать механизм групповых политик для централизованного управления средой пользователей.

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

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

Определение параметров системы безопасности. С каждым пользователем или компьютером может быть ассоциирован определенный набор настроек системы безопасности. В данном случае принято говорить о политике безопасности (security policy) определяемой в контексте групповой политики. Политика безопасности позволяет однообразно конфигурировать большое количество субъектов безопасности. Например, определить уровень доступа к системному реестру или задать порядок осуществления аудита событий.

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

Перенаправление пользовательских папок. Папка My Documents (Мои документы) традиционно рассматривается как место хранения пользовательских документов. В корпоративной сети, в которой работает множество мобильных пользователей, актуальной становится проблема доступности этих документов. Посредством механизма групповой политики администратор может задать перенаправление всех обращений пользователей к этой папке на некоторый сетевой ресурс.

Группы

Группы


Подразделения являются не единственным механизмом, который администратор может использовать для группировки объектов по некоторому признаку. Объекты, ассоциированные с пользователями, компьютерами и контактной информацией, могут быть объединены в специальные группы (groups). Это позволяет упростить процесс управления, поскольку администратор может в процессе управления сослаться на всю группу, а не указывать отдельные объекты. Наиболее часто группы упоминаются в контексте объединения пользователей. Тем не менее, необходимо всегда помнить, что группа может включать в себя объекты следующих типов:

пользователи (users);

компьютеры (computers);

контакты (contacts).

Active Directory позволяет объединять объекты в группы двух типов: группы безопасности (security groups) и группы рассылки (distributed groups).
Группы безопасности рассматриваются подсистемой безопасности в качестве своих субъектов. Другими словами, они могут использоваться для разграничения доступа к ресурсам сети. Выдавая разрешение на доступ к объекту определенной группе, администратор автоматически разрешает доступ к данному объекту всем членам данной группы.

Группы безопасности могут также использоваться для ограничения действия групповой политики. Об этом будет рассказано в главе 21 "Использование групповых политик".
Группы рассылки изначально ориентировались на использование почтовой системой, как средство одновременной передачи сообщения некоторому коллективу пользователей. В настоящее время механизм групп рассылок Active Directory используется в почтовой системе Microsoft 2000 Exchange.
С каждой группой объектов связано понятие области действия (group scope). Область действия определяет, в какой части леса доменов на данную группу можно ссылаться. Существует три области действия групп:

доменная область действия (domain local scope);

глобальная область действия (global scope);

универсальная область действия (universal scope).

Область действия группы может быть различной в зависимости от того, на каком функциональном уровне находится домен. На функциональном уровне Windows 2000 mixed доступны только две области действия групп: доменная и глобальная.
На функциональном уровне Windows 2000 mixed также ограничена возможность использования механизма вложенных групп (nested groups). Разрешается только включать группы с глобальной областью действия в группы с доменной областью действия. Подобные ограничения объясняются требованиями сохранения совместимости с контроллерами домена Windows NT, которые используют описанный формат групп пользователей.
На функциональных уровнях домена Windows 2000 native и Windows Server 2003 становится доступной универсальная область действия. Кроме того, становится доступной возможность вложенности групп. На этих функциональных уровнях администратор может без труда конвертировать группы из одного типа в другой. Охарактеризуем группы каждой области действия на этих функциональных уровнях.

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

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

Группа с универсальной областью действия. Эти группы также доступны в рамках всего леса доменов. В состав группы могут входить объекты, а также группы с универсальной или глобальной областью действия, принадлежащие к любому домену леса. Далее мы будем называть группы этой области действия универсальными группами.

С каждой группой в момент создания ассоциируется объект каталога, значения атрибутов которого определяют ее характеристику. Один из атрибутов содержит список всех членов группы. В случае изменения состава группы будут реплицироваться не все значения атрибута (в случае, если группа насчитывает тысячи объектов, подобная репликация может вызвать заметный трафик), а только произведенные изменения. В данном случае речь идет о механизме репликации связанных значений (linked value replication). Этот механизм будет работать только в случае, когда лес доменов находится на функциональном уровне Windows Server 2003.

В данном разделе речь велась о группах Active Directory. Однако в контексте каждого компьютера Windows NT/2000 или Windows Server 2003 могут быть созданы так называемые локальные группы (local group). Эти группы доступны только в пределах того компьютера, к которому они принадлежат.

Иерархия доменов

Иерархия доменов


Для именования доменов используется соглашение о доменных именах. Имя домена записывается в форме полного доменного имени (Fully Qualified Domain Name, FQDN), которое определяет положение домена относительно корня пространства имен. Полное доменное имя образуется из имени домена, к которому добавляется имя родительского домена. Так, например, для домена kit, являющегося дочерним по отношению к домену khsu.ru, полное доменное имя будет записано в форме kit. khsu.ru.
Выбор подобной схемы именования позволил формировать доменное пространство имен, аналогичное пространству имен службы DNS. Отображение доменов Active Directory на домены DNS позволило упростить процессы поиска серверов служб и разрешения имен, осуществляемые серверами DNS в ответ на запросы клиентов службы каталога.

Следует заметить, что каждому домену Active Directory помимо DNS имени сопоставлено уникальное NetBIOS-имя. Это имя используется для идентификации домена клиентами Windows 9x/NT.
Совокупность доменов, использующих единую схему каталога, называется лесом доменов (forest). Строго говоря, входящие в лес домены могут не образовывать "непрерывного" пространства смежных имен. Тем не менее, так же как и в случае пространства имен DNS, домены Active Directory могут образовывать непрерывное пространство имен. В этом случае они связываются между собой отношениями "родитель-потомок". При этом имя дочернего домена обязательно включает в себя имя родительского домена. Совокупность доменов, образующих непрерывное пространство смежных имен, называют деревом доменов (domain tree) (Рисунок 18.1). Лес может состоять из произвольного количества деревьев домена.

Имена NetBIOS

Имена NetBIOS


До появления службы каталога Active Directory в качестве основного способа именования объектов в операционных системах Windows применялись имена NetBIOS. В частности этот способ именования используется в операционных системах Windows 95/98/NT. Имена пользователей, компьютеров и доменов в среде Windows NT представляют собой имена NetBIOS. Архитектура этих операционных систем и, в частности, сетевых компонентов строится на основе имен NetBIOS. Большинство приложений, разработанных для этого семейства операционных систем, предполагают использование только этой схемы именования. Данная схема именования была реализована в Active Directory с целью сохранения обратной совместимости со старыми операционными системами и разработанными для них приложениями.
Имя NetBIOS должно быть уникально в пределах домена и его длина не должна превышать 15 символов.

Канонические имена

Канонические имена


Вместо отличительного имени для определения положения объекта в дереве каталога можно использовать так называемое каноническое имя (canonical name). Принцип построения канонического имени аналогичен принципу формирования отличительных имен, за исключением того, что при записи канонического имени опускаются спецификаторы, обозначающие тип объекта или контейнера. Для указания домена в каноническом имени используется соглашение о доменных именах. Ниже приводится пример канонического имени: khsu.ru/cit/nd/tasha

Компоненты службы Active Directory

Компоненты службы Active Directory


Перейдем от терминологии к рассмотрению механизмов и подсистем, составляющих архитектуру Active Directory. Для начала рассмотрим структуру службы каталога.
Active Directory представляет собой совокупность служб, обслуживающих обращения пользователей к каталогу. Каталог рассматривается как распределенная база данных, в которой хранятся сведения об объектах сети. Пользователь не может работать с каталогом напрямую, а взаимодействует с ним через целый ряд подсистем и механизмов, которые в совокупности называются службой каталога. С точки зрения обслуживания обращений пользователей подсистемы службы каталога образуют некую структуру, в которой компания Microsoft выделяет пять уровней.
1. Интерфейсы доступа к каталогу. Это самый верхний уровень службы каталога, отвечающий за непосредственное взаимодействие с приложениями пользователей. На данном уровне описаны все возможные методы доступа к каталогу. Можно рассматривать данный уровень как набор прикладных интерфейсов программирования (Application Program Interfaces, API), посредством которых приложения пользователей могут взаимодействовать с системным агентом каталога.
2. Системный агент каталога (Directory System Agent, DSA). Любой клиент, подключающийся к каталогу, взаимодействует с DSA. Мы уже сталкивались с системным агентом каталога при рассмотрении спецификации Х.500. Все запросы, поступающие от пользователей, обрабатываются агентом, он же возвращает клиентам результаты запросов.
3. Уровень базы данных (Database Layer). Данный уровень службы каталога осуществляет преобразование запросов пользователей в формат, приемлемый для расширяемой оболочки хранилища. Это преобразование необходимо, поскольку расширяемая оболочка хранилища манипулирует данными в представлении реляционной базы данных. Однако вышестоящие уровни представляют содержимое каталога в виде древовидной структуры.
4. Расширяемая оболочка хранилища (Extensible Storage Engine, ESE). Расширяемая оболочка хранилища представляет собой механизм управления реляционным хранилищем данных, в форме которого реализован каталог. Компания Microsoft рассматривает ESE в качестве стандартного механизма управления реляционными хранилищами и широко применяет ее в различных своих продуктах. ESE берет на себя все обязанности по обслуживанию запросов, поступающих от пользователей (и преобразованных в соответствующий формат на вышестоящем уровне) на извлечение данных из каталога и манипуляции ими. Можно представить ESE как систему управления базой данных (СУБД). При этом в качестве базы данных выступает непосредственно хранилище данных.
5. Файлы хранилища (Data Store files). Хранилище данных реализовано в виде набора файлов, которые используются непосредственно для организации хранения данных каталога. Поскольку информация, содержащаяся в этих файлах, критически важна для функционирования Active Directory, доступ к ним имеет только расширяемая оболочка хранилища. В данном случае можно говорить о самом низшем уровне операций в рамках службы каталога. Именно на этом уровне происходит манипуляция с данными, содержащимися в каталоге.

Контроллеры домена

Контроллеры домена


Серверы Windows Server 2003, на которых функционирует экземпляр службы каталога Active Directory, называются контроллерами домена (domain controller, DC). Контроллеры домена являются носителями полнофункциональных копий каталога. Применительно к Windows Server 2003 контроллеры домена выполняют задачи, перечисленные ниже.

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

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

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

Аутентификация пользователей. Контроллер домена осуществляет проверку полномочий пользователей, регистрирующихся на клиентских системах. Каждый контроллер домена Windows Server 2003 может рассматриваться как Центр распределения ключей (KDC) Kerberos.

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

Механизмы репликации каталога

Механизмы репликации каталога


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

Модель именования LDAP

Модель именования LDAP


Одним из условий успешного манипулирования объектами каталога является однозначная идентификация каждого объекта. Для именования и идентификации объектов в каталоге протокол LDAP использует механизм отличительных имен (Distinguished Name, DN). Отличительное имя однозначно определяет положение объекта в информационном дереве каталога, представляя информацию обо всех узлах дерева, которые необходимо пройти, чтобы прийти от данного объекта к корню дерева. Можно провести аналогию с понятием полного пути, используемым для определения месторасположения файла в файловой системе. Ниже приводится пример отличительного имени, идентифицирующего объект Tasha, принадлежащий к подразделению ND домена khsu.ru: DC=ru,DC=khsu,OU=ND,CN=Users,CN=Tasha
Для формирования отличительного имени используются спецификаторы (specifier), определяющие тип объекта:

DC (Domain Component) — спецификатор "составная часть доменного имени";

OU (Organizational Unit) — спецификатор "организационная единица";

CN (Common Name) — спецификатор "общее имя".

Имя, идентифицирующее сам объект, согласно терминологии LDAP выступает в качестве относительного отличительного имени (Relative Distinguish Name, RDN). Относительное отличительное имя может повторяться в рамках всего каталога. Однако оно должно быть уникально в пределах родительского контейнера. Ниже приводится пример относительного отличительного имени объекта Tasha: CN=Tasha
Механизм отличительных имен LDAP является предпочтительной, но не единственной схемой именования объектов в Active Directory. Поэтому ниже мы рассмотрим все другие возможные схемы именования.

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

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


Параметры групповой политики хранятся в виде объектов групповой политики (Group Policy Object, GPO). Эти объекты хранятся в каталоге подобно другим объектам. Для именования объекта групповой политики используется глобальный уникальный идентификатор (GUID).
Различают два вида объектов групповой политики — объекты групповой политики, создаваемые в контексте службы каталога, и локальные объекты групповой политики. Локальные объекты групповой политики (Local Group Policy Object, LGPO) создаются в процессе установки операционной системы Windows 2000/XP или Windows Server 2003. Локальный объект GPO используется в том случае, когда компьютер не включен в состав домена. Как только компьютер подключается к домену, компьютер и пользователь, работающий на нем, подпадают под действие объектов GPO, определенных в контексте данного домена, и параметры, заданные локальным объектом GPO, могут быть переопределены на более высоком уровне (на уровне сайта, домена или подразделения).
Объекты групповой политики размещаются в каталоге в специальных контейнерах групповой политики (Group Policy Container, GTC). Кроме того, для размещения файлов, связанных с объектами GPO, система использует специальную папку SYSVOL\sysvol\<имя домена>\роlicies. В этой папке размещаются шаблоны групповой политики (Group Policy Template, GPT). Шаблон групповой политики представляет собой папку, в качестве- имени которой используется глобальный уникальный идентификатор (GUID) соответствующего объекта групповой политики. В шаблоне групповой политики размещаются административные шаблоны, сценарии и параметры безопасности.

Объекты и дерево каталога

Объекты и дерево каталога


Основным структурным компонентом каталога является элемент (entry), который в терминологии Active Directory называется объектом (object). Объекты являются фундаментальными единицами, которыми манипулирует служба каталога. При этом каждый объект характеризует некоторую отдельную сущность (например, принтер, компьютер, совместно используемую папку или пользователя).
Выделяют объекты двух типов — контейнерного и неконтейнерного типа. Объекты контейнерного типа способны выступать в качестве родительских объектов и могут быть использованы для размещения других объектов. Напрашивается аналогия с папками файловой системы, в которых могут быть размещены файлы и другие папки. Объекты контейнерного типа используются для организации объектов по какому-либо признаку. Например, все объекты, ассоциированные с пользователями, размещаются внутри объекта контейнерного типа. Объекты, ассоциированные с компьютерами, размешаются в другом объекте контейнерного типа. Такой подход позволяет упорядочить объекты и облегчить управление ими.
Множество объектов, содержащихся во множестве вложенных контейнеров, организовано в иерархическую структуру, которая в терминологии Х.500 называется информационным деревом каталога (Directory Information Tree, DIT). Листьями этого дерева всегда выступают объекты неконтейнерного типа, в то время как в качестве узлов дерева (node) выступают объекты контейнерною типа.
Каждую ветку дерева, вместе со всей совокупностью порожденных ею веток, можно рассматривать по отдельности как самостоятельное дерево. Такая совокупность называется прилегающим поддеревом (contiguous subtree). Можно представить пространство имен каталога в виде множества прилегающих поддеревьев. Фрагменты, представляющие собой законченные и непрерывные прилегающие поддеревья, называются контекстами имен (naming context). Самый верхний элемент в иерархии объектов каталога в терминологии Х.500 называют корнем дерева. Роль корня информационного дерева каталога в спецификации Х.500 играет объект rootDSE.

Основные имена субъектов безопасности

Основные имена субъектов безопасности


Механизм основных имен (Security principal name, SPN) реализует способ именования объектов каталога, рассматриваемых подсистемой безопасности Windows Server 2003 в качестве своих субъектов. Основное имя субъекта системы безопасности определяется в качестве одного из атрибутов объекта каталога и имеет следующий формат: <имя_субъекта>@<суффикс_основного_имени>
В качестве суффикса основного имени может выступать DNS-имя текущего или корневого домена. Возможно также применение альтернативных суффиксов, например, lex@ayan.ru или kaizer@khsu. Используемый для образования основного имени суффикс должен удовлетворять правилам построения доменных имен.
Применительно к объектам, ассоциированным с пользователями, следует говорить об основном имени пользователя (User Principal Name, UPN). Основное имя позволяет упростить процесс регистрации пользователей в сети на компьютерах, принадлежащих к различным доменам. Основное имя уникально в пределах леса доменов, поэтому для регистрации от пользователя не требуется указания домена, к которому он принадлежит. Ниже приводится пример основного имени пользователя: lex@ayan.ru
Другой плюс использования основных имен для идентификации объектов заключается в том, что основное имя никоим образом не связано с его отличительным именем. Вследствие этого основное имя не меняется даже в случае перемещения объекта в рамках каталога.

Основные концепции Active Directory

Основные концепции Active Directory


Для организации доменов на базе систем Windows 2000 Server и Windows Server 2003 используется служба каталога Active Directory. Каждый контроллер домена под управлением этих систем является сервером каталога Active Directory, и службу Active Directory невозможно развернуть без создания доменной структуры. Автономная версия службы каталога — Active Directory/Application Mode — не входит в состав систем Windows Server 2003 и планируется к выходу в конце 2003 года. . Поскольку понятия "домены Windows 2000/Server 2003" и "служба каталога Active Directory" тесно связаны, мы рассмотрим сначала возможности, организацию и использование службы Active Directory. Развертывание доменов на ее основе подробно описывается в следующей главе.

Подразделения (Организационные единицы)

Подразделения (Организационные единицы)


Подразделения, или организационные единицы (organizational unit) представляют собой объекты каталога контейнерного типа, посредством которых администратор может организовать объекты в соответствии с некоторой логической структурой вычислительной сети. Основное предназначение подразделений состоит в логической организации сетевых ресурсов с целью наиболее эффективного управления ими. Все объекты, размешенные внутри подразделения, рассматриваются как некоторый административный блок.
Рассмотрим задачи, для решения которых могут быть применены организационные единицы.

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

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

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

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

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

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

Полные доменные имена

Полные доменные имена


Полное доменное имя (Fully Qualified Domain Name, FQDN) используется для однозначной идентификации объектов в пространстве доменных имен. Полное доменное имя образуется в соответствии с соглашениями о доменных именах. В рамках службы каталога механизм полных доменных имен используется для идентификации доменов и принадлежащих им компьютеров. Применительно к компьютеру полное доменное имя состоит из имени компьютера и имени домена. Ниже приводится пример полного доменного имени для компьютера root, являющегося частью домена khsu. ru: root.khsu.ru

Понятие службы каталога и Active Directory

Понятие службы каталога и Active Directory


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

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

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

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

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

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

протокол LDAP;

система доменных имен (Domain Name System, DNS);

протокол аутентификации Kerberos v5.

Эти стандарты (особенно LDAP) определили терминологию, используемую в архитектуре Active Directory, поэтому сначала мы кратко рассмотрим их особенности и взаимодействие со службой Active Directory.

Протокол аутентификации Kerberos

Протокол аутентификации Kerberos


Протокол аутентификации Kerberos является основным механизмом аутентификации, используемым в среде доменов Active Directory на базе Windows 2000 Server и Windows Server 2003. Этот протокол был разработан в Массачу-сетском технологическом институте (Massachusetts Institute of Technology, MIT) в начале 1980-х. Существует несколько версий протокола Kerberos. В доменах Active Directory используется пятая версия протокола Kerberos, спецификация которого определена в стандарте RFC 1510.
Проблема аутентификации пользователя заключается в необходимости проверки того факта, что он является тем, за кого себя выдает. Известно множество различных способов проверки подлинности личности, которые упрощенно можно разделить на две группы:

проверка личности на факт соответствия некоторым индивидуальным характеристикам человека (проверка отпечатков пальцев, снимков радужки глаза, код ДНК и т. д.). Для применения этой группы методов аутентификации необходимо задействовать специальное оборудование;

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

Подробно протокол Kerberos v5 описывается в главе 22 "Средства безопасности Windows Server 2003".

Протокол LDAP

Протокол LDAP


Для лучшего понимания роли протокола LDAP рассмотрим основные идеи спецификации Х.500. Данная спецификация была разработана Международным консультационным комитетом по телефонии и телеграфии (Consultative Committee for International Telephone and Telegraph, CCITT) совместно с Международной организацией по стандартизации (International Standardization Organization, ISO). В рамках спецификации Х.500 определяется ряд понятий:

системный агент каталога (Directory System Agent, DSA) представляет собой базу данных, в которой хранится информация каталога. База данных имеет иерархическую организацию и позволяет быстро и эффективно осуществлять поиск и извлечение необходимых данных;

агент пользователя каталога (Directory User Agent, DUA) обеспечивает функциональность доступа к каталогу, которая может быть реализована в различных пользовательских приложениях;

протокол доступа к каталогу (Directory Access Protocol, DAP) контролирует процесс взаимодействия между системным и пользовательским агентами каталога.

Протокол DAP является достаточно громоздким и сложным. Поэтому позднее специалисты предложили несколько его модификаций, обеспечивающих более простой и быстрый способ доступа к каталогу. Одной из таких модификаций является протокол Lightweight Directory Access Protocol (LDAP, Облегченный протокол доступа к каталогу), впервые описанный в рамках спецификации RFC 1487. На настоящий момент имеются три версии этого протокола. Версия 2 описана в рамках RFC 1777, а версия 3 в спецификации RFC 2251.
Протокол LDAP обеспечивает доступ к каталогу, разработанному в соответствии с рекомендациями стандарта Х.500. Протокол представляет собой стандартное средство реализации доступа и обновления информации в каталоге для приложений. Протокол LDAP является частью стека протоколов TCP/IP, что и послужило одной из причин его популярности.
Другая ключевая особенность протокола LDAP, обеспечившая ему широкое распространение, заключается в том, что протокол не требует от каталога полной совместимости со спецификацией Х.500. Основное требование — служба каталога должна поддерживать систему именования Х.500. Это очень важный факт, поскольку, вопреки широко распространенному заблуждению, служба каталога Active Directory не является Х.ЗОО-каталогом. Разработчики компании Microsoft взяли за основу информационную модель Х.500 и реализовали поддержку протокола LDAP. Это позволило обеспечить необходимый уровень совместимости с большинством существующего программного обеспечения, что в условиях гетерогенных сред является одним из важнейших факторов. Доступ к содержимому каталога Active Directory no протоколу LDAP может осуществляться с помощью любого LDAP-клиента. При этом использование протокола LDAP не является единственно возможным способом доступа к каталогу Active Directory.

Служба каталога Active Directory поддерживает протокол LDAP версий 2 и 3.
Спецификация протокола LDAP базируется на четырех моделях.

Информационная модель (Information Model) описывает структуру каталога и содержащейся в ней информации.

Модель именования (Naming Model) описывает схему организации информации в каталоге и используемые схемы именования и идентификации объектов каталога.

Функциональная модель (Functional Model) определяет действия, которые могут быть осуществлены над информацией, размещенной в каталоге.

Модель безопасности (Security Model) описывает механизмы защиты информации, размещенной в каталоге.

Понимание этих моделей необходимо как для эффективного использования служб Active Directory в целом, так и для работы со многими системными утилитами и программами. Понимание моделей, на которых базируется протокол LDAP, необходимо также и для написания многих административных сценариев.

Расписание репликации

Расписание репликации


Процесс репликации изменений каталога может быть инициирован одним из двух способов:

уведомление об изменениях (change notification) используются между контроллерами домена внутри сайта. Если на некотором контроллере модифицируется атрибут какого-нибудь объекта, данный контроллер посылает уведомление первому партнеру по репликации, и это происходит через определенное время (по умолчанию 5 минут). После этого партнер запрашивает изменения у контроллера-источника изменений (originating DC) и получает их;

изменения реплицируются между сайтами согласно расписанию (schedule). Эти расписания определяются с помощью оснастки Active Directory Sites and Services.

Разделы каталога

Разделы каталога


С точки зрения механизма репликации Active Directory представляет собой не цельную иерархическую структуру, а отдельные фрагменты. Каждый фрагмент, являясь частью каталога, представляет собой самостоятельное дерево. В терминологии службы Active Directory подобная совокупность ветвей называется прилегающим поддеревом (contiguous subtree) или контекстом имен (naming context).
Разделение пространства имен каталога на фрагменты позволяет оптимизировать процесс синхронизации копий каталога между множеством его носителей. Это достигается за счет того, что в каждом контексте имен хранится определенного вида информация. По умолчанию каталог Active Directory поделен на три контекста имен, которые называются разделы каталога (directory partition):

доменный раздел каталога (Domain partition) используется для размещения информации о сетевых ресурсах, принадлежащих к определенному домену. Реплики доменного раздела располагаются на всех контроллерах указанного домена. Соответственно изменения, происходящие в этом разделе, реплицируются только на эти реплики;

раздел схемы (Schema partition). Понятие схемы каталога было дано в начале главе. Для ее хранения используется специальный раздел каталога. Поскольку схема является общей для всех доменов леса, изменения в ней распространяются на все носители копии каталога;

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

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

На серверах глобального каталога присутствует еще один раздел — содержащий подмножество атрибутов объектов всех доменных разделов каталога. При этом данный раздел доступен только для чтения информации.
Любой контроллер домена Active Directory может производить изменения в собственных репликах в любой момент времени. При этом все произведенные изменения будут синхронизированы с другими репликами. Подобная модель репликации получила название репликация с множеством равноправных участников (multimaster replication).

Разделы приложений

Разделы приложений


Дополнительно к перечисленным разделам, в каталоге Active Directory на базе систем Windows Server 2003 могут быть созданы специализированные разделы, которые получили название разделов приложений (application directory partitions). Разделы приложений могут быть созданы при необходимости администратором либо непосредственно самими приложениями. В разделе приложений могут быть размещены любые объекты, определения которых содержатся в схеме, за исключением субъектов подсистемы безопасности (таких, например, как учетные записи пользователей или компьютеров).
Служба каталога Active Directory, реализованная на базе Windows 2000 Server, использовала для размещения информации приложений доменные разделы и раздел конфигурации. Это приводило к тому, что информация приложений реплицировалась на все контроллеры домена (даже когда этого и не требовалось). Изменение этой информации приводило к синхронизации всех копий каталога. В крупной корпоративной сети подобное решение зачастую становилось причиной интенсивного трафика репликации.
Разделы приложений были реализованы в Windows Server 2003. Их использование позволяет сократить накладные расходы, вызванные репликацией. В отличие от трех основных разделов каталога, реплицируемых на все контроллеры домена, разделы приложений могут располагаться на строго оговоренных контроллерах. Администратор может перечислить контроллеры домена, на которые необходимо разместить копии определенного раздела каталога. В данном вопросе основным является потребность приложения в доступности данных. Приложениям зачастую не требуется, чтобы размещенная ими в каталоге информация была доступна повсеместно в сети. Существуют приложения, применение которых ограничено отдельным доменом или деревом доменов. Если приложение, для которого создается раздел, используется только в двух доменах леса, то копии раздела приложения должны быть размещены только на контроллерах домена двух указанных доменов. Контроллеры других доменов не будут содержать данный раздел.
Имеется два встроенных раздела приложений, которые используются службой DNS для размещения содержимого зон, интегрированных с Active Directory. Это разделы ForestDnsZones.forestName и DomamDnsZones.forestName. При этом вместо суффикса forestName в имени раздела указывается DNS-имя корневого домена леса. (Данные разделы рассматриваются в главе 13 "Серверы DHCP, DNS и WINS".)
Существует три способа создания раздела приложений.

Использование утилиты NtdsUtil.exe. Эта утилита командной строки представляет собой основной инструмент администратора службы каталога Active Directory, используемый для диагностики и разрешения проблем. Этот способ предполагает создание раздела приложения администратором вручную.

Использование утилиты Ldp.exe. Данная утилита позволяет администратору работать с любым LDAP-совместимым каталогом (каким, по сути, является Active Directory). Этот способ, так же как и предыдущий, предполагает создание раздела приложения администратором вручную.

Использование интерфейса прикладного программирования ADSI (Active Directory Service Interfaces). Приложения, использующие данный интерфейс для взаимодействия со службой каталога Active Directory, могут создавать разделы приложений в каталоге самостоятельно (например, в процессе развертывания).

Сайты

Сайты


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

Под термином "подсеть" в данном случае понимается подсеть IP. Администратор может создать в каталоге объекты, ассоциируемые с подсетями. Границы сайта описываются именно этими объектами.
Физическая структура сети, как правило, не является зеркальным отображением логической (доменной) структуры. Сайты представляют собой самостоятельные образования, напрямую не зависящие от доменной структуры вашей сети. Хотя администратор может использовать домены для регулирования трафика репликации, зачастую структура сайтов не отображается на иерархию доменов. Сайты не являются частью пространства имен каталога, они лишь характеризуют его физическую структуру. Это означает, что принадлежность объекта к тому или иному сайту не влияет на его положение в каталоге. Выбор того или иного сайта определяется, прежде всего, тем, в какой подсети физически находится данный объект. Например, в зависимости от того, на каком компьютере пользователь входит в сеть, он может рассматриваться как находящийся то в одном, то в другом сайте.
Поскольку структура сайтов реализуется независимо от структуры доменов, один домен может быть разделен на несколько сайтов и, напротив, один сайт может быть образован фрагментами нескольких доменов.
Структура сайтов является основным механизмом, посредством которого администратор может влиять на формирование топологии репликации. Поскольку считается, что сайты соединяются друг с другом медленными линиями связи, репликация изменений внутри сайта и между сайтами имеет несколько различий. Внутри сайта контроллеры домена соединены линиями с высокой пропускной способностью. Соответственно, произведенные изменения могут сразу же реплицироваться между контроллерами домена. Для репликации между сайтами обычно применяется передача изменений по определенному расписанию. Кроме того, в этом случае характерно использование маршрутов, основанных на стоимости доступных коммуникационных линий. В случае репликации между сайтами администратор может прибегнуть к сжатию передаваемых данных.
Процесс аутентификации пользователей может вызвать заметный трафик, особенно если речь идет о большом количестве пользователей (например, когда все сотрудники компании утром приходят на работу). Администратор должен обеспечить возможность аутентификации пользователей сайта, даже если коммуникационные линии, связывающие сайт с остальной сетью, заняты или недоступны.
При входе пользователя в сеть, его аутентификация осуществляется ближайшим контроллером домена. В процессе локализации ближайшего контроллера домена в первую очередь используется информация о сайте, к которому принадлежит компьютер, запрашивающий аутентификацию. Ближайшим считается контроллер домена, расположенный в том же сайте, что и аутентифицируемый пользователь. В каждом сайте необходимо установить как минимум один контроллер для каждого домена, охватываемого сайтом.
Важное место в процессе аутентификации занимает также сервер глобального каталога. Поэтому рекомендуется в каждом сайте размещать как минимум один сервер глобального каталога. Многие компоненты службы каталога (а также пользователи) используют серверы глобального каталога для поиска объектов. В случае, если доступ к серверу глобального каталога осуществляется через линии связи с низкой пропускной способностью, многие операции службы каталога будут выполняться медленно. Далее в этой главе мы еще вернемся к рассмотрению серверов глобального каталога.
В ходе создания леса доменов мастером установки автоматически создается сайт по умолчанию с именем Defauit-First-site-Name. Формируя физическую структуру сети, администратор должен самостоятельно создать новые сайты и задать для них границы, создав объекты, ассоциированные с имеющимися подсетями. В процессе создания нового контроллера на основании выделенного ему IP-адреса служба каталога автоматически отнесет его к соответствующему сайту. При этом в разделе конфигурации каталога в рамках данного сайта будет создан объект класса Server, ассоциируемый с контроллером домена.

Серверы глобального каталога

Серверы глобального каталога


Глобальный каталог (global catalog) представляет собой базу данных, содержащую фрагменты всех доменных контекстов имен, образующих пространство имен каталога. Глобальный каталог является важной и неотъемлемой частью Active Directory. В глобальном каталоге содержатся сведения обо всех объектах, принадлежащих к доменным контекстам имен. Однако в глобальном каталоге хранятся не все объекты целиком, а только подмножество их атрибутов. Выбираются те атрибуты, которые чаще всего присутствуют в запросах пользователей.
Атрибуты, размещаемые в глобальном каталоге, определяются в рамках схемы каталога. У каждого класса атрибутов имеется параметр isMemberof FartialAttributeSet. Если значение этого параметра равно TRUE, атрибут будет размещен в глобальном каталоге. Администратор может определить для размещения в глобальном каталоге дополнительные атрибуты. Однако необходимо помнить, что расширение числа атрибутов, заносимых в глобальный каталог, приводит к росту его объема. Соответственно дороже обходится его обслуживание.
Процесс добавления нового атрибута для размещения в глобальном каталоге влечет за собой синхронизацию всех его реплик. Если лес находится на функциональном уровне Windows Server 2003, добавление нового атрибута приведет к репликации только этого атрибута на все носители глобального каталога. Если же лес находится на функциональном уровне Windows 2000, добавление нового атрибута приводит к полной синхронизации всех реплик глобального каталога.
Контроллер домена, выступающий в качестве носителя глобального каталога, принято называть сервером глобального каталога (global catalog server). Необходимо обратить внимание на то, что функции сервера глобального каталога могут быть возложены только на контроллер домена. При этом на контроллере домена создается дополнительный раздел, который используется для размещения базы данных глобального каталога.
Сервер глобального каталога выполняет две функции.

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

Аутентификация пользователей. Сервер глобального каталога предоставляет информацию о членстве пользователя в различных группах с универсальной областью действия (universal group). Эта информация требуется в процессе аутентификации пользователя. Именно на основании членства пользователя в тех или иных группах происходит назначение прав доступа. Более того, сервер глобального каталога необходим в том случае, если для регистрации в системе пользователь использует свое основное имя. Разрешение основного имени осуществляется непосредственно сервером глобального каталога. Если сервер глобального каталога оказывается недоступным, контроллер домена, осуществляющий аутентификацию, не будет располагать данными, необходимыми для авторизации пользователя. В результате пользователю будет отказано в регистрации. Исключение составляют члены группы Domain Admins (Администраторы домена), аутентификация которых осуществляется даже в том случае, когда сервер глобального каталога недоступен.

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

Схема каталога

Схема каталога


Определения всех классов объектов, а также совокупность правил, позволяющих управлять структурой каталога и его содержимым, хранятся в специальной иерархической структуре, которая называется схемой каталога (schema). Чтобы создать в каталоге объект нового типа, необходимо, прежде всего, добавить в схему определение нового класса объектов. При этом принято говорить о расширении (extending) схемы. Возможность расширения схемы фактически означает расширяемость каталога путем его адаптации для хранения новых типов объектов.
Информация схемы также хранится в виде объектов двух классов: схемы классов (Class schema) и схемы атрибутов (Attribute schema). Схема классов объединяет классы, определяющие типы объектов. В схеме атрибутов описываются атрибуты, которые могут быть определены для объектов каталога. Для каждого класса объектов в схеме определяются:

перечень атрибутов, которые обязательно должны быть определены для экземпляров указанного класса;

перечень атрибутов, которые могут быть определены для экземпляров данного класса;

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

Схемы именования объектов в Active Directory

Схемы именования объектов в Active Directory


Протокол LDAP предполагает единственный способ идентификации объектов в каталоге посредством отличительных имен. Однако служба каталога Active Directory позволяет использовать целый ряд дополнительных схем именования, каждая из которых применяется в определенных ситуациях.

Служба DNS

Служба DNS


Протокол LDAP представляет собой механизм доступа пользователей к каталогу. Однако для того, чтобы клиент смог подключиться к серверу LDAP и отправить свой запрос, он должен точно знать его расположение в сети. До сих пор мы не касались вопроса о том, как именно клиент узнает о расположении сервера LDAP. Проблема осложняется тем фактом, что в сети может иметься несколько LDAP-серверов, с которыми клиента соединяют коммуникационные линии с различной пропускной способностью. Кроме того, интересующая клиента информация может располагаться не на всех LDAP-серверах.
Компания Microsoft предложила задействовать Службу доменных имен (Domain Name Systems DNS) в качестве средства обнаружения (определения местонахождения) различных сетевых служб, например контроллеров доменов и Центров распределения ключей Kerberos. Следует заметить, что доменная служба имен традиционно используется в TCP/IP-сетях для разрешения символических имен в IP-адреса. Для обнаружения сетевых служб (сервисов) DNS использует специальный тип ресурсных записей. Речь идет об SRV-записях.
Нужно сразу отметить два важнейших момента:

Active Directory требует обязательного использования службы DNS.

Active Directory может работать с любой службой DNS, которая поддерживает SRV-записи, разрешает использование в именах символа подчеркивания ("_") и, желательно (но не строго обязательно), обеспечивает динамическое обновление ресурсных записей.

Соглашение о доменных именах, лежащее в основе DNS, используется как основной способ именования доменов Active Directory (на базе компьютеров под управлением Windows 2000 Server и Windows Server 2003). При этом доменное пространство имен Active Directory полностью отображается на пространство имен DNS. Другими словами, иерархия доменов корпоративной службы DNS аналогична иерархии доменов Active Directory.

Служба каталога и служба FRS

Служба каталога и служба FRS


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

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

Служба репликации файлов

Служба репликации файлов


Каталог рассматривается как централизованное место хранения информации о сетевых ресурсах. Однако в силу определенных причин некоторая часть информации не может быть размещена в каталоге. Например, старые версии операционных систем (Windows 9x/NT) используют специальный сетевой ресурс NETLOGON для размещения информации, необходимой для регистрации в сети. Эта папка используется для размещения перемещаемых или обязательных профилей пользователей, сценариев регистрации, системных политик и т. п. Эта информация жизненно необходима для корректного функционирования сети. При этом требуется, чтобы эта папка присутствовала на всех контроллерах домена.
Служба репликации файлов (File Replication Service, FRS) представляет собой механизм репликации с множеством равноправных участников, осуществляющий синхронизацию содержимого системного тома SYSVOL между контроллерами домена. Том SYSVOL создается на каждом сервере непосредственно в ходе повышения его до контроллера домена и используется для размещения системных файлов общего доступа. В частности, именно внутри него располагается уже упоминавшаяся папка NETLOGON. Помимо этого, в томе SYSVOL размещаются настройки объектов групповых политик, системные политики контроллеров домена и сценарии регистрации.

Поскольку служба репликации файлов использует модель с множеством равноправных участников (multimaster replication), изменение содержимого реплицируемой папки может быть произведено любым участником. При этом в цепочке серверов, участвующих в репликации, нельзя выделить какой-то один, координирующий процесс репликации. Каждый участник может изменить содержимое тома SYSVOL и передать сведения об изменении содержимого любым другим участникам.
Служба репликации файлов может также осуществлять синхронизацию содержимого набора реплик распределенной файловой системы DFS (см. главу 8 "Работа с дисковыми ресурсами").

Соединения сайтов

Соединения сайтов


Топология репликации формируется при помощи специального класса объектов — соединений (connections). Соединение представляет собой однонаправленное соглашение между двумя контроллерами домена о передаче изменений. С каждым соединением ассоциируется объект в разделе конфигурации каталога. Атрибуты объекта, ассоциированного с соединением, определяют передающего партнера по репликации, а также расписание репликации и используемый при этом транспорт. Все соединения автоматически генерируются системным сервисом Knowledge Consistency Checker, KCC, который проверяет существующую топологию и доступность имеющихся соединений и при необходимости вносит соответствующие коррективы.
Контроллеры домена, расположенные в различных сайтах и взаимодействующие между собой в процессе репликации, называются мостовыми серверами (bridgehead server). В каждом сайте один из контроллеров домена берет на себя обязанности по управлению входящими соединениями для всех мостовых серверов сайта. Этот контроллер домена называется генератором топологии между сайтами (Inter-Site Topology Generator, ISTG). Если контроллер домена, выполняющий функции ISTG, становится недоступен (например, выходит из строя), эта функция автоматически возлагается на другой контроллер домена.
В случае репликации между сайтами используется термин связь сайтов (site link), который описывает соединения двух и более узлов, способных обмениваться информацией при помощи единого транспорта. Связь узлов используется для задания стоимости соединения (cost), расписания репликации и транспорта. Механизм стоимостей позволяет оценить связь сайтов с точки зрения доступности коммуникационных линий и их пропускной способности. Если имеется несколько связей сайтов, для репликации будет выбрана та, что обладает меньшим значением стоимости.
Несколько связей сайтов, использующих единый транспорт, образуют связующий мост между узлами (site link bridge). Использование связующих мостов между сайтами полезно в больших сетях, поскольку избавляет от необходимости описывать все возможные комбинации соединений между каждым из сайтов.

Создание системного тома SYSVOL

Создание системного тома SYSVOL


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

По умолчанию том SYSVOL располагается непосредственно внутри системной папки %SystemRoot%. Однако в процессе повышения роли сервера до контроллера домена администратор может указать любое другое место расположения этого тома. Единственное условие — том должен располагаться на NTFS-разделе.

Специализированные роли контроллеров домена

Специализированные роли контроллеров домена


Служба каталога Active Directory использует модель репликации с множеством равноправных участников (multimaster replication). С точки зрения подсистемы репликации не имеет значения, какой из носителей осуществляет изменения в каталоге. Изменения могут быть произведены в любой из копий каталога.
Однако существует определенный класс операций, которые должны выполняться только одним контроллером домена. Этот класс операций называется операциями с одним исполнителем (Flexible Single-Master Operations, FSMO).
Если привлечь к выполнению подобных операций более одного контроллера домена, нельзя исключать возможность конфликтов. В определенных случаях подобные конфликты могут привести к нарушению целостности каталога.
Имеется два типа операций с одним исполнителем, которые принято называть ролями контроллеров домена. От первого типа ролей требуется уникальность исполнителя в пределах всего леса доменов. Роль данного типа может быть возложена только на один контроллер в лесу доменов. К другому типу ролей предъявляется требование уникальности исполнителя только в пределах домена. В каждом домене может быть только один исполнитель роли. Таким образом, в рамках леса доменов исполнителей каждой из подобных ролей будет столько же, сколько и доменов, образующих лес.
Рассмотрим пять существующих специализированных ролей.

Владелец схемы (Schema Master). Контроллер домена, осуществляющий изменения в схеме каталога. Существование только одного владельца (хозяина) схемы в пределах леса доменов исключает возможность конфликтов, связанных с ее изменением. Отказ владельца схемы приводит к тому, что выполнение операции расширения схемы станет невозможным.

Владелец доменных имен (Domain Naming Master). Контроллер домена, отслеживающий изменения в структуре леса доменов. Любое изменение пространства имен доменов Active Directory (добавление, удаление, а также переименование доменов) осуществляется исполнителем данной роли. Тем самым гарантируется целостность пространства имен и уникальность его компонентов. Отказ исполнителя этой роли приводит к тому, что любое изменение пространства имен каталога станет невозможным.

Владелец идентификаторов (Relative ID Master). Контроллер домена, осуществляющий генерацию идентификаторов (глобальные идентификаторы, идентификаторы безопасности и т. п.). От идентификатора в первую очередь требуется уникальность. Самый простой способ гарантировать уникальность генерируемых идентификаторов — возложить обязанность исполнителя данной роли на один контроллер в домене. Отказ исполнителя данной роли приводит к тому, что создание объектов в домене станет невозможным.

Эмулятор основного контроллера домена (PDC Emulator). Если домен находится на функциональном уровне Windows 2000 mixed, эмулятор основного контроллера домена (PDC) используется для обеспечения репликации изменений между контроллерами домена Windows NT и Windows 2000/Server 2003. Исполнитель роли фактически эмулирует домен Windows NT. Поскольку в домене Windows NT допустимо наличие только одного основного контроллера, его эмулятор в домене Active Directory также может быть только один. На других функциональных уровнях эмулятор основного домена используется для изменения паролей учетных записей, а также играет ведущую роль в процессе синхронизации системных часов всех контроллеров домена. Эмулятор РОС по умолчанию выбирается оснасткой Group Policy Object Editor. Поэтому, если исполнитель данной роли недоступен, администратор может столкнуться с серьезными проблемами при редактировании объектов групповой политики.

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

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

SRVзаписи

SRV-записи


Служба доменных имен использует SRV-записи для определения местонахождения серверов, предоставляющих услуги определенных служб. Каждая SRV-запись, используемая для работы с Active Directory, представляет собой DNS-псевдоним службы, записанный в формате: _Service._Protocol.DnsDomainName
где:

service — название сетевой службы, которая доступна на данном сервере (например: Idap, kerberos, gc, kpasswd);

Protocol — протокол, который клиенты могут использовать для подключения к указанной службе (tcp, udp);

DnsDomainName — доменное имя домена, к которому принадлежит указанный сервер.

Например, для LDAP-сервера, принадлежащего к домену khsu.ru, DNS-имя службы будет выглядеть следующим образом: _ldap._tcp. khsu. ru
SRV-записи регистрируются в базе данных DNS-сервера непосредственно контроллерами домена. По умолчанию каждый контроллер домена регистрирует в базе данных DNS пятнадцать различных SRV-записей. Если контроллер домена выполняет также функции сервера глобального каталога, в базе данных службы DNS регистрируется двадцать SRV-записей.

Перечень ресурсных записей, которые каждый контроллер домена Windows Server 2003 регистрирует на сервере DNS в процессе своей загрузки, хранится в файле %SysfemRoot%\system32\config\netlogon.dns.
Если на контроллере домена размещены реплики разделов приложений, в базе данных службы DNS дополнительно регистрируются три ресурсных записи — одна А-типа и две SRV-типа для каждой реплики. Это записи _ldap._tcp.<имя_раздела> И _ldap._tcp.<имя__сайта>._sites.<имя_разделах. В текущей версии Active Directory эти записи не используются службой каталога. Однако они позволяют приложениям обращаться к службе доменных имен для поиска сервера, содержащего интересующий раздел приложения.

Служба DNS, реализованная в Windows Server 2003, поддерживает динамическую регистрацию ресурсных записей. Это означает, что контроллеры домена Windows Server 2003 способны автоматически регистрировать в базе данных DNS-сервера все необходимые SRV-записи. Однако, если вы используете реализацию DNS-сервера, которая не поддерживает режим динамической регистрации ресурсных записей, все указанные SRV-записи должны быть зарегистрированы вручную.

Доверительные отношения

Таблица 18.1. Доверительные отношения, поддерживаемые доменами на базе Windows Server 2003

Доверительные отношения	Характеристика	Описание
Доверительные отношения внутри дерева	Двусторонние, транзитивные	Устанавливаются автоматически при создании в дереве нового домена. В рамках дерева доменов отношения описываются схемой "родитель-потомок"
Доверительные отношения внутри леса	Двусторонние, транзитивные	Устанавливаются автоматически при создании в существующем лесе нового дерева доменов. Фактически доверительные отношения устанавливаются между корневым доменом леса и создаваемым доменом, который будет являться корневым для нового дерева
Доверительные отношения между лесами доменов	Двусторонние или односторонние, транзитивные	Устанавливаются администраторами лесов доменов вручную. При этом администраторы сами решают — будут отношения двусторонними или односторонними
Перекрестные (shortcut) доверительные отношения	Односторонние или двусторонние, транзитивные	Устанавливаются между доменами различных деревьев, принадлежащих к одному лесу. Необходимость доверительных отношений данного типа не всегда очевидна, поскольку между доменами, принадлежащими одному лесу, через корневые домены автоматически устанавливаются неявные доверительные отношения. Перекрестные отношения доверия позволяют повысить эффективность взаимодействия между двумя доменами, уменьшая путь доверия (trust path). Путь доверия — последовательность переходов между доверяющими друг другу доменами, требуемых для аутентификации запроса. В случае неявных доверительных отношений этот путь может включать в себя несколько переходов, которые перекрестные отношения доверия позволяют избежать
Доверительные отношения с внешними доменами	Односторонние или двусторонние, нетранзитивные	Устанавливаются между доменами, принадлежащими к разным лесам, либо между доменом Windows Server 2003 и доменом Windows NT. Этот тип доверительных отношений может использоваться для соединения лесов, когда невозможно установить отношения доверия между лесами в целом (вследствие того, что один или оба леса не находятся на функциональном уровне Windows Server 2003)
Доверительные отношения между областями Kerberos	Односторонние или двусторонние, транзитивные или нетранзитивные	Устанавливаются между Windows Server 2003-доменом и областью Kerberos v5, реализованной не на базе Windows. Данный тип доверительных отношений может использоваться для обеспечения сквозной аутентификации на Windows и UNIX-системах

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

Транспорты репликации

Таблица 18.2. Транспорты репликации

Разделы каталога	Внутри сайта	Между сайтами
		Один домен	Разные домены
Доменный раздел каталога	RPC over IP	RPC over IP	-
Разделы конфигурации и схемы	RPC over IP	RPC over IP	SMTP
	Трафик не сжимается	Трафик сжимается

Протокол RFC over IP обеспечивает низкоскоростную двуточечную синхронную репликацию всех разделов каталога. Этот транспорт лучше всего подходит для ситуаций, когда узлы соединены надежными линиями связи с низкой вероятностью потери пакетов. Протокол SMTP используется для низкоскоростной асинхронной репликации между сайтами и поддерживает репликацию только для разделов конфигурации и схемы, а также для глобального каталога.
Репликация изменений каталога между контроллерами домена, принадлежащими к одному узлу, всегда осуществляется посредством протокола RPC over IP.
Если контроллеры домена располагаются в различных сайтах, но принадлежат к одному домену, то репликация между ними осуществляется также при помощи протокола RPC over IP. Если контроллеры домена расположены в различных сайтах и принадлежат к разным доменам, то для репликации изменений между ними используется протокол SMTP, функционирующий поверх IP.

Топология репликации

Топология репликации


Процесс репликации предполагает обмен изменениями в разделах каталога между отдельными участниками. Для обозначения односторонней передачи данных от одного партнера по репликации к другому используется термин соединение (connection). Соединение представляет собой однонаправленное соглашение о репликации, заключенное между двумя контроллерами домена.
Одним из наиболее ответственных моментов в процессе функционирования подсистемы репликации службы каталога является формирование инфраструктуры соединений между имеющимися контроллерами домена. Подобная инфраструктура называется топологией репликации (replication topology). Каждый раздел каталога строит свою собственную топологию репликации.
За формирование топологии репликации отвечает специальный системный процесс Knowledge Consistency Checker, КСС. Этот процесс выполняется на всех контроллерах домена, автоматически генерируя топологию репликации. При этом КСС основывается на информации о физической структуре каталога. Периодически активизируясь, КСС проверяет доступность существующих соединений. Основываясь на полученных данных, КСС может переформировать топологию репликации для некоторого раздела каталога. Именно КСС отвечает за установление соединения с партнером по репликации. Соединения генерируются автоматически, хотя служба каталога допускает определение соединений непосредственно администратором.

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

Транспорт репликации

Транспорт репликации


Понятие транспорта репликации характеризует механизмы и протоколы, используемые для передачи изменений. Active Directory может использовать в качестве транспорта RFC over IP ("RPC поверх IP") или протокол SMTP. В табл. 18.2 перечислены правила использования различных транспортных протоколов для репликации разных разделов.

Унифицированный указатель ресурсов LDAP

Унифицированный указатель ресурсов LDAP


Протокол LDAP является одним из стандартных методов доступа к каталогу Active Directory. Любое LDAP-совместимое приложение может обратиться к объектам каталога посредством запроса, записанного в формате унифицированного указателя ресурсов LDAP (LDAP Uniform Resource Locator, LDAP URL). Унифицированный указатель ресурсов LDAP начинается с ключевого слова LDAP, затем следует имя сервера, содержащего копию каталога, и отличительное имя ресурса. Ниже приводится пример записи унифицированного указателя ресурсов: LDAP: //root. khsu. ru/cn=tasha, cn=user, cu=r.d, clc=khsu, dc=ru

Internet Information Services 6.0

Функциональные уровни

Функциональные уровни


В службе каталога Windows 2000 существует понятие режима функционирования домена (domain mode). Домен может находиться в одном из двух режимов — основном (native) или смешанном (mixed). Режим функционирования домена определяет возможность использования контроллеров домена Windows NT. В Windows Server 2003 появилось понятие функционального уровня (functional level). Функциональный уровень определяет доступные функциональные возможности.
Введение понятия функционального уровня позволяет обеспечить возможность сосуществования в сети контроллеров домена, находящихся под управлением различных версий операционных систем. Как следствие, администратор может реализовать постепенный, поэтапный перевод корпоративной сети на новую версию операционной системы. Необходимость введения понятия функционального уровня обусловлена ограничением на использование некоторых функциональных возможностей в ситуации, когда в домене (или лесе доменов) присутствуют контроллеры домена Windows NT/2000.
Функциональный уровень определяется как для отдельных доменов, так и для всего леса доменов в целом.

Функциональный уровень доменов

Функциональный уровень доменов


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

Функциональный уровень леса доменов

Функциональный уровень леса доменов


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

Windows 2000. Данный функциональный уровень предполагает наличие в сети контроллеров домена различных версий — Windows NT/2000 и Windows Server 2003. В этом случае некоторая часть новых возможностей Active Directory недоступна. Используется функциональность леса, поддерживаемая системами Windows 2000.

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

Изменение функционального уровня домена и леса доменов

Изменение функционального уровня домена и леса доменов


Функциональный уровень, на котором находится домен или лес доменов, определяет перечень возможностей, доступных в рамках домена или леса доменов. Чем выше функциональный уровень, тем шире диапазон возможностей. Необходимо, однако, понимать, что механизм функциональных уровней был введен компанией Microsoft с целью сохранения совместимости с предыдущими версиями серверных операционных систем (Windows NT/ 2000), которые широко распространены в корпоративных сетях. Организация перехода на Windows Server 2003 требует от компаний значительных финансовых и временных затрат, поэтому для многих из них предпочтительным вариантом является постепенный переход на новую платформу. Этот подход характеризуется одновременным сосуществованием в сети нескольких поколений операционных систем.
Поэтому перевод домена на новый функциональный уровень возможен только в ситуации, когда администратор отказывается от использования одного из поколений операционных систем в качестве контроллеров домена. Отказ от контроллеров домена под управлением Windows NT позволяет перевести домен на функциональный уровень Windows 2000 native. Соответственно, отказ от использования контроллеров домена Windows 2000 позволяет перевести домен на функциональный уровень Windows Server 2003. Только после того как все домены переведены на функциональный уровень Windows Server 2003, администратор может перевести лес доменов на функциональный уровень Windows Server 2003. На этом этапе становится доступен весь спектр возможностей Windows Server 2003.
Для изменения функционального уровня могут использоваться две оснастки: Active Directory Users and Computers и Active Directory Domain and Trusts. Для изменения функционального уровня домена в контекстном меню объекта, ассоциированного с нужным доменом, выберите пункт Raise Domain Functional Level. В открывшемся окне (Рисунок 19.10) под строкой Current domain functional level отображается текущий функциональный уровень домена. Для его изменения выберите из раскрывающегося списка необходимый функциональный уровень и нажмите кнопку Raise. После изменения функционального уровня домена необходимо некоторое время, чтобы сведения об изменении реплицировались на все контроллеры в домене.

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

Изменение функционального уровня домена

Рисунок 19.10. Изменение функционального уровня домена


Изменение функционального уровня леса доменов выполняется аналогичным образом. Вызвав контекстное меню объекта, находящегося в корне пространства имен оснастки Active Directory Domain and Trusts, необходимо выбрать в нем пункт Raise Forest Functional Level. Если возможность переведения леса доменов на новый функциональный уровень отсутствует, в открывшемся окне будет выведено соответствующее предупреждение, говорящее о том, что один из доменов, входящих в лес, еще не был переведен на функциональный уровень Windows Server 2003.
Если все требования для изменения функционального уровня леса доменов соблюдены, необходимо нажать кнопку Raise. После того как сведения о произведенном изменении будут реплицированы на все контроллеры домена леса, администратор может использовать новые функциональные возможности.

Изменение имен доменов

Изменение имен доменов


В службе каталога Active Directory, реализованной в составе Windows 2000. лес доменов представлял собой статичную структуру. Администратор мог либо добавить новые домены или даже целые деревья, либо удалить их. Он не мог изменить пространство имен каталога, переименовав один или несколько доменов.
В службе каталога Windows Server 2003 реализована возможность изменения имени домена Active Directory.

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

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

Любой домен может быть перемещен, за исключением корневого домена леса. Функции корневого домена леса не могут быть возложены на другой домен. Тем не менее, администратор может изменить имя корневого домена леса.
В зависимости от задач, стоящих перед администратором, процесс переименования может занять множество шагов и является далеко не тривиальным; поэтому предварительное планирование леса по-прежнему остается важным этапом при развертывании Active Directory. Непосредственно переименование выполняется утилитой командной строки Rendom.exe, которая располагается в папке VALUEADD\MSFT\MGMT\DOMREN дистрибутивного диска. Эта утилита используется исключительно для изменения имени домена. Она не может использоваться для добавления нового домена или удаления существующего.

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

Изменение имени контроллера домена

Изменение имени контроллера домена


Архитектура Windows Server 2003 допускает возможность изменения имени контроллеров домена (в Windows 2000 такая возможность отсутствует). Сам процесс изменения имени не сопряжен с какими-либо сложностями, однако от администратора требуется четкое выполнение определенной последовательности действий. Целью этих действий является последующее изменение всех записей об имени контроллера домена в базе данных службы DNS и в копиях каталога других контроллеров домена (фактически являющихся партнерами по репликации).

Изменение имени контроллера домена возможно только в домене, находящемся на функциональном уровне Windows Server 2003.
Процесс переименования контроллера домена не предполагает его перемещение между различными доменами. Чтобы выполнить перемещение контроллера между доменами, необходимо выполнить его понижение (demotion) до обычного сервера, а затем заново установить его в уже новом домене.
Перед изменением имени контроллера домена необходимо проинформировать других носителей каталога о его новом имени. Для этого в режиме командной строки необходимо выполнить операцию: netdom computername <текущее_имя> /add:<новое_имя>
В результате новое имя контроллера домена будет зарегистрировано в базе данных службы DNS в качестве альтернативного имени. Необходимо подождать пока информация о новом имени не будет реплицирована на все носители зоны. После этого альтернативное имя надо сделать основным. Для этого используется команда: netdom computer-name <текущее_имя> /MakePrimary: <новое_имя>
Данная команда обновляет сведения об имени контроллера домена в каталоге Active Directory. На этом этапе необходимо перезагрузить контроллер домена. После того как изменения будут реплицированы на все носители каталога, следует выполнить команду, удаляющую старое имя из базы данных DNS и каталога Active Directory: netdom computername <новое_имя> /Remove:<текущее_имя>
После этого можно изменять собственно имя компьютера. Для этого откройте окно свойств объекта My Computer (Мой компьютер) и перейдите на вкладку Computer Name (Имя компьютера). Щелкните по кнопке Change (Изменить) и в открывшемся окне замените существующее имя компьютера новым.

Изолированное корпоративное пространство имен

Изолированное корпоративное пространство имен


Данный сценарий является наиболее простым. Корпоративное пространство имен DNS полностью изолировано от других пространств имен, являющихся внешними по отношению к компании. Для решения задач, стоящих перед работниками компании, не требуется доступ к внешним ресурсам. Пример подобного пространства имен приведен на Рисунок 19.1.
Для реализации подобного пространства имен необходимо, чтобы DNS-сервер, стоящий на вершине корпоративного пространства имен DNS, являлся корневым сервером. Для этого необходимо, чтобы все корпоративные DNS-серверы указывали на этот сервер как на корневой сервер пространства имен. Кроме того, корневой сервер не должен быть сконфигурирован для переадресации запросов на другой DNS-сервер. Другими словами, вкладка Forwarders окна свойств этого сервера должна быть пустой.
Для адресации хостов в корпоративной сети администратор может также избрать любую схему. Администратор не обязан принимать во внимание схемы распределения IP-адресов и подсетей, принятые в Интернете. Определяющими в данном случае являются исключительно правила формирования IP-адресов, описанные в спецификации протокола IP.

Изолированное пространство имен DNS

Рисунок 19.1. Изолированное пространство имен DNS


На следующем этапе администратор должен выбрать способ именования доменов. Формируя пространство имен DNS, не являющегося частью пространства DNS-имен Интернета, администратор может не придерживаться схемы именования доменов, принятой в этой глобальной сети. Нет нужды использовать для имен доменов первого уровня стандартные имена Интернета — ru, com, edu и т. п. Администратор может разработать свою собственную схему именования доменов. Определяющим здесь является понятность и простота.

Конфигурирование клиентов

Конфигурирование клиентов


После того как домен создан и установлены все необходимые контроллеры домена, администратор должен соответствующим образом сконфигурировать клиентские компьютеры. Этот процесс может отличаться в зависимости от версии клиентской операционной системы. Полное взаимодействие со службой каталога для решения различных задач допускает только архитектура операционных систем Windows 2000/XP и Windows Server 2003. Операционные системы Windows 9.X/NT разрабатывались в расчете на использование совсем других механизмов обнаружения контроллера домена, разрешения имен и поиска объектов в сети. Чтобы обеспечить возможность нормальной работы в сети для этих клиентов, необходимо установить специальный компонент — службу клиента Active Directory. Независимо от версии операционной системы следует определить для клиента адрес предпочитаемого DNS-сервера и DNS-суффикс (DNS-имя домена). Для того чтобы DNS-суффикс мог изменяться в процессе перемещения клиента между доменами, необходимо убедиться, что флажок Change primary DNS suffix when domain membership changes установлен.
Следует помнить, что в большинстве случаев проблемы в процессе взаимодействия клиента и контроллера домена обусловлены ошибками в конфигурировании стека протоколов TCP/IP. Наиболее важным является адрес предпочитаемого DNS-сервера. Клиент использует DNS-сервер для получения списка доступных контроллеров домена. Если клиент не может получить адреса контроллеров домена, он не сможет участвовать в процессе аутентификации. Как следствие — сетевые ресурсы окажутся недоступными для него. Учитывая ту роль, которую играет служба DNS в процессе функционирования сети, необходимо уделить особое внимание вопросу проверки настроек DNS-клиента на компьютере (адреса предпочитаемого DNS-сервера и DNS-суффикса). Кроме того, всегда в случае возникновения каких-либо проблем в процессе функционирования цепочки "клиент — контроллер домена", необходимо в первую очередь обращаться к настройке DNS-клиента.

Прежде чем компьютер под управлением Windows NT/2000/XP и Windows Server 2003 будет включен в состав домена, необходимо создать в соответствующем доменном разделе каталога объект, ассоциированный с учетной записью для данного компьютера. В противном случае процедура добавления клиента в домен окончится неудачно. Эту операцию можно выполнять заранее или непосредственно при добавлении компьютера к домену.
В случае клиентов под управлением Windows 2000/XP и Windows Server 2003 администратор может использовать различные диагностические инструменты, позволяющие выявить причины возникающих проблем.
Утилита Netdiag позволяет протестировать настройки DNS-клиента и проверить доступность контроллеров для того домена (например, khsu.ru), к которому планируется подключить клиентский компьютер: C:\>netdiag /test:DsGetDc /d:khsu.ru /v
Если предпочитаемый DNS-сервер не содержит информации о домене, к которому подключается клиент, следует проверить настройки клиента и при необходимости использовать другой DNS-сервер в качестве предпочитаемого.
Другой тест позволяет получить список доступных клиенту контроллеров для указанного домена. Этот тест полезно выполнить уже после того, как клиент добавлен в состав домена: C:\>netdiag /testtDcList /d:khsu.ru /v
Если один из контроллеров домена окажется недоступным, утилита выдаст ошибку. В этом случае возможны проблемы с аутентификацией клиента в домене, поиском в каталоге, применением групповых политик и т. д.

Конфигурирование механизма маршрутизации суффиксов

Рисунок 19.9. Конфигурирование механизма маршрутизации суффиксов

Корпоративное пространство имен

Корпоративное пространство имен, интегрированное с внешним пространством имен


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

запросы на разрешение доменных имен, принадлежащих к корпоративному пространству имен. Эти запросы разрешаются корпоративными DNS-серверами;

запросы на разрешение доменных имен, принадлежащих ко внешнему пространству имен. Эти запросы разрешаются внешними DNS-серверами, обслуживающими внешнее пространство имен.

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

Рисунок 19.2. Корпоративное пространство имен и пространство имен Интернета


Данный сценарий реализуется следующим образом. Корпоративное пространство формируется так же, как и в предыдущем случае. Однако корневой DNS-сервер конфигурируется таким образом, чтобы все запросы, адресованные к внешним доменам, переадресовывались на один из внешних DNS-серверов. Для этого используется режим выборочного перенаправления, который конфигурируется на вкладке Forwarders (Перенаправление) окна свойств корневого сервера.
Для доменов корпоративного пространства имен режим перенаправления на корневом сервере должен быть отключен (т. е. сервер не должен переадресовывать запросы на другой сервер). Для остальных доменов запросы должны переадресовываться на внешний DNS-сервер.

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


Корпоративное пространство имен, являющееся частью внешнего пространства имен


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

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

Рисунок 19.4. Мастер установки обнаружил проблемы с разрешением имени будущего домена

Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server. Выбор этого переключателя перекладывает все обязанности по конфигурированию DNS-сервера на мастера установки Active Directory. В случае установки первого контроллера домена в лесу доменов этот режим конфигурирования службы DNS является предпочтительным. Мастер сам выполнит установку службы DNS и создаст все необходимые зоны (за исключением зон обратного разрешения, которые администратор должен создать самостоятельно после окончания процедуры установки).

I will correct the problem later by configuring DNS manually (Advanced). Эта опция означает, что мастер должен продолжить свою работу, несмотря на обнаруженные ошибки. Администратор в этом случае берет на себя все обязанности по конфигурированию службы DNS после окончания процедуры установки. Фактически администратору нужно будет создать две зоны для создаваемого домена и зарегистрировать в них все необходимые ресурсные записи.

Мастер также выдаст сообщение об ошибке, если предпочтительный DNS-сервер не содержит информацию о домене, для которого предполагается установить дополнительный контроллер домена.
Если процесс тестирования структуры DNS закончился успешно, мастер выдаст соответствующую информацию (Рисунок 19.5).

На понижаемом контроллере домена

Рисунок 19.7. На понижаемом контроллере домена обнаружены последние реплики разделов приложений


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

Обновление существующего леса доменов Windows

Обновление существующего леса доменов Windows 2000


Рассмотрим ситуацию, когда администратор выполняет установку контроллера домена Windows Server 2003 в среде Windows 2000. Это может быть первым шагом к переходу с Windows 2000 на Windows Server 2003. Архитектура службы каталога Windows Server 2003 претерпела ряд принципиальных изменений, из которых, в первую очередь, следует отметить изменения, коснувшиеся схемы каталога (появление новых классов объектов, в том числе динамических).
Как следствие, наличие различий в архитектуре потребовало выполнения специальной процедуры "подготовки" службы каталога Windows 2000 к установке контроллеров домена Windows Server 2003. Фактически эта процедура сводится к выполнению расширения схемы. Для выполнения процедуры используется специальная утилита командной строки Adprep.exe. Эта утилита поставляется в составе дистрибутивного диска Windows Server 2003 и располагается в каталоге \I386.

Перед выполнением "подготовки" леса доменов Windows 2000 на всех контроллерах домена должен быть установлен пакет обновления Windows 2000 Service Pack 2 (или выше). В противном случае работа утилиты Adprep может привести к нарушению работоспособности отдельных контроллеров домена.

Подготовка службы каталога Windows 2000 должна быть выполнена на двух уровнях.

На уровне леса. Следует подготовить лес в целом к развертыванию Windows Server 2003. Для этого необходимо запустить утилиту Adprep с ключом /forestprep. Утилита должна быть запущена на контроллере домена, являющимся хозяином схемы (schema master).

На уровне отдельного домена. После того как выполнено расширение схемы (на уровне всего леса доменов), необходимо выполнить подготовку каждого домена, в котором планируется установка контроллеров домена Windows Server 2003. Для этого следует запустить утилиту Adprep с ключом /domainprep на контроллере домена, являющимся хозяином инфраструктуры домена (infrastructure master).

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

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

Подготовка к установке контроллера домена

Подготовка к установке контроллера домена


Прежде чем приступить к установке контроллера домена, администратор должен проделать несколько подготовительных операций. В первую очередь администратор должен убедиться в том, что компьютер, выбранный на роль контроллера домена (а, следовательно, носителя копии каталога), отвечает предъявляемым к нему требованиям. Прежде всего, речь идет о минимальных аппаратных и программных требованиях, соблюдение которых является одним из условий успешного выполнения операции установки.
Кроме того, перед выполнением установки контроллера домена необходимо убедиться в работоспособности службы DNS. Ранее уже неоднократно говорилось о роли этой службы в процессе функционирования Active Directory. Тестирование службы DNS на подготовительном этапе позволит предотвратить возникновение проблем в процессе установки контроллера домена.

Процедура тестирования службы DNS окончилась успешно

Рисунок 19.5. Процедура тестирования службы DNS окончилась успешно


На заключительном этапе работы мастера администратору необходимо будет определить уровень совместимости разрешений с подсистемой безопасности Windows NT. Если в среде Windows Server 2003 планируется существование серверов под управлением Windows NT (не обязательно контроллеров домена) с установленными на них серверными приложениями, необходимо выбрать уровень совместимости разрешений с платформой Windows NT (переключатель Permissions compatible with pre-Windows 2000 operating system). Этот же уровень совместимости разрешений следует избрать в ситуации, когда контроллер домена Windows Server 2003 устанавливается в среде Windows NT. На этом уровне совместимости разрешается анонимный доступ к информации в доменном разделе каталога. Если изначально администратор уверен, что в сети будут использоваться только серверы Windows 2000 и Windows Server 2003, вопросами совместимости разрешений с архитектурой Windows NT можно пренебречь.

Необходимо понимать, что уровень совместимости разрешений влияет только на серверные приложения, установленные на Windows NT-серверах. На работу обычных клиентов (в том числе находящихся под управлением операционных систем Windows 9x/ME/NT) выбранный уровень совместимости не влияет.
Если в процессе создания домена не был выбран необходимый уровень совместимости разрешений, администратор может впоследствии исправить ситуацию посредством команды net localgroup "Pre-Windows 2000 Compatible Access" everyone /add.
По окончании установки контроллера домена потребуется перезагрузить систему. В процессе загрузки будет зарегистрировано доменное имя в базе данных предпочитаемого DNS-сервера. Если установленный контроллер домена является первым в лесу, то учетная запись локального администратора, в контексте которого производилась установка, преобразуется в учетную запись Administrator (Администратор созданного домена). Эта учетная запись автоматически включается в состав следующих групп:

Administrators. Встроенная локальная группа;

Domain Admins. Группа с глобальной областью действия. Члены этой группы обладают необходимыми полномочиями для управления доменом. По умолчанию включается в состав группы Administrators;

Domain Users. Группа с глобальной областью действия. В состав этой группы включаются все создаваемые в контексте домена пользователи. По умолчанию группа включается в состав встроенной локальной группы Users;

Enterprise Admins. Группа с глобальной областью действия. Члены этой группы обладают полномочиями на управление инфраструктурой службы каталога. По умолчанию группа включается в состав группы Administrators;

Group Policy Creator Owners. Группа с глобальной областью действия. Члены этой группы могут редактировать параметры объектов групповой политики в рамках данного домена;

Schema Admins. Группа с глобальной областью действия. Члены группы обладают полномочиями, необходимыми для изменения схемы каталога.

Проектирование доменов и развертывание Active Directory

Проектирование доменов и развертывание Active Directory


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

доменная структура каталога (создание структуры доменов);

логическая структура каталога (создание подразделений);

физическая структура каталога (создание подсетей и сайтов).

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

Проверка службы DNS

Проверка службы DNS


Прежде чем запустить на сервере мастер установки Active Directory, администратор должен проверить настройки стека протоколов TCP/IP для данного компьютера, обратив, в первую очередь, внимание на параметры службы DNS-клиента. Одним из важнейших параметров в этой ситуации является адрес предпочитаемого DNS-сервера (preferred DNS server). Именно указанный в этом параметре сервер будет использоваться мастером установки для диагностики пространства имен DNS, предшествующего созданию нового домена Active Directory, и поиска существующих носителей копий каталога. Этот же DNS-сервер впоследствии будет использоваться для регистрации доменного имени сервера. Ошибки, допущенные на этом этапе, могут привести к тому, что по окончании процедуры установки контроллер домена окажется неработоспособным. Типичны следующие ошибки:

настройки сервера, выбранного на роль контроллера домена, не содержат сведений о предпочитаемом DNS-сервере;

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

Если вы осуществляете установку первого контроллера домена в лесу доменов (фактически это означает первый этап развертывания в сети службы каталога), то вы должны предоставить возможность мастеру установки Active Directory установить на сервере службу DNS и произвести ее последующее конфигурирование. При этом в настройках стека протоколов TCP/IP данного сервера параметр Preferred DNS Server (Предпочитаемый DNS-сервер) должен указывать непосредственно на сам сервер. То есть поcле установки контроллера домена все ассоциированные с ним ресурсные записи будут зарегистрированы службой DNS, функционирующей на этом же сервере. Все последующие контроллеры домена должны указывать уже на существующие DNS-серверы (например, на первый установленный DNS-сервер).
Кроме того, необходимо проверить доступность DNS-сервера с компьютера, который выбран на роль контроллера домена. Различные проблемы с сетевыми компонентами могут привести к тому, что хотя DNS-сервер функционирует и успешно используется другими хостами, вновь устанавливаемый контроллер домена не имеет с ним сетевого соединения.
Если планируется использование реализации службы DNS от стороннего производителя (не Windows 2000 или Windows Server 2003), необходимо убедиться в том, что этот DNS-сервер поддерживает требования, предъявляемые к нему службой- каталога Active Directory. Сервер имен должен поддерживать ресурсные записи SRV-типа и допускать возможность динамической регистрации имен.
Указанные подготовительные работы могут быть проделаны администратором при помощи специальной утилиты командной строки DCdiag.exe, поставляемой в составе вспомогательного комплекта утилит Windows Server 2003 Support Tools. Эта утилита является основным диагностическим инструментом администратора в ситуации, когда работа мастера установки Active Directory прерывается по причине возникновения каких-либо проблем со службой DNS.
Следующий тест позволяет проверить конфигурацию службы DNS с точки зрения возможности повышения некоторого сервера до роли контроллера домена в уже существующем домене khsu.ru: с:\dcdiag.exe /test:dcpromo /dnsdomain:khsu.ru /replicadc
В случае ошибки проверьте настройку DNS-сервера или укажите в настройках стека протокола TCP/IP другой DNS-сервер.
Другой тест позволяет проверить способность будущего контроллера домена выполнить динамическую регистрацию доменного имени в базе данных DNS-сервера. Хотелось бы отметить, что так же как и в предыдущем случае, тест запускается на сервере, который планируется повысить до роли контроллера домена.
c:\dcdiag.exe /test:RegisterlnDNS /dnsdomain:khsu.ru
Мастер установки Active Directory (утилита Dcpromo) в Windows Server 2003 имеет новые встроенные средства диагностики конфигурации DNS, что позволяет застраховаться от ошибок разрешения имен при создании контроллера домена.

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

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


Довольно часто возникает необходимость убедиться в том, процесс перехода сервера в новое качество успешно завершен. Если, например, служба репликации файлов (FRS) не может успешно стартовать, она не инициализирует системный том, в результате чего служба Netlogon не может сделать общей (shared) системную папку SYSVOL. Как следствие папка NETLOGON также становится недоступной для общего доступа. Это приводит к возникновению проблем с выполнением групповых политик, а также многих других проблем, в частности, с репликацией и аутентификацией. При возникновении неисправностей в Active Directory, перед тем, как выявлять проблемы, касающиеся соединений между контроллерами домена, аутентификации и т. д., вы в обоих случаях должны убедиться в том, что серверы Windows Server 2003 действительно являются контроллерами домена.
Существует несколько способов, посредством которых администратор может убедиться в том, что некоторый сервер на базе Windows Server 2003 по окончании операции повышения роли сервера (promotion) выполняет функции контроллера домена.

Раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services должен содержать подраздел NTDS.

Введите в командной строке net accounts. Поле Computer role (Роль компьютера) должна содержать значение PRIMARY или BACKUP для контроллера домена. Для обычных серверов это поле имеет значение SERVERS.

Введите в командной строке net start. В списке запущенных сервисов должна присутствовать служба Kerberos Key Distribution Center (Центр распределения ключей Kerberos). Если эта служба не запущена на контроллере домена, механизм аутентификации может не работать.

. Введите в командной строке nbtstat -n. Имя домена, имеющее тип , должно быть зарегистрировано (в поле Status указано значение REGISTERED).

Введите в командной строке net share. На сервере должны присутствовать общие папки SYSVOL (%SystemRoot%\SYSVOL\sysvol) и NETLOGON (%SystemRoot%\SYSVOL\sysvol\\SCRIPTS).

С помощью утилиты Ldp.exe проверьте значение атрибута isSynchronized объекта RootosE. По окончании процесса повышения роли сервера система должна полностью синхронизировать все разделы каталога. Когда синхронизация закончена, атрибут isSynchronized принимает значение TRUE.

Используйте утилиту командной строки NLtest.exe. Эта утилита поставляется в составе пакета вспомогательных утилит Windows Server 2003 Support Tools.

С помощью утилиты Ntdsutil.exe можно подключиться к только что установленному контроллеру домена и проверить его способность отвечать на запросы LDAP. Утилита позволяет также проверить, знает ли контроллер о расположении ролей FSMO в своем домене.

Сценарии формирования пространства имен

Сценарии формирования пространства имен


Рассмотрим некоторые сценарии создания корпоративного пространства имен DNS. Фактически существует три сценария:

изолированное пространство имен DNS;

пространство имен DNS, интегрированное с внешним пространством имен;

пространство имен DNS, являющееся фрагментом другого более глобального пространства имен.

Сценарии создания контроллера домена

Рисунок 19.3. Сценарии создания контроллера домена


Администратор осуществляет выбор одного из этих сценариев на первых страницах мастера. Если сценарий предполагает создание нового домена, мастер предложит ввести доменное и NetBIOS-имя будущего домена. В сценарии, предполагающем установку дополнительного контроллера, администратору будет необходимо ввести имя существующего домена.
Независимо от избранного сценария мастер предложит выбрать место расположения файлов хранилища и журналов. Вы можете разместить их в одной папке (по умолчанию предлагается %SystemRoot%\NTDS), либо разнести в разные (например, на разные физические диски). Напомним, что эти файлы могут размещаться только в NTFS-разделах. Кроме того, потребуется выбрать место расположения системного тома SYSVOL, используемого службой репликации файлов. Эта папка также может быть размещена только в NTFS-разделе.
На следующем этапе мастер, учитывая информацию о выбранном администратором доменном имени, обратится с запросом к службе DNS. Для взаимодействия со службой DNS используется информация о предпочитаемом DNS-сервере. Версия мастера установки Active Directory, реализованная в рамках Windows Server 2003, позволяет выполнить диагностику имеющейся конфигурации службы DNS в случае возникновения проблем. На Рисунок 19.4 изображено окно мастера в ситуации, когда предпочитаемый DNS-сервер не содержит зоны для создаваемого домена Active Directory. При этом администратору будет предложено несколько вариантов дальнейших действий.

I have corrected the problem. Perform the DNS diagnostic test again. Выбор этого переключателя предписывает мастеру произвести повторную диагностику службы DNS. Предполагается, что администратор вмешался и устранил возникшую проблему. Применительно к рассматриваемой ситуации, администратор может выполнить создание необходимой зоны.

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

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


Для создания доверительных отношений запустите оснастку Active Directory Domain and Trusts и откройте окно свойств объекта, ассоциированного с нужным доменом. Перейдите на вкладку Trusts (Рисунок 19.8). В поле Domains trusted by this domain отображаются домены1, которым доверяет конфигурируемый домен (исходящие доверительные отношения), а в поле Domains that trust this domain — домены, доверяющие конфигурируемому домену (входящие доверительные отношения). Для каждого значения отображается информация о типе доверительных отношений и транзитивности. Применительно к типу доверительных отношений возможны следующие значения:

Forest — доверительные отношения, установленные между лесами доменов;

Tree Root — доверительные отношения, установленные между деревьями доменов в рамках одного леса доменов;

Child — доверительные отношения, установленные в рамках дерева доменов между дочерним и родительским доменами;

External — доверительные отношения, установленные с внешним доменом любого типа;

Shortcut — перекрестные доверительные отношения, установленные между отдельными доменами леса;

Realm — доверительные отношения, установленные между областями Kerberos.

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

Функциональные уровни домена

Таблица 19.1. Функциональные уровни домена

Функциональный уровень	Допустимые контроллеры домена
Windows 2000 mixed	Windows NT, Windows 2000, Windows Server 2003
Windows 2000 native	Windows 2000, Windows Server 2003
Windows Server 2003	Только Windows Server 2003

Уровни Windows 2000 mixed и Windows 2000 native соответствуют смешанному и основному режимам функционирования домена Windows 2000. Охарактеризуем каждый из функциональных уровней.

Windows 2000 mixed. Этот функциональный уровень допускает сосуществование в домене контроллеров домена, находящихся под управлением различных операционных систем (Windows NT/2000 и Windows Server 2003). Контроллеры домена Windows NT могут существовать в системе только в качестве резервных контроллеров домена (Backup Domain Controller, BDC). Один из контроллеров домена (Windows 2000 или Windows Server 2003) выступает для резервных контроллеров домена Windows NT в качестве основного контроллера домена Windows NT (Primary Domain Controller, PDC). На данном уровне недоступен ряд возможностей Windows 2000 доменов — универсальные (universal) группы безопасности, вложенность групп и т. д. Все создаваемые домены по умолчанию находятся на этом функциональном уровне.

Windows 2000 native. Данный функциональный уровень ограничивает перечень используемых контроллеров доменов (Windows 2000 и Windows Server 2003). Это объясняется тем, что в домене больше не поддерживается механизм NTLM-репликации, используемый Windows NT. Тем не менее, клиенты могут работать под управлением любых операционных систем. На этом функциональном уровне становятся доступны все возможности Windows 2000 доменов. Однако ряд функциональных возможностей Windows Server 2003 недоступен — возможность переименования контроллеров домена, использование объектов класса InetOrgPerson, номера версий ключей Kerberos.

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

Существует одно серьезное ограничение, связанное с использованием функциональных уровней. Архитектура службы каталога допускает только повышение функционального уровня. Другими словами, если домен находится на уровне Windows Server 2003, он не может быть переведен на уровни Windows 2000 mixed или даже Windows 2000 native. Это обусловлено принципиальными изменениями, происходящими в каталоге после повышения функционального уровня.
Не требуется, чтобы все домены леса (или дерева доменов) находились на одном функциональном уровне. Тем не менее, функциональный уровень доменов определяет функциональный уровень леса.

Новые возможности

Таблица 19.2. Новые возможности доменов и леса, доступные на функциональном уровне Windows Server 2003

Функция	Описание
Переименование домена	Любой домен может быть переименован. Процесс переименования может привести к изменению положения домена в рамках иерархии домена (за исключением корневого домена леса)
Доверительные отношения между лесами доменов	Между двумя лесами доменов, находящимися на функциональном уровне Windows Server 2003, могут быть установлены транзитивные доверительные отношения (как односторонние, так и двусторонние)
Репликация связанных (linked) значений	Изменение состава группы пользователей приводит к передаче информации только о новых или удаленных членах группы
Деактивация объектов схемы	Определения классов объектов и атрибутов, содержащиеся в схеме, не могут быть удалены (поскольку это нарушило бы целостность каталога). Вместо этого администратор может выполнить деактивацию требуемого объекта (например, если он содержит ошибку). Впоследствии объект может быть снова активирован
Оптимизация процесса репликации содержимого глобального каталога	Если происходит изменение одного из атрибутов объекта, содержащегося в глобальном каталоге, реплицируется не весь объект, а только измененный атрибут
Динамические объекты и вспомогательные классы	Администратор может создавать в каталоге объекты, которые имеют , ограниченный срок жизни (существуют в каталоге в течение строго определенного периода времени)
Усовершенствованный алгоритм генерации топологии репликации	Оптимизирована работа сервиса Knowledge Consistency Checker (KCC) для лесов доменов, имеющих большое количество сайтов

Таким образом, чтобы сделать доступными весь спектр возможностей Windows Server 2003, администратор должен поднять лес доменов на функциональный уровень Windows Server 2003.
Существует еще один функциональный уровень, который используется в ситуации, когда происходит обновление сети на основе Windows NT до Windows Sewer 2003. В этом случае первый же контроллер домена Windows NT, обновленный до Windows Server 2003, переводится на функциональный уровень Windows Server 2003 interim. Этот функциональный уровень допускает существование в сети только контроллеров домена Windows NT и Windows Server 2003. Контроллеры домена под управлением Windows 2000 не допускаются.
Функциональный уровень Windows Sewer 2003 interim включает в себя все возможности, доступные на уровне Windows 2000, плюс две функции уровня Windows Server 2003:

усовершенствованный алгоритм генерации топологии репликации;

репликация связанных значений.

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

Требования и ограничения

Требования и ограничения


Процесс повышения выделенного сервера до контроллера домена требует выполнения определенных условий. Рассмотрим эти требования.

Перед установкой на сервере должен быть установлен стек протоколов TCP/IP и для каждого из интерфейсов сервера выделен статический IP-адрес. Впоследствии администратор может изменить этот адрес и заново зарегистрировать в базе данных DNS доменное имя с уже новым адресом.

Для сервера должен быть установлен DNS-суффикс, соответствующий имени домена, для которого будет устанавливаться контроллер домена. Последнее требование является необязательным, если установлен флажок Change primary DNS suffix when domain membership changes. В этом случае система автоматически определит DNS-суффикс при включении сервера в состав некоторого домена.

Служба каталога может быть установлена на раздел диска с файловой системой NTFS. Это требование обусловлено соблюдением должного уровня безопасности, требующего разграничения доступа к файлам, непосредственно на уровне файловой системы (скажем, файловая система FAT не предоставляет такой возможности). Кроме того, раздел, предназначенный для установки службы каталога, должен иметь как минимум 250 Мбайт свободного дискового пространства. С целью повышения производительности службы каталога администратор может разместить файлы хранилища каталога и журнала транзакций на отдельные физические диски. Это позволит избежать конкуренции операции ввода/вывода.

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

Операция установки контроллера домена требует наличия у выполняющего ее пользователя определенных полномочий. Установка первого контроллера домена в лесе осуществляется на одиночном сервере, не являющимся частью какого-либо домена. В этой ситуации пользователь должен обладать полномочиями локального администратора на том сервере, на котором происходит установка. Если происходит установка первого контроллера в домене (в рамках уже существующего леса доменов), пользователь должен являться членом группы Enterprise Admins (Администраторы корпорации). В случае установки дополнительного контроллера в домене пользователь должен быть либо членом уже упомянутой группы, либо членом группы Domain Admins (Администраторы домена).

Удаление доверительных отношений

Удаление доверительных отношений


Для удаления доверительных отношений необходимо выбрать в списке требуемую запись и нажать кнопку Remove (Удалить). Если отношения двусторонние, администратор может при желании удалить отношения доверия направленные как в одну сторону, так ив другую. Может быть удалено только одно из направлений двусторонних отношений доверия.

Необходимо помнить, что не могут быть удалены отношения доверия между корневыми деревьями домена, а также отношения между родительским и дочерним доменами.
Для получения информации о состоянии доверительных отношений администратор может использовать утилиту командной строки NLtest.exe. Ниже приводится результат проверки состояния доверительных отношений между текущим доменом и доменом khsu. khakasnet. ru:

С:\>nltest /sc_query:khsu.khakasnet.ru Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name\\main.khsu.khakasnet.ru Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully

Удаление контроллера домена

Удаление контроллера домена


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

Перед выполнением операции понижения контроллера домена необходимо убедиться в том, что контроллер не является сервером глобального каталога или исполнителем специализированных ролей. В последнем случае перед понижением контроллера домена администратор должен передать эти роли другим контроллерам. Необходимо, чтобы после понижения контроллера в домене оставался хотя бы один сервер глобального каталога.
Понижение контроллера, являющегося последним в домене, приводит к удалению домена. Операция удаления домена не может быть осуществлена (соответственно, будет прервана операция понижения последнего контроллера домена), если домен имеет дочерние домены. Запрещается также понижать контроллеры домена, являющиеся последними носителями реплик разделов приложений. Перед выполнением операции понижения администратор должен вручную удалить разделы приложений с помощью утилиты Ntdsutil.exe.
Для выполнения операции понижения необходимо, чтобы контроллер домена был работоспособным. Также должны быть доступны другие контроллеры домена. Это позволит выполнить изменения в каталоге, информирующие об удалении контроллера домена. Операция понижения контроллера домена выполняется мастером установки Active Directory (утилита Dcpromo).
В процессе понижения роли комьпьютера мастер установки проверит копию каталога понижаемого контроллера домена на предмет наличия реплик разделов приложений. Если будут обнаружены реплики, являющиеся последними, мастер выдаст соответствующее предупреждение (Рисунок 19.7). В этом случае мастер в следующем окне потребует подтвердить готовность администратора удалить эту реплику.

Управление доверительными отношениями между лесами доменов

Управление доверительными отношениями между лесами доменов


Если два леса доменов находятся на функциональном уровне Windows Server 2003, они могут быть соединены друг с другом посредством транзитивных доверительных отношений. Если хотя бы один из лесов доменов находится на функциональном уровне Windows 2000, леса доменов могут быть соединены только посредством внешних доверительных отношений (external trusts), которые не обладают свойством транзитивности.

Перед выполнением процедуры создания доверительных отношений между лесами доменов необходимо убедиться, что DNS-сервер способен разрешить доменные имена корневых доменов обоих лесов.
Запустите мастер создания доверительных отношений для корневого домена леса. В ответ на просьбу указать имя домена на противоположном конце доверительных отношений укажите имя корневого домена другого леса. Мастер предложит выбрать способ соединения двух лесов: либо посредством транзитивных доверительных отношений между лесами (forest trust), либо посредством нетранзитивных внешних доверительных отношений (external trust).
На двух последующих страницах мастер попросит предоставить информацию о направлении доверительных отношений (односторонние или двусторонние), а также сведения об учетной записи, в контексте которой создается отношение доверия. Далее администратор должен определить, какая часть ресурсов леса доменов будет доступна аутентифицированным пользователям из другого леса доменов. Имеются два варианта (переключателя на странице мастера):

Allow authentication for all resources in the local forest. В этом случае пользователи одного леса могут получить доступ к любым ресурсам в рамках другого леса доменов. Данный режим можно использовать в ситуации, когда оба леса доменов принадлежат одной организации;

Allow authentication only for selected resources in the local forest. Администратор вручную указывает ресурсы в рамках леса доменов, которые будут доступны пользователям из другого леса. Этот способ разграничения доступа подходит для сценариев, когда леса доменов принадлежат различным организациям, не желающим предоставлять доступ ко всем ресурсам.

Область доступности ресурсов может быть изменена администратором уже после того, как доверительные отношения созданы. Для этого необходимо открыть окно свойств доверительных отношений и перейти на вкладку Authentication.
На заключительном этапе администратор должен сконфигурировать механизм маршрутизации суффиксов (name suffix routing). По умолчанию, если не обнаружены конфликты в доменных именах, мастер предлагает активизировать механизм маршрутизации суффиксов для всех доменов, входящих в оба леса (Рисунок 19.9). Администратор может снять флажки напротив имени определенного леса, чтобы предотвратить возможность доступа пользователей в указанный домен.
Впоследствии администратор может произвести дополнительное конфигурирование механизма маршрутизации суффиксов. В окне свойств объекта, ассоциированного с доверительными отношениями между лесами доменов, имеется вкладка Name Suffix Routing, на которой перечислены все параметры. Администратор может отключить (disable) или, наоборот, включить маршрутизацию некоторого суффикса, а также исключить (exclude) некоторый домен из маршрутизации.

Управление доверительными отношениями

Управление доверительными отношениями


Как говорилось в предыдущей главе, доверительные отношения выступают в качестве связующего звена между доменами, посредством которого домены организуются в иерархию. Для управления доверительными отношениями используется оснастка Active Directory Domain and Trusts (Active Directory — домены и доверия).

Также администратор может использовать для управления доверительными отношениями утилиту командной строки Netdom.exe..

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

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


Архитектура Windows Server 2003 позволяет установить в домене дополнительный контроллер, используя резервную копию о состоянии системы (System state) уже существующего контроллера домена. Хотелось бы обратить особое внимание на то, что данная возможность распространяется только на установку дополнительных доменов. Создание нового домена или дерева доменов может быть выполнено только стандартным способом.
Установка контроллера домена из резервной копии позволяет избежать копирования всего содержимого каталога через сеть с уже существующих носителей. Вместо этого, наполнение вновь устанавливаемого каталога будет производиться с резервной копии. Администратор может использовать эту возможность для установки контроллера домена в удаленных филиалах, соединенных с основной корпоративной сетью посредством коммуникационных линий с низкой пропускной способностью. Преимущества указанного метода особенно ощутимы в случае большого размера копии каталога. В этом сценарии на одном из контроллеров домена корпоративный администратор создает резервную копию и передает ее администратору удаленного филиала. Администратор филиала, используя полученную резервную копию, выполняет установку дополнительного контроллера домена. После процедуры синхронизации только что установленный контроллер готов обслуживать пользователей филиала.

Однако необходимо заметить, что даже в случае установки с резервной копии полностью исключить взаимодействие через сеть с уже существующими контроллерами домена нельзя. Поэтому в процессе выполнения установки создаваемый контроллер домена должен иметь сетевое соединение с другими контроллерами в домене.
Если резервная копия была создана на контроллере домена, выполняющем функцию сервера глобального каталога, устанавливаемый из этой копии контроллер домена может быть также сконфигурирован в качестве сервера глобального каталога непосредственно в процессе установки. С другой стороны, существующие разделы приложений не будут автоматически воссозданы на устанавливаемом контроллере домена, даже если оригинальный контроллер был их носителем. Для создания этих разделов администратор должен использовать утилиту Ntdsutil.exe.
Процесс создания резервной копии, отражающей состояние системы (в том числе и файлы службы каталога), будет подробно описан в главе 23 "Восстановление системы". Здесь же заметим, что в процессе создания резервной копии, предназначенной для установки дополнительных контроллеров домена, необходимо снять флажок Automatically backup System Protected Files with the System State (Автоматически резервировать защищенные системные файлы). В этом случае в создаваемую резервную копию не будут включаться защищенные системные файлы.
На сервере Windows Server 2003, выбранном на роль контроллера домена, используя утилиту Backup, восстановите резервную копию в некоторую папку. Для этого из рскрывающегося списка Restore files to (Восстановить файлы в) выберите значение Alternate location (Альтернативное место расположения) и в одноименном поле укажите папку, в которую должна быть восстановлена резервная копия.
После того как процесс восстановления из резервной копии закончится, необходимо запустить утилиту Dcpromo с ключом /adv. Это приведет к запуску мастера установки Active Directory в расширенном режиме. После того как будет выбран режим установки дополнительного контроллера домена, мастер предложит указать способ наполнения каталога на создаваемом контроллере (Рисунок 19.6):

наполнение через сеть путем копирования с уже существующего контроллера домена. Этому способу соответствует пункт Over the network from a domain controller. В данном случае процесс установки продолжится по стандартному сценарию;

наполнение из резервной копии. Этому способу соответствует пункт From these restored backup files. При этом администратору потребуется указать папку, в которой располагается восстановленная на предыдущем этапе резервная копия.

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

Установка контроллера домена Windows Server

Установка контроллера домена Windows Server 2003


Процедура установки контроллера домена (также называемая повышением роли сервера до контроллера домена) выполняется при помощи мастера Active Directory Installation Wizard (Мастер установки Active Directory). Этот мастер запускается утилитой командной строки Dcpromo.exe.
В процессе установки контроллера домена происходит наполнение каталога. В случае установки первого контроллера домена в лесе все содержимое каталога создается непосредственно мастером установки. Если в лесе создается новый домен, то мастер установки создает исключительно доменный раздел. Раздел схемы и каталога копируется с уже существующих контроллеров домена. В ситуации, когда администратор создает дополнительный контроллер в уже существующем домене, имеется два варианта наполнения каталога:

все содержимое каталога копируется с уже существующего контроллера домена;

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

Каждый из предложенных вариантов имеет свои плюсы и минусы. Мы рассмотрим оба варианта.

Мастер установки Active Directory может быть вызван из утилиты Configure Your Server, которая располагается в меню Administrative Tools.

Установка контроллера домена Windows

Установка контроллера домена Windows NT/2000 в среде Windows Server 2003


Прежде чем приступить к установке контроллера домена, находящегося под управлением предыдущих версий Windows (Windows NT/2000), необходимо убедиться, что функциональный уровень, на котором находится интересующий домен, позволяет это сделать. Контроллер домена Windows NT может быть установлен только в случае, если домен находится на функциональном уровне Windows 2000 mixed. Установка контроллера домена Windows 2000, соответственно, возможна в домене, находящемся на функциональных уровнях Windows 2000 mixed или Windows 2000 native.
В случае установки контроллера домена Windows NT имеется одно ограничение: контроллер домена должен устанавливаться исключительно как резервный контроллер домена (Backup Domain Controller, BDC). Резервные контроллеры домена Windows NT располагают копией базы данных учетных записей, доступной исключительно для чтения. Один из контроллеров в домене, находящийся под управлением Windows Server 2003, выступает исполнителем роли эмулятора РОС. Этот контроллер домена отвечает за репликацию изменений каталога на контроллеры домена Windows NT. При этом реплицируемые данные преобразовываются в специальный формат подсистемы репликации Windows NT.
Прежде чем приступить к установке BDC Windows NT, необходимо создать для него учетную запись в каталоге Active Directory. Для создания объекта, ассоциированного с учетной записью компьютера, используется утилита Active Directory Users and Computers, расположенная в группе программ Administrative Tools. В меню Action (Действие) выберите пункт New | Computer (Создать | Компьютер). В открывшемся окне необходимо ввести информацию об имени компьютера и установить флажки Assign this computer account as a pre-Windows 2000 computer (Рассматривать этот компьютер как пред-Windows 2000 компьютер) и Assign this computer account as a backup domain controller (Рассматривать этот компьютер как резервный контроллер домена).

Если на момент выполнения установки контроллера домена Windows NT в каталоге Active Directory не будет обнаружена соответствующая учетная запись, процедура установки будет на определенном этапе прервана и администратор получит сообщение: "The Machine Account for This Computer either does not exist or is inaccessible". Чтобы продолжить установку, администратору потребуется создать учетную запись в каталоге.

Установка контроллеров домена

Установка контроллеров домена


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

Вкладка Trusts окна свойств домена

Рисунок 19.8. Вкладка Trusts окна свойств домена


Процесс создания доверительных отношений зависит от того, какой именно тип отношений администратор хочет создать. Например, если администратор хочет создать отношения полного доверия с внешним доменом, он должен создать пару встречных односторонних доверительных отношений.
Для установки доверительных отношений необходимо щелкнуть по кнопке New Trust (Новые доверительные отношения), что приведет к запуску мастера New Trust Wizard. В ходе работы мастера администратор должен будет предоставить мастеру информацию об имени домена, с которым устанавливаются доверительные отношения. Если домен с указанным именем не обнаружен, мастер предполагает, что подразумевается имя области Kerberos.

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

Выберите способ наполнения каталога

Рисунок 19.6. Выберите способ наполнения каталога для устанавливаемого контроллера домена

Выполнение установки

Выполнение установки


В ходе использования мастера установки Active Directory возможны четыре сценария (Рисунок 19.3):

создание нового леса доменов;

создание нового дерева доменов в рамках существующего леса доменов;

создание нового домена в рамках существующего дерева доменов;

установка дополнительного контроллера домена в уже существующем домене.

Internet Information Services 6.0

Active Directory Replication Monitor (ReplMon exe)

Active Directory Replication Monitor (ReplMon.exe)


Имеющая графический интерфейс утилита Active Directory Replication Monitor (ReplMon.exe) может быть использована для выполнения следующих операций, связанных с репликацией:

синхронизация всех разделов каталога некоторого контроллера домена со всеми партнерами по репликации (для этой операции имеются три дополнительных режима);

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

синхронизация указанного раздела каталога некоторого контроллера домена с определенным партнером по репликации.

Одним из достоинств утилиты Active Directory Replication Monitor является возможность подробного протоколирования операции репликации.

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

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


Время, которое администратор тратит на выполнение операций управления системой, во многом зависит от используемого инструментария. В составе Windows Server 2003 поставляется множество системных утилит и оснасток самого разного назначения. Более того, одна и та же операция может быть выполнена различными инструментами. Поэтому администратору необходимо знать имеющиеся возможности и умело их использовать.
В данной главе будут рассмотрены некоторые из наиболее важных инструментов администрирования доменов на базе Active Directory. Это те инструменты, которые используют в своей повседневной работе администраторы службы каталога. Кроме того, описываются способы выполнения типовых операций по управлению Active Directory.
Начнем с краткого обзора имеющихся средств администрирования.

Активизация режима кэширования

Рисунок 20.5. Активизация режима кэширования информации о составе универсальных групп


Чтобы активизировать процесс кэширования информации о составе универсальных групп, нужно открыть окно свойств объекта NTDS Site Settings (Настройки NTDS сайта), расположенного непосредственно внутри контейнера, ассоциированного с требуемым сайтом. В открывшемся окне (Рисунок 20.5) на вкладке Site Settings (Настройки сайта) необходимо установить флажок Enable Universal Group Membership Caching (Включить кэширование информации о составе универсальных групп). При этом в раскрывающемся списке Refresh cache from (Обновлять кэш из) следует выбрать сайт, к которому будут осуществляться обращения для обновления содержимого кэша.

Аудит событий доступа к объектам Active Directory

Аудит событий доступа к объектам Active Directory


Оценка эффективности существующей политики безопасности системы должна базироваться на некотором аналитическом материале. В состав операционной системы Windows Server 2003 включены действенные механизмы протоколирования событий, связанных с попытками (как удачными, так и неудачными) получения доступа к ресурсам сети. Согласно терминологии Microsoft, процесс протоколирования действий пользователей получил название аудита (audit). Сведения обо всех событиях, связанных с попыткой получения доступа к ресурсам, для которых активизирован режим аудита, фиксируются системой в специальном журнале безопасности (Security log).
Для объектов каталога реализация аудита осуществляется в два этапа:
1. Активизация режима аудита. При этом администратор должен указать категории событий, которые подлежат аудиту.
2. Определение объектов каталога, для которых будет осуществляться аудит событий.
Подсистема безопасности Windows Server 2003 оперирует девятью категориями событий, подлежащих аудиту. Применительно к аудиту событий, связанных с функционированием службы каталога, интерес представляют три категории событий:

Audit object access (Аудит событий, связанных с доступом к объектам);

Audit directory service access (Аудит событий, связанных с доступом к службе каталога);

Audit account management (Аудит событий, связанных с управлением учетными записями).

Аудит доступа к службе каталога выполняется по отношению к операциям, выполняемым на контроллерах домена. Для активизации аудита можно использовать оснастку Domain Controllers Security Policy. Эта оснастка работает с объектом групповой политики Default Domain Controllers Policy, привязанного к подразделению Domain Controller. Откройте узел Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy (Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Локальные политики | Политика аудита) содержащий категории аудита.
По умолчанию для политик аудита задано одно значение — No auditing (Нет аудита). В окне оснастки выберите категорию событий, откройте его окно свойств, установите флажок Define these policy settings (Определить следующие параметры политики) и определите, какие именно попытки — успешные (Success) или неуспешные (Failure) — должны регистрироваться в системном журнале безопасности. Если флажок Define these policy settings (Определить следующие параметры политики) снят, считается, что для данной категории событий аудит не определен (Not Defined).
Следует заметить, что установки No auditing (Нет аудита) и Not defined (He определено) имеют разное значение. Если политика не определена, вы можете установить ее на другом уровне. Значение No auditing переопределяет все установки, которые могли быть заданы ранее. Групповые политики для контейнера Domain Controllers применяются последними и, следовательно, имеют самый высокий приоритет. Поэтому установки аудита, определяемые этими политиками по умолчанию, переопределяют любые параметры, заданные на предыдущих уровнях.
На следующем этапе администратор определяет объекты каталога, для которых будет осуществляться аудит событий. Для каждого объекта каталога аудит событий может производиться на двух уровнях:

на первом уровне отслеживаются все события, связанные с доступом непосредственно к самому объекту (создание, удаление, чтение объекта и т. п.);

на втором уровне система регистрирует в системном журнале все события, связанные с доступом к индивидуальным атрибутам объекта (чтение или изменение атрибута объекта).

Режим аудита позволяет отслеживать действия над объектами каталога и их атрибутами на любом уровне иерархии. При этом допускается наследование дочерними объектами параметров аудита от родительских объектов.
Для операций чтения рекомендуется задавать аудит неудачных обращений (отказов), поскольку при регистрации большого количества успешных обращений журнал безопасности (Security Log) будет быстро переполняться. Как следствие, снижается производительность контроллеров домена. Для операций записи, создания/удаления и других критичных операций (которые выполняются гораздо реже, чем чтение) можно устанавливать аудит всех событий, т. е. как успешных, так и неудачных обращений.
По умолчанию для группы Everyone (Все) выполняется аудит специальных обращений (успешных и неудачных) ко всем объектам в домене. Все объекты домена наследуют эти установки от корневого доменного контейнера. У некоторых контейнеров имеются дополнительные параметры аудита. Эти установки разрешают аудит критических операций, таких как запись, удаление, изменение и т. д. Все установки аудита можно просматривать в окне свойств объекта: откройте вкладку Security (Безопасность), нажмите кнопку Advanced (Дополнительно) и перейдите на вкладку Auditing (Аудит).
Нажмите кнопку Edit (Редактирование), и в открывшемся окне вы можете просматривать и изменять параметры. Если вы откроете вкладку Auditing для некоторого дочернего объекта каталога, то заметите, что все установленные флажки затенены. Их нельзя изменить непосредственно, для этого нужно открыть родительский или корневой объект. Если установить еще не отмеченный флажок, система создаст новый набор параметров аудита и добавит его в список.
Поскольку по умолчанию многие успешные обращения регистрируются, после включения аудита может возникнуть громадное количество записей в системных журналах. Поэтому при выполнении аудита в течение достаточно длительного времени следует изменить параметры, заданные по умолчанию.
Содержимое журнала безопасности может быть просмотрено при помощи оснастки Event Viewer. Для каждого события утилита отображает следующую информация:

успешность попытки (была ли попытка доступа успешной или нет);

дата и время попытки;

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

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

Авторитетное восстановление

Авторитетное восстановление


Процедура авторитетного восстановления каталога предполагает откат на всех контроллерах домена изменений, касающихся определенных объектов или даже фрагментов каталога. Авторитетное восстановление может быть выполнено для объектов, расположенных в доменном разделе каталога, а также в разделе каталога, содержащем данные конфигурации. Поскольку операция расширения схемы каталога является необратимой, авторитетное восстановление схемы невозможно.
Суть авторизованного восстановления заключается в установке для некоторого подмножества объектов каталога значения Originating USN в метаданных репликации равным текущему значению USN контроллера домена. Как следствие, информация об этих объектах будет реплицирована на остальные контроллеры домена.
Авторитетное восстановление всегда производится после неавторизованного восстановления каталога. Для выполнения этой операции используется утилита командной строки NtdsUtil.exe. Рассмотрим процедуру выполнения авторизованного восстановления более подробно.
На предварительном этапе контроллер домена должен быть загружен в режиме восстановления службы каталога. Используя имеющуюся резервную копию, администратор должен произвести неавторитетное восстановление службы кататога. При этом на вкладке Restore утилиты Backup из раскрывающегося списка Restore flies to (Восстанавливать файлы в) надо выбрать значение Alternate location (Альтернативное расположение). Необходимо будет указать папку на локальном диске, в которую будет произведено восстановление содержимого резервной копии. В выбранном месте после восстановления появятся следующие папки:

Active Directory. Файлы, используемые механизмом ESE для организации хранилища каталога (файлы ntds.dit, edb.log и т. п.);

СОМ+ Class Registration Database. Файлы, определяющие содержимое базы данных регистрации классов СОМ+ (файл ComReg.Db.bak);

Boot Files. Эта папка содержит загрузочные файлы (файлы ntdetect.com, ntldr);

Registry. В этой папке находятся файлы, содержимое которых определяет значение основных ключей системного реестра (файлы default, SAM, SECURITY, software, system, userdiff);

Sys Vol. Эта папка определяет содержимое системного тома SYSVOL.

По окончании процедуры неавторизованного восстановления система предложит выполнить перезагрузку. Для выполнения авторизованного восстановления необходимо отказаться от перезагрузки, поскольку при этом произойдет обновление всех системных файлов. Запустите редактор реестра и убедитесь в существовании параметра RestoreinProgress в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS.
Вместо перезагрузки необходимо перейти в режим командной строки и запустить утилиту NtdsUtil. Ниже приведен пример диалога для операции authoritative restore (команды администратора выделены полужирным):

C:\>ntdsutil ntdsutil: authoritative restore authoritative restore: restore subtree OU=ND,DC=khsu,DC=ru Opening DIT database... Done. The current time is 09-20-02 21:45.14. Most recent database update occurred at 09-19-02 11:03.01. Increasing attribute version numbers by 300000. Counting records that need updating... Records found: 0000000004 Done. Found 4 records to update. Updating records... Records remaining: 0000000000 Done. Successfully updated 4 records.
Authoritative Restore completed successfully,
authoritative restore: quit
ntdsutil: quit
После этого необходимо выполнить перезагрузку компьютера. Обратите внимание на то, что номера версий объектов увеличиваются на 100 000 для каждого дня, прошедшего с момента создания резервной копии. Для просмотра изменений метаданных можно применять утилиту RepAdmin.exe. Например, для восстановленного подразделения можно воспользоваться следующей командой: c:\repadmin /showmeta OU=ND, DC=khsu, DC=ru store.khsu.ru
Выполняя эту команду на различных контроллерах домена, можно проверить успешность выполнения авторизованного восстановления и проследить за распространением изменений в процессе репликации.
Если в вашей конфигурации объекты Active Directory меняются редко, можно изменить стандартное значение, на которое увеличивается номер версии. При этом в процессе работы утилиты NtdsUtil используется команда, подобная следующей: restore subtree OU=ND, DC=khsu, DC=ru verinc 1000
При выполнении авторизованного восстановления администратор должен учитывать срок действия паролей, соответствующих учетным записям (пользователей и компьютеров) и используемых для установления доверительных отношений между доменами. Служба каталога рассматривает смену пароля как изменение состояния объекта. Политика учетных записей задает срок жизни пароля и накладывает определенные ограничения на выполнение авторизованного восстановления объектов, ассоциированных с учетными записями. Возможна ситуация, когда откат изменений восстановит старые значения паролей учетных записей, что приведет к нарушению нормальной работы сети. По умолчанию пароли, ассоциированные с учетными записями компьютеров, а также используемые для установления доверительных отношений между доменами, меняются каждые семь дней. Кроме того, в каталоге хранятся также и предыдущие значения паролей. Таким образом, если применяются установки по умолчанию, не следует использовать для авторизованного восстановления объектов каталога, ассоциированных с учетными записями, резервные копии старше 14 дней.

Делегирование административных полномочий

Делегирование административных полномочий


После создания домена все полномочия на управление им сосредоточены в руках специальной категории пользователей — администраторов домена. Администраторы домена обладают абсолютными правами на выполнение любых операций. Следует заметить, что использование механизма организационных единиц и сайтов позволяет реализовывать домены огромного размера с разветвленной инфраструктурой. Управление подобным доменом характеризуется большой нагрузкой на администраторов. Однако реализация подобной инфраструктуры, отражающей логическую и физическую структуру организации, дает возможность делегировать выполнение определенной части задач на квалифицированных пользователей на "местах".
Механизм делегирования некоторой части административных полномочий выгодно отличается от подхода, когда проблема увеличения нагрузки на администраторов решается за счет увеличения их количества. Увеличение количества пользователей, обладающих неограниченными правами на управление доменом, нежелательно. Подобные права должны предоставляться исключительно квалифицированным специалистам, а привлечение большого числа квалифицированных специалистов сопряжено с высокими финансовыми затратами. Механизм делегирования предполагает передачу пользователям полномочий, необходимых для выполнения отдельных операций. Это рутинные операции, выполнение которых не требует от исполнителя обширных знаний. Делегирование этих операций пользователям в подразделениях и сайтах позволяет высвободить администратора для выполнения других более сложных задач.
С точки зрения архитектуры Active Directory, делегирование полномочий на выполнение некоторых операций подразумевает под собой предоставление пользователю необходимых разрешений на доступ к объектам каталога. Это разрешения на создание дочерних объектов, их удаление, изменение атрибутов и т. п. Подобные полномочия нужны для выполнения определенных операций.
В качестве примера можно привести ситуацию с созданием учетных записей для новых сотрудников, а также изменение паролей для существующих. Эти операции могут быть делегированы пользователям в организационных единицах (назовем их администраторами организационных единиц). Помимо разгрузки администратора домена, делегирование позволяет также сократить срок принятия элементарных решений. В приведенном примере для создания учетной записи не надо обращаться к администратору домена (который, в случае множества сайтов, может даже находиться в другом городе).
Операция делегирования административных полномочий осуществляется при помощи мастера Delegation of Control Wizard (Мастер делегирования полномочий). Этот мастер может быть вызван из оснасток Active Directory Users and Computers и Active Directory Sites and Services. Посредством этого мастера администратор может осуществлять делегирование полномочий на уровне отдельных контейнеров каталога.
Полный перечень контейнеров, на уровне которых может быть осуществлено делегирование, приведен в табл. 20.3. Существует два режима делегирования. В первом случае мастер предлагает выбрать из списка операцию, которая будет делегирована пользователю. Во втором случае администратор должен выбрать из списка объекты, право создания или удаление которых будет делегировано выбранной категории пользователей. Этот режим делегирования требует четкого понимания всех совершаемых действий и рассчитан на опытных администраторов.

Для отзыва всех делегированных

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


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

Кэширование информации о составе

Кэширование информации о составе групп с универсальной областью действия


Каждый контроллер домена под управлением Windows Server 2003, не являющийся сервером глобального каталога, может хранить информацию о составе групп безопасности с универсальной областью действия (universal group) и поддерживать ее в актуальном состоянии, периодически выполняя обновление. Кэширование позволяет избежать частых обращений к серверу глобального каталога для получения информации о составе групп с универсальной областью действия. Эта информация необходима, например, в процессе аутентификации пользователей.

Режим кэширования доступен только для контроллеров домена под управлением Windows Server 2003, не являющихся серверами глобального каталога.

Настройка команды поиска на клиентском компьютере

Настройка команды поиска на клиентском компьютере


Напомним, что механизмы доступа к службе каталога реализованы только в составе операционных систем Windows 2000/XP и Windows Server 2003. Операционные системы Windows 9x/ME/NT также могут взаимодействовать со службой каталога, однако для этого необходимо установить на компьютере службу клиента Active Directory (DSClient). Служба клиента поставляется в составе дистрибутивного диска Windows Server 2003.
Ярлык для операций поиска может быть добавлен на рабочий стол или в любую папку файловой системы. Для этого необходимо вызвать контекстное меню родительского объекта и в нем выбрать команду New | Shortcut (Создать | Ярлык). В поле Type the location of the item (Укажите местоположение объекта) необходимо ввести строку: rundll32.exe dsquery,OpenQueryWindow
В следующем окне дайте ярлыку имя и нажмите кнопку Finish (Готово). При необходимости созданный ярлык можно переместить в некоторую папку или меню. Теперь этот ярлык может использоваться для вызова окна поиска объектов в каталоге. Из этого окна можно выполнять поиск пользователей, контактов, групп, принтеров, подразделений и т. д. Область поиска ресурсов может варьироваться от конкретного контейнера (подразделения) до целого домена или всего леса доменов. Выбор параметра Entire Directory (Вся папка) эквивалентен поиску в Глобальном каталоге.

Одновременное изменение атрибутов

Рисунок 20.3. Одновременное изменение атрибутов множества учетных записей пользователей


Выделение множества объектов осуществляется стандартным для интерфейса Windows способом — при помощи клавиш и . Выделив объекты, щелкните правой кнопкой мыши, чтобы вызвать контекстное меню. Для изменения атрибутов выбранных объектов в контекстном меню выберите пункт Properties (Свойства). Это приведет к открытию модифицированного окна свойств для выбранного класса объектов. Применительно к объектам, ассоциированным с учетными записями пользователей, окно свойств показано на Рисунок 20.3.
Обратите внимание на то, как происходит изменение атрибутов. Если необходимо изменить указанный атрибут для всех выбранных объектов, установите напротив него флажок и определите его значение. В ситуации, когда администратор не определяет для атрибута новое значение, существующее значение данного атрибута у выделенных объектов сбрасывается. Например, администратор может поменять порядок изменения паролей для выбранных объектов, ассоциированных с учетными записями пользователей.

Определение владельцев ролей FSMO

Определение владельцев ролей FSMO


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

Оснастка Active Directory Users and Computers отображает информацию о владельцах ролей, к которым предъявляются требования уникальности в пределах домена (владелец инфраструктуры каталога, идентификаторов и эмулятора PDC). Для получения информации о текущем владельце той или иной роли необходимо выбрать в контекстном меню объекта, ассоциированного с интересующим доменом, команду Operations Master (Владелец операций). В соответствующем окне на трех вкладках будет выведена информация о существующих владельцах. Текущий владелец роли отображается в поле Operations master.

Оснастка Active Directory Domains and Trusts может быть использована для получения информации о владельце доменных имен (Domain Naming master). Для получения информации о текущем владельце необходимо выбрать в контекстном меню объекта, расположенного в корне пространства имен оснастки, команду Operations Master (Владелец операций). Текущий владелец роли доменных имен отображается в поле Domain naming operations master.

Оснастка Active Directory Schema позволяет получить информацию о владельце схемы. Эта оснастка должна быть загружена администратором в консоль ММС вручную. Для получения информации о текущем владельце схемы необходимо выбрать в контекстном меню объекта, ассоциированного с загруженной оснасткой, команду Operations Master (Владелец операций). Текущий владелец роли отображается в открывшемся окне в поле Current schema master.

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

Оснастка Active Directory Domains and Trusts

Оснастка Active Directory Domains and Trusts


Оснастка Active Directory Domains and Trusts позволяет осуществлять управление структурой леса домена и, в первую очередь, ориентирована на администратора уровня предприятия. Эта оснастка позволяет просмотреть лес доменов и выбрать некоторый домен для администрирования, а также управлять доверительными отношениями между доменами и лесами. На Рисунок 20.6 показан пример оснастки Active Directory Domains and Trusts, в которой отображается структура леса доменов, состоящего из двух деревьев (с корневыми доменами khsu. ru и khsu. khakasnet. ru).

Рисунок 20.6. Оснастка Active Directory Domains and Trusts


Чтобы перейти к администрированию домена, необходимо в его контекстном меню выбрать команду Manage (Управление). При этом для выбранного домена будет запущена оснастка Active Directory Users and Computer.
Использование оснастки Active Directory Domains and Trusts для создания доверительных отношений рассматривалось в разд. "Управление доверительными отношениями" предыдущей главы.

Оснастка Active Directory Sites and Services

Оснастка Active Directory Sites and Services


Оснастка Active Directory Sites and Services представляет собой основной инструмент с графическим интерфейсом, посредством которого администратор может управлять физической структурой Active Directory — подсетями, сайтами и соединениями; другие же административные оснастки представляют Active Directory на логическом уровне как единое целое. Оснастка Active Directory Sites and Services является одним из основных средств администрирования Active Directory в том случае, когда корпоративная сеть реализована в виде нескольких сайтов. В случае, если механизм сайтов не используется при построении службы каталога (т. е. сайт только один — созданный по умолчанию), данная оснастка, скорее всего, останется невостребованной.
Оснастка Active Directory Sites and Services позволяет выполнять следующие операции:

изменение топологии репликации в лесе доменов (создание/удаление сайтов, подсетей и соединений);

определение стоимости для соединений (cost);

изменение расписаний и интервалов для репликации внутри сайта и между сайтами;

определение мостовых серверов (bridgehead server);

инициация процесса репликации внутри сайта и между сайтами;

запуск сервиса Knowledge Consistency Checker (KCC) для регенерации топологии репликации;

делегирование пользователям или группам прав на управление сайтами, подсетями, серверами и другими контейнерами в разделе конфигурации;

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

выбор объектов GPO, привязка объектов GPO к сайтам и запуск оснастки Group Policy Object Editor для редактирования объектов GPO;

назначение контроллерам домена роли сервера глобального каталога;

назначение политик запросов LDAP.

На Рисунок 20.4 показан пример окна оснастки Active Directory Sites and Services. В приведенном примере представлены практически все основные элементы сетевой топологии Active Directory: сайты, подсети, межсайтовые соединения, соединения между контроллерами домена в рамках сайта, а также непосредственно сами контроллеры домена.

Оснастка Active Directory Sites and Services


Стандартным инструментом управления процессом репликации изменений каталога является оснастка Active Directory Sites and Services. При помощи этой оснастки администратор может инициировать процесс репликации изменений для всех разделов каталога от отдельного партнера по репликации. Следует обратить особое внимание на то, что реплицируются все разделы каталога. Нельзя инициировать процедуру репликации только для одного раздела каталога.
Для инициации процесса репликации изменений выберите целевой контроллер в контейнере Servers (Серверы) соответствующего сайта и откройте объект NTDS Settings (Параметры NT Directory Service). Можно запросить репликацию у любого контроллера домена, соединение с которым присутствует в правом окне в виде объекта класса Connection. Для этого вызовите контекстное меню нужного соединения и выберите команду Replicate Now (Реплицировать немедленно). В зависимости от пропускной способности коммуникационных линий, соединяющих контроллеры домена, и объема имеющихся изменений может потребоваться некоторое время для выполнения процедуры репликации. В случае успешной репликации всех изменений будет выведено сообщение "Active Directory has replicated the connections" (Active Directory произвела репликацию подключений).
Несмотря на удобный графический интерфейс, оснастка Active Directory Sites and Services предлагает достаточно ограниченные возможности управления процессом репликации. Как уже упоминалось ранее, администратор не может запросить репликацию изменений для отдельного раздела каталога. Кроме того, администратор не может запросить репликацию изменений от всех источников-партнеров по репликации как одну операцию.

Оснастка Active Directory Users and Computers

Оснастка Active Directory Users and Computers


Оснастка Active Directory Users and Computers является основным инструментом, посредством которого администратор осуществляет управление содержимым доменных разделов каталога. Вот перечень лишь основных операций: создание, модификация и удаление объектов различного типа, привязка объектов групповых политик к контейнерам Active Directory, настройка прав доступа к объектам каталога, аудит. Знание возможностей этой оснастки позволяет повысить эффективность выполнения рутинных операций, особенно в случае, когда доменные разделы содержат большое количество объектов, что затрудняет их поиск и работу с ними.
В системах Windows Server 2003 оснастка Active Directory Users and Computers имеет насколько новых возможностей:

одновременная работа с несколькими объектами каталога;

операции, выполняемые с помощью мыши (например, перемещение объектов между контейнерами);

хранимые запросы (saved queries).

Для выполнения операций с каталогом оснастка Active Directory Users and Computers должна быть подключена к некоторому контроллеру домена (которые выступают в качестве носителя копии разделов каталога). Оснастка может быть подключена только к одному контроллеру домена и, соответственно, к одному доменному разделу. По умолчанию оснастка подключается к контроллеру домена, в котором зарегистрировался текущий пользователь. Администратор может подключить оснастку к любому другому контроллеру домена, а также к другому домену при условии наличия у него соответствующих прав.

Основное и неавторитетное восстановление

Основное и неавторитетное восстановление


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

жесткий диск не должен быть меньшего объема, чем вышедший из строя;

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

Процесс восстановления состояния системы (а точнее восстановления каталога) зависит от времени жизни объектов, помеченных для удаления (tombstone lifetime). По окончании процедуры неавторитетного восстановления каталога на контроллер домена будут реплицированы сведения обо всех изменениях, произошедших с момента выполнения использованной резервной копии. Это касается также и сведений об изменениях, вызванных операцией удаления объектов.
Объекты, выбранные пользователем для удаления, не удаляются из каталога сразу. Они помечаются службой каталога для удаления, и информация об этом реплицируется на все остальные контроллеры домена. Только через некоторый промежуток времени, называемый временем жизни объекта, помеченного для удаления, объект будет реально удален из каталога. По умолчанию время жизни объектов, помеченных для удаления, составляет 60 дней (минимальное значение — 2 дня). Эта величина хранится в атрибуте tombstoneLifetime объекта c именем CN=Directory Service, CN=Windows NT, CN=Service, CN=Configuration, DC=. Для восстановления каталога запрещается использовать резервные копии старше, чем значение времени жизни объектов, помеченных для удаления.
Восстановление резервной копии, так же как и операция ее создания, может быть выполнено двумя способами: посредством мастера Restore Wizard и вручную. Рассмотрим процесс ручного восстановления.
Запустите утилиту Backup и перейдите на вкладку Restore. Выберите из списка необходимую резервную копию и установите в ней флажок System State. Выберите из списка Restore files to (Восстанавливать файлы в) значение Original location (Исходное расположение). Нажмите кнопку Start Restore и выберите опцию Advanced в окне Confirm Restore (Подтверждение восстановления). Для выполнения основного восстановления необходимо установить флажки, как показано на Рисунок 20.11. Если выполняется неавторитетное восстановление, необходимо снять флажок When restoring replicated data sets, mark the restored data as the primary data for all replicas. Закройте окно и начните процесс восстановления.
По окончании процесса восстановления необходимо перезагрузить компьютер.

По окончании процедуры восстановления для системного агента каталога (DSA) контроллера домена генерируется новый глобальный идентификатор (GUID). При этом служба каталога начинает нумерацию порядковых номеров обновления (USN)сначала.
После того как резервная копия состояния системы загружена, необходимо выполнить перезагрузку системы. Однако до того как будет выполнена перезагрузка, администратор может проверить успешность выполнения операции восстановления каталога. Показателем успешности служит наличие в реестре параметра RestoreinProgress в ключе реестра HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlset\Services\NTDS. Этот параметр используется системой для обнаружения факта восстановления каталога и используется для инициации процесса обновления соответствующих системных файлов.

Основные оснастки для администрирования Active Directory

Основные оснастки для администрирования Active Directory


После того как на базе некоторого сервера под управлением Windows Server 2003 создан контроллер домена, в группе Administrative Tools (Администрирование) на панели управления появляются новые инструменты (табл. 20.1).
Перечисленные в табл. 20.1 оснастки входят в состав пакета Windows Server 2003 Administrative Tools. Они могут быть установлены на любом компьютере под управлением Windows XP или Windows Server 2003, входящем в состав леса доменов. В этом случае оснастки Security Policy (Политики безопасности) не появляются в меню Start (Пуск).

Передача и захват ролей FSMO

Передача и захват ролей FSMO


Если в рамках леса доменов имеется несколько контроллеров домена, обязанности исполнения специализированной роли могут быть перенесены с одного контроллера домена на другой. Процедура передачи роли требует, чтобы в оперативном режиме находились контроллеры домена, выступающие в качестве текущего и будущего исполнителя. В этом случае передача роли может быть осуществлена при помощи стандартных оснасток (таких, например, как Active Directory Users and Computers).
В случае, если необходимо передать роль другому контроллеру домена при недоступном текущем исполнителе, следует прибегнуть к захвату роли. Захват роли осуществляется при помощи утилиты NtdsUtil.exe.

Передача роли владельца доменных имен

Передача роли владельца доменных имен


Передача роли владельца доменных имен осуществляется при помощи оснастки Active Directory Domains and Trusts. Подключите оснастку к контроллеру домена, который выбран в качестве нового исполнителя роли. В контекстном меню корневого объекта пространства имен утилиты выберите команду Operations Masters (Владелец операций). Чтобы изменить исполнителя роли в открывшемся окне, щелкните по кнопке Change (Изменить). Помните о том, что только один контроллер в лесу доменов может исполнять роль владельца доменных имен. При этом данный контроллер домена должен также выполнять функции сервера глобального каталога.

Передача роли владельца операций RID PDC и Infrastructure

Передача роли владельца операций RID, PDC и Infrastructure


Процедура передачи ролей, требующих уникальности исполнителя в пределах домена, происходит следующим образом. Подключите оснастку Active Directory Users and Computers к контроллеру домена, который выбран в качестве нового исполнителя роли. В контекстном меню корневого объекта пространства имен утилиты выберите команду Operations Masters (Владелец операций). В открывшемся окне необходимо перейти на требуемую вкладку: RID, PDC или Infrastructure. Чтобы изменить исполнителя роли, щелкните по кнопке Change (Изменить).
Если в домене установлено несколько контроллеров домена, необходимо следить за тем, чтобы роль владельца инфраструктуры не возлагалась на контроллер домена, являющийся сервером глобального каталога. В противном случае в журнале Directory Service на контроллере домена, выбранном в качестве нового владельца роли, появится предупреждение.

Передача роли владельца схемы

Передача роли владельца схемы


Передача роли владельца схемы осуществляется при помощи оснастки Active Directory Schema. Подключите оснастку к контроллеру домена, который выбран в качестве нового исполнителя роли. В контекстном меню корневого объекта пространства имен утилиты выберите команду Operations Masters (Владелец операций). Чтобы изменить владельца роли в открывшемся окне, щелкните по кнопке Change (Изменить). Помните о том, что только один контроллер в лесу доменов может быть владельцем схемы.
Владелец схемы каталога определяет контроллер домена, который отвечает за осуществление операции расширения схемы. По умолчанию право работать со схемой имеют только члены группы Schema Admins (Администраторы схемы).

Поиск объектов в каталоге

Поиск объектов в каталоге


Служба каталога используется клиентами для обнаружения сетевых ресурсов, точное местоположение которых зачастую неизвестно. Для поиска объектов в каталоге Active Directory клиенты могут использовать перечисленные ниже инструменты (некоторые из которых доступны клиентам любого типа,. включая клиентов нижнего уровня, а некоторые могут работать только в системах Windows 2000/XP и Windows Server 2003).

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

Утилиты командной строки DsQuery.exe и DsGet.exe, входящие в состав Windows Server 2003, представляют собой стандартный инструмент, посредством которого администратор может обращаться с запросами к каталогу.

Оснастка ADSI Edit. С помощью этого инструмента, входящего в состав пакета Windows Server 2003 Support Tools, администратор может формировать запросы с целью поиска в каталоге необходимых объектов. Данная утилита позволяет также модифицировать найденные объекты независимо от того, к какому разделу каталога они принадлежат.

Сценарий Search.vbs' — самое простое средство для выполнения запросов, использующее протокол LDAP. Сценарий входит в состав пакета Windows Server 2003 Support Tools.

Утилита Active Directory Administration Tool (Ldp.exe), входящая в состав пакета Windows Server 2003 Support Tools, представляет собой сложный административный инструмент, позволяющий просматривать дерево каталога и модифицировать объекты. Утилита использует протокол LDAP для доступа к каталогу и является единственным средством, позволяющим получить доступ к удаленным объектам.

При работе с большинством из перечисленных инструментов требуется хорошее знание синтаксиса фильтров LDAP. Только в этом случае вы сможете быстро и точно выбирать нужные объекты.

окна оснастки Active Directory Sites and Services

Рисунок 20.4. Пример окна оснастки Active Directory Sites and Services

Публикация папок и принтеров

Публикация папок и принтеров


Служба Active Directory значительно упрощает работу с общими сетевыми ресурсами по сравнению с традиционными методами просмотра доменов. Информация о любом ресурсе может быть опубликована (published) в каталоге Active Directory. Публикация папки или принтера в Active Directory подразумевает под собой создание в каталоге нового объекта — Shared Folder (Общая папка) или Printer (Принтер) соответственно.
В этом случае пользователи могут использовать службу каталога для поиска ресурсов (например, с помощью команды Search | For Printers в меню Start). Место публикации ресурсов определяется существующей структурой каталога. Если в домене существуют организационные единицы, созданные для объединения ресурсов, то каждый тип ресурса будет располагаться в отдельной организационной единице. Если же организационные единицы создавались для реализации административной иерархии, ресурсы будут размещаться в контейнерах в зависимости от их принадлежности к некоторому структурному подразделению корпорации.
В процессе создания в каталоге объекта, ассоциированного с общей папкой, администратор может указать ключевые слова, которые характеризуют содержимое папки. Эти ключевые слова могут быть использованы для поиска в каталоге необходимой общей папки на основании ее характеристик. Если пользователь выполняет в каталоге поиск общих папок, он может указать некоторые ключевые слова и найти ресурсы по их содержимому, а не по их именам. Чтобы задать ключевые слова в пространстве имен утилиты Active Directory Users and Computers, выберите объект, ассоциированный с общей папкой, и вызовите окно свойств объекта. В открывшемся окне щелкните на кнопке Keywords (Ключевые слова). Надо будет добавить в список слова, логически связанные с содержимым папки.
При публикации папки необходимо быть внимательным. Система не выполняет проверки введенного имени папки. В том случае, если при публикации была допущена ошибка, пользователи не смогут подключиться к указанной папке.
Принтеры, подключенные к компьютерам, под управлением Windows 2000/ХР или Windows Server 2003, могут быть опубликованы только из окна свойств принтера. Для этого на вкладке Sharing (Доступ) необходимо установить флажок List in the Directory (Отображать в каталоге).
Процессом публикации и удаления (pruning) принтеров в домене администратор может управлять при помощи механизма групповых политик. Соответствующий объект находится в узле Computer Configuration | Administrative Templates | Printers пространства имен оснастки Group Policy Object Editor.

Работа с множеством объектов

Работа с множеством объектов


В системах Windows Server 2003 оснастка Active Directory Users and Computers предоставляет пользователю возможность манипуляции множеством объектов. Другими словами, пользователь может задействовать в некоторой операции сразу несколько объектов. Для большинства классов объектов (группы, компьютеры, подразделения и т. п.) единственной доступной групповой операцией является изменение описания. В случае объектов, ассоциированных с учетными записями пользователей, имеется порядка 30 атрибутов, которые допускается изменять сразу для множества объектов.

Replication Diagnostics Tool (RepAdmin exe)

Replication Diagnostics Tool (RepAdmin.exe)


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

запрос репликации изменений определенного раздела каталога со всех серверов-источников, выступающих в качестве партнеров по репликации;

запрос репликации изменений определенного раздела каталога с одного сервера-источника.

В первом случае необходимо использовать следующий формат утилиты: repadmin /syncall <целевой_сервер> [<раздел_каталога>] [<флаги>]
В этом случае выполняется репликация только одного раздела, однако от всех источников-партнеров по репликации. Флаги позволяют задать параметры репликации. Например, чтобы инициировать репликацию изменений доменного раздела khsu.ru на контроллер домена store со всех источников-партнеров, необходимо воспользоваться следующей командой: repadmin /syncall store.khsu.ru DC=khsv., DC=ru
Следует помнить о том, что команда repadmin /syncall позволяет выполнить репликацию только одного раздела каталога. Однако достаточно часто возникает необходимость синхронизировать все разделы каталога. Для этого используется специальный флаг /А. Ниже приводится пример синхронизации всех разделов каталога для контроллера домена store. repadmin /syncall store.khsu.ru /А
Чтобы выполнить репликацию изменений в рамках всего леса доменов, администратор может создать пакетный файл, содержащий аналогичные команды для каждого контроллера домена и для всех разделов каталога. Впоследствии при необходимости администратор может использовать созданный пакетный файл для выполнения полной репликации в домене или лесе.
Для выполнения репликации некоторого раздела каталога от одного конкретного партнера используется другой формат утилиты: repadmin /sync <раздел_каталога> <целевой_сервер> <сервер_источник> [<флаги>]
Сервер-источник задается посредством глобально уникального идентификатора (GUID). Например, для репликации изменений доменного раздела khsu.ru на контроллер домена store с контроллера домена root (имеющего GUID 337e47bb-3902-4a8f-9666-fe736ddc0b7c) необходимо воспользоваться следующей командой: repadmin /sync DC=khsu, DC=ru store.khsu.ru 337e47bb-3902-4a8f-9666-fe736ddc0b7c

Резервирование и восстановление Active Directory

Резервирование и восстановление Active Directory


Для выполнения операций резервного копирования в составе операционной системы Windows Server 2003 Server поставляется утилита Backup. С ее помощью можно резервировать и восстанавливать многие системные данные, в том числе файлы базы данных Active Directory. Использование этой утилиты подробно рассматривается в главе 23 "Восстановление системы", здесь мы коснемся лишь специфики работы с Active Directory.
Важно понимать, что резервная копия состояния системы (System State) содержит параметры, характеризующие конкретный контроллер домена. Как следствие, вы не можете использовать резервную копию состояния системы одного контроллера домена для восстановления другого контроллера домена. В этом случае вы получите два абсолютно идентичных контроллера домена, что приведет к возникновению конфликтов (начиная с идентичных настроек стека протоколов TCP/IP и заканчивая GUID DSA).

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

Режим Saved Queries (Сохраненные запросы)

Режим Saved Queries (Сохраненные запросы)


Благодаря этому режиму администратор имеет возможность сохранять предварительно созданные LDAP-запросы. Впоследствии администратор может использовать сохраненные запросы для быстрого поиска требуемых объектов. Сохраненные запросы избавляют администратора от необходимости многократного определения однотипных фильтров при формировании LDAP-запросов.
Оснастка позволяет организовать сохраненные запросы в некую иерархическую структуру в соответствии с предпочтениями администратора. Данная структура формируется внутри контейнера Saved Query оснастки. В рамках этого контейнера могут размещаться как непосредственно сохраненные запросы, так и контейнеры, используемые для их логической организации.
Чтобы создать сохраненный запрос, в контекстном меню контейнера выберите команду New | Query (Создать | Запрос). В открывшемся окне (Рисунок 20.1) необходимо дать имя создаваемому запросу и краткое описание. Параметр Query root (Корень запроса) задает область поиска. По умолчанию запрос охватывает домен целиком. При необходимости администратор может ограничить область поиска некоторым подразделением. Если требуется, чтобы поиск осуществлялся и во вложенных контейнерах, администратор должен установить флажок Include subcontainers (Включая вложенные контейнеры). Чтобы сформировать LDAP-запрос, нужно щелкнуть по кнопке Define Query (Определить запрос) и выбрать объекты и критерии поиска.
В конечном итоге, администратор может сформировать некоторую произвольную иерархию запросов (Рисунок 20.2). Для логической организации запросов можно использовать контейнеры. Чтобы создать контейнер, в контекстном меню корневого контейнера выбрать New | Container (Создать | Контейнер).
Сохраненные запросы хранятся не в виде объектов каталога, а в виде атрибутов оснастки. Таким образом, запросы сохраняются вместе с другими настройками оснастки. По умолчанию настройки административных оснасток размещаются в XML-файле в папке Documents and settings \ <имя_пользователя>\Аррliсаtion Data\Microsoft\MMC. Если администратор будет запускать оснастки с различных контроллеров домена, запросы будут сохранены только для одного из экземпляров оснастки. В этой ситуации оптимальным решением будет размещение всех административных оснасток в перемещаемом профиле пользователя. При этом одни и те же настройки оснастки будут использоваться администратором независимо от того, на каком контроллере домена он их запускает.

Создание резервной копии Active Directory

Создание резервной копии Active Directory


Подсистема резервного копирования Windows Server 2003 позволяет создавать резервные копии различных типов (нормальную, дублирующую, добавочную, разностную и ежедневную). Однако применительно к резервной копии, отражающей состояние системы, речь может идти только о нормальном резервном копировании (normal backup).
Для создания резервной копии состояния системы запустите утилиту Backup, выполнив команду Start | Programs | Accessories | System Tools | Backup.
Утилита Backup предлагает администратору два способа создания резервной копии.

Использование мастера Backup Wizard. Этот способ является наиболее удобным, поскольку упрощает процедуру резервного копирования.

Создание резервной копии вручную. Этот способ дает администратору больший контроль над операцией резервного копирования. При этом, однако, от администратора требуется четкое понимание всех механизмов резервного копирования.
Рассмотрим процесс создания резервной копии вручную. Процесс сохранения данных Active Directory сводится к резервированию состояния системы на контроллере домена. Перейдите на вкладку Backup и установите флажок System State в окне структуры. При необходимости можно также включить в создаваемую резервную копию ряд дополнительных файлов. В списке Backup Destination выберите тип носителя архива. Если выбран режим создания резервной копии на жестком диске, в поле Backup media or file name необходимо будет указать имя файла. Затем нажмите кнопку Start Backup, и процесс архивации начнется. Напомним, что полученный архив можно использовать для установки контроллера домена из резервной копии (см. главу 19 "Проектирование доменов и развертывание Active Directory").

Создание сохраненного запроса

Рисунок 20.1. Создание сохраненного запроса

и редактирования Windows Server 2003

Средства поиска и редактирования Windows Server 2003


В системах Windows Server 2003 имеется набор эффективных утилит, позволяющих выполнять многие операции с объектами Active Directory из командной строки или из командных файлов. Все эти утилиты используют протокол LDAP и могут работать с любыми доменами на базе Active Directory (Windows 2000 и Windows Server 2003). При этом запускаться они могут только на компьютерах под управлением Windows XP или Windows Server 2003.

DsAdd — позволяет создать объект заданного типа: computer, contact, group, OU, user или quota.

DsQuery и DsGet — служат для поиска объектов каталога любого типа или с указанным типом. Утилита Dsget.exe позволяет отображать атрибуты объектов указанного типа. Например, для поиска всех пользователей домена можно использовать команду dsquery user.

DsMod — позволяет изменять атрибуты объектов указанного типа: computer, contact, group, OU, server или user.

DsMove — позволяет переименовать или переместить объект любого типа.

DsRm — служит для удаления объектов каталога или целых поддеревьев каталога (например, можно удалить подразделение со всем содержимым).

Структура сохраненных запросов

Рисунок 20.2. Структура сохраненных запросов


Существующие сохраненные запросы могут быть экспортированы в XML-файлы. Эти файлы могут быть переданы другим пользователям или администраторам для последующего использования (при этом они должны импортировать запросы в свои экземпляры оснасток). Для экспорта запроса необходимо в его контекстном меню выбрать пункт Export Query Definition (Экспортировать определение запроса).

Стандартные средства

Таблица 20.1. Стандартные средства администрирования Active Directory

Оснастки	Назначение
Active Directory Domains and Trusts (Active Directory — домены и доверия)	Выбор администрируемого домена в больших лесах. Просмотр режима работы домена. Создание, проверка и удаление доверительных отношений между доменами
Active Directory Sites and Services (Active Directory — сайты и службы)	Создание и изменение сайтов, транспортов и подсетей. Настройка расписаний репликации и связей (links). Запуск репликации между контроллерами домена. Установка разрешений на объекты. Привязка объектов групповой политики (GPO) к сайтам. Запуск серверов глобального каталога на контроллерах домена
Active Directory Users and Computers (Active Directory — пользователи и компьютеры)	Создание и изменение объектов каталога (пользователей, групп, подразделений и т. д.). Установка разрешений на объекты. Привязка объектов групповой политики (GPO) к доменам и подразделениям (OU). Управление специализированными ролями (FSMO)
Domain Controller Security Policy (Политика безопасности контроллера домена)	Модификация узла Security Settings (Параметры безопасности) объекта групповой политики, привязанного к подразделению Domain Controllers. Для редактирования всего GPO используйте оснастку Group Policy Object Editor
Domain Security Policy (Политика безопасности домена)	Модификация узла Security Settings объекта групповой политики, привязанного к контейнеру домена. Для редактирования всего GPO используйте оснастку Group Policy Object Editor
Group Policy Object Editor (Редактор объекта групповой политики)	Модификация объекта групповой политики, привязанного к некоторому контейнеру Active Directory (сайту, домену, подразделению) или хранящегося локально на компьютере. Эта оснастка не отображается в меню Start (Пуск), однако она доступна из других административных оснасток или может быть добавлена к пользовательской консоли ММС

Некоторые дополнительные инструменты (табл. 20.2) для администрирования Active Directory поставляются в составе пакета Windows Server 2003 Support Tools. Эти инструменты незаменимы в некоторых случаях для тонкой настройки и мониторинга Active Directory.

Дополнительные средства

Таблица 20.2. Дополнительные средства администрирования Active Directory (из пакета Windows Server 2003 Support Tools)

Утилита	Описание
ADSI Edit (AdsiEdit.msc)	"Низкоуровневое" редактирование объектов Active Directory, расположенных в любом разделе каталога (раздел доменных имен, разделы конфигурации и схемы). Посредством утилиты можно также получить информацию об объекте RootDSE. Администратор может использовать утилиту для установки разрешений на доступ к объектам
Active Directory Administration Tool (Ldp.exe)	Утилита может использоваться для поиска и модификации объектов Active Directory при помощи запросов LDAP
Active Directory Replication Monitor (ReplNon.exe)	Утилита может использоваться для мониторинга состояния репликации и существующей топологии репликации. Утилита позволяет инициировать процесс репликации. Кроме того, утилита может быть использована для получения информации об исполнителях специализированных ролей и статусе контроллеров домена

Уровни делегирования полномочий

Таблица 20.3. Уровни делегирования полномочий

Объект каталога	Описание
Контейнер Sites	Делегированные на этом уровне полномочия распространяются на все сайты леса доменов
Контейнер Inter-Site Transport	На этом уровне могут быть делегированы полномочия для управления соединениями сайтов (создание, конфигурирование или удаление), а также транспортами репликации
Контейнер Subnets	На этом уровне администратор может делегировать полномочия для управления подсетями, образующими сайты (создание, изменение и удаление)
Конкретный сайт	Используя этот уровень делегирования, администратор может предоставить полномочия на управление сайтом (в том числе и управление процессом репликации)
Конкретный домен	На этом уровне администратор может делегировать полномочия на включение клиентов в состав домена, что означает создание объекта, ассоциированного с учетной записью компьютера, а также полномочия на управление ссылками групповой политики на уровне домена
Конкретное подразделение (OU)	На этом уровне администратор может делегировать некоторым пользователям полномочия, действие которых ограничивается выбранным подразделением. Конкретные полномочия, которые будут делегированы, определяются целями, с которыми создавалось это подразделение
Контейнер Computers	Делегируя полномочия на этом уровне, администратор предоставляет пользователям полномочия на управление объектами, ассоциированными с учетными записями компьютеров
Контейнер Domain Controllers	На этом уровне администратор предоставляет пользователям полномочия на управление учетными записями контроллеров домена
Контейнер System	Делегируя полномочия на этом уровне, администратор предоставляет полномочия на управление объектами, значение атрибутов которых определяют параметры различных служб Active Directory
Контейнер Users	На этом уровне администратор предоставляет пользователям полномочие на управление учетными записями пользователей

В табл. 20.4 перечислены задачи, выполнение которых администратор может делегировать на уровне отдельной организационной единицы, а также контейнеров Computers, Domain Controllers, ForeignSecurityPrincipals, System и Users.

Задачи которые могут

Таблица 20.4. Задачи, которые могут быть делегированы на уровне организационных единиц

Задача	Описание
Create, delete, and manage user account	Полномочия на создание, удаление и управление учетными записями пользователей
Reset user passwords and force password change at next logon	Полномочия на изменение паролей учетных записей пользователей, а также установка требования на изменение пароля самим пользователем при следующей регистрации в системе
Read all user information	Полномочия на просмотр любой информации о пользователях
Create, delete, and manage groups	Полномочия на создание, удаление и управление группами пользователей
Modify the membership of a group	Полномочия на изменение членства в группе
Manage Group Policy links	Полномочия на управление ссылками групповой политики
Generate Resultant Set of Policy (Planning)	Полномочия, необходимые для генерации результирующих политик в режиме планирования
Generate Resultant Set of Policy (Logging)	Полномочия, необходимые для генерации результирующих политик в режиме ведения журнала
Create, delete and manage inetOrgPerson accounts	Полномочия на создание, удаление и управление объектами класса inetOrgPerson
Reset inetOrgPerson passwords and force password change at next logon	Полномочия на изменение паролей, сопоставленных объектам класса inetOrgPerson, а также установка требования на изменение пароля самим субъектом подсистемы безопасности при следующей регистрации в системе
Read all inetOrgPerson information	Полномочия на просмотр любой информации об объекте класса inetOrgPerson

Процесс делегирования полномочий выполняется следующим образом. Запустите оснастку Active Directory Users and Computers. Выберите контейнер, для которого вы хотите делегировать полномочия и вызовите его контекстное меню. Выберите в меню пункт Delegate Control (Делегировать управление), чтобы запустить мастер Delegation of Control Wizard (Мастер делегирования полномочий). На странице Users or Groups необходимо определить пользователей, которым будут делегированы полномочия (Рисунок 20.7).

Управление объектами каталога

Управление объектами каталога


В распоряжении администратора имеется множество инструментов, посредством которых он может создавать или удалять объекты Active Directory, a также изменять их атрибуты. Некоторые из этих инструментов позволяют управлять отдельными объектами, другие позволяют управлять группами объектов (так называемый пакетный режим). Многие задачи могут быть выполнены любым из этих инструментов. Ниже перечислены все основные средства управления каталогом Active Directory, предоставляемые системами Windows Server 2003.

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

оснастка Active Directory Users and Computers позволяет работать с пользователями, контактами, группами, компьютерами, пользователями из внешних служб каталога, принтерами, общими папками и организационными единицами;

оснастка Active Directory Sites and Services предназначена для манипулирования сайтами, подсетями, связями и соединениями;

оснастка Active Directory Domains and Trusts позволяет осуществлять управление доверительными отношениями между доменами.

Специализированные оснастки — утилиты с графическим интерфейсом, используемые для выполнения специальных операций либо для точной настройки и отладки Active Directory:

оснастка Active Directory Schema позволяет осуществлять управление содержимым схемы, создавать новые классы атрибутов и объектов. Эта утилита не создается по умолчанию. Администратор должен создать ее самостоятельно, загрузив соответствующую оснастку в пустую консоль ММС;

оснастка ADSI Edit, утилиты Ldp.exe и AdsVw.exe. Эти утилиты позволяют редактировать отдельные атрибуты существующих объектов. Однако они могут быть использованы также для создания объектов любого типа (включая те, которые невозможно создать при помощи стандартных инструментов).

Утилиты LDIFDE и CSVDE — утилиты командной строки, предназначенные для выполнения операций импорта/экспорта объектов каталога. Эти утилиты могут быть использованы как средство повышения эффективности администрирования крупномасштабных инсталляций Active Directory. Утилиту LDIFDE можно также применять для изменения атрибутов множества однотипных объектов.

Специальные сценарии и утилиты, позволяющие выполнять специфические задачи:

утилиты DsAdd.exe и AddUsers.exe, сценарии CreateUsers.vbs, CreateGroups.vbs и другие специализированные утилиты командной строки (например, утилиту NetDom.exe можно использовать для создания учетных записей компьютеров домена);

сценарии ADSI (Active Directory Service Interfaces) — самый гибкий и довольно простой способ манипулирования объектами Active Directory. Эти сценарии используют программный интерфейс ADSI для доступа к каталогу.

Управление процессом репликации

Управление процессом репликации


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

оснастка Active Directory Sites and Services;

утилита командной строки Replication Diagnostics Tool (RepAdmin.exe);

утилита Active Directory Replication Monitor (ReplMon.exe).

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

между некоторой парой контроллеров домена;

между контроллером и всеми его партнерами по репликации.

В контексте разговора об управлении процессом репликации изменений необходимо уточнить терминологию. Изменения содержимого каталога всегда реплицируются с сервера-источника (source DC) на целевой сервер (target DC). Поэтому для инициации процесса репликации сначала необходимо выбрать целевой сервер, а затем — сервер-источник.

Управление ролями FSMO

Управление ролями FSMO


Выполнение ряда операций в доменах на базе Active Directory требует уникальности их исполнителя. Контроллеры домена, на которых возложена обязанность выполнения указанных операций, называют исполнителями специализированных ролей — Flexible Single-Master Operations (FSMO). В данном разделе разговор пойдет о процессе управления ролями FSMO, a также о методике получения информации об их владельцах (хозяевах).

Восстановление Active Directory

Восстановление Active Directory


В случае выхода из строя контроллера домена, у администратора имеется две возможности восстановления его работоспособности:

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

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

В данном разделе речь пойдет о восстановлении из резервной копии. При этом у администратора имеется три различных сценария восстановления состояния системы:

выполнить основное восстановление (primary restore), если имеется только один контроллер домена и требуется восстановить содержимое каталога. При основном восстановлении создается новая -база данных службы репликации файлов (FRS); поэтому восстановленные данные будут затем реплицироваться на другие контроллеры домена;

если в домене остался хотя бы один контроллер домена, можно выполнить неавторитетное восстановление (non-authoritative restore). При этом база данных каталога будет приведена в состояние, в котором каталог находился на момент создания резервной копии. Восстановленный контроллер получит актуальные данные об изменениях, произошедших в каталоге с момента создания данной резервной копии, в процессе репликации Active Directory с других контроллеров домена. К неавторитетному восстановлению целостности каталога прибегают в случае возникновения неисправностей, вызванных нарушениями в работе компьютера. Этот тип восстановления используется чаще всего;

если требуется восстановить данные, удаленные из Active Directory, необходимо использовать авторитетное восстановление (authoritative restore). Авторитетное восстановление службы каталога применяется для приведения каталога в некоторое состояние, непосредственно предшествующее сбою системы. Однако авторитетное восстановление может быть выполнено только после того, как будет выполнено неавторитетное восстановление каталога. Авторитетное восстановление возможно для любого раздела каталога, за исключением раздела схемы.

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

Восстановление содержимого системного тома SYSVOL

Восстановление содержимого системного тома SYSVOL


В ряде ситуаций может потребоваться восстановить содержимое системного тома SYSVOL. В качестве примера можно привести ситуацию, когда удаляется группа объектов групповой политики. Информация о групповой политике хранится как в виде объектов каталога, так и в виде файлов в составе системного тома SYSVOL. Поэтому восстановление только объектов каталога не приведет к полному восстановлению объектов групповой политики. Необходимо также восстановить содержимое системного тома SYSVOL.
По окончании процедуры авторитетного восстановления следует перезагрузить контроллер домена в нормальном режиме и дождаться момента публикации тома SYSVOL. Обнаружить момент публикации можно при помощи команды net share.
Скопируйте содержимое тома SYSVOL из альтернативной папки в его рабочую папку (по умолчанию %SystemRoot%\SYSVOL\sysvo\). Изменение состояния тома SYSVOL вызовет репликацию тома на остальные контроллеры домена.

Выбор классов объектов управление которыми делегируется

Рисунок 20.9. Выбор классов объектов, управление которыми делегируется


Процесс делегирования только предоставляет пользователям необходимые полномочия для управления объектами. Чтобы предоставить пользователям действительную возможность применить эти полномочия, администратор должен создать для них необходимые инструменты. Используя механизм создания заказных управляющих консолей (ММС), описанный в главе 6 "Средства управления системой", администратор может создавать любой необходимый инструментарий, который и будет применяться пользователями для осуществления операций управления.
Помимо задачи делегирования полномочий, существует также задача отзыва уже предоставленных полномочий. Отзыв полномочий фактически означает отзыв у пользователей определенных разрешений на доступ к контейнерам, на уровне которых осуществлялось делегирование. Для отзыва указанных разрешений необходимо в окне свойств соответствующего контейнера перейти на вкладку Security (Безопасность). Для пользователей, которым были делегированы полномочия, необходимо снять флажки Allow (Разрешено) напротив соответствующих полномочий. Таким образом, администратор редактирует элементы списка управления доступом (ACL) выбранного контейнера. Флажки устанавливаются напротив соответствующих разрешений в ходе работы мастера делегирования. Понимая этот механизм, администратор может легко и гибко управлять объектами каталога и, как следствие, точнее настраивать Active Directory под стоящие перед ним задачи.
Кроме того, администратор всегда может восстановить для контейнера установки по умолчанию. Для этого необходимо в окне Advanced Security Settings (Дополнительные параметры безопасности) щелкнуть по кнопке Default (По умолчанию) (Рисунок 20.10). Однако следует помнить о том, что в результате будут отозваны все полномочия, предоставленные кому-либо на уровне данного контейнера. Кроме того, будут восстановлены полномочия, наследуемые контейнером от родительских объектов.

Выбор пользователей которым будут делегированы полномочия

Рисунок 20.7. Выбор пользователей, которым будут делегированы полномочия


Для большинства контейнеров на следующей странице мастер предложит выбрать задачи для делегирования (Рисунок 20.8):

выбрать задачи, выполнение которых будет разрешено пользователям. Данный режим является наиболее предпочтительным для большинства случаев. Этому режиму соответствует переключатель Delegate the following common tasks (Делегировать следующие общие задачи);

выбрать вручную объекты каталога, управление которыми будет разрешено пользователям. Этот режим рассчитан на опытных администраторов и ему соответствует переключатель Create a custom task to delegate (Создать задачу для делегирования вручную).

Выбор режима делегирования

Рисунок 20.8. Выбор режима делегирования


Выбрав первый режим делегирования, администратор должен установить флажки напротив задач, которые должны быть делегированы. Если же был выбран расширенный режим делегирования, администратор должен определить классы объектов, управление которыми будет делегировано пользователям в рамках рассматриваемого контейнера (Рисунок 20.9). Если администратор хочет предоставить пользователям возможность создания или удаления экземпляров выбранных классов объектов, он должен установить флажки Create selected objects in this folder (Создание выбранных объектов в данном контейнере) или Delete selected objects in this folder (Удаление выбранных объектов в данном контейнере).

Выполнение основного восстановления

Рисунок 20.11. Выполнение основного восстановления

Захват ролей

Захват ролей


К операции захвата роли (seize role) прибегают в том случае, когда текущий исполнитель роли становится по той или иной причине недоступным, в результате чего выполнение специализированных операций станет невозможным. Операция захвата роли выполняется при помощи утилиты командной строки NtdsUtil.exe.
Ниже приводится пример использования утилиты NtdsUtil для захвата всех специализированных ролей контроллером домена store.khsu.ru (полужирным выделены команды, вводимые администратором):

C:\ntdsutil
ntdsutil: roles
fsmo maintenance: connection
server connections: connect to server store.khsu.ru
Binding to store.khsu.ru...
Connected to store.khsu.ru using credentials of locally logged on user
server connection: quit
fsmo maintenance seize schema master
fsmo maintenance seize domain naming master
fsmo maintenance seize PDC
fsmo maintenance seize RID master
fsmo maintenance seize infrastructure master
fsmo maintenance quit
ntdsutil: quit
Disconnecting from store.khsu.ru...
Применительно к ролям владельца схемы, владельца доменных имен и владельца идентификаторов запрещается возвращение в сеть прежнего исполнителя роли после выполнения ее захвата. Об этом необходимо помнить, выполняя захват указанных ролей.

Internet Information Services 6.0

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

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


Механизм административных шаблонов позволяет администратору посредством групповой политики конфигурировать системный реестр клиентских компьютеров. Для любой рабочей станции, подпадающей под действие некоторого объекта групповой политики, системный реестр будет сконфигурирован в соответствии с административным шаблоном, определенным в рамках данного объекта.
Административные шаблоны не задействуют весь реестр целиком, а только два его ключа: HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER. Создаваемый пользователем административный шаблон может охватывать любые подразделы в рамках указанных ключей. Ключ HKEY_LOCAL_MACHINE используется для определения настроек операционной системы. Значения параметров данного ключа используются для настройки системы непосредственно на этапе ее инициализации (т. е. до момента регистрации пользователя). Содержимое этого ключа реестра определяется в рамках административного шаблона групповой политики конфигурации компьютера (computer configuration).
Ключ HKEY_CURRENT_USER используется для формирования на рабочей станции индивидуальной среды пользователя. Значения параметров данного ключа используются для настройки системы на этапе регистрации пользователя. Содержимое этого ключа реестра определяется в рамках административного шаблона групповой политики конфигурации пользователя (user configuration).
Хотя, как было замечено, административный шаблон может использоваться для конфигурирования любых ключей реестра, предпочтительным является использование ключей HKEY_LOCAL_MACHINE\software\Policies (для управления Параметрами компьютера) И HKEY_CURRENT_USER\Software\Policies (для управления средой пользователей). Данные ключи реестра очищаются системой автоматически, при каждом применении или отзыве объекта групповой политики. Как следствие, в случае, когда компьютер не подпадает под действие ни одного объекта групповой политики, для настройки системы используются стандартные значения параметров, определенных в соответствующих ключах реестра.
Административный шаблон представляет собой текстовый файл в формате Unicode, в котором определяются требуемые значения параметров реестра. Данный файл имеет расширение adm и хранится в папке %SystemRoot%\inf. Файл содержит перечисление ключей и параметров реестра, которые должны быть определены администратором в процессе формирования групповой политики. Административные шаблоны, поставляемые в составе Windows Server 2003, перечислены в табл. 21.2.

Блокирование процесса наследования

Рисунок 21.14. Блокирование процесса наследования параметров объектов групповой политики

Блокировка процесса наследования

Блокировка процесса наследования параметров объектов групповой политики


Администратор может управлять процессом наследования параметров объектов групповых политик. Для этого в окне оснастки Active Directory Users and Computers необходимо открыть окно свойств контейнера, к которому привязан объект групповой политики. На вкладке Group Policy (Групповая политика) необходимо установить флажок Block Policy inheritance (Блокировать наследование политики) (Рисунок 21.14). При этом параметры групповой политики, определенные на уровне вышестоящих контейнеров, не будут распространяться на содержимое конфигурируемого контейнера.

Использование групповых политик

Использование групповых политик


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

Конфигурирование параметров перенаправления

Рисунок 21.12. Конфигурирование параметров перенаправления

Настройка основного режима перенаправления папки

Рисунок 21.9. Настройка основного режима перенаправления папки

Папки пользователей перенаправляются на некоторый сетевой ресурс, на котором для каждого пользователя создается отдельная папка. Для выбора данной схемы в списке Target folder location (Расположение папки) необходимо выбрать значение Redirect to the following location (Перенаправить в следующее место). В поле Root Path (Путь к корневой папке) необходимо указать папку, в которую будет производиться перенаправление папок.

Папки пользователей перенаправляются в локальный профиль пользователя. Данная схема перенаправления необходима для того, чтобы вернуть содержимое папок из сетевого ресурса в локальный профиль пользователя. Если просто отключить механизм перенаправления, то содержимое папок пользователя будет утеряно. Поэтому перед отключением администратор должен перенаправить папки пользователя на его локальный профиль. Только после выполнения этой операции администратор может отключить механизм перенаправления. Для выбора данной схемы в списке Target folder location (Расположение папки) необходимо выбрать значение Redirect to the local user profile location (Перенаправить в локальный профиль пользователя).

Для папки My Documents (Мои документы) возможна еще одна схема перенаправления. Указанная папка может быть перенаправлена в домашнюю папку пользователя (home directory). Подобная схема перенаправления разрешена только для клиентов, находящихся под управлением операционных систем Windows XP Professional и Windows Server 2003.
Для выбора данной схемы в списке Target folder location (Расположение папки) необходимо выбрать значение Redirect to the user's home directory (Перенаправить в домашнюю папку пользователя). При этом на момент перенаправления для пользователя должно быть определено месторасположение домашней папки. Для этого на вкладке Profile (Профиль) окна свойств объекта, ассоциированного с пользователем, необходимо в группе элементов Home folder (Домашняя папка) указать требуемую папку. Это может быть как папка на локальном диске, так и некий сетевой ресурс (Рисунок 21.10).

Настройка основного режима перенаправления папок

Настройка основного режима перенаправления папок


В данном режиме для всех пользователей используется единая схема перенаправления папок. Администратору при этом необходимо определить, какая именно из возможных схем будет использоваться для перенаправления.

Папки всех пользователей перенаправляются в одну общую папку. Для выбора данной схемы в поле Target folder location (Расположение папки) следует выбрать значение Create a folder for each user under the root path (Создать папку для каждого пользователя в корневой папке) (Рисунок 21.9).

В поле Root Path (Путь к корневой папке) необходимо указать общую папку, которая будет использоваться для размещения перенаправленных папок.

Настройка расширенного режима перенаправления папок

Настройка расширенного режима перенаправления папок

Расширенный режим позволяет выбирать способ перенаправления папок пользователя в зависимости от его членства в группах. Благодаря этому, администратор может реализовать различные уровни обеспечения надежности для хранимых папок для разных категорий пользователей (Рисунок 21.11). Наиболее важные документы, например, должны храниться на RAID-массивах. Как следствие, администратор может организовать различные политики резервного копирования для этих данных.

Рисунок 21.11. Настройка расширенного режима перенаправления папки


Конфигурирование расширенного режима перенаправления папки выполняется аналогично основному режиму. Чтобы определить возможные параметры режима, надо щелкнуть по кнопке Add (Добавить) и в открывшемся окне (Рисунок 21.12) в поле Security Group Membership указать группу, для членов которой необходимо определить перенаправление. Остальные параметры аналогичны рассмотренным в предыдущем разделе.

Назначение домашней папки пользователя

Рисунок 21.10. Назначение домашней папки пользователя

Назначение приложений

Назначение приложений


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

Назначение приложений пользователям. Этот режим используется в случае определения параметров объекта групповой политики в конфигурации пользователя (user configuration). В процессе регистрации пользователя в системе на его рабочий стол помещается ярлык, идентифицирующий данное приложение. Установка приложения происходит в момент, когда пользователь щелкает по ярлыку, пытаясь запустить приложение, либо когда в первый раз открывается документ, ассоциированный с данным приложением.

Назначение приложений компьютерам. Этот режим используется в случае настройки параметров объекта групповой политики в конфигурации компьютера (computer configuration). Приложения устанавливаются на компьютер, подпадающий под действие объекта групповой политики в процессе инициализации системы. После того как назначенные приложения установлены на компьютере, только пользователь с полномочиями локального администратора может выполнить их удаление.

Если для компьютера назначено несколько приложений, их установка может потребовать значительное время.
Для назначения приложения в контекстном меню контейнера Software Installation необходимо выбрать пункт Package. В открывшемся окне требуется указать месторасположение инсталляционного пакета. В окне Deploy Software администратор должен установить параметр Assigned (см. Рисунок 21.13).

Назначение сценария выхода из

Рисунок 21.8. Назначение сценария выхода из системы объекту групповой политики

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

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


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

Окно выбора объектов для которых

Рисунок 21.17.Окно выбора объектов, для которых определяются результирующие политики


3. Пропустим второстепенные настройки мастера, для чего установим флажок Skip to the final page и нажмем кнопку Далее (Next).
4. После проверки правильности заданных критериев на странице Summary of Selections снова нажмем кнопку Next. Система некоторое время будет анализировать параметры политик.
5. На последней странице мастера нажмем кнопку Finish (Готово).
Процесс анализа завершен — можно анализировать результаты. В окне (Рисунок 21.18), напоминающем окно оснастки Group Policy Object Editor, будут отображаться только те папки (ниже второго уровня), в которых имеются установленные политики. В нашем случае узел Computer Configuration содержит все политики, действующие на учетные записи компьютеров, находящиеся в подразделении Admins, а узел User Configuration содержит все политики, действующие на учетные записи пользователей, находящиеся в этом же подразделении.

Определение действующих политик

Определение действующих политик


Для работы с доменными групповыми политиками в системах Windows Server 2003 имеются появившиеся еще в Windows XP две очень полезные утилиты командной строки:

GPUpdate.exe — выполните эту команду, если вы изменяли групповые политики и хотите, чтобы они немедленно стали активными (сначала запустите ее с параметром /?). В Windows 2000 для этих целей использовалась команда secedit /refreshPolicy;

GPResult.exe — эта команда, входившая ранее в состав пакета Windows 2000 Resource Kit, стала стандартной командой системы. С ее помощью можно определить, какие настройки групповых политик фактически применяются по отношению к указанному компьютеру/пользователю. Может выполняться для удаленного компьютера. Запускать команду лучше всего с параметром /v — в этом случае сразу становятся видны ее возможности. Аналогичную задачу выполняет описываемая ниже оснастка Resultant set of Policies (Результирующая политика).

Определение параметров групповой политики

Рисунок 21.7. Определение параметров групповой политики

Определение схемы выбора контроллера домена

Рисунок 21.3. Определение схемы выбора контроллера домена


Отдельного комментария заслуживает вторая из предлагаемых опций. Оснастку Group Policy Object Editor можно запускать из окна оснасток Active Directory Users and Computers или Active Directory Sites and Services, которые в этот момент подключены к определенному контроллеру домена. В подобной ситуации оснастка Group Policy Object Editor может работать с тем же контроллером домена, что и оснастка, из которой она была запущена. Выбранная опция сохраняется и используется при следующем запуске оснастки. При этом, если выбранный контроллер домена недоступен при запуске оснастки, возникает ошибка.
Существует групповая политика, позволяющая администратору определить стратегию выбора предпочитаемого контроллера домена. Откройте используемый объект GPO и перейдите к узлу User Configuration | Administrative Templates | System | Group Policy (Конфигурация пользователя Административные шаблоны | Система | Групповая политика). Откройте политику Group Policy domain controller selection. Активизируйте политику, установив переключатель Enable, а затем одну из следующих возможностей:

Use the Primary Domain Controller (Использовать основной контроллер домена);

Inherit from Active Directory Snap-ins (Унаследовать от оснасток Active Directory);

Use any available domain controller (Использовать любой доступный контроллер домена).

Если эта политика запрещена (disabled) или не установлена (not configured), оснастка Group Policy Object Editor подключается к контроллеру домена, являющегося исполнителем роли РОС. Если политика установлена, она переопределяет опцию, заданную в самой оснастке Group Policy Object Editor.

Примечание Поскольку при поиске объектов групповой политики выполняются обращения к DNS, ошибки при запуске оснасток Group Policy Object Editor нередко объясняются неправильной работой службы DNS. Поэтому при появлении подобных ошибок всегда проверяйте конфигурацию DNS. Помните о том, что DNS — это динамическая система, и ресурсные записи становятся просроченными и требуют периодической перерегистрации.

Определение способа развертывания приложений

Рисунок 21.13. Определение способа развертывания приложений

Оснастка Group Policy Object Editor

Оснастка Group Policy Object Editor


Оснастка Group Policy Object Editor (Редактор объектов групповой политики) используется для редактирования параметров объектов групповой политики (group policy objects, GPO). Эта оснастка может использоваться для редактирования любых объектов GPO (как локальных, так и тех, что хранятся в каталоге). Администратор может запустить оснастку Group Policy Object Editor из определенных административных оснасток. Кроме того, эта оснастка может быть добавлена непосредственно в пользовательскую консоль.
Оснастка позволяет конфигурировать параметры групповой политики, касающиеся как компьютера, так и пользователя. В панели пространства имен оснастки эти группы параметров GPO представлены контейнерами Computer Configuration (Конфигурация компьютера) и User Configuration (Конфигурация пользователя).
Оснастка Group Policy Object Editor предоставляет администратору больше возможностей по конфигурированию параметров групповой политики по сравнению с другими оснастками, предполагающими работу с групповой политикой, — оснастками Local Security Policy, Domain Controller Security Policy и Domain Security Policy. Указанные оснастки обеспечивают доступ только к ограниченному подмножеству параметров групповой политики, расположенных в контейнере Security Setting (Параметры безопасности) соответствующего объекта групповой политики. Оснастки Domain Controller Security Policy и Domain Security Policy устанавливаются на каждом контроллере домена. Оснастка Local Security Policy присутствует на каждом рядовом компьютере под управлением Windows 2000/XP или Windows Server 2003.

Оснастка Resultant set of Policies

Оснастка Resultant set of Policies


В системах Windows XP и Windows Server 2003 имеется очень удобный инструмент для работы с групповыми политиками, который особенно оценят администраторы крупных доменов с многоуровневой иерархией объектов GPO — это оснастка Resultant set of Policies (Результирующая политика).
Информацию о результирующих политиках можно получать в одном из двух режимов.

Режим планирования (planning mode) позволяет администраторам моделировать использование групповых политик, определенных в различных объектам GPO, при этом можно даже не выбирать целевые компьютеры и пользователей. К примеру, с помощью этого режима можно получить ответ на вопрос "Какие установки групповых политик применяются к пользователям, учетные записи которых находятся в подразделении Admins, а зарегистрировались они на компьютерах, входящих в подразделение Managers?" При этом можно также моделировать присутствие или отсутствие пользователя в определенных группах безопасности.

Режим ведения журнала (logging mode) можно использовать только для определения реально действующих параметров групповых политик для пользователя, зарегистрированного на некотором компьютере.

Режим планирования можно применять для любого объекта каталога: домена, подразделения, пользователя и компьютера. Очевидно, что режим ведения журнала возможен только для учетных записей пользователей и компьютеров — поскольку только пользователь может регистрироваться на компьютере.
Процедура предварительного конфигурирования оснастки Resultant Set of Policy практически одинакова для обоих режимов, поэтому нет смысла рассматривать их индивидуально. Для примера определим, какие групповые политики применяются к пользователям, чьи учетные записи располагаются в некотором подразделении. Для этого:
1. Откроем оснастку Active Directory Users and Computers, выберем в окне структуры интересующее нас подразделение и в контекстном меню выполним команду All Tasks | Resultant Set of Policy (Planning) (Все задачи | Результирующие политики (планирование)).
2. В окне мастера Resultant Set of Policy Wizard (Рисунок 21.17) можно изменить выбранный контейнер (нажав кнопку Browse и выбрав другой контейнер для пользовательского или компьютерного объекта) или конкретизировать запрос, установив переключатель User или Computer и выбрав соответствующую учетную запись (которая может находиться и в другом подразделении).

Оснастка Resultant Set of Policy

Рисунок 21.18. Оснастка Resultant Set of Policy позволяет быстро найти действующие политики


Например, в нашем примере показано, что для выбранного пользователя установлен сценарий выхода из системы (узел Logoff), а для компьютера задана политика отключения журнала событий выключения системы — Display Shutdown Event Tracker; причем в столбце GPO Name можно видеть, что эта политика была установлена доменным объектом GPO. Полученные сведения можно (и полезно!) проверить с помощью утилиты GRResult и сравнить результаты.
Полученный инструмент ММС можно закрыть или сохранить (при повторном запуске оснастка вновь анализирует систему и выводит обновленные данные). Можно изменить критерии запроса и выполнить анализ повторно, не закрывая полученной оснастки Resultant Set of Policy. Для этого нужно выбрать корневой узел в окне структуры и в меню Action выполнить команду Change Query.

Перенаправление пользовательских папок

Перенаправление пользовательских папок


Традиционным местом размещения документов пользователей является папка My Documents (Мои документы). В ситуации, когда пользователи перемещаются по организации, регистрируясь в сети на различных рабочих станциях, администратор может использовать перемещаемые профили для организации централизованного хранения пользовательских документов и настроек (roaming user profiles).
Профиль создается в момент первой регистрации пользователя в системе. По умолчанию локальные профили пользователя в операционных системах Windows 2000/XP и Windows Server 2003 размещаются в папке Documents and Settings (Документы и настройки). Механизм перемещаемых профилей позволяет организовать централизованное хранение всех настроек и документов пользователей на сервере. Централизованное хранение профилей позволяет упростить такие процессы, как регулярное резервное копирование, проверка на наличие вирусов и т. п.
Механизм групповой политики позволяет администратору организовать перенаправление обращений пользователя к папкам пользователя, содержащим его настройки и документы, на некоторый сетевой ресурс. Так же как и в случае с перемещаемыми профилями, информация, содержащаяся в перенаправленных папках, будет доступна пользователю на любой рабочей станции. Перенаправление папок позволяет избежать постоянного копирования информации пользовательских папок с сервера на локальный диск компьютера, характерного для перемещаемых профилей. Система предоставляет прозрачный доступ к данным. Пользователь работает непосредственно с тем сетевым ресурсом, на котором находятся его папки. В табл. 21.3 перечислены папки пользовательского профиля, для которых допускается перенаправление.

Построение иерархии объектов групповой политики

Построение иерархии объектов групповой политики


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

сначала применяются объекты групповой политики, привязанные к сайту, в котором находится объект каталога;

после этого применяются объекты, привязанные на уровне домена,

последними применяются объекты групповой политики, привязанные к подразделениям.

Если имеется несколько вложенных подразделений, объекты групповой политики применяются в соответствии с уровнями вложенности. В данном случае речь идет о наследовании параметров вышестоящих объектов групповой политики (group policy inheritance).
Объекты групповой политики, привязанные к дочерним контейнерам, могут переопределять параметры объектов групповой политики, привязанных к вышестоящим объектам. В этом случае принято говорить о переопределении (group policy overriding) параметров объекта групповой политики. При этом наследуются только те параметры объектов групповой политики, что были определены для родительского контейнера, но не определены для дочернего. В противном случае значения параметров, определенные в объекте групповой политики, привязанном к нижестоящему объекту групповой политики, будут переопределять значения аналогичных параметров объекта групповой политики, привязанной к вышестоящему контейнеру. Если некоторый параметр объекта групповой политики допускает множество значений, значения параметра объекта групповой политики родительского контейнера дополняют значения аналогичного параметра, определенного в рамках объекта групповой политики дочернего контейнера.

Предоставление полномочий на доступ

Предоставление полномочий на доступ к объектам групповой политики


Администратор может делегировать некоторым пользователям часть обязанностей по управлению объектами групповой политики. Чтобы предоставить пользователю полномочия, необходимые для выполнения привязки объекта групповой политики на уровне определенного контейнера, администратор должен использовать мастер Delegate of Control Wizard (Мастер делегирования управления). При работе мастера надо делегировать пользователям полномочия, необходимые для выполнения задачи управления привязками объектов групповой политики (флажок Manage Group Policy links на странице мастера Tasks to Delegate).
Кроме того, указанная категория пользователей должна иметь разрешение на чтение объекта групповой политики. По умолчанию подобное разрешение предоставляется всем аутентифицированным пользователям.

Используя механизм разрешений, администратор может также предоставить разрешения на модификацию параметров объекта групповой политики. Этими полномочиями по умолчанию в рамках домена обладают пользователи, входящие в состав группы Group Policy Creator Owners (Владельцы объектов групповой политики).

Применение административного шаблона

Рисунок 21.6. Применение административного шаблона к объекту групповой политики


При помощи оснастки Group Policy Object Editor администратор имеет возможность редактировать вручную параметры групповой политики, расположенные внутри контейнера Administrative Templates и отвечающие за конфигурирование реестра клиентского компьютера. Выбрав интересующий параметр, администратор должен открыть окно его свойств. На вкладке Settings (Настройки) окна свойств (Рисунок 21.7) можно определить значение выбранного параметра:

Not Configured (He определено). Данное значение оставляет неопределенной возможность использования пользователем выбранного режима в рамках рассматриваемого объекта групповой политики. Фактически доступность выбранного режима удаленной установки ставится в зависимость от значения аналогичного параметра групповой политики, определенного на вышестоящем уровне;

Enabled (Активизировать). Выбор данного значения активизирует выбранный параметр групповой политики. Применительно к рассматриваемому параметру значение явно разрешает использование выбранного режима установки пользователям, подпадающим под действие конфигурируемого объекта групповой политики;

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

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

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


Следует четко понимать, что использование административных шаблонов возможно исключительно через механизм групповой политики. Это означает, что для распространения административного шаблона на некоторое множество компьютеров, он должен являться частью соответствующего объекта групповой политики. Чтобы сделать административный шаблон частью объекта групповой политики, следует загрузить его в оснастку Group Policy Object Editor. Для этого в контекстном меню контейнера Administrative Tools необходимо выбрать пункт Add/Remove Templates (Добавить/удалить шаблоны). В открывшемся окне (Рисунок 21.6) надо выбрать интересующий шаблон и нажать кнопку Add (Добавить). В результате, шаблон будет применен к конфигурируемому объекту групповой политики.

Привязка объекта групповой политики

Привязка объекта групповой политики к контейнеру Active Directory


Любой объект групповой политики может быть привязан к некоторому сайту, домену или подразделению. Один объект групповой политики может быть привязан к множеству контейнеров. Для выполнения привязки необходимо щелкнуть на кнопке Add на вкладке Group Policy окна свойств контейнера. В окне Browse for a Group Policy Object все объекты групповой политики, существующие в домене, перечислены на вкладке All (Все).
Администратору достаточно выбрать необходимый объект групповой политики и щелкнуть по кнопке ОК.
Возможна и обратная операция. Администратор может найти контейнеры, к которым привязан выбранный объект групповой политики. Для этого в оснастке Group Policy Object Editor необходимо в контекстном меню корневого объекта оснастки выбрать пункт Properties (Свойства), чтобы открыть окно свойств объекта групповой политики. В окне свойств необходимо перейти на вкладку Links (Рисунок 21.4). Выбрав из раскрывающегося списка Domain нужный домен и щелкнув по кнопке Find Now (Найти), администратор получит список контейнеров, к которым к настоящий момент привязан рассматриваемый объект групповой политики.

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

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


Оснастка Group Policy Object Editor может быть вызвана из оснасток Active Directory Users and Computers и Active Directory Sites and Services. Для этого в окне свойств объекта, ассоциированного с сайтом, доменом или подразделением, необходимо перейти на вкладку Group Policy (Рисунок 21.1).

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

Рисунок 21.4. Просмотр привязок выбранного объекта групповой политики

Публикация приложений

Публикация приложений


Публикация приложений может осуществляться исключительно в конфигурации пользователей. При этом пользователю, подпадающему под действие объекта групповой политики, предлагается список доступных для установки приложений. При этом пользователь самостоятельно принимает решение о том, необходимо ли выполнять установку приложения или нет.
В процессе публикации приложений инсталляционные пакеты (installation package) помещаются в специальное хранилище. Для установки опубликованного приложения, пользователь должен использовать мастер Add/Remove Programs (Установка/удаление программ). Чтобы просмотреть список опубликованных приложений, пользователь должен щелкнуть по пиктограмме Add New Programs (Добавить новое приложение).
Чтобы опубликовать приложение, в контекстном меню контейнера Software Installation необходимо выбрать пункт New | Package. Указав в открывшемся окне месторасположение инсталляционного пакета, администратор должен указать способ развертывания приложения (Рисунок 21.13).

Сценарии

Сценарии


Под сценарием (scripts) понимается некоторая предопределенная последовательность команд, способных выполнятся в автоматическом режиме (т. е. без участия пользователя). Основное преимущество сценариев заключается в том, что их выполнение может осуществляться в соответствии с некоторым расписанием. Администраторы используют сценарии в ситуациях, когда необходимо многократно выполнять некоторую последовательность действий.
Используя механизм групповых политик, администратор может определить последовательность операций, которые будут выполняться в момент включения или выключения компьютера, либо при регистрации пользователя в системе или при выходе из нее. Таким образом, можно выделить четыре группы сценариев:

сценарии, выполняемые при инициализации системы (startup scripts);

сценарии, выполняемые при регистрации пользователя в системе (logon scripts);

сценарии, выполняемые при выключении компьютера (shutdown scripts);

сценарии, выполняемые при выходе пользователя из системы (logoff scripts).

Интерпретация сценариев осуществляется сервером сценариев Windows Script Host. Этот стандартный компонент, входящий в состав Windows 2000/XP и Windows Server 2003, позволяет создавать сценарии, используя специализированные языки Visual Basic Scripting Edition, JScript. Для старых версий клиентов (Windows 9x/NT) сценарии должны представлять собой пакетные файлы (.bat-файлы), либо нужно установить на них сервер сценариев Windows Script Host (загружаемый свободно с сайта Microsoft).
Все сценарии, определяемые в рамках объекта групповой политики, хранятся в шаблоне групповой политики, который в свою очередь располагается в папке %SystemRoot%\SYSVOL\sysvol\<имя-домена>\policies\
Выполнение сценариев происходит в следующем порядке. В первую очередь выполняются сценарии инициализации (startup scripts). После этого выполняются сценарии регистрации пользователя (logon scripts). Сценарии выхода пользователя из системы и сценарии завершения работы выполняются, соответственно, в обратном порядке.
Сценарий должен быть создан и протестирован еще до того момента, как он будет назначен в рамках некоторого объекта групповой политики. Чтобы назначить объекту групповой политики новый сценарий, необходимо перейти к категории параметров Scripts и в панели результатов вызвать контекстное меню объекта, ассоциированного с соответствующим типом сценария. В меню надо выбрать пункт Properties (Свойства).

Сценарии, выполняемые в момент инициализации системы, а также в момент завершения работы, назначаются в конфигурации компьютера (computer configuration). Соответственно, сценарии, выполняемые в момент при регистрации пользователя в системе и при выходе из нее, назначаются в конфигурации пользователя (user configuration).
В открывшемся окне (Рисунок 21.8) администратор может добавить или удалить привязку сценария к конфигурируемому объекту групповой политики. В рамках одного объекта групповой политики администратор может определить несколько сценариев одного типа. При этом администратор должен определить порядок, в котором они будут выполняться. Порядок перечисления сценариев в окне соответствует порядку их выполнения. Для изменения порядка используются кнопки Up (Вверх) и Down (Вниз).

Создание административных шаблонов

Создание административных шаблонов


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

Административные шаблоны Windows Server 2003 имеют порядка 200 новых параметров, отсутствующих в административных шаблонах Windows 2000.

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

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


Для создания нового объекта групповой политики достаточно щелкнуть на кнопке New (Создать) на вкладке Group Policy (см. Рисунок 21.1) в окне свойств некоторого контейнера или щелкнуть на соответствующей кнопке в панели инструментов окна Browse for a Group Policy Object (см. Рисунок 21.2). Система предложит администратору дать имя создаваемому объекту групповой политики. После этого системой будет создан объект групповой политики со значениями параметров по умолчанию.
Удаление объекта групповой политики, не привязанного к какому-либо контейнеру каталога, не вызывает особых трудностей. В случае, если подобная привязка существует, система потребует дать дополнительные указания:

Remove the link from the list (Изъять ссылку из списка, не удаляя объекта). Выбирая этот режим, администратор фактически только удаляет привязку выбранного объекта групповой политики к некоторому контейнеру каталога. Непосредственно сам объект групповой политики остается неизменным, и администратор может использовать его впоследствии;

Remove the link and delete the Group Policy Object permanently (Изъять ссылку и окончательно удалить объект групповой политики). Выбор данного режима приводит к удалению непосредственно самого объекта групповой политики. При этом также удаляются существующие привязки указанного объекта к контейнерам каталога.

Структура объекта групповой политики

Структура объекта групповой политики


Множество параметров, определяемых в рамках объекта групповой политики, разделено на две части. Одна часть параметров используется для конфигурирования компьютера (computer configuration), другая часть параметров используется для конфигурирования среды пользователя (user configuration). Конфигурирование компьютера предполагает определение значений для параметров, влияющих на формирование окружения любых пользователей, регистрирующихся на данном компьютере. Конфигурирование среды пользователя дает возможность управлять процессом формирования окружения конкретного пользователя, независимо от того, на каком компьютере он регистрируется в сети.
Независимо от типа конфигурирования, параметры групповой политики организованы в специальные категории (Рисунок 21.5). Каждая из категорий параметров групповой политики определяет отдельную область окружения пользователя. Доступные категории параметров перечислены в табл. 21.1. В свою очередь категории параметров групповой политики организованы в три контейнера в соответствии со своим назначением:

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

Рисунок 21.5. Структура объекта групповой политики

Windows Settings (Конфигурация Windows). В контейнере размешаются категории параметров групповой политики, определяющие настройки непосредственно самой операционной системы. Содержимое данного контейнера может быть различным, в зависимости от того, для кого определяются параметры групповой политики (для пользователя или компьютера);

Administrative Templates (Административные шаблоны). Этот контейнер содержит категории параметров групповой политики, применяемых для управления содержимым системного реестра компьютера.

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

Таблица 21.1. Категории параметров групповой политики

Категория	Контейнер	Описание
Software Installation	Software Settings	Данная категория параметров используется для централизованного управления приложениями, доступными на данном компьютере, или для данного пользователя. При этом в зависимости от параметров групповой политики приложения могут либо устанавливаться принудительно, либо рекомендоваться для установки
Remote Installation Service	Windows Settings	Данная категория параметров используется для управления процессом удаленной установки на клиентском компьютере. Эта категория параметров доступна только в случае конфигурирования на уровне пользователя
Scripts	Windows Settings	Категория используется для определения сценариев, которые будут выполняться при включении/выключении компьютера (Startup/Shutdown Scripts), либо при регистрации пользователя в системе или его выхода из нее (Logon/Logoff Scripts)
Security Settings	Windows Settings	Параметры данной категории используются для управления настройками безопасности клиентского компьютера. Помимо групповой политики, администратор может также использовать другие механизмы для управления настройками безопасности
Folder Redirection	Windows Settings	Посредством параметров данной категории администратор может сконфигурировать процесс перенаправления папок из пользовательского профиля (таких, например, как My Documents) на некоторый сетевой ресурс. Эта категория параметров доступна только для конфигурации пользователя
Internet Explorer Maintenance	Windows Settings	Параметры данной категории используются для настройки браузера Internet Explorer. Эта категория параметров доступна только для конфигурации пользователя
Windows Components	Administrative Templates	В данной категории представлены параметры, посредством которых администратор может осуществлять управление настройками Windows-компонентов, установленных на конфигурируемой системе
Start Menu and Taskbar	Administrative Templates	Параметры данной категории позволяют администратору конфигурировать главное меню и панель задач клиентского компьютера (прежде всего, ограничивать доступную функциональность). Эта категория параметров доступна только для конфигурации пользователя
Desktop	Administrative Templates	Параметры данной категории позволяют администратору конфигурировать вид рабочего стола клиентского компьютера и его функциональность. Эта категория параметров доступна только в случае конфигурирования на уровне пользователя. Эта категория параметров доступна только для конфигурации пользователя
Control Panel	Administrative Templates	Параметры данной категории позволяют администратору управлять видимостью отдельных компонентов панели управления на клиентском компьютере. Эта категория параметров доступна только для конфигурации пользователя
Shared Folders	Administrative Templates	Параметры данной категории позволяют управлять процессом публикации общих папок. Эта категория параметров доступна только для конфигурации пользователя
Networks	Administrative Templates	Данная категория параметров используется для управления конфигурацией сетевых компонентов системы
System	Administrative Templates	В данной категории представлены параметры, позволяющие управлять настройками реестра, влияющими на поведение системы в целом
Printers	Administrative Templates	Параметры данной категории используются для управления процессом публикации принтеров. Эта категория параметров доступна только для конфигурации компьютера

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

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

Таблица 21.2. Административные шаблоны, поставляемые в составе Windows Server 2003

Административный шаблон	Описание
Common.adm	Административный шаблон, используемый для настройки параметров системы на Windows 9х/МТ-клиентах
Conf.adm	Административный шаблон, используемый для настройки NetMeeting
Inetcorp.adm	Административный шаблон, используемый для настройки браузера Internet Explorer для работы в корпоративной среде
Inetres.adm	Административный шаблон, используемый для настройки ограничений браузера Internet Explorer
Inetset.adm	Административный шаблон, используемый для настройки браузера Internet Explorer
System. adm	Административный шаблон, используемый для настройки различных параметров системы
Windows. adm	Административный шаблон, используемый для конфигурирования Windows Эх-клиентов
Winnt.adm	Административный шаблон, используемый для конфигурирования Windows NT-клиентов
Wmplayer.adm	Административный шаблон, используемый для настройки приложения Windows Media Player
Wuau.adm	Административный шаблон, используемый для настройки службы автоматического обновления

Для работы с шаблонами Common.adm, Windows.adm и Winnt.adm необходимо использовать утилиту System Policy Editor (Редактор системной политики).

Папки пользовательского

Таблица 21.3. Папки пользовательского профиля, для которых допускается перенаправление

Папка	Описание
Application data	В папке размещается информация, используемая приложениями. Некоторые приложения могут хранить в этой папке свои настройки, индивидуальные для каждого конкретного пользователя
Desktop	В папке хранятся объекты рабочего стола, включая ярлыки и файлы
My Documents	Папка используется для размещения документов пользователя
My Pictures	Папка используется для размещения графических файлов пользователя
Start Menu	В папке размещаются ярлыки программ главного меню

Важно понимать, что механизм перенаправления (так же как и механизм перемещаемых профилей) эффективен только в том случае, когда пользователи используют собственные профили для размещения своих документов.
Режим перенаправления пользовательских папок настраивается в объектах групповой политики исключительно в конфигурации пользователя. Для определения параметров этого режима используется категория параметров Folder Redirection (Перенаправление папок). Администратор может определить индивидуально параметры перенаправления для каждой из пяти описанных папок. Для этого необходимо в контекстном меню объекта, ассоциированного с папкой, выбрать пункт Properties. На вкладке Target из раскрывающегося списка Setting (Настройка) необходимо выбрать режим перенаправления. Возможны три режима перенаправления папок. .

Перенаправление папки не выполняется. Чтобы выбрать данный режим, необходимо выбрать из списка значение Not configured (He определено).

Основной режим. В данном режиме указанная папка для всех пользователей, подпадающих под действие редактируемого объекта групповой политики, перенаправляется на один сетевой ресурс. Данному режиму соответствует значение Basic - Redirect everyone's folder to the same location (Основной — перенаправлять папки всех пользователей в одно место).

Расширенный режим. В этом режиме администратор может определить перенаправление папок пользователей на различные сетевые ресурсы. Выбор конкретного сетевого ресурса определяется группой, к которой принадлежит пользователь. Для выбора этого режима перенаправления в списке необходимо выбрать значение Advanced — Specify locations for various user groups (Расширенный — определить место для различных групп пользователей).

Ниже рассмотрим процесс настройки основного и расширенного режимов более подробно.

Перенаправление папок возможно только для Windows 2000/XP- и Windows Server 2003-клиентов. Следует также заметить, что функциональность механизма перенаправления папок была существенным образом расширена в Windows Server 2003. Однако появившиеся новые возможности доступны только на клиентах Windows XP и Windows Server 2003.

Управление приложениями

Управление приложениями


Механизм групповой политики может использоваться как средство управления процессом развертывания приложений на Windows 2000/XP- и Windows Server 2003-клиентах. Администратор может определить перечень приложений, которые будут доступны пользователям. В зависимости от выбранного режима, в процессе применения объекта групповой политики на компьютере будут установлены все необходимые приложения. Возможны следующие режимы управления процессом развертывания приложений:

публикация приложений;

назначение приложений пользователям',

назначение приложений компьютерам.

Механизм управления процессом развертывания приложений базируется на технологии Windows Installer. В составе большинства продуктов поставляются специальные инсталляционные пакеты (installation package), которые могут быть использованы для автоматической установки данного приложения.
Описание процесса развертывания выходит за рамки данной книги. В данном разделе мы постараемся осветить основные моменты данного процесса.

Вкладка Group Policy окна свойств подразделения

Рисунок 21.1.Вкладка Group Policy окна свойств подразделения


Чтобы изменять параметры произвольного объекта GPO, администратор должен вручную загрузить оснастку Group Policy Object Editor в консоль ММС, при этом необходимо выполнить ее привязку к некоторому объекту групповой политики. В окне Select Group Policy Object (Выбор объекта групповой политики) по умолчанию предлагается привязать оснастку либо к локальному объекту GPO, либо к одному из доменных GPO. Чтобы выбрать объект групповой политики, щелкните по кнопке Browse (Обзор). В окне Browse for a Group Policy Object (Поиск объекта групповой политики) администратор может (Рисунок 21.2):

выбрать один из существующих (и, как правило, уже привязанный к какому-нибудь контейнеру каталога) объектов групповой политики в списке и загрузить его для редактирования в оснастку Group Policy Object Editor;

создать новый объект групповой политики.

Выбор контроллера домена

Выбор контроллера домена


Оснастка Group Policy Object Editor работает с объектами каталога, следовательно, все ее манипуляции с объектами должны производиться в контексте некоторого контроллера домена. Чтобы определить правило выбора контроллера домена, в контексте которого будет работать оснастка Group Policy Object Editor, выберите имя оснастки и в меню View (Вид) выполните команду DC Options (Параметры контроллера домена). В открывшемся окне (Рисунок 21.3) следует выбрать необходимое значение.

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

Рисунок 21.2. Выбор объекта групповой политики


В дальнейшем необходимо различать операцию привязки оснастки Group Policy Object Editor к некоторому объекту GPO и операцию привязки непосредственно самого объекта GPO к некоторому контейнеру каталога.
Следует заметить, что один экземпляр оснастки Group Policy Object Editor позволяет работать только с одним экземпляром объекта групповой политики. Привязка оснасток возможна только в момент создания пользовательских консолей, включающих оснастку Group Policy Object Editor. Если необходимо редактировать другой объект групповой политики, администратор должен запустить второй экземпляр оснастки.

Запрещение переопределения параметров

Запрещение переопределения параметров объектов групповой политики


Для запрещения переопределения параметров объектов групповой политики в окне свойств контейнера необходимо перейти на вкладку Group Policy и щелкнуть по кнопке Options (Параметры). В открывшемся окне (Рисунок 21.15) надо установить флажок No Override (He переопределять). При этом на содержимое дочернего контейнера будут распространяться параметры объекта групповой политики, привязанные к родительским контейнерам, даже в том случае, если аналогичные параметры переопределены непосредственно на уровне дочернего контейнера. При установленном флажке No Override наследуемые параметры имеют преимущество над аналогичными параметрами объекта групповой политики, привязанного к дочернему контейнеру, даже если для этого контейнера установлен флажок Block Policy inheritance.

Рисунок 21.15. Запрещение переопределения параметров объектов групповой политики

Запрещение применения параметров объекта групповой политики

Запрещение применения параметров объекта групповой политики


Администратор может запретить применение параметров любых объектов групповой политики к содержимому некоторого контейнера каталога. Для этого на вкладке Group Policy окна свойств контейнера необходимо щелкнуть по кнопке Options (Параметры) и в открывшемся окне (см. Рисунок 21.15) установить флажок Disabled (Отключено).

Запрет на применение параметров

Рисунок 21.16. Запрет на применение параметров данного объекта групповой политики к членам группы Enterprise Admins


Для этого необходимо на вкладке Security (Безопасность) окна свойств выбранного объекта групповой политики указать нужную группу безопасности и установить флажок Deny (Запретить) напротив разрешения Apply Group Policy (Применять групповую политику) (Рисунок 21.16). Эта процедура называется фильтрацией групповых политик (group policy filtering).

Internet Information Services 6.0

Администрирование безопасности IP

Администрирование безопасности IP


Управление безопасностью IP в Windows Server 2003 позволяет администраторам создавать настраиваемую политику безопасности с уникальной политикой переговоров и IP-фильтрами. Не требуются никакие изменения прикладных программ. Также не требуется обучать конечных пользователей, поскольку администраторы конфигурируют всю политику безопасности в службе Active Directory, а действия шифрования прозрачны на уровне конечного пользователя.

Алгоритмы шифрования

Алгоритмы шифрования


Для защиты данных применяются математические алгоритмы шифрования. Безопасность IP в Windows 2000/Server 2003 использует стандартные криптографические алгоритмы, перечисленные ниже.

Методика Diffie-Hellman (D-H). Алгоритм шифрования с открытым ключом (названный по имени изобретателей — Diffie и Hellman), который позволяет двум поддерживающим связь объектам договариваться об общедоступном ключе без требования шифрования во время порождения ключа. Процесс начинают два объекта, обменивающиеся общедоступной информацией. Затем каждый объект объединяет общую информацию другой стороны со своей собственной секретной информацией, чтобы сгенерировать секретное общедоступное значение.

Код аутентификации хэшированного сообщения (НМАС, Hash Message Authentication Code). НМАС — алгоритм шифрования с закрытым ключом, обеспечивающий целостность сообщений, установление их подлинности и предотвращение повторного использования. Установление подлинности, использующее функции хэширования (перемешивания), объединено с методом закрытого ключа. Хэшированное значение, известное также как дайджест (digest), или выборка сообщений, используется для создания и проверки цифровой подписи. Это уникальное значение намного меньше, чем первоначальное сообщение, созданное из цифровой копии кадра данных. Если передаваемое сообщение изменилось по пути следования, то хэшированное значение будет отличаться от оригинала, а IP-пакет будет отброшен.

HMAC-MD5. Дайджест сообщений-5 (MD5, Message Digest) — функция хэширования, которая порождает 128-разрядное значение, являющееся подписью данного блока данных. Эта подпись служит для установления подлинности, целостности и предотвращения повторного использования.

HMAC-SHA. Безопасный алгоритм хэширования (SHA, Secure Hash Algorithm) — еще одна функция хэширования, которая порождает 160-разрядное значение подписи, необходимое для установления подлинности, целостности и предотвращения повторного использования.

DES-CBC. Стандарт шифрования данных (Data Encryption Standard, DES) — формирование цепочки шифрованных блоков (Cipher Block Chaining, CBC) — алгоритм шифрования с закрытым ключом, обеспечивающий конфиденциальность. Генерируется случайное число, которое используется совместно с закрытым ключом для шифрования данных.

Моделирование

Если совсем коротко, то это попытка получить ответ на вопрос -что будет, если? Штука в том, что задать вопрос гораздо легче чем получить на него правильный ответ. Это касается всех областей человеческой деятельности от бизнеса, до романтических отношений. Трудно, но попытаться стоит. Правда стоит оставить местечко и для здоровой критики ответа.

Моделирование в Ansys
Моделирование в Matlab
Моделирование в Simulink
Моделирование - Биржа
Вероятности моделирования

---

Моделирование - Данные
Имитационное моделирование
Методология SADT
Взаимосвязи сущностей
Экспертные системы моделей

---

Расчет приводов
Вибродиагностика
Машиностроения - Материалы
Теория динамики машин
Проектирование программ

---

Графика в системе Pcad
Создание проекта в Pcad
Учебник по PRO Engineer 2001
Учебник Making The Drawings
Fractal Design Painter 5

---

Пользователи Autodesk
Арматура сцепная линейная
Проектировщик-электрик
Моделирование систем
3D в Mechanical Desktop

---

Mechanical Desktop - Сборки
Создание элементов в P-CAD
Радиоэлементы в P-CAD 2002
Библиотеки P-CAD
Печатные платы P-CAD PCB

---

Библиотеки в P-CAD 2002
Электро схемы в P-CAD
Штамп чертежа в P-CAD 2002
Проектирование плат P-CAD
Библиотеки P-CAD

---

Советы по P-CAD
Ошибки P-CAD РСВ
Трассировка плат TopoR
FreeStyle Router - функции
Программа sPlan

---

Модели в Design Center
AutoCAD - проектирование
Математическое моделирование
Методы моделирования
Модели в моделировании

---

Прикладные системы моделирования
Софт для моделирования
Финансы моделирования
Экономическое моделирование
Теория крэкинга

---

Моделирование в Simulink
Моделирование течений
Редактор P-CAD Schematic
Самоучитель по P-cad
Unigraphics. Сборка

---

Unigraphics. Черчение
Unigraphics. Моделирование
Unigraphics. Интерфейс
AutoCAD 2004 - руководство
Cамоучитель AutoCAD

---

Работа с AutoCAD 2004
Основы AutoCAD

Архитектура безопасности IP

Архитектура безопасности IP


Механизм безопасности IP в Windows Server 2003 разработан для защиты любого сквозного соединения между двумя компьютерами (Рисунок 22.2). При сквозном соединении два осуществляющих связь компьютера (системы) поддерживают IP-безопасность на каждом конце соединения. Сделано предположение, что располагающаяся между ними среда, по которой передаются данные, небезопасна. Данные прикладной программы компьютера, начинающего связь, перед пересылкой по сети автоматически (прозрачно для прикладной программы) шифруются. На компьютере адресата данные также автоматически дешифруются — прежде, чем они будут переданы приложению-получателю. Шифрование всего сетевого IP-трафика гарантирует, что любая связь с использованием TCP/IP защищена от подслушивания. Поскольку данные передаются и шифруются на уровне протокола IP, для каждого протокола в наборе протоколов TCP/IP не требуются отдельные пакеты, обеспечивающие безопасность.
Безопасность IP в Windows Server 2003 объединяет методы шифрования с открытыми и закрытыми ключами для повышения уровня безопасности и большей производительности.
Управление безопасностью IP в Windows Server 2003 допускает создание политики, определяющей тип и уровень безопасности, необходимые во время обмена информации.

Политика безопасности (security policy)

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

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

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


EFS содержит следующие компоненты операционной системы (Рисунок 22.7).

Драйвер EFS. Драйвер EFS является надстройкой над файловой системой NTFS. Он обменивается данными со службой EFS — запрашивает ключи шифрования, наборы DDF (Data Decryption Field) и DRF (Data Recovery Field), — а также с другими службами управления ключами. Полученную информацию драйвер EFS передает Библиотеке реального времени файловой системы EFS (File System Run-Time Library, FSRTL), которая прозрачно для операционной системы выполняет различные операции, характерные для файловой системы (чтение, запись, открытие файла, присоединение информации).

Библиотека реального времени файловой системы EFS. FSRTL — это модуль, находящийся внутри драйвера EFS, реализующий вызовы NTFS, выполняющие такие операции, как чтение, запись и открытие зашифрованных файлов и каталогов, а также операции, связанные с шифрованием, дешифрованием и восстановлением файлов при их чтении или записи на диск. Хотя драйверы EFS и FSRTL реализованы в виде одного компонента, они никогда не обмениваются данными напрямую. Для передачи сообщений друг другу они используют механизм вызовов (callouts) NTFS, предназначенный для управления файлами. Это гарантирует, что вся работа с файлами происходит при непосредственном участии NTFS. С помощью механизма управления файлами операции записи значений атрибутов EFS (DDF и DRF) реализованы как обычная модификация атрибутов файла. Кроме того, передача ключа шифрования файла РЕК (см. ниже), полученного службой EFS, в FSRTL выполняется так, чтобы он мог быть установлен в контексте открытого файла. Затем контекст файла используется для автоматического выполнения операций шифрования и дешифрования при записи и чтении информации файла.

Рисунок 22.7. Архитектура EFS

Служба EFS. Служба EFS (EFS Service) является частью системы безопасности операционной системы. Для обмена данными с драйвером EFS она использует порт связи LPC, существующий между Локальным администратором безопасности (Local Security Authority, LSA) и монитором безопасности, работающим в привилегированном режиме. В режиме пользователя для создания ключей шифрования файлов и генерирования данных для DDF и DRF служба EFS использует CryptoAPI. Она также поддерживает набор API для Win32.

Набор API для Win32. Этот набор интерфейсов прикладного программирования позволяет выполнять шифрование файлов, дешифрование и восстановление зашифрованных файлов, а также их импорт и экспорт (без предварительного дешифрования). Эти API поддерживаются стандартным системным модулем DLL — advapi32.dll.

Архивация зашифрованных файлов

Архивация зашифрованных файлов


Резервную копию зашифрованного файла можно создать с помощью простого копирования его на другой жесткий диск или с использованием утилиты архивации. Однако, как сказано в предыдущем разделе, простое копирование, например, на дискету или оптический диск может привести к тому, что резервная копия будет содержать открытые данные. То есть, если скопировать зашифрованный файл в FAT-раздел или на дискету, копия будет не зашифрована и, следовательно, доступна для чтения любому пользователю.
Специализированная операция архивации не требует для ее выполнения доступа к открытым ключам пользователя — только к архивируемой информации. Поэтому для обеспечения безопасности конфиденциальных данных при создании резервных копий рекомендуется применять специальные утилиты архивации. Для этих целей предназначена стандартная утилита архивации данных Backup.
В процессе архивации зашифрованные данные будут скопированы на указанный носитель без дешифрования. Целевой носитель может не поддерживать NTFS 5.0. Например, резервная копия зашифрованных файлов может быть создана на гибком диске.

Аутентификация Kerberos в доменах Active Directory

Аутентификация Kerberos в доменах Active Directory


По мере роста и усложнения компьютерных сетей предприятия, построенных на основе систем Windows, становится необходимым применение протокола, обеспечивающего более совершенную и надежную аутентификацию пользователей при доступе к распределенным ресурсам. В операционных системах Windows 2000 для этих целей начат применяться протокол аутентификации Kerberos версии 5, входящий в систему безопасности доменов Windows 2000, тесно интегрированную с Active Directory. Реализация протокола Kerberos версии 5 в Windows 2000 основана на RFC 1510. Этот документ широко обсуждался и корректировался многими организациями, работающими в области создания и применения защищенных средств передачи информации по компьютерным сетям. Аутентификация Kerberos полностью отвечает требованиям к протоколам подобного назначения и позволяет создать высокопроизводительную и защищенную сеть предприятия. Программное обеспечение Kerberos, созданное Microsoft, поддерживает всех клиентов, удовлетворяющих RFC 1510. Однако полную поддержку сетей Windows 2000 осуществляет только клиент Kerberos, разработанный Microsoft, поскольку версия Kerberos Microsoft обладает рядом расширений.
Системы Windows Server 2003 в полной мере используют все средства распределенной безопасности, внедренные в Windows 2000. Протокол Kerberos интегрирован в существующую модель распределенной безопасности Windows 2000/Server 2003. В этих системах используются расширения протокола Kerberos — так же, как и другие архитектуры безопасности, например ОСЕ и SESAME. Протокол Kerberos — один из протоколов безопасности, поддерживаемых Windows 2000/Server 2003. Кроме него, поддерживаются протоколы NTLM для совместимости с предыдущими версиями, SSL и стандарт IETF безопасности транспортного уровня. В качестве механизма безопасности применяется протокол защищенных переговоров (Simple Protected Negotiation, SPNEGO). Для обеспечения безопасности передачи данных на сетевом уровне применяется технология IP Security (IPSec).

Аутентификация

Аутентификация


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

аутентификация пользователя для защищенного веб-узла посредством протоколов Transport Layer Security (TLS) или Secure Sockets Layer (SSL);

аутентификация сервера для пользователя посредством TLS.

Безопасность IP (IPSec)

Безопасность IP (IPSec)


Средства безопасности протокола IP позволяют управлять защитой всего IP-трафика от источника информации до ее получателя. Возможности технологии IP Security Management (Управление безопасностью IP) в Windows Server 2003 позволяют назначать и применять политику безопасности IP, которая гарантирует защищенный обмен информацией для всей сети. Механизм безопасности IP представляет собой прозрачную для пользователя реализацию протокола безопасности IP (IP Security, IPSec), причем администрирование безопасности централизовано и совмещает гарантии безопасного обмена информацией с легкостью применения.
Потребность в защите сетей, основанных на протоколе IP, достаточно велика и растет с каждым годом. В настоящее время в тесно взаимосвязанном деловом мире сетей Интернет, интранет, экстранет (extranet — корпоративная сеть, части которой связаны через открытые сети, например, через Интернет), филиалов и удаленного доступа по сетям передается важная информация, конфиденциальность которой нельзя нарушать. Одним из основных требований, предъявляемых к сети со стороны сетевых администраторов и прочих профессионалов, обслуживающих и использующих сети, является требование гарантии, что этот трафик будет защищен от:

доступа субъектов, не имеющих на это прав;

перехвата, просмотра или копирования;

модификации данных во время пути по сети.

Эти проблемы характеризуются такими показателями, как целостность данных, конфиденциальность и подлинность. Кроме того, защита от повторного использования (replay protection) предотвращает принятие повторно посланного пакета.

Реализация безопасности IP в Windows Server 2003 основана на стандартах RFC, разработанных консорциумом Internet Engineering Task Force (IETF), рабочей группой IP Security (IPSEC).

Центр сертификации

Центр сертификации


Центр сертификации (ЦС), или поставщик сертификатов (Certificate Authority, CA), — это организация или служба, создающая сертификаты. ЦС выступает в качестве гаранта истинности связи между открытым ключом субъекта и идентифицирующей этот субъект информацией, содержащейся в сертификате. Различные ЦС могут применять для проверки связи различные средства, поэтому перед выбором достойного доверия ЦС важно хорошо понять политику данного ЦС и применяемые им процедуры проверки.

Центры сертификации

Центры сертификации


Центр сертификации (также встречается термин поставщик сертификатов) (Certification Authority, CA) представляет собой службу, которой доверен выпуск сертификатов, если индивидуальный пользователь или организация, которые запрашивают сертификат, удовлетворяют условиям установленной политики. Это осуществляется путем принятия запроса на получение сертификата, проверки и регистрации имени запрашивающего сертификат пользователя и открытого ключа в соответствии с политикой. Каждый ЦС должен получить от запрашивающей сертификат стороны подтверждение ее идентичности, такое как удостоверение личности или физический адрес. Затем производится подписание и назначение сертификата, подтверждающего выполнение пользователем критериев политики, которые были установлены для авторизации. Большинство используемых на .сегодня сертификатов основаны на стандарте Х.509, эта фундаментальная технология применяется в инфраструктуре открытых ключей Windows 2000 и Windows Server 2003.
Центром сертификации может быть удаленная организация, такая как VeriSign, или локальная служба, созданная в вашей организации путем инсталляции служб Certificate Services (Служб сертификации). Выбор ЦС основывается на доверительном отношении (trust). Вы доверяете, что ЦС использует правильную политику при рассмотрении запросов на подписание сертификатов. Кроме того, вы доверяете, что ЦС отзывает сертификаты с истекшим сроком действия путем публикации списка отозванных сертификатов (certificate revocation list).
Центры сертификации также имеют собственные сертификаты. Причем вышестоящий центр подписывает сертификаты для нижестоящих центров. Таким образом, формируется иерархия сертификатов (certificate hierarchy).
Доверие центру сертификации устанавливается при наличии копии корневого сертификата в хранилище доверяемых корневых центров сертификации, а также действительного пути к сертификату. Это означает, что ни один из сертификатов иерархии (пути сертификатов) не был отозван и не имеет истекшего срока действия.
Если в организации используется Active Directory, то доверие к центрам сертификации вашей организации устанавливается автоматически на основе решений и установок, выполненных системным администратором.
Сертификат удостоверяет, что индивидуальный пользователь или ЦС, представляющий сертификат, был авторизован в соответствии с политикой, которая была установлена для ЦС, выпустившего сертификат. Обычно сертификаты содержат следующую информацию:

открытый ключ (public key) владельца сертификата;

идентификационную информацию владельца сертификата;

период действия сертификата;

информацию о центре сертификации;

цифровую подпись (digital signature).

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

центр сертификации предприятия (enterprise certification authority). Требует наличия Active Directory. Использует информацию, доступную в Active Directory, для проверки идентификационной информации запрашивающего сертификат. Публикует списки отозванных сертификатов в Active Directory, а также в общей папке;

изолированный (автономный) центр сертификации (stand-alone certification authority). He зависит от Active Directory. По умолчанию пользователи могут запрашивать сертификаты у данного центра только с веб-страниц. Изолированный центр сертификации публикует списки отозванных сертификатов в общей папке или в Active Directory (если служба каталогов доступна).

Что такое сертификат

Что такое сертификат


Сертификат — это средство, позволяющее гарантированно установить связь между переданным открытым ключом и передавшей его стороной, владеющей соответствующим личным ключом. Сертификат представляет собой набор данных, зашифрованных с помощью цифровой, или электронной, подписи. Информация сертификата подтверждает истинность открытого ключа и владельца соответствующего личного ключа.
Обычно сертификаты содержат дополнительную информацию, позволяющую идентифицировать владельца личного ключа, соответствующего данному открытому ключу. Сертификат должен быть подписан авторизованным генератором сертификатов.
Наиболее распространенным на данный момент стандартом сертификатов является ITU-T X.509. Эта фундаментальная технология применяется в Windows 2000 и Windows Server 2003. Однако это не единственная форма сертификатов.

Цифровые (электронные) подписи

Цифровые (электронные) подписи


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

только владелец секретного ключа может создать цифровую подпись;

любой пользователь, обладающий соответствующим открытым ключом, может проверить истинность цифровой подписи;

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

Цифровые подписи гарантируют целостность (integrity) и подлинность (nonrepudiation) данных. Когда данные распространяются открытым текстом (без шифрования), получатели должны иметь возможность проверки, что данные в сообщении не были изменены.
Добавление подписи не изменяет содержания данных: в этом случае генерируется цифровая подпись, которая может быть связана с данными или передаваться отдельно.
Для выполнения этой операции клиентская программа создает дайджест, снимок данных, используя метод хэширования (например, MDS). Программа использует ваш личный ключ для шифрования дайджеста и подписывает данные или сообщение с помощью вашего сертификата, добавляя ваш открытый ключ. Соответствующая программа адресата сообщения использует открытый ключ для расшифровки дайджеста, затем использует тот же алгоритм хэширования для создания другого дайджеста данных. Данная программа затем сравнивает два дайджеста сообщений. Если они идентичны, то подтверждаются целостность и подлинность данных сообщения.

Данное окно позволяет выбрать

Рисунок 22.9. Данное окно позволяет выбрать пользователя и просмотреть его сертификат


Зашифровав файл или папку и открыв заново окно Encryption Details (Подробности шифрования), вы можете легко проверить, определен ли в вашей системе агент восстановления.
Теперь можно нажать кнопку Add (Добавить) и в окне Select User (Выбор пользователя) (Рисунок 22.9) указать, какие пользователи смогут также работать с зашифрованным файлом. Окно Select User позволяет просмотреть имеющиеся сертификаты пользователей и искать пользователей в каталоге Active Directory.

Дешифрование файлов и каталогов

Дешифрование файлов и каталогов


Чтобы дешифровать файл или каталог:
1. На вкладке Sharing окна свойств соответствующего объекта нажмите кнопку Advanced.
2. В открывшемся диалоговом окне в группе Compress or Encrypt attributes сбросьте флажок Encrypt contents to secure data.

Достоинства IP Security

Достоинства IP Security


Сетевые атаки могут привести к неработоспособности системы, считыванию конфиденциальных данных и другим дорогостоящим нарушениям. Для защиты информации требуются методы "сильного" шифрования и сертификации, основанные на криптографических алгоритмах. Однако высокий уровень безопасности не должен ухудшать производительность труда пользователей или увеличивать затраты на администрирование.
IP Security в системах Windows 2000 и Windows Server 2003 обеспечивает следующие преимущества, которые помогают достичь высокого уровня безопасности взаимодействия при низких затратах.

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

Прозрачность безопасности IP для пользователей и прикладных программ. Не нужно иметь отдельные программные средства безопасности для каждого протокола в стеке TCP/IP, поскольку приложения, использующие TCP/IP, передают данные уровню протокола IP, где они шифруются. Установленная и настроенная служба IPSec прозрачна для пользователя и не требует обучения.

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

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

Туннелирование. Данные могут быть посланы через безопасные туннели для обмена информацией в Интернете и корпоративных сетях.

Усиленная служба аутентификации, которая предотвращает перехват данных путем подмены идентификаторов.

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

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

Безопасная связь между пользователями в любом домене корпоративной сети, основанной на протоколе IP.

Отраслевой стандарт IPSec открыт для реализации других технологий шифрования IP, что позволяет взаимодействовать с другими платформами и продуктами.

Сертификаты с -открытым ключом и поддержка ключей pre-shared (заранее известных). Это требуется для разрешения установления безопасной связи с компьютерами, которые не являются частью доверенного домена.

IPSec работает во взаимодействии с другими механизмами защиты, сетевыми протоколами и базовыми механизмами безопасности операционной системы.

Поддерживается шифрование сообщений RSVP для реализации служб QoS и ACS, т. е. IPSec не мешает использовать все преимущества приоритетного управления шириной полосы пропускания, обеспечиваемые этими службами.

Возможности стандарта IPSec и подробности реализации очень сложны и описаны подробно в ряде RFC и проектов IETF, а также в документах Microsoft. IPSec использует криптографическую защиту для обеспечения управления доступом, целостности без установления логического соединения, удостоверения подлинности данных, защиты от повторного использования, полной и ограниченной конфиденциальности потока данных. Поскольку протокол IPSec работает на уровне IP, его услуги доступны протоколам верхнего уровня в стеке и, очевидно, существующим приложениям.
IPSec дает системе возможность выбрать протоколы защиты, решить, какой (какие) алгоритм(ы) использовать для служб(ы), а также устанавливать и поддерживать криптографические ключи для каждой защищенной связи.
IPSec может защищать пути между компьютерами, между шлюзами защиты или между шлюзами защиты и компьютерами. Услуги, доступные и требуемые для трафика, настраиваются с использованием политики IPSec. Политика IPSec может быть настроена локально на отдельном компьютере или может быть назначена через механизм групповых политик в Active Directory. Политика IPSec определяет, как компьютеры доверяют друг другу. Самое простое — полагаться на применение доменов доверия Active Directory, основанных на протоколе Kerberos. Для того чтобы доверять компьютерам в том же самом или в другом доверенном домене, задается предопределенная политика IPSec.
Каждая датаграмма на уровне протокола IP сравнивается с набором фильтров, предоставляемых политикой безопасности, которая поддерживается администратором для компьютера, пользователя, организационной единицы (OU) или всего домена. С любой датаграммой службы IP могут выполнить одно из трех действий:

передать на обработку службам IPSec;

передать ее без изменений;

игнорировать ее.

Установка IPSec включает описание характеристик трафика для фильтрации (IP-адрес источника/адресата, протокол, порт и т. д.) и определение того, какие механизмы требуется применить для трафика, соответствующего фильтру (фильтрам). Например, в очень простом случае два автономных компьютера могут быть сконфигурированы для использования IPSec между ними в одном и том же домене Active Directory и активизации политики блокировки (lockdown). Если два компьютера — не элементы одного и того же или доверенного домена, то доверие должно быть сконфигурировано с использованием пароля или ключа pre-shared в режиме "закрытый". Для этого выполняются операции:

установка фильтра, который определяет весь трафик между двумя компьютерами;

выбор метода опознавания (выбор ключа pre-shared или ввод пароля);

выбор политики переговоров (в режиме "закрытый", при этом весь трафик, соответствующий фильтру (фильтрам), должен использовать IPSec);

определение типа подключения (ЛВС, коммутируемое соединение или оба типа подключения).

Применение политики блокировки также ограничит все другие типы трафика от достижимых адресатов, которые не понимают IPSec или не являются частью той же самой доверенной группы. Безопасная политика инициатора обеспечивает установки, применяемые лучше всего к тем серверам, для которых предпринята защита трафика, но если клиент "не понимает" IPSec, то результатом переговоров будет возобновление посылки "чистых" текстовых пакетов.
Когда IPSec применяется для шифрования данных, производительность сети понижается из-за непроизводительных затрат на обработку и шифрование. Один из возможных методов уменьшения воздействия этих непроизводительных затрат — обработка на аппаратном уровне. Поскольку интерфейс NDIS 5.1 поддерживает такую функцию, можно включить аппаратные средства шифрования в сетевой адаптер. Адаптер, обеспечивающий перегрузку IPSec на аппаратные средства, скоро представят на рынке несколько поставщиков аппаратного обеспечения.

Функционирование агента политики безопасности

Рисунок 22.3. Функционирование агента политики безопасности

Служба управления ключами ISAKMP/Oakley

Это локальный, резидентный агент, который получает политику безопасности от агента политики. При использовании политики безопасности служба ISAKMP устанавливает ассоциацию безопасности (SA) с компьютером-получателем. Тождество поддерживающих связь сторон опознается с помощью центра распределения ключей Kerberos. В заключение служба ISAKMP посылает SA и информацию о ключе драйверу IPSec. Служба ISAKMP/Oakley запускается агентом политики.

Драйвер безопасности IP (IPSec-драйвер)

Это локальный, резидентный агент, который просматривает все IP-пакеты на соответствие фильтру IP. Если он находит соответствие, то задерживает пакеты в очереди, в то время как служба ISAKMP/Oakley генерирует необходимую SA и ключ, чтобы защитить обмен информацией. Агент, получив эту информацию от службы ISAKMP, шифрует IP-пакеты и посылает их компьютеру-адресату (Рисунок 22.4). Драйвер IPSec запускается агентом политики.

Функционирование драйвера IPSec

Рисунок 22.4. Функционирование драйвера IPSec


Все три перечисленные компонента установлены в Windows Server 2003 по умолчанию и запускаются автоматически.

Каждый контроллер домена содержит Центр распространения ключей Kerberos (Kerberos Distribution Center, KDC) для установления подлинности, который конфигурируется сетевым администратором. Протокол Kerberos служит третьим доверенным лицом, которое проверяет подлинность поддерживающей связь стороны. Безопасность IP в Windows Server 2003 использует Kerberos для идентификации компьютеров.
Рассмотрим пример, в котором пользователь Компьютера А (Пользователь 1) посылает данные пользователю Компьютера В (Пользователю 2). Безопасность IP установлена на обоих компьютерах.

Хранилища сертификатов

Хранилища сертификатов


Операционная система сохраняет сертификаты локально на том компьютере, с которого запрашивался сертификат для данного компьютера или для пользователя, работающего за данным компьютером. Место хранения сертификатов называется хранилищем сертификатов (certificate store).
С помощью оснастки Certificates (Сертификаты) (Рисунок 22.10) можно просматривать хранилища сертификатов для пользователя, компьютера или сервиса (службы), в которых сертификаты можно сортировать. Режим сортировки определяется переключателями в окне View Options (Параметры просмотра), которое вызывается с помощью команды View | Options (Вид Параметры). Переключатель Certificate purpose определяет режим просмотра сертификатов по назначению, а переключатель Logical certificate stores — по логическим хранилищам. В табл. 22.1 перечислены некоторые основные папки, которые отображаются в окне оснастки Certificates в разных режимах просмотра.

Оснастка Certificates отсутствует в пользовательском интерфейсе системы, поэтому ее нужно подключить вручную к консоли ММС. Процедура создания инструмента ММС описана в разд. "Создание новой консоли" главы 6 "Средства управления системой".

Импорт и экспорт сертификатов

Импорт и экспорт сертификатов


При импорте или экспорте сертификат копируется в хранилище или из хранилища. Импорт или экспорт сертификата проводится при выполнении следующих задач:

инсталляция сертификата, полученного вами от другого пользователя (импорт);

восстановление сертификата, который хранился в виде резервной копии (импорт);

создание резервной копии сертификата (экспорт);

копирование сертификата или ключа для использования на другом компьютере (экспорт).

Передавать сертификаты можно в следующих форматах.

Personal Information Exchange (Обмен персональной информацией) (PKCS #12)

Данный формат (Personal Information Exchange, PFX) позволяет приложениям передавать сертификаты и соответствующие личные ключи с одного компьютера на другой, на съемный накопитель или смарт-карту.
PKCS #12 является стандартным в отрасли форматом, применяемым для передачи или резервного копирования и восстановления сертификатов и их ключей. Сертификаты в этом формате могут передаваться между продуктами одного или различных производителей, например, Microsoft и IBM. Для использования формата PKCS #12 поставщик услуг шифрования (CSP) должен считать сертификаты и ключи доступными для экспорта.
Экспорт личного ключа — рискованная операция, поскольку ключом могут завладеть посторонние лица. Поэтому PKCS #12 является единственным форматом, который Microsoft поддерживает для экспорта сертификатов и связанных с ними личных ключей.

Cryptographic Message Syntax Standard (Криптографический стандарт на синтаксис сообщений) (PKCS #7)

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

DER Encoded Binary X.509

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

Base64 Encoded X. 509

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

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

Интегрированная аутентификация Kerberos

Интегрированная аутентификация Kerberos


В Windows Server 2003 аутентификация Kerberos реализована на уровне доменов, что позволяет выполнять одну регистрацию в системе при доступе ко всем ресурсам сети и поддерживать модель распределенной безопасности Windows Server 2003. На любом участке дерева доменов Active Directory протокол Kerberos обеспечивает взаимную аутентификацию, ускоренную аутентификацию и транзитное доверие на аутентификацию. Аутентификация Kerberos в Windows Server 2003 используется для выполнения интерактивной регистрации пользователя в домене. Расширение стандартной аутентификации Kerberos для применения открытого ключа позволяет применять регистрацию в Windows Server 2003 с помощью смарт-карты. Протокол Kerberos реачизован в виде поставщика безопасности, доступ к которому осуществляется с применением интерфейса поддержки поставщика безопасности (Security Support Provider Interface, SSPI).
Поставщик безопасности Kerberos используется клиентом и сервером SMB (Server Message Block). Он также доступен для DCOM, авторизованного RPC и любого протокола, использующего SSPI для обеспечения безопасности информации, передаваемой по сети. SSPI — это интерфейс безопасности Win32, который существует в составе Windows NT, начиная с версии 3.5. Он также поддерживается в Windows 95/98. В SSPI применяются те же архитектурные концепции, что и в наборе программных вызовов общих служб безопасности (Generic Security Services API, GSS-API), соответствующих RFC 1964. SSPI позволяет освободить приложения от непосредственного взаимодействия с протоколами сетевой безопасности.
В системах Windows 2000 и Windows Server 2003 реализован Центр распространения ключей Kerberos (Kerberos Key Distribution Center, KDC). На каждом контроллере домена помимо службы Active Directory имеется служба KDC, выполняющаяся вместе с Active Directory как процесс в привилегированном режиме. Оба процесса осуществляют управление жизненно важной информацией, включая пароли учетных записей пользователей. Active Directory выполняет автоматическую репликацию служебной информации на всех контроллерах домена. Поэтому создавать новые учетные записи пользователей, настраивать членство пользователей в группах или переустанавливать пароли можно на любом контроллере домена. Это означает, что в отличие от Windows NT 4,0, где изменить административную информацию можно было только на главном контроллере домена (Primary Domain Controller, PDC) с последующим обновлением доступных только для чтения реплик на резервных контроллерах домена (Backup Domain Controller, BDC), в доменах Active Directory можно изменять любую реплику каталога, хранящуюся на некотором контроллере домена.
Клиенты и серверы используют протокол Kerberos для взаимной аутентификации. Запрос Kerberos содержит билет сеанса и аутентификатор, получаемый в КDС и позволяющий исключить возможность подмены билета сеанса. Поставщик безопасности Kerberos на стороне клиента интегрируется с локальным администратором безопасности, поддерживающим локальный кэш билетов. При инициализации клиентом контекста безопасности поставщик безопасности Kerberos считывает билет сеанса, соответствующий целевой службе, или запрашивает новый билет сеанса в КОС. Сообщение запроса Kerberos, созданного поставщиком безопасности Kerberos, соответствует форматам маркера механизма GSS KerbS, описанным в RFC 1964. Клиенты могут аутентифицироваться для любой службы домена или доверенного владения, поддерживающего механизм GSS. Поставщик безопасности Kerberos может воспринять запрос Kerberos, который сгенерирован любым клиентом, поддерживающим форматы маркера в стандарте GSS, RFC 1964.
Такой уровень взаимодействия позволяет осуществлять поддержку традиционной аутентификации Kerberos, основанной на именах, в многоплатформ-ных средах. Для имперсонализации и управления доступом в рамках принятой модели распределенной безопасности системным службам достаточно данных авторизации, находящихся в билете сеанса.

Использование сертификатов для обеспечения безопасности

Использование сертификатов для обеспечения безопасности


Сертификаты можно использовать для решения различных задач безопасности.

Аутентификация (authentication) или проверка подлинности. Проверка того, что объект, с которым вы взаимодействуете, является в действительности авторизованным объектом.

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

Шифрование (encryption). Обеспечивает доступ к информации только для того пользователя, которому она предназначена.

Цифровые подписи (digital signatures). Обеспечение целостности и подлинности данных.

Использование сертификатов в Интернете

Использование сертификатов в Интернете


При работе в Интернете браузер Internet Explorer использует два типа сертификатов: персональный сертификат (personal certificate) и сертификат веб-узла (Web site certificate). Персональный сертификат удостоверяет личность пользователя. Информация сертификата используется при передаче личной информации через Интернет на веб-узел, который требует проверки пользователя посредством сертификата. Сертификат веб-узла подтверждает, что данный узел является безопасным и подлинным. При этом гарантируется, что никакой другой веб-узел не является идентичным оригинальному веб-узлу. Internet Explorer при подключении к веб-узлу проверяет, что интернет-адрес в сертификате совпадает с действительным адресом и срок действия сертификата еще не истек.

Ключи

Ключи


Для обеспечения безопасности данных в криптографии совместно с алгоритмами используются ключи. Ключ — это некоторое значение, применяемое для шифрования или дешифрования информации. Для шифрования в системах безопасности могут использоваться как закрытые, так и открытые ключи. Даже если алгоритм известен, без ключа данные нельзя просмотреть или изменить. Безопасность IP в Windows Server 2003 использует ключи большой длины, чтобы обеспечить повышенную безопасность. Если длину ключа увеличить на один бит, число возможных комбинаций удваивается. Безопасность IP в Windows Server 2003 также применяет динамическое обновление ключей; это означает, что после определенного интервала для продолжения обмена данными генерируется новый ключ. Такое решение позволяет защититься от злоумышленника, который получил доступ к части информации во время ее передачи.

Компоненты Windows Server 2003 обеспечивающие шифрование

Компоненты Windows Server 2003, обеспечивающие шифрование


На Рисунок 22.1 схематично показана логическая взаимосвязь средств Windows 2000, позволяющих применять шифрование с открытым ключом.
Изображенные на Рисунок 22.1 средства необязательно должны размещаться на отдельных компьютерах. Несколько служб могут эффективно работать на одном компьютере. Ключевое звено схемы — службы сертификатов Microsoft (Microsoft Certificate Services). Они позволяют создать один или несколько ЦС предприятия, поддерживающих создание и отзыв сертификатов. Они интегрированы в Active Directory, где хранится информация о политике ЦС и их местоположении. Кроме того, с помощью Active Directory выполняется публикация информации о сертификатах и их отзыве. Средства работы с открытым ключом не заменяют существующих механизмов доверительных отношений между доменами и аутентификации, реализованных с помощью контроллеров доменов и центров распространения ключей Kerberos (Key Distribution Center, KDC). Напротив, данные средства взаимодействуют с этими службами, что позволяет приложениям безопасно передавать конфиденциальную информацию через Интернет и корпоративным глобальным каналам.

Конфиденциальность

Конфиденциальность


Для обеспечения конфиденциальности при передаче данных в незащищенных сетях или по частным локальным сетям применяется шифрование с секретным, или закрытым, ключом (secret key encryption).
Сертификаты обеспечивают конфиденциальность передаваемых данных при помощи ряда методов. Протоколы, наиболее широко используемые для обеспечения секретности:

Secure Multipurpose Internet Mail Extensions (S/MIME);

Transport Layer Security (TLS);

IP Security (IPSec).

Копирование перемещение переименование

Копирование, перемещение, переименование и уничтожение зашифрованных файлов и папок


Операции копирования, перемещения, переименования и уничтожения зашифрованных файлов и папок выполняются точно так же, как и с незашифрованными объектами. Однако следует помнить, что пункт назначения зашифрованной информации должен поддерживать шифрование (должен иметь файловую систему NTFS 5.0). В противном случае при копировании данные будут расшифрованы, и копия будет содержать открытую информацию.

Модель распределенной безопасности Windows Server

Модель распределенной безопасности Windows Server 2003

Модель распределенной безопасности Windows Server 2003 основана на трех основных концепциях.

Каждая рабочая станция и сервер имеют прямой доверенный путь (trust path) к контроллеру домена, членом которого является данная машина. Доверенный путь устанавливается службой NetLogon с помощью аутентифицированного соединения RPC с контроллером домена. Защищенный канал устанавливается и с другими доменами с помощью междоменных доверительных отношений. Этот канал используется для проверки информации безопасности, включая идентификаторы безопасности (Security Identifiers, SID) пользователей и групп.

Перед выполнением запрошенных клиентом операций сетевые службы имперсонализируют контекст безопасности этого клиента. Имперсонализация основана на маркере адреса безопасности, созданном локальным администратором безопасности (Local Security Authority, LSA). Он представляет собой авторизацию клиента на сервере. Поток, находящийся на сервере и соответствующий данному клиенту, имперсонализирует контекст безопасности клиента и выполняет операции в соответствии с авторизацией данного клиента, а не в соответствии с идентификатором безопасности сервера. Имперсонализация поддерживается всеми службами Windows Server 2003, включая, например, службу удаленного файлового сервера CIFS/SNB. Аутентифицированный RPC и DCOM поддерживают имперсонализацию для распределенных приложений. Серверы семейства BackOffice: Exchange Server, SNA Server и Internet Information Server также поддерживают имперсонализацию.

Ядро Windows Server 2003 поддерживает объектно-ориентированное управление доступом, сравнивая SID в маркере доступа с правами доступа, определенными в списке управления доступом данного объекта. Каждый объект Windows Sewer 2003 (ключи реестра, файлы и каталоги NTFS, общие ресурсы, объекты ядра, очереди печати и т. д.) имеют собственные списки управления доступом. Ядро Windows Server 2003 проверяет разрешения при каждой попытке доступа к данному объекту. Управление доступом и аудит осуществляются с помощью настройки свойств безопасности объекта, позволяющих предоставить пользователю или группе доступ к объекту. Управление авторизацией выполняется централизованно посредством включения пользователей в локальные группы системы, которым предоставлены необходимые права доступа.

В операционной системе Windows Server 2003 существуют дополнительные средства обеспечения безопасности — аутентификация клиента с помощью открытого ключа посредством SSL/TLS и протокола Kerberos версии 5, которые интегрированы в систему безопасности.

Обеспечение истинности открытых ключей

Обеспечение истинности открытых ключей


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

Общие понятия безопасности

Общие понятия безопасности

Аутентификация (проверка подлинности). Это процесс надежного определения подлинности поддерживающих связь компьютеров. Аутентификация основана на методах криптографии, и это гарантирует, что нападающий или прослушивающий сеть не сможет получить информацию, необходимую для рассекречивания пользователя или другого объекта. Аутентификация позволяет поддерживающему связь объекту доказать свое тождество другому объекту без пересылки незащищенных данных по сети. Без "сильной" (strong) аутентификации и поддержания целостности данных любые данные и компьютер, который их послал, являются подозрительными.

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

Конфиденциальность (privacy). Гарантия того, что данные будут раскрыты только тем получателем, которому они были предназначены. Это свойство не является обязательным.

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

Окно оснастки Certificates

Рисунок 22.10. Окно оснастки Certificates

Окно оснастки Certification Authority

Рисунок 22.11. Окно оснастки Certification Authority

Основные понятия

Основные понятия


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

проверка личности на факт соответствия некоторым индивидуальным характеристикам человека (проверка отпечатков пальцев, снимков радужки глаза, код ДНК и т. д.). Для применения этой группы методов аутентификации необходимо задействовать специальное оборудование;

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

При реализации метода аутентификации, базирующегося на проверке факта знания некоторого секрета, необходимо решить следующие вопросы:

каким образом клиент будет получать информацию о секрете?

каким образом клиент будет предоставлять серверу аутентификации информацию о своих полномочиях?

каким образом клиент будет проверять полномочия сервера?

каким образом сервер сможет убедиться в том, что полномочия, предоставленные клиентом, подлинные?

каким образом будет обеспечиваться безопасность взаимодействия сервера и клиента в ходе проверки полномочий?

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

В процедуре аутентификации участвуют три стороны;

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

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

сервер, хранящий информацию о секретах всех клиентов. В терминологии Kerberos этот сервер получил название Центра распределения ключей (Key Distribution Center, KDC). Центр распределения ключей берет на себя роль посредника между серверами и их клиентами. Каждое подключение должно иметь уникальный секрет, поскольку к любому серверу может обращаться произвольное число пользователей. Центр распределения ключей решает эту задачу, обеспечивая каждое подобное подключение собственным уникальным секретом, известным только клиенту и серверу.

Протокол Kerberos представляет собой набор методов идентификации и проверки истинности партнеров по обмену информацией (рабочих станций, пользователей или серверов) в открытой (незащищенной) сети. Процесс идентификации не зависит от аутентификации, выполняемой сетевой операционной системой, не основывается в принятии решений на адресах хостов и не предполагает обязательную организацию физической безопасности всех хостов сети. Кроме того, допускается, что пакеты информации, передаваемые по сети, могут быть изменены, прочитаны и переданы в любой момент времени.
Следует, однако, отметить, что большинство приложений использует функции протокола Kerberos только при создании сеансов передачи потоков информации. При этом предполагается, что последующее несанкционированное разрушение потока данных невозможно. Поэтому применяется прямое доверие, основанное на адресе хоста. Kerberos выполняет аутентификацию как доверенная служба третьей стороны, используя шифрование с помощью общего секретного ключа (shared secret key).
Аутентификация выполняется следующим образом:
1. Клиент посылает запрос серверу аутентификации (Authentication Server, AS) на информацию, однозначно идентифицирующую некоторый нужный клиенту сервер.
2. Сервер AS передает требуемую информацию, зашифрованную с помощью известного пользователю ключа. Переданная информация состоит из билета сервера и временного ключа, предназначенного для шифрования (часто называемого ключом сеанса).
3. Клиент пересылает серверу билет, содержащий идентификатор клиента и ключ сеанса, зашифрованные с помощью ключа, известного серверу.
4. Теперь ключ сеанса известен и клиенту, и серверу. Он может быть использован для аутентификации клиента, а также для аутентификации сервера. Ключ сеанса можно применять для шифрования передаваемой в сеансе информации или для взаимного обмена ключами подсеанса, предназначенными для шифрования последующей передаваемой информации.
Протокол Kerberos функционирует на одном или нескольких серверах аутентификации, работающих на физически защищенном хосте. Серверы аутентификации ведут базы данных партнеров по обмену информацией в сети (пользователей, серверов и т. д.) и их секретных ключей. Программный код, обеспечивающий функционирование самого протокола и шифрование данных, находится в специальных библиотеках. Для того чтобы выполнять аутентификацию Kerberos для своих транзакций, приложения должны сделать несколько обращений к библиотекам Kerberos. Процесс аутентификации состоит из обмена необходимыми сообщениями с сервером аутентификации Kerberos.
Протокол Kerberos состоит из нескольких субпротоколов (или протоколов обмена сообщениями). Существует два метода, которыми клиент может запросить у сервера Kerberos информацию, идентифицирующую определенный сервер. Первый способ предполагает, что клиент посылает AS простой текстовый запрос билета для конкретного сервера, а в ответ получает данные, зашифрованные с помощью своего секретного ключа. Как правило, в данном случае клиент посылает запрос на билет, позволяющий получить билет (Ticket Granting Ticket, TGT), который в дальнейшем используется для работы с выдающим билеты сервером (Ticket Granting Server, TGS). Второй способ предполагает, что клиент посылает TGT-билеты на TGS-сервер так же, как будто он обменивается информацией с другим сервером приложений, требующим аутентификации Kerberos.
Информация, идентифицирующая сервер, может быть использована для идентификации партнеров по транзакции, что позволит гарантировать целостность передаваемых между ними сообщений или сохранить в секрете передаваемую информацию.
Для идентификации партнеров по транзакции клиент посылает билет на сервер. Поскольку посылаемый билет "открыт" (некоторые его части зашифрованы, но они не помешают выполнить посылку копии) и может быть перехвачен и использован злоумышленником, для подтверждения истинности партнера, пославшего билет, передается дополнительная информация, называемая аутентификатором. Она зашифрована с помощью ключа сеанса и содержит отсчет времени, подтверждающий, что сообщение было сгенерировано недавно и не является копией оригинальной посылки. Шифрование аутентификатора с помощью ключа сеанса доказывает, что информация была передана истинным партнером по обмену данными. Поскольку, кроме запрашивающего партнера и сервера, никто не знает ключ сеанса (он никогда не посылается по сети в открытом виде), с его помощью можно полностью гарантировать истинность партнера.
Целостность сообщений, которыми обмениваются партнеры, гарантируется с помощью ключа сеанса (передается в билете и содержится в информации идентификации партнера). Этот подход позволяет обнаружить атаки типа посылки злоумышленником перехваченной копии запроса и модификации потока данных. Это достигается генерированием и пересылкой контрольной суммы (хэш-функции) сообщения клиента, зашифрованной с помощью ключа сеанса. Безопасность и целостность сообщений, которыми обмениваются партнеры, может быть обеспечена шифрованием передаваемых данных с помощью ключа сеанса, передаваемого в билете и содержащегося в информации идентификации партнера.
Описанная выше аутентификация требует доступа на чтение к базе данных Kerberos. Однако иногда записи базы данных могут быть модифицированы. Это происходит, например, при добавлении новых партнеров по обмену информацией или при изменении секретного ключа партнера. Изменения базы данных выполняются с помощью специального протокола обмена между клиентом и сервером Kerberos, применяющимся и при поддержке нескольких копий баз данных Kerberos.
Для нормальной работы протокола Kerberos необходимо, чтобы каждый хост сети имел часы, которые были приблизительно синхронизированы с часами других хостов. Синхронизация необходима, чтобы было легче обнаружить факт передачи копии заранее перехваченного сообщения. Степень приблизительности синхронизации может быть установлена индивидуально для каждого сервера. Сам протокол синхронизации серверов сети должен быть защищен от атак злоумышленников.

Политики безопасности

Политики безопасности


Политики безопасности действуют в рамках сайта, домена или контейнера (подразделения, или организационной единицы, OU) и распространяются на группы, компьютеры и пользователей — т. е. на все объекты администрирования. Безопасность шифрования с открытым ключом является одним из аспектов общей политики безопасности Windows 2000/Server 2003 и интегрирована в ее структуру. Это механизм, с помощью которого можно посредством объектов политики безопасности централизованно осуществлять настройку и управление глобальной политикой работы с открытым ключом.
С помощью политики открытого ключа можно определять следующие аспекты безопасности Windows 2000/Server 2003:

доверенные корни ЦС;

процесс регистрации и обновления сертификатов;

регистрация в системе с помощью смарт-карты.

Применение алгоритмов шифрования

Применение алгоритмов шифрования с открытым ключом в Windows Server 2003


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

Аутентификация Kerberos используется многими службами

Применение Kerberos в сетях Windows 2000/Server 2003

Аутентификация Kerberos используется многими службами домена Active Directory. Интерфейс SSPI применяется для аутентификации в большинстве системных служб, поэтому их перевод с аутентификации NTLM на Kerberos требует минимальных усилий. Более сложные изменения необходимы на сервере SMB, который не использовал SSPI до версии Windows 2000. Многие новые распределенные службы Windows 2000 используют аутентификацию Kerberos. Примеры областей применения аутентификации Kerberos в Windows 2000/Server 2003:

аутентификация в Active Directory с применением LDAP для запросов или управления каталогом;

протокол удаленного доступа к файлам CIFS/SMB;

управление распределенной файловой системой DFS;

защищенное обновление адресов DNS;

службы печати;

необязательная взаимная аутентификация IPSec-хостов при работе протоколов ISAKMP/Oakley;

запросы резервирования для службы качества обслуживания (Quality of Service);

аутентификация интрасети в службах Internet Information Services;

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

удаленное управление сервером или рабочей станцией с помощью аутентифицированного RPC и DCOM.

Это первый шаг к основной цели, поставленной в Windows 2000, — полному исключению аутентификации NTLM в компьютерных сетях, основанных на этой операционной системе.

реализации безопасности IP

Рисунок 22.5. Пример реализации безопасности IP


На уровне пользователя процесс доставки IP-пакетов прозрачен. Пользователь 1 просто запускает приложение, которое использует протокол стека TCP/IP, например FTP, и посылает данные Пользователю 2. Политики безопасности, назначенные Компьютеру А и Компьютеру В администратором, определяют уровень безопасности взаимодействия. Они выбираются агентом политики и передаются службе ISAKMP/Oakley и драйверу IPSec. Служба ISAKMP/Oakley на каждом компьютере использует политику переговоров, связанную с назначенной политикой безопасности, чтобы установить ключ и общий метод переговоров (ассоциация безопасности). Результаты переговоров о политике ISAKMP между двумя компьютерами передаются драйверу IPSec, который использует ключ для шифрования данных. В заключение драйвер IPSec посылает шифрованные данные на Компьютер В. Драйвер IPSec на Компьютере В дешифрует данные и передает их приложению-получателю (см. описание процесса на Рисунок 22.5).

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

Протокол аутентификации Kerberos


Протокол аутентификации Kerberos является основным механизмом аутентификации, используемым в среде Windows 2000/Server 2003. Этот протокол был разработан в Массачусетском технологическом институте (Massachusetts Institute of Technology, MIT) в начале 1980-х гг. Существует несколько версий протокола Kerberos. В среде Windows 2000/Server 2003 применяется пятая версия протокола Kerberos, спецификация которого определена в стандарте RFC 1510.

и авторизация Windows Server 2003

Протокол Kerberos и авторизация Windows Server 2003

Имперсонализация Windows Server 2003 требует, чтобы локальный администратор безопасности (LSA) сервера мог безопасно получать SID пользователя и список идентификаторов безопасности членов групп. Идентификаторы безопасности генерируются системой безопасности домена и используются в LSA при создании маркеров доступа для имперсонализации. После создания соединения связанный с ним поток имперсонализирует зарегистрировавшегося пользователя, после чего операционная система сравнивает маркер доступа клиента с ACL объекта, к которому пользователь пытается получить доступ. При аутентификации NTLM идентификаторы безопасности пользователя и группы передаются с помощью защищенного канала Net Logon прямо с контроллера домена или любого доверенного домена. При использовании протокола Kerberos идентификаторы безопасности пользователей и групп передаются в составе данных авторизации билета сеанса Kerberos.
Данные авторизации, находящиеся в билете Kerberos, полученном из КDС, содержат список идентификаторов безопасности пользователей и идентификаторов, определяющих членство в группах. Локальному администратору безопасности данные авторизации нужны для поддержки имперсонализации поставщика безопасности Kerberos.
Протокол Kerberos позволяет обращаться к данным авторизации билета Kerberos, которые определяются приложением. Они полностью соответствуют RFC 1510. Кроме того, их структура преобразована для уменьшения проблем, возникающих при совместной работе с другими операционными системами.
При первоначальной регистрации пользователя в домене КDС помещает в TGT данные авторизации, включающие идентификаторы безопасности пользователей или групп домена учетных записей (account domain). Членство в группах также определяется при первоначальной регистрации. После этого КDС копирует данные авторизации из ТОТ в билеты сеанса, применяемые для аутентификации серверов приложений. В сети с несколькими доменами КОС, управляющий запросами на получение билетов сеанса, может добавлять в данные авторизации дополнительные группы целевого домена, к которым может принадлежать пользователь.
По мере развития ОС Windows Server 2003 формат данных авторизации может изменяться. Но в любом случае эти данные будут содержать список идентификаторов безопасности, предназначенных для поддержки аутентификации Kerberos в много платформенных системах, а также подпись, обеспечивающую целостность данных и устанавливаемую КОС.

Протоколы безопасности

Протоколы безопасности


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

Протокол ассоциаций безопасности и управления ключами Интернет (ISAKMP, Internet Security Association and Key Management Protocol) Прежде чем IP-пакеты будут переданы от одного компьютера другому, должна быть установлена ассоциация, или сопоставление, безопасности (Security Association, SA). SA — набор параметров, который определяет необходимые для защищенной связи услуги и механизмы, типы ключей для безопасных протоколов. SA должна существовать между двумя поддерживающими связь сторонами, использующими безопасность IP. ISAKMP определяет основу для поддержки и установления ассоциаций безопасности. Протокол ISAKMP не связан ни с одним конкретным алгоритмом, методом порождения ключей или протоколом безопасности.

Oakley. Протокол определения ключей, который использует алгоритм обмена ключами Diffie-Hellman (D-H). Oakley генерирует ключи, необходимые для безопасного обмена информацией.

Заголовок аутентификации IP (АН, Authentication Header). АН обеспечивает целостность, установление подлинности и защиту от повторного использования. Также при помощи АН поддерживается конфиденциальность. АН основан на некотором алгоритме вычисления ключевого кэшированного значения сообщения (НМАС) для каждого IP-пакета.

Протокол инкапсуляции безопасности (ESP, Encapsulating Security Protocol). В дополнение к услугам АН, описанным выше, ESP обеспечивает конфиденциальность, используя алгоритм DES-CBC.

Работа с EFS

Работа с EFS


Самая серьезная и, к сожалению, нередко встречающаяся ошибка при работе с EFS заключается в том, что пользователи шифруют данные на локальном компьютере (или компьютере — члене группы), а затем переустанавливают операционную систему. В этом случае данные будут безвозвратно утеряны, т. к. доступ к ним имели только два пользователя той системы, в которой данные были зашифрованы: пользователь, выполнивший эту операцию, и агент восстановления. Ошибка состоит в том, что для расшифровки данных необходимо предъявить сертификаты одного из названных пользователей, а для этого соответствующие сертификаты нужно было экспортировать и сохранить.
EFS располагает встроенными средствами восстановления зашифрованных данных в условиях, когда неизвестен личный ключ пользователя. Пользователи, которые могут восстанавливать зашифрованные данные в условиях утраты личного ключа, называются агентами восстановления данных. Агенты восстановления данных обладают сертификатом (Х.509 v.3) на восстановление файлов и личным ключом, с помощью которых выполняется операция восстановления зашифрованных файлов. Используя ключ восстановления, можно получить только сгенерированный случайным образом ключ, с помощью которого был зашифрован конкретный файл. Поэтому агенту восстановления не может случайно стать доступной другая конфиденциальная информация.
Средства восстановления данных предназначены для применения в разнообразных конфигурациях вычислительных сред. Параметры процедуры восстановления зашифрованных данных в условиях утраты личного ключа задаются политикой восстановления. Она представляет собой одну из политик открытого ключа (public key policy). Политика восстановления определяется только в домене Windows Server 2003. Администратор домена одновременно является и агентом восстановления с соответствующими полномочиями. Могут быть добавлены и другие агенты. Это делается с помощью оснастки Group Policy Object Editor (Групповая политика), в окне которой нужно выбрать узел Security Settings | Public Key Policies | Encrypting File System. В контекстном меню этого узла имеются команды, позволяющие управлять агентами и политиками восстановления. Политика восстановления может быть задана и на одиночном компьютере.

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

Распределенная аутентификация

Распределенная аутентификация


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

Разработка плана безопасности

Разработка плана безопасности


Перед тем как реализовать безопасность IP в Windows 2000, полезно разработать и задокументировать план безопасности, охватывающий всю корпоративную сеть. Необходимо проанализировать следующие вопросы.

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

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

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

Необходимо создать и сконфигурировать политику безопасности для каждого сценария, который был указан в плане.
Например, в компании может быть юридический отдел, которому требуется собственная политика безопасности для любых данных, посланных с использованием IP-протокола. Пользователи в юридическом отделе должны иметь высокий, обеспечивающий конфиденциальность, уровень безопасности для любых данных, посылаемых за пределы отдела. Однако в плане безопасности компании может быть определено, что пользователи в юридическом отделе не требуют конфиденциальности при посылке данных друг другу.
Чтобы реализовать план безопасности для юридического отдела, администратор может выполнить следующие шаги:
1. Создать политику безопасности с именем Legal и привязать ее к заданной по умолчанию политике домена (Default Domain Policy). Поскольку каждый компьютер входит в домен компании, агент политики компьютера выберет политику безопасности Legal в каталоге Active Directory. Политика безопасности Legal могла бы иметь описанные ниже политику переговоров и IP-фильтры, связанные с ней.
2. Создать две политики переговоров и связать их с политикой безопасности Legal:

первую политику переговоров, Legal NP 1, настроенную на службы и обеспечивающую конфиденциальность для взаимодействия пользователей юридического отдела с пользователями других отделов ("передаваемые данные будут конфиденциальны, подлинны и не модифицированы" — парадигма протокола безопасности ESP);

вторую политику переговоров, Legal NP 2, настроенную на службы и обеспечивающую только установление подлинности и защиту от изменений, когда пользователи юридического отдела общаются друг с другом ("передаваемые данные будут подлинны и не модифицированы" — парадигма протокола безопасности АН).

3. Создать два IP-фильтра и связать каждый с политикой переговоров. Пользователи в юридическом отделе находятся в сети 157.55.0.0 с маской подсети 255.255.0.0. Пользователи других отделов находятся в сети 147.20.0.0 с маской подсети 255.255.0.0.
Первый IP-фильтр, Legal IP Filter 1, предназначен для пользователей в юридическом отделе, которые связываются с пользователями других отделов. Он будет связан с политикой переговоров Legal NP 1. Администратор устанавливает свойства фильтра в соответствии со следующими значениями:

заданный IP-адрес для источника — 157.55.0.0. Этот адрес будет соответствовать любому адресу IP в сети юридического отдела, т. к. он является IP-адресом подсети;

заданный IP-адрес для получателя — 147.20.0.0;

поскольку план безопасности компании обусловливает безопасность всех данных, посланных при помощи протокола IP, тип протокола — любой (Any).

Пользователи юридического отдела, поддерживающие связь с другими пользователями внутри отдела, используют второй IP-фильтр, Legal IP Filter 2. Он связан с политикой переговоров, Legal NP 2, а параметры фильтра установлены в соответствии со следующими значениями:

заданный IP-адрес для источника — 157.55.0.0;

заданный IP-адрес для получателя — 157.55.0.0;

тип протокола — любой (Any).

Когда пользователь в юридическом отделе посылает информацию любому другому пользователю, адреса источника и получателя IP-пакетов сверяются с IP-фильтрами политики безопасности Legal. Если адреса соответствуют одному из фильтров, связанная политика переговоров определяет уровень IP-безопасности для поддержания взаимодействия.
Например, если пользователь в юридическом отделе с адресом IP 157.55.2.1 посылает данные пользователю с адресом 147.20.4.5, это соответствует Legal IP Filter 1. Это означает, что связь будет организована на уровне безопасности, определенном политикой переговоров Legal NP 1, которая обеспечивает установление подлинности, защиту от изменений и конфиденциальность связи.

Сертификаты

Сертификаты


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

Шифрование файлов для совместного использования

Шифрование файлов для совместного использования


Системы Windows XP и Windows Server 2003, в отличие от Windows 2000, поддерживают совместный доступ к зашифрованным файлам, расположенным на общих сетевых ресурсах в домене на базе Active Directory или на локальных дисках. Дополнительные разрешения нужно давать для каждого файла индивидуально.
После того как владелец-создатель зашифровал файл, он может снова открыть окно Advanced Attributes (Дополнительные атрибуты) и нажать кнопку Details (Подробно). Появится окно, аналогичное показанному на Рисунок 22.8 (для изолированного компьютера картина будет аналогичной). В приведенном примере видно, что к файлу помимо агента восстановления имеют доступ еще два пользователя.

Шифрование файлов и каталогов

Шифрование файлов и каталогов


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

Для шифрования/дешифрования файлов и папок можно также использовать утилиту командной строки Cipher.exe.
Шифрование информации задается в окне свойств файла или папки:
1. Укажите файл или папку, которую требуется зашифровать, нажмите правую кнопку мыши и выберите в контекстном меню команду Properties (Свойства).
2. В появившемся окне свойств на вкладке General (Общие) нажмите кнопку Advanced (Другие). Появится диалоговое окно Advanced Attributes (Дополнительные атрибуты).
3. В группе Compress or Encrypt attributes (Атрибуты сжатия и шифрования) установите флажок Encrypt contents to secure data (Шифровать содержимое для защиты данных) и нажмите кнопку ОК.
4. Нажмите кнопку ОК в окне свойств зашифровываемого файла или папки. В появившемся диалоговом окне подтвердите режим шифрования.
При шифровании папки можно указать следующие режимы:

Apply changes to this folder (Только к этой папке);

Apply changes to this folder, subfolders and files (К этой папке и всем вложенным папкам и файлам).

Шифрование с открытым ключом

Шифрование с открытым ключом


Криптография — это наука о защите данных. Алгоритмы криптографии с помощью математических методов комбинируют входной открытый текст и ключ шифрования, в результате чего получаются зашифрованные данные. Применение криптографии обеспечивает надежную передачу данных и предотвращение их получение несанкционированной стороной. Применяя хороший алгоритм шифрования, можно сделать практически невозможным, с точки зрения необходимых вычислительных и временных ресурсов, взлом защиты и получение открытого текста подбором ключа. Для быстрого выполнения подобного преобразования необходим расшифровывающий ключ.
В традиционном шифровании с секретным ключом (secret key) (симметричное шифрование) зашифровывающий и расшифровывающий ключи совпадают. Стороны, обменивающиеся зашифрованными данными, должны знать общий секретный ключ. Процесс обмена информацией о секретном ключе представляет собой брешь в безопасности вычислительной системы.
Фундаментальное отличие шифрования с открытым ключом (асимметричное шифрование) заключается в том, что зашифровывающий и расшифровывающий ключи не совпадают. Шифрование информации является односторонним процессом: открытые данные шифруются с помощью зашифровывающего ключа, однако с помощью того же ключа нельзя осуществить обратное преобразование и получить открытые данные. Для этого необходим расшифровывающий ключ, который связан с зашифровывающим ключом, но не совпадает с ним. Подобная технология шифрования предполагает, что каждый пользователь имеет в своем распоряжении пару ключей — открытый ключ (public key) и личный или закрытый ключ (private key). Свободно распространяя открытый ключ, вы даете возможность другим пользователям посылать вам зашифрованные данные, которые могут быть расшифрованы с помощью известного только вам личного ключа. Аналогично, с помощью личного ключа вы можете преобразовать данные так, чтобы другая сторона убедилась в том, что информация пришла именно от вас. Эта возможность применяется при работе с цифровыми или электронными подписями. Шифрование с открытым ключом имеет все возможности шифрования с закрытым ключом, но может проходить медленнее из-за необходимости генерировать два ключа. Однако этот метод безопаснее.
Появление пары "личный ключ/открытый ключ" привело к возникновению нескольких новых технологий, наиболее важными из которых являются цифровые подписи, распределенная аутентификация, соглашение о секретном ключе, достигаемое с применением открытого ключа, и шифрование больших объемов данных без предварительного соглашения о секретном ключе.
Существует несколько хорошо известных алгоритмов шифрования с открытым ключом. Некоторые из них, например RSA (Rivest-Shamir-Adelman) и шифрование с помощью эллиптической кривой (Elliptic Curve Criptography, ECC), являются алгоритмами общего употребления в том смысле, что они поддерживают все упомянутые выше операции. Другие алгоритмы поддерживают только некоторые операции. К ним относятся: алгоритм цифровой подписи (Digital Signature Algorithm, DSA), используемый только для работы с цифровыми подписями, и алгоритм Diffie-Hellman (D-H), применяемый только для соглашений о секретных ключах. Алгоритмы шифрования, используемые безопасностью IP (IP Security), подробнее описаны в данной главе в разд. "Безопасность IP".
Ниже кратко рассмотрены основные области применения шифрования с открытым ключом.

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

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


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

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

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

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

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

Все перечисленные выше проблемы позволяет решить шифрующая фашювая система (Encrypting File System, EFS), впервые реализованная в Windows 2000 и работающая только на NTFS 5.0. В следующих разделах подробно описаны технология шифрования, место шифрования в операционной системе, взаимодействие с пользователями и способ восстановления данных.

Временные файлы, создаваемые приложениями, наследуют

Система EFS и Windows Server 2003

EPS тесно взаимодействует с NTFS 5.0. Временные файлы, создаваемые приложениями, наследуют атрибуты оригинальных файлов (если файлы находятся в разделе NTFS). Вместе с файлом шифруются также и его временные копии. EFS находится в ядре Windows Server 2003 и использует для хранения ключей специальный пул, не выгружаемый на жесткий диск. Поэтому ключи никогда не попадают в файл подкачки.
В Windows Server 2003 файловая система EFS имеет некоторые новые возможности:

с зашифрованными файлами могут работать несколько пользователей. Пользователь, зашифровавший файл, может разрешить другим локальным и доменным пользователям (на компьютерах под управлением Windows 2000 и Windows XP) работать с этим файлом;

можно шифровать автономные папки и файлы (offline folders);

агент восстановления (recovery agent) по умолчанию не используется;

стандартный алгоритм шифрования — Advanced Encryption Standard, AES (Rijndael) (256 бит). Алгоритм DESX, используемый по умолчанию системой EFS в Windows 2000 и Windows XP Professional, не может применяться для шифрования файлов в Windows Server 2003;

вместо AES может использоваться алгоритм шифрования 3DES (128 или 168 бит), для этого нужно изменить политику безопасности;

зашифрованные файлы могут располагаться в веб-папках;

сертификаты EFS могут автоматически доставляться пользователю службами сертификатов (Certificate Services) и механизмом автоподписи сертификатов;

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

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

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

Конфигурация EFS, устанавливаемая по умолчанию, позволяет пользователю шифровать свои файлы без всякого вмешательства со стороны администратора. В этом случае EFS автоматически генерирует для пользователя пару ключей (открытый и личный), применяемых для криптозащиты данных, и подписывает сертификат.
Шифрование и дешифрование файлов может быть выполнено как для определенных файлов, так и для целого каталога. Эти операции прозрачны для пользователя. При шифровании каталога автоматически шифруются и все входящие в него файлы и подкаталоги. Каждый файл обладает уникальным ключом, позволяющим легко выполнять операцию переименования. Если вы переименовываете файл, находящийся в зашифрованном каталоге, и переносите его в незашифрованный каталог, сам файл остается зашифрованным (при условии, что целевой каталог находится на томе NTFS 5.0). Средства шифрования и дешифрования доступны через Windows Explorer. Кроме того, можно использовать все возможности шифрования данных с помощью набора утилит командной строки и интерфейсов администрирования.
Если зашифрованные файлы хранятся на общих ресурсах, то для работы с ними пользователи должны иметь сертификат и личный ключ того, кто установил шифрование этих файлов. Впоследствии каждый пользователь может при необходимости независимо расшифровать файл при помощи своего личного ключа.

Соглашение о секретном ключе достигаемое

Соглашение о секретном ключе, достигаемое с помощью открытого ключа


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

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

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


Домены Active Directory должны иметь возможность одновременно поддерживать клиентские компьютеры и серверы, на которых работает программное обеспечение Windows NT 3.x—4.0, Windows 9х/МЕ, а также Windows 2000/XP и Windows Server 2003. Для этого в Windows Server 2003 остается поддержка аутентификации NTLM, обеспечивающей совместимость с операционными системами более ранних версий. Обновленные версии клиента Active Directory обеспечивают расширенные возможности аутентификации по протоколу NTLM v.2; хотя протокол Kerberos не поддерживается.

Создание агента восстановления

Создание агента восстановления


Описываемая ниже процедура должна выполняться на автономном компьютере, на котором планируется использование системы EFS. Сначала необходимо создать сертификат агента восстановления (лучше использовать административную учетную запись, хотя, строго говоря, это не обязательно), импортировать его, а затем назначить политику восстановления.
Чтобы создать сертификат агента восстановления:
1. Войдите в систему как администратор.
2. В окне консоли введите команду cipher /R:имяФайла — без расширения.
3. Введите и подтвердите пароль, защищающий личный ключ.
В текущем каталоге будут созданы два файла: с расширением сer (содержит только сгенерированный ключ) и с расширением pfx (содержит и ключ, и сертификат агента восстановления). Для большей сохранности перепишите файлы на дискету.
Для импорта сертификата, с помощью которого можно восстанавливать индивидуальные файлы пользователей:
1. Зарегистрируйтесь в системе как администратор.
2. Запустите оснастку Certificates, откройте узел Personal.
3. Импортируйте созданный РЕХ-файл.
Чтобы определить политику агента восстановления для любых операций шифрования:
1. Запустите оснастку Local Security Settings.
2. Выберите узел Public Key Policies | Encrypting File System (Политики открытого ключа | Файловая система EPS).
3. В контекстном меню выполните команду Add Data Recovery Agent (Добавить агента восстановления данных).
4. В окне мастера Add Recovery Agent Wizard (Мастер добавления агента восстановления) нажмите кнопку Browse Folders (Обзор папок) и выберите местоположение созданного ранее файла сертификата с расширением сеr. (Имя пользователя будет неизвестно, поскольку оно не хранится в файле — это нормальная ситуация.)
5. Нажмите кнопку Next (Далее) и на следующей странице мастера — Finish (Готово).
Сертификат будет импортирован и его владелец станет агентом восстановления на данном компьютере. Обратите внимание на то, что в столбце Intended Purposes (Назначение) импортированного сертификата указано File Recovery (Восстановление файлов).
Теперь можно использовать шифрование информации, не опасаясь потери "ключа" к ней.

Средства безопасности Windows Server 2003

Средства безопасности Windows Server 2003


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

Список папок хранилища

Таблица 22.1. Список папок хранилища сертификатов с кратким описанием

Сортировка по	Папка	Содержит
Логическим хранилищам	Personal (Личные)	Сертификаты, связанные с закрытыми ключами пользователя. Сертификаты, которые были выданы компьютеру или службе, для которых выполняется управление сертификатами
Trusted Root Certification Authorities (Доверенные корневые центры сертификации)	Полностью доверяемые центры сертификации
Enterprise Trust (Доверительные отношения в предприятии)	Списки доверяемых отношений сертификатов (certificate trust list). Обеспечивает механизм доверия к корневым сертификатам со стороны других организаций
Intermediate Certification Authorities (Промежуточные центры сертификации)	Сертификаты, выпущенные для других пользователей и центров сертификации
Active Directory User Object (Объект пользователя Active Directory)	Сертификаты, связанные с вашим пользовательским объектом и опубликованные в Active Directory
Trusted Publishers (Доверенные издатели)	Сертификаты, выпущенные центрами сертификации, которые соответствуют политикам Software Restriction
Untrusted Certificates (Сертификаты, к которым нет доверия)	Сертификаты, для которых явно установлено отсутствие доверительных отношений
Third-Party Root Certification Authorities (Сторонние корневые центры сертификации)	Доверяемые корневые сертификаты от центров сертификации, отличных от Microsoft и вашей собственной организации
Trusted People (Доверенные лица)	Сертификаты, выпущенные для других пользователей или конечных устройств, с которыми налажены доверительные отношения
По назначению	Server Authentication (Проверка подлинности сервера)	Сертификаты, которые используются серверными программами для аутентификации при обращении к клиентам
Client Authentication (Проверка подлинности клиента)	Сертификаты, которые используются клиентскими программами для аутентификации при обращении к серверам
Code Signing (Подписывание кода)	Сертификаты, связанные с парами ключей, используемых для подписи активного содержания
Secure Email (Защищенная электронная почта)	Сертификаты, связанные с парами ключей, используемых для подписи электронных сообщений
Encrypting File System (Шифрующая файловая система)	Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для шифрования и расшифровки данных
File Recovery (Восстановление файлов)	Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для восстановления зашифрованных данных

При наличии соответствующих прав вы можете импортировать или экспортировать сертификаты из любой папки в хранилище сертификатов. Если личный ключ, связанный с сертификатом, доступен для экспорта, то вы можете экспортировать сертификат и личный ключ в файл, соответствующий стандарту PKCS #12.
Оснастка Certificates позволяет публиковать выпущенные сертификаты в Active Directory. Публикация сертификата в Active Directory дает возможность всем группам, которые имеют необходимые разрешения, извлекать сертификат при необходимости.
Команда Find Certificates (Поиск сертификатов) (контекстного меню или меню Action (Действие)) помогает отыскать выпущенные сертификаты в хранилищах сертификатов. Вы можете провести поиск в определенном хранилище или во всех хранилищах и ограничить поиск на основании определенной информации сертификатов, например, искать сертификаты, выпущенные определенным центром сертификации.

Технологии шифрования EFS

Технологии шифрования EFS


Данный раздел поможет вам понять, как шифруется информация и почему перед использованием EFS обязательно экспортировать сертификаты (вместе с личными ключами) пользователей и агентов восстановления данных. Очень часто непонимание этих моментов приводит к тому, что зашифрованные данные безвозвратно теряются по вине пользователей.
EFS основана на шифровании с открытым ключом и использует все возможности архитектуры CryptoAPI. Каждый файл шифруется с помощью случайно сгенерированного ключа, зависящего от пары открытого (public) и личного, закрытого (private), ключей пользователя. Подобный подход в значительной степени затрудняет осуществление большого набора атак, основанных на криптоанализе. При криптозащите файлов может быть применен любой ачгоритм симметричного шифрования. EFS позволяет осуществлять шифрование и дешифрование файлов, находящихся на удаленных файловых серверах.

В данном случае EFS может работать только с файлами, находящимися на диске. Шифрующая файловая система не осуществляет криптозащиту данных, передаваемых по сети. Для шифрования передаваемой информации следует применять специальные сетевые протоколы, например SSL/PCT.
В EFS для шифрования и дешифрования информации используются открытые ключи. Данные зашифровываются с помощью симметричного алгоритма с применением Ключа шифрования фаша (File Encryption Key, FEK). FEK — это сгенерированный случайным образом ключ, имеющий определенную длину.
В свою очередь, FEK шифруется с помощью одного или нескольких открытых ключей, предназначенных для криптозашиты ключа. В этом случае создается список зашифрованных ключей FEK, что позволяет организовать доступ к файлу со стороны нескольких пользователей. Для шифрования набора FEK используется открытая часть пары ключей каждого пользователя. Список зашифрованных ключей FEK хранится вместе с зашифрованным файлом в специальном атрибуте EFS, называемом Полем дешифрования данных (Data Decryption Field, DDF). Информация, требуемая для дешифрования, привязывается к самому файлу. Секретная часть ключа пользователя используется при дешифровании FEK. Она хранится в безопасном месте, например на смарт-карте или другом устройстве, обладающем высокой степенью защищенности.
FEK применяется для создания ключей восстановления. Для этого FEK шифруется с помощью одного или нескольких открытых мючей восстановления. Список FEK, зашифрованных для целей восстановления, хранится вместе с зашифрованным файлом в специальном атрибуте EFS, называемом Полем восстановления данных (Data Recovery Field, DRF). Благодаря существованию набора зашифрованных ключей FEK агенты восстановления данных могут дешифровать файл. Для шифрования ключа FEK в поле DRF необходима только общая часть пары ключей восстановления, ее присутствие в системе необходимо в любой момент времени для нормального функционирования файловой системы. Сама процедура восстановления выполняется довольно редко, когда пользователь увольняется из организации или забывает секретную часть ключа. Поэтому агенты восстановления могут хранить секретную часть ключей восстановления в безопасном месте, например на смарт-картах или других хорошо защищенных устройствах.

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

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


После инсталляции центра сертификации можно запустить управляющую оснастку Certification Authority. Для этого в меню Administrative Tools выполните команду Certification Authority. В окне оснастки (Рисунок 22.11) можно просматривать списки сертификатов, а также работать с шаблонами сертификатов. В системах Windows Server 2003 шаблоны сертификатов можно создавать и модифицировать, для чего имеется специальная оснастка — Certificate Templates.

Управление политиками IP Security

Рисунок 22.6. Управление политиками IP Security в окне оснастки Default Domain Policy


Можно конфигурировать безопасность IP, используя оснастки Local Security Settings (Локальные параметры безопасности) (на локальном компьютере) или Default Domain Policy (Рисунок 22.6) (для домена). Также можно подключить к консоли ММС изолированную оснастку IP Security Policy Management (Управление политикой безопасности IP) и настроить ее для компьютера или домена.

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

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


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

В вышесказанном легко убедиться, если после инсталляции системы запустить оснастку Certificates и раскрыть узел (папку) Personal: этот узел будет пуст. Если затем зашифровать некоторый файл или папку и вернуться в оснастку Certificates, то можно увидеть, что в папке Personal появился сертификат, выданный текущему пользователю.
Управление сертификатами, их импорт и экспорт осуществляются с помощью контекстных меню оснастки Certificates (см. также ниже разд. "Импорт к экспорт сертификатов"). Пользователи имеют возможность управлять только своими собственными сертификатами.

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

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


Центр сертификации (ЦС) — важный элемент в системе безопасности организации, поэтому в большинстве организаций имеется собственный ЦС. В Windows Server 2003 центры сертификации могут быть двух классов: ЦС предприятия (Enterprise СА) и изолированный ЦС (Stand-alone CA). Внутри каждого класса могут быть два типа ЦС: корневой (root) и подчиненный (subordinate).
В большинстве случаев центры сертификации организованы в иерархическом порядке, где наиболее доверяемый, или корневой, центр находится на вершине иерархии. В корпоративной сети все остальные ЦС в иерархии являются подчиненными. В корпоративной сети ЦС предприятия имеет максимальное доверие. ЦС предприятия имеют специальный модуль политик, который определяет, как обрабатываются и выпускаются сертификаты. Информация политики из данного модуля хранится в Active Directory, поэтому для инсталляции ЦС предприятия сначала следует установить Active Directory. Изолированные ЦС имеют очень простой модуль политик и не хранят никакой информации на удаленном сервере, поэтому для инсталляции данного центра не требуется наличия Active Directory.
Для развертывания собственного ЦС:
1. Выберите на панели управления значок Add or Remove Programs (Установка и удаление программ).
2. В открывшемся окне нажмите кнопку Add/Remove Windows Components (Добавление и удаление компонентов Windows).
3. В окне мастера Windows Components Wizard (Мастер компонентов Windows) установите флажок Certificate Services (Службы сертификации) (при этом система предупредит вас о последствиях установки этих служб) и нажмите кнопку Next (Далее).
4. На следующей странице мастера необходимо выбрать тип ЦС. Существуют четыре типа ЦС:

Enterprise root СА (Корневой ЦС предприятия) — установите переключатель в это положение, если данный ЦС будет выпускать сертификаты для всех устройств, подключенных к сети в организации, и будет зарегистрирован в Active Directory. Данный ЦС является корнем в корпоративной иерархии ЦС и может устанавливаться только на контроллере домена. Обычно корневой ЦС предприятия выпускает сертификаты только для подчиненных ЦС;

Enterprise subordinate СА (Подчиненный ЦС предприятия) — если у вас уже установлен корневой ЦС предприятия, выберите это положение переключателя. Однако данный ЦС не имеет наивысшего доверия в организации, поскольку он подчиняется корневому ЦС. Может устанавливаться только на контроллере домена;

Stand-alone root CA (Изолированный корневой ЦС) — данный ЦС устанавливается для выпуска сертификатов за пределами корпоративной сети. Например, требуется установить изолированный корневой ЦС, если этот ЦС не будет участвовать в корпоративном домене и будет выпускать сертификаты для узлов во внешних сетях. Корневой ЦС обычно используется для выпуска сертификатов для подчиненных ЦС;

Stand-alone subordinate CA (Изолированный подчиненный ЦС) — подчиненный ЦС, который выпускает сертификаты для узлов за пределами корпоративной сети.

5. Если вы собираетесь изменить параметры шифрования по умолчанию, установите флажок Use custom setting to generate the key pair and CA certificate (Использовать специальные параметры для генерации пары ключей и сертификата ЦС).
6. Нажмите кнопку Next.
7. Укажите имя ЦС и срок действия сертификатов. Введите необходимую информацию и нажмите кнопку Next.
8. Укажите папку на локальном или общем диске для хранения сертификатов и нажмите кнопку Next.
9. По окончании процедуры инсталляции нажмите кнопку Finish (Готово).

В этом окне перечислены все пользователи

Рисунок 22.8. В этом окне перечислены все пользователи, имеющие доступ к зашифрованному файлу

Восстановление зашифрованных файлов на другом компьютере

Восстановление зашифрованных файлов на другом компьютере


Иногда возникает необходимость восстановить зашифрованную информацию не на том компьютере, на котором она была заархивирована. Это можно выполнить с помощью утилиты архивации, которая сохраняет информацию в зашифрованном виде вместе с атрибутом шифрования. Однако нужно позаботиться о переносе на новый компьютер соответствующего сертификата и личного ключа пользователя либо с помощью перемещаемого профиля, либо вручную.
На любом компьютере, где зарегистрировался пользователь, обладающий перемещаемым профилем, будут применяться одни и те же ключи шифрования.
Ручной перенос личного ключа и сертификата выполняется в два этапа: сначала следует создать резервную копию сертификата и личного ключа (при этом сертификат и секретный ключ должны быть экспортированы в файл с расширением pfx), а затем восстановить созданную копию на другом компьютере. (Эта процедура имеет смысл только для компьютеров, не входящих в домен. В домене можно использовать процедуру, описанную выше в разд. "Шифрование файлов для совместного использования".) В результате этой процедуры текущий пользователь (который импортировал сертификат) получит возможность работать с зашифрованными данными на этом компьютере.

и Windows Server 2003, предназначенных

Рисунок 22.1. Взаимосвязь средств Windows 2000 и Windows Server 2003, предназначенных для работы с открытым ключом


Поддержка прикладных средств шифрования информации с открытым ключом включена в состав программного обеспечения всех операционных систем Windows.
Основой архитектуры поддержки прикладных программ шифрования информации с открытым ключом является библиотека CryptoAPI. Она позволяет работать со всеми устанавливаемыми поставщиками услуг шифрования (Cryptographic Service Providers, CSP) через стандартный интерфейс. CSP могут быть реализованы на программном уровне или с помощью специального оборудования. Они поддерживают различные длины ключей и алгоритмы шифрования. Один из CSP поддерживает смарт-карты. Услугами служб шифрования пользуются службы управления сертификатами. Они соответствуют стандарту Х.509 v3 и позволяют организовывать принудительное хранение, службы подсчета и дешифрования. Кроме того, эти службы предназначены для работы с различными отраслевыми стандартами сообщений. В основном они поддерживают стандарты PKCS и разработанный в IETF (Internet Engineering Task Force) набор предварительных стандартов PKIX (Public Key Infrastructure, X.509).
Остальные службы используют CryptoAPI для придания дополнительной функциональности прикладным программам. Защищенный канал (Secure Channel) поддерживает сетевую аутентификацию и шифрование в соответствии со стандартными протоколами TLS и SSL, обращение к которым может быть выполнено с помощью интерфейсов Microsoft Winlnet и SSPI. Служба Authenticode предназначена для проверки и подписи объектов и в основном используется при получении информации через Интернет.

Запрос сертификата

Запрос сертификата


Если администратор создал политику открытого ключа для автоматизации запросов на получение сертификатов, то вам, возможно, никогда не придется запрашивать сертификаты самостоятельно, если только вы не работаете со смарт-картами. Пользователи смарт-карт должны запрашивать свои сертификаты.
Если вы пользуетесь смарт-картами, или в вашей организации не применяются автоматические запросы на получение сертификатов, то вы можете запросить новые сертификаты. Запросить новый сертификат можно с помощью мастера Certificate Request Wizard (Мастер запроса сертификата) или на веб-страницах служб сертификации. При запросе сертификатов в центре сертификации предприятия Windows Server 2003 используется, как правило, мастер Certificate Request Wizard, вызываемый из оснастки Certificates. Кроме того, центр сертификации, установленный на Windows Server 2003 в сочетании со службами Интернета (Internet Information Services), имеет веб- страницу, на которой можно запрашивать сертификаты. По умолчанию ЭТИ сертификаты находятся ПО адресу http://servername/certsrv, где servername — имя сервера, на котором находится ЦС.
Для того чтобы запросить сертификат в оснастке Certificates:
1. Откройте окно оснастки Certificates.
2. На панели структуры (левое подокно) откройте нужный узел: для пользователя Certificates | Current User (Сертификаты | текущий пользователь), для компьютера — Certificates | Computer Name (Сертификаты (локальный компьютер)).
3. Если вы находитесь в режиме просмотра "по логическим хранилищам", выберите папку Personal. В режиме "по назначению" выберите соответствующий режим (папку).
4. В меню Action (Действие) выберите команду All Tasks | Request New Certificate (Все задачи | Запросить новый сертификат).
5. В окне мастера Certificate Request Wizard выберите:

тип (шаблон) сертификата;

ЦС, который выдаст сертификат (если имеется несколько ЦС) (если установлен флажок Advanced (Дополнительно));

поставщика службы криптографии (Cryptographic Service Provider, CSP) (если установлен флажок Advanced).

6. Введите дружественное имя сертификата и его описание.
7. После выбора и проверки всех параметров нажмите кнопку Finish (Готово).

Internet Information Services 6.0

Безопасный режим загрузки (Safe mode)

Безопасный режим загрузки (Safe mode)


Загрузчик Windows Server 2003 (NTLDR) отображает на экране меню, из которого можно выбрать запускаемую операционную систему (см. главу 3 "Загрузка операционной системы"). Если при появлении меню загрузки нажать клавишу , то на экране появится меню опций отладки и дополнительных режимов загрузки, которое будет оставаться на экране до тех пор, пока не будет выбрана одна из опций.
При загрузке в безопасном режиме (safe mode) Windows использует стандартные параметры настройки (монитор VGA, без запуска сетевых средств, с запуском минимального количества драйверов — фактически запускаются только драйверы, минимально необходимые для запуска Windows). Например, если после инсталляции нового программного обеспечения Windows XP или Windows Server 2003 перестали запускаться, то вполне возможно, что загрузка в безопасном режиме позволит выполнить запуск операционной системы с минимальным количеством сервисов и драйверов. После загрузки вы сможете изменить параметры настройки компьютера, не позволяющие выполнить корректную загрузку Windows, или удалить программное обеспечение, вызвавшее эти проблемы.
Если вы имеете некоторый опыт работы с Windows NT 4.0, то наверняка знаете, что в этой системе проблемы с загрузкой чаще всего вызывались некорректно работающими драйверами устройств. Такие несовместимые драйверы могли привести к краху системы либо сразу же после инсталляции, либо даже после некоторого времени, в течение которого их работа на первый взгляд казалась корректной. Причем вторая ситуация, когда драйвер в течение некоторого времени все же работал, не вызывая никаких проблем, всегда была более труднообъяснимой (а в самом деле, что же могло вызвать ошибку?). При этом, хотя на первый взгляд и кажется, что нет причин, которые могли бы хоть как-то объяснить это непредсказуемое поведение, причины этому все же есть. Заключаются они в том, что как программная, так и аппаратная конфигурация компьютера со временем могут меняться, а эти изменения могут спровоцировать ошибки, допущенные при проектировании драйвера и оставшиеся незамеченными. Windows 2000/XP и Windows Server 2003, как и Windows NT 4.0, тоже могут быть выведены из строя установкой несовместимого драйвера. Однако загрузка в безопасном режиме (safe mode), концепция которого была позаимствована из Windows 9x, предоставляет более удобные средства быстрого восстановления системы после подобных ошибок, нежели Windows NT 4.0.
Если несовместимый драйвер вызывает проблему при первой же перезагрузке, то вам очень повезло, потому что, как правило, в этом случае вам действительно поможет опция Last Known Good Configuration. Когда пользователь выбирает из меню безопасного режима эту опцию, система при загрузке использует информацию ключа реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlset и восстановит всю конфигурационную информацию, сохраненную после того, как компьютер в последний раз был успешно загружен.

Опция Last Known Good Configuration в Windows XP и Windows Server 2003 претерпела незаметное на первый взгляд, но весьма полезное усовершенствование. В отличие от Windows NT/2000, Windows XP и Windows Server 2003 перед обновлением набора установленных драйверов выполняют его резервное копирование. Опция Last Known Good Configuration, в дополнение к восстановлению информации реестра, выполнит также и восстановление драйверов, использовавшихся при последней успешной регистрации пользователя в системе. Таким образом, теперь эта опция поможет вам восстановить систему с конфигурационными проблемами в тех ситуациях, когда аналогичная опция Windows NT/2000 оказывалась бесполезной.
В ряде случаев, если использование опции Last Known Good Configuration не помогло, но вам известен драйвер, вызвавший проблему (список таких драйверов можно получить с помощью утилиты Sigverif, описанной ранее в этой главе), то вы можете попробовать другие способы быстрого восстановления. Например, можно попытаться использовать такие опции меню безопасного режима, как Safe Mode, Safe Mode with Networking или Safe Mode with Command Prompt. Как уже говорилось, при использовании этих опций Windows 2000, Windows XP и Windows Server 2003 загружаются с использованием минимального набора драйверов и сервисов. После загрузки системы вы сможете удалить из системы проблемный драйвер с помощью штатных средств операционной системы. Особое внимание пользователей Windows XP/Windows Server 2003 следует обратить на уже обсуждавшуюся ранее в этой главе возможность отката драйверов (Driver Rollback), которая может применяться как при нормальном режиме загрузки, так и в безопасном режиме.
Если системный и загрузочный раздел отформатированы для использования файловой системы FAT, можно попытаться загрузить компьютер с помощью загрузочной дискеты MS-DOS (или Windows 9х) и вручную удалить или переименовать файл проблемного драйвера.

Чтобы системные конфигурационные

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


Обратите внимание на то, что программа Backup не позволяет выполнить выборочное резервное копирование отдельных компонентов набора System State.
В списке Backup destination выберите ленточное устройство (если оно установлено на компьютере, и резервное копирование должно быть выполнено на ленту, вставленную в это устройство) или выберите опцию File (если резервное копирование должно выполняться в файл). Если компьютер не оснащен ленточным устройством, то опция File всегда будет выбрана по умолчанию. Если резервное копирование будет выполняться в файл, то в поле Backup media or file name укажите путь к файлу, в который будет выполняться резервное копирование (файлы резервных копий всегда имеют расширение bkf), или нажмите кнопку Browse, чтобы найти нужный файл. Если резервное копирование должно выполняться на ленту, выберите ленту, на которую будет выполняться резервное копирование. Дополнительные опции резервного копирования можно задать, выбрав команду Options из меню Tools. Чтобы начать процедуру резервного копирования, нажмите кнопку Start Backup (Начать копирование).

Диалоговое окно Driver Signature Notice

Рисунок 23.4. Диалоговое окно Driver Signature Notice

Диалоговое окно Driver Signing

Рисунок 23.2. Диалоговое окно Driver Signing Options с установками по умолчанию


Пользователи, зарегистрировавшиеся в системе от имени администратора (Administrator) или являющиеся членами локальной группы Administrators, имеют возможность установить режим, при котором выбранная ими опция будет применяться как опция по умолчанию для всех пользователей, регистрирующихся на данном компьютере. Для этого следует установить флажок Make this action the system default (Применять выбранное действие по умолчанию) в группе Administrator option (Административные опции).

Для просмотра отчета о ходе процесса

Рисунок 23.17. Для просмотра отчета о ходе процесса резервного копирования нажмите кнопку Report

Использование Recovery Console

Использование Recovery Console


Интерфейс Recovery Console представляет собой полноэкранный интерфейс командной строки (как в MS-DOS). Фактически ориентироваться в работе с Recovery Console вам поможет команда help, которая, как несложно догадаться, выводит список команд, доступных при работе с консолью. Помимо этого, полный список команд Recovery Console можно найти в справочной системе (достаточно выполнить поиск по словам "Recovery Console").
Краткий список команд Recovery Console приведен ниже.

Attrib — изменение атрибутов файла или каталога.

Batch — исполнение команд, содержащихся в указанном текстовом файле.

Bootcfg — конфигурирование и восстановление файла Boot.ini.

choir (CD) — переход в другой каталог.

chkdsk — запуск программы chkdsk с выводом отчета.

cis — очистка экрана.

сору — копирование указанного одиночного файла.

Delete (DEL) — удаление одиночного файла.

Dir — вывод списка содержимого каталога.

Disable — блокировка системного сервиса или драйвера.

Diskpart — управление разделами на жестком диске.

Enable — активизация сервиса или драйвера.

Exit — завершение работы с Recovery Console и перезагрузка компьютера.

Expand — распаковка сжатого файла.

Fixboot — исправление поврежденного загрузочного сектора на системном разделе.

Fixmbr — исправление поврежденной главной загрузочной записи.

Format — форматирование диска.

Help — вывод справочной информации по командам Recovery Console.

Listsvc — вывод списка всех доступных в системе сервисов и драйверов.

Logon — регистрация в системе Windows XP.

мар — отображение списка буквенных обозначений дисков.

MkDir (мо) — создание каталога.

More — вывод текстового файла на экран по частям.

Rename (REN) — переименование файла.

RmDir (RD) — удаление каталога.

set — отображение и установка переменных окружения Recovery Console.

SystemRoot — закрепление за текущим каталогом статуса SystemRoot.

туре — вывод текстового файла на экран.

Чтобы вывести информацию по работе с конкретной командой, используйте следующий синтаксис: HELP command name (например, HELP FIXBOOT) или command name /? (например, LISTSVC /?).

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

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


Несмотря на то, что в составе Windows Server 2003 появились новые встроенные средства устранения неполадок с загрузкой, к числу которых относятся так называемый безопасный режим (safe mode) и консоль восстановления (Recovery Console), о которых речь пойдет далее в этой главе, в ряде случаев вам очень пригодится и загрузочная дискета. Разумеется, безопасный режим предоставляет удобное средство для устранения неполадок с загрузкой, например, в таких случаях, когда в системе установлен несовместимый или некорректно работающий драйвер устройства.
Однако в некоторых ситуациях опции безопасного режима не помогут. В частности, эта ситуация возникнет, если получит повреждение один из системных модулей или жизненно важный драйвер устройства, принадлежащий к минимальному набору драйверов, которые должны быть загружены в любом случае. Также подобная проблема возникнет, если повреждена, например, такая важная структура данных, как главная загрузочная запись (MBR). Для таких случаев в состав Windows 2000, Windows XP и Windows Server 2003 включено новое, мощное средство — Recovery Console (RC), которое будет обсуждаться далее в этой главе.
Однако, если опция запуска Recovery Console не включена в меню загрузчика, то для доступа к этому средству вам потребуется так или иначе запустить программу установки операционной системы (наиболее простым способом ее запуска является загрузка компьютера с дистрибутивного компакт-диска). Эти методы запуска Recovery Console являются "штатными" и официально рекомендуемыми. Однако, если имеющееся устройство CD-ROM не является загрузочным, в вашем распоряжении останется только загрузка компьютера с загрузочной дискеты с последующим запуском программы winnt32.exe.

В Windows 2000 в распоряжении пользователей имелся еще один метод запуска Recovery Console — загрузка компьютера с помощью четырех загрузочных дискет Windows 2000. Однако загрузка с помощью установочных дискет занимает довольно много времени. По этой причине предлагаемый метод, пригодный как в Windows 2000, так и в Windows XP/Windows Server 2003, является предпочтительным.
Для изготовления загрузочной дискеты Windows 2000/XP/Windows Server 2003 выполните следующие операции:
1. Отформатируйте дискету, работая под управлением Windows 2000, Windows XP или Windows Server 2003.
2. Скопируйте на эту дискету следующие файлы:

Ntldr;

Ntdetect.com;

Boot.ini;

Bootsect.dos — если вы имеете мультизагрузочную систему и хотите обеспечить возможность загрузки с этой дискеты также для MS-DOS или Windows 9x/ME;

Ntbootdd.sys — если в файле Boot.ini применяется синтаксис scsi ().

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

повреждены главная загрузочная запись и/или загрузочный сектор раздела на системном разделе;

возникли проблемы с диском, на котором располагается системный раздел (загрузочный раздел находится на другом диске);

вы выполняете переконфигурирование жестких дисков и хотите обеспечить возможность запуска Windows NT/2000/XP или Windows Server 2003 в случае возникновения проблем.

Консоль восстановления (Recovery Console)

Консоль восстановления (Recovery Console)


Консоль восстановления (Recovery Console) впервые появилась в Windows 2000, и многие администраторы и специалисты из групп технической поддержки сразу же оценили это исключительно полезное нововведение. Разумеется, консоль восстановления присутствует и в Windows XP, а также в продуктах из семейства Windows Server 2003.
Recovery Console представляет собой консоль с интерфейсом командной строки, предоставляющую администраторам и пользователям с административными правами необходимый минимум средств, позволяющих выполнить восстановительные процедуры в системе, имеющей проблемы с загрузкой. Используя Recovery Console, можно запускать и останавливать сервисы, форматировать диски, выполнять чтение и запись данных на локальные жесткие диски (включая и те, которые отформатированы для использования файловой системы NTFS), устранять проблемы с поврежденной главной загрузочной записью (MBR) и поврежденными загрузочными секторами, а также выполнять другие административные задачи.
Особенно полезной Recovery Console может оказаться в том случае, если для восстановления системы требуется скопировать на жесткий диск один или несколько системных файлов (с дискеты или компакт-диска) или же переконфигурировать сервис или драйвер, некорректная конфигурация которого мешает выполнить загрузку Windows 2000 или Windows XP/ Windows Server 2003.

Для применения Recovery Console необходимо зарегистрироваться в выбранной операционной системе от имени администратора (пользователь Administrator).

Мастер подготовки ASR предлагает

Рисунок 23.14. Мастер подготовки ASR предлагает указать тип носителя и путь к резервной копии


4. В последнем окне мастера подготовки процесса ASR нажмите кнопку Finish. Утилита Backup начнет сканирование системы и составит список файлов, которые необходимо включить в состав резервной копии ASR. Далее, вам будет предложено вставить носитель для выполнения резервного копирования. Мастер отобразит на экране серию сообщений примерно следующего содержания:

Mounting the media Preparing to backup using a shadow copy
Затем на экране появится окно Backup Progress (Рисунок 23.15), информирующее о ходе процесса создания резервной копии ASR.

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

Обзор средств защиты от сбоев

Обзор средств защиты от сбоев и восстановления поврежденной системы


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

проблемы с жестким диском, на котором находится системный раздел (загрузочный раздел может находиться на другом диске);

повреждение главной загрузочной записи (Master Boot Record, MBR) или загрузочного сектора на системном разделе;

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

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

Средства защиты системных файлов цифровой подписью. С появлением Windows 2000 в составе операционной системы появился набор средств, позволяющих гарантировать защиту системных файлов и драйверов устройств от их случайной замены при установке дополнительного программного обеспечения. Во всех предыдущих версиях Windows системные файлы, в том числе динамически загружаемые библиотеки (*.dll) и исполняемые файлы (*.ехе), не имели такой защиты. При их замене некорректно работающей или несовместимой версией были возможны самые разнообразные последствия — от снижения общей производительности системы до ее катастрофического сбоя. Набор средств защиты файлов цифровой подписью включает в свой состав такие средства, как зашита системных файлов (Windows File Protection, WFP), проверка системных файлов (System File Checker, SFC) и верификация цифровой подписи файлов (File Signature Verification, FSV). В Windows XP эти функциональные возможности были расширены за счет включения еще одного чрезвычайно полезного и удобного средства — возможности отката драйверов (Driver Rollback). Теперь, если после установки обновленного драйвера устройства операционная система станет работать нестабильно, пользователю будет предоставлена возможность вернуть ее в исходное состояние путем замены драйвера на предыдущую версию.

Безопасный режим загрузки (Safe mode). Эта опция, напоминающая аналогичную опцию загрузки Windows 95/98/ME, также была впервые введена в Windows 2000. В Windows XP и продуктах из семейства Windows Server 2003 возможности безопасного режима загрузки были расширены и усовершенствованы, что выгодно отличает эту операционную систему не только от предыдущих версий Windows NT, но и от Windows 2000. При использовании безопасного режима система загружается с минимальным набором драйверов устройств и сервисов. Использование безопасного режима предоставляет средства быстрого восстановления системы после сбоев, вызванных некорректной установкой нового программного обеспечения или драйверов устройств. Однако применение безопасного режима загрузки помогает не во всех случаях. Так, она оказывается практически бесполезной, если повреждены системные файлы, а также в случаях повреждения жесткого диска. Более подробная информация об опциях загрузки в безопасном режиме будет приведена далее в этой главе.

Автоматическое восстановление системы (Automated System Recovery, ASR). ASR представляет собой двухступенчатую систему восстановления, которая позволяет выполнить восстановление операционных систем Windows ХР и Windows Server 2003 с использованием файлов резервной копии, сохраненных на жестком диске или съемном носителе и конфигурационной информации жесткого диска, сохраненной на дискете. Функция ASR замещает собой диск аварийного восстановления (Emergency Repair Disk, ERD), использовавшийся для аварийного восстановления системы в Windows NT 4.0 и Windows 2000. Подготовка и проведение аварийного восстановления системы будут подробно рассмотрены далее в этой главе. Здесь же следует подчеркнуть, что это средство позволит вам восстановить поврежденную операционную систему в тех случаях, когда все остальные методы восстановления эффекта не дадут (например, если повреждение жесткого диска не позволяет запустить Windows Server 2003 ни в нормальном, ни в безопасном режиме, а также использовать Recovery Console или конфигурацию Last Known Good).

Консоль восстановления (Recovery Console). Функции Recovery Console предоставляют интерфейс командной строки, с помощью которого можно выполнить восстановление поврежденной системы. Консоль восстановления является функциональной возможностью, впервые введенной в Windows 2000. С помощью Recovery Console можно активизировать и блокировать запуск сервисов, восстанавливать поврежденные главные загрузочные записи и загрузочные секторы разделов, а также выполнять замену поврежденных системных файлов их работоспособными копиями. Эта функциональная возможность предоставляет максимум возможностей по управлению процессом восстановления, и поэтому доступна только пользователям, имеющим административные права в восстанавливаемой системе. Синтаксис команд Recovery Console будет подробно обсуждаться ниже в этой главе.

Все эти средства подробно описаны в данной главе.

В Windows XP, кроме функций, перечисленных выше, имеется также средство восстановления системы (System Restore), позаимствованное из Windows Millennium Edition. Будучи активизированной, эта функция периодически сохраняет системную информацию в автоматическом режиме, не требуя вмешательства пользователя. Поскольку в состав Windows Server 2003 эта функция не включена, мы ее не будем здесь рассматривать.

Окно Advanced Backup Options

Рисунок 23.13. Окно Advanced Backup Options


На экране появится окно Backup Job Information (Рисунок 23.12). Чтобы установить в этом окне дополнительные опции задания на резервное копирование, нажмите кнопку Advanced. Раскроется окно Advanced Backup Options (Рисунок 23.13). (Обратите внимание на состояние флажка Automatically backup System Protected Files with the System State!)
Краткий список опций, которые можно задать в окне Advanced Backup Options, приведен ниже.

Back up data that is in Remote Storage. Если эта опция установлена, то программа Backup выполнит резервное копирование данных, перенаправленных для службы Remote Storage.

Восстанавливать данные Remote Storage можно только на тома NTFS. Кроме того, обратите внимание на то, что сервис Remote Storage доступен только для серверных продуктов (Windows 2000 Server и Windows Server 2003, Enterprise Edition).

Verify data after backup. При использовании этой опции программа Backup после завершения резервного копирования выполнит проверку соответствия скопированных данных и исходных данных. Обратите внимание, что Microsoft настоятельно рекомендует применять эту опцию, т. к. она позволяет гарантировать точность резервной копии и ее пригодность к использованию. Следует, правда, отметить, что установка этой опции может существенно увеличить время, необходимое для завершения операции резервного копирования.

If possible, compress the backup data to save space. Эта опция будет полезна, если резервное копирование выполняется на магнитную ленту. Обратите внимание на то, что аппаратное сжатие доступно только для ленточных устройств. По этой причине опция будет недоступна при выполнении резервного копирования в файл.

Automatically backup System Protected Files with the System State. Как уже отмечалось, вы не можете выполнять выборочного резервного копирования данных из набора System State. Однако Windows XP и продукты из семейства Windows Server 2003 предоставляют возможность одновременно с резервным копированием системных конфигурационных файлов выполнить резервное копирование всех защищенных файлов операционной системы (по сути, сделать архивную копию самой системы, что далеко не всегда нужно). По умолчанию эта опция активизирована, однако вы можете блокировать ее, сбросив данный флажок. Размер архива в этом случае будет, понятно, значительно меньше.

Защищенные файлы операционной системы изменяются только в том случае, когда пользователь устанавливает пакеты обновления (Service Pack), приложения или выполняет обновление операционной системы. Как правило, эти файлы занимают существенный объем дискового пространства (около 180 Мбайт). Поэтому включать защищенные файлы операционной системы в состав резервной копии рекомендуется только в том случае, когда вы выполняли установку новых программ (т. к. в противном случае эти программы не будут корректно работать после восстановления данных из набора System State).

Disable volume shadow copy. Эта опция позволяет блокировать технологию "моментальных снимков тома" (volume shadow copy). Как уже говорилось, эта технология, впервые введенная в Windows XP, позволяет программе Backup работать параллельно с другими приложениями и сервисами. По умолчанию Windows XP/Windows Server 2003 будет использовать свободное дисковое пространство на любом из томов NTFS для хранения данных "моментального снимка" вплоть до завершения процесса резервного копирования. Объем дискового пространства, используемого для хранения "моментального снимка", зависит от объема данных, выбранных для включения в состав резервной копии, а также от объема данных, подвергшихся изменению в ходе резервного копирования. По умолчанию Windows XP и Windows Server 2003 всегда используют "моментальные снимки", но вы можете отключить эту опцию при том условии, что объем резервной копии невелик.

Если в вашей системе недостаточно свободного дискового пространства, Windows XP и Windows Server 2003 не смогут сохранить данные "моментального снимка", и в этом случае программа Backup будет вести себя точно так же, как во всех предыдущих версиях Windows — она будет пропускать файлы, которые были открыты на момент резервного копирования. Кроме того, следует обратить внимание и на то, что при резервном копировании данных из набора System State опция блокирования "моментального снимка" недоступна.
Наверняка любой более или менее любознательный пользователь задастся вопросом: а что же именно скрывается за общим названием "System State"? Ответ на данный вопрос на первый взгляд кажется очевидным: ведь в правой панели окна программы Backup (см. Рисунок 23.11) отображается список компонентов системы, которые включаются в состав резервной копии, когда пользователь устанавливает флажок System State. Однако обратите внимание на то, что программа Backup не позволяет осуществлять выборочное резервное копирование, флажки напротив опций, отображенных в правой панели, затенены, и их нельзя устанавливать или сбрасывать. Помимо этого, для Windows 2000 Professional/Windows XP и Windows 2000 Server/Windows Server 2003 набор файлов, входящих в System State, будет различным. В системах Windows 2000 Professional/Windows XP в состояние системы включаются следующие файлы:

реестр (Registry);

регистрационная база данных классов СОМ+;

файлы, необходимые для загрузки (Boot files).

Для систем Windows 2000 Server/Windows Server 2003 набор системных конфигурационных данных включает все те же компоненты, что и для Windows 2000 Professional/Windows XP, а также следующие данные:

базу данных службы сертификатов (Certificate Services database), если сервер является сервером сертификатов;

базу данных Active Directory и том SYSVOL, если сервер является контроллером домена;

информацию, необходимую для восстановления кластера, если на сервере работает сервис кластера. Эта информация включает данные контрольных точек реестра и журнал восстановления ресурса кворума (quorum resource), который содержит информацию о базе данных кластера.

Как уже упоминалось, если выбрана опция резервного копирования системных конфигурационных данных (System State), то программа Backup не позволит выполнить выборочное резервное копирование отдельных компонентов этого набора, что объясняется взаимозависимостью данных компонентов. Кроме того, при выполнении резервного копирования данных из набора System State вы не сможете блокировать использование технологии "моментальных снимков" томов.
Помимо этого, важно отметить следующее:

чтобы выполнить резервное копирование данных из набора System State, необходимо иметь в системе права администратора (Administrator или один из пользователей, включенных в группу Administrators) или оператора резервного копирования (один из пользователей, включенных в группу Backup operators);

в любом случае можно выполнить резервное копирование системных конфигурационных данных (System State data) только для локального компьютера. Резервное копирование этих данных для удаленного компьютера выполнить нельзя;

при выполнении резервного копирования данных из набора System State система сохраняет копии файлов реестра в папке %SystemRoot%\Kpa\r \regback. В случае удаления или повреждения файлов реестра резервные копии его файлов, сохраненные в этой папке, могут использоваться для восстановления системы без необходимости прибегать к полной процедуре восстановления системных конфигурационных данных (однако применять этот метод могут только опытные пользователи, хорошо знающие принципы загрузки и функционирования системы).

Окно Backup Job Information

Рисунок 23.12. Окно Backup Job Information

Окно Backup Progress

Рисунок 23.15. Окно Backup Progress


5. Когда процесс резервного копирования завершится, мастер подготовки ASR предложит вставить в дисковод чистую отформатированную дискету, на которую будет сохранена информация о конфигурации дисковой подсистемы, в том числе сигнатуры дисков, таблица разделов, данные о томах, информация об аппаратной конфигурации вашего компьютера, а также список файлов, подлежащих восстановлению (Рисунок 23.16). Впоследствии, если вы будете выполнять процедуру аварийного восстановления, процесс ASR Restore будет считывать информацию о конфигурации дисковой подсистемы и другие данные с этой дискеты.
6. Когда резервное копирование будет завершено, мастер отобразит сообщение, рекомендующее пометить дискету как дискету аварийного восстановления и сохранить ее в безопасном месте. Для просмотра отчета о ходе резервного копирования нажмите кнопку Report в окне Backup Progress (Рисунок 23.17).

Окно File Signature Verification

Рисунок 23.5. Окно File Signature Verification

Окно с предупреждением о том что

Рисунок 23.3. Окно с предупреждением о том, что устанавливаемый драйвер не имеет цифровой подписи

Окно Signature Verification Results

Рисунок 23.7. Окно Signature Verification Results

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

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


При разработке Windows XP и Windows Server 2003 особое внимание уделялось обеспечению отказоустойчивости системы и безопасности данных. Многие средства и утилиты были радикально переработаны, и встроенная утилита Backup не является исключением из этого правила. Так, помимо традиционных функциональных возможностей по резервному копированию и 'восстановлению данных, версия программы Backup, входящая в состав Windows XP и Windows Server 2003, включает и новую функцию подготовки к автоматическому восстановлению системы (Automated System Recovery, ASR). Автоматическое восстановление системы представляет собой двухступенчатый процесс, который позволяет пользователю восстановить поврежденную копию Windows XP/Windows Server 2003, используя для этой цели резервную копию конфигурационных данных операционной системы и информацию о дисковой конфигурации, сохраненную на дискете.

Большинство опытных пользователей Windows NT/2000 помнят возможности по восстановлению системы с помощью диска аварийного восстановления (Emergency Repair Disk, ERD). В Windows NT для изготовления диска аварийного восстановления применялась специальная утилита — Rdisk.exe. В Windows 2000 эта же задача выполнялась уже с помощью утилиты Backup. Что касается Windows XP и Windows Server 2003, то в этой операционной системе на смену ERD пришел процесс автоматического восстановления системы (ASR).
Для подготовки к автоматическому восстановлению системы, выполните следующие операции:
1. Если на компьютере установлено ленточное устройство, приготовьте носитель для выполнения резервного копирования. Если такого устройства у вас нет, то вы будете ограничены возможностью выполнения резервного копирования в файл на жестком диске. В этом случае следует освободить достаточный объем свободного дискового пространства. Кроме того, в любом случае вам потребуется пустая отформатированная дискета.
2. Запустите утилиту Backup в режиме Advanced Mode. Нажмите кнопку Automated System Recovery Wizard (Мастер автоматического восстановления системы) на вкладке Welcome или выберите команду ASR wizard из меню Tools. В первом окне программы-мастера подготовки к автоматическому восстановлению системы нажмите кнопку Next.
3. В следующем окне (Рисунок 23.14) вам потребуется указать тип носителя, на который будет производиться резервное копирование, а также указать путь к резервной копии. Как и в случае копирования системных конфигурационных данных, если компьютер оборудован ленточным устройством, вам потребуется выбрать это устройство из списка Backup media type (Тип носителя архива). Если ленточное устройство не установлено, то по умолчанию в этом списке будет установлена опция File. Введите полный путь к носителю или файлу резервной копии в поле Backup media or file name или нажмите кнопку Browse.

в работе Windows Server 2003

Предотвращение сбоев в работе Windows Server 2003


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

в вашем распоряжении имеется точная и достоверная информация об аппаратной конфигурации восстанавливаемого компьютера и установленном на нем программном обеспечении;

вы регулярно проводите плановые процедуры по профилактическому обслуживанию техники;

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

Конкретный план резервного копирования зависит от ваших специфических потребностей. Однако его разработка в обязательном порядке должна включать следующие шаги:
1. Выбор и приобретение устройства резервного копирования. В частности, перед приобретением устройства рекомендуется проанализировать его надежность, быстродействие, емкость, стоимость (с учетом затрат на приобретение необходимого количества съемных носителей), а также совместимость с Windows Server 2003. Поддерживаемые устройства должны быть перечислены в списке совместимых аппаратных средств (HCL), последнюю версию которого можно найти по адресу http://www.microsoft.com/hwdq/hcl/.
2. Тщательное тестирование как устройства резервного копирования, так и используемого для резервного копирования программного обеспечения.
3. Определение необходимого количества носителей и выработка расписания операций резервного копирования.

При появлении экрана где программа

Рисунок 23.19. При появлении экрана, где программа Setup предлагает на выбор опции установки Windows, восстановления поврежденной копии Windows или завершения программы установки, нажмите клавишу


При восстановлении контроллера домена Recovery Console требует для регистрации не обычный пароль администратора, а пароль, указанный для восстановления Active Directory (Directory Services Restore Mode Administrator Password). Этот пароль задается в процессе повышения роли сервера (promotion) до контроллера домена.
В частности, Recovery Console позволяет выполнять следующие операции:

форматировать разделы;

запускать и останавливать сервисы;

выполнять чтение и запись файлов;

восстанавливать поврежденные главные загрузочные записи (MBR).

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

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


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

Windows XP и Windows Server 2003, как и следовало ожидать, вводят технологические усовершенствования и в этой области. К числу таких усовершенствований относится и технология моментальных снимков тома (volume shadow сору), которая позволяет создать "моментальный снимок" жесткого диска на момент начала резервного копирования. В процессе резервного копирования будет использоваться этот "моментальный снимок" (остающийся неизменным), а не фактическое содержимое жесткого диска (которое в ходе резервного копирования может изменяться). Эта технология предоставляет особые преимущества тем пользователям, которым необходимо продолжать работу в ходе выполнения резервного копирования, т. к. она позволяет существенно сократить время, требующееся на завершение процесса резервного копирования. При этом приложение Backup может выполнять резервное копирование открытых файлов, с которыми на данный момент работает пользователь. Обратите внимание, что в Windows 2000 файлы, открытые на момент выполнения резервного копирования, исключались из резервной копии.
Чтобы вызвать программу Backup в Windows XP или Windows Server 2003, выберите из меню Start команды All Programs | Accessories | System Tools | Backup (разумеется, в случае частого использования этой программы для нее можно создать ярлык на рабочем столе). Помимо этого традиционного способа, вызов программы Backup можно осуществить и через контекстное меню, выводимое по нажатию правой кнопки мыши. Для этого в окнах Windows Explorer или My Computer укажите курсором на диск, для которого требуется выполнить резервное копирование, выполните щелчок правой кнопкой мыши и выберите из раскрывшегося меню команду Properties. В появившемся диалоговом окне перейдите на вкладку Tools и нажмите кнопку Backup Now (Рисунок 23.10).

Перед резервным копированием рекомендуется выполнить проверку файловой системы диска, чтобы полученная резервная копия была качественной и работоспособной. Следует помнить, что программы резервного копирования (в том числе и программа Backup, включенная в состав Windows XP или Windows Server 2003), не могут распознавать ошибки и повреждения в пользовательских данных. Обратите внимание, что при применении этого метода операцию проверки выполнять очень удобно — просто нажмите кнопку Check Now, расположенную на этой же вкладке.

Проверка системных файлов (System File Checker)

Проверка системных файлов (System File Checker)


В состав Windows 2000, Windows XP и Windows Server 2003 включено средство проверки системных файлов — System File Checker (Sfc.exe), которое представляет собой утилиту командной строки. Данная утилита сканирует все установленные системные файлы и выполняет проверку их версий. Если эта утилита обнаружит, что один из защищаемых системных файлов был замещен, она найдет корректную версию этого файла в каталоге %SystemRoot%\systern32\dllcache и запишет ее вместо измененного файла.
Эта утилита командной строки имеет следующий синтаксис: SFC [/SCANNOW] [/SCANONCE] [/SCANBOOT] [/REVERT] [/PURGECACHE] [/CACHESIZE=X]
где:
/SCANNOW — параметр, при использовании которого выполняется немедленное сканирование всех защищаемых системных файлов;
/SCANONCE — параметр, указывающий на необходимость однократного сканирования всех защищаемых системных файлов;
/SCANBOOT — параметр, задающий опцию сканирования всех защищаемых системных файлов при каждой перезагрузке;
/REVERT — установить для параметров сканирования значения, принятые по умолчанию;
/PURGECACHE — очищает файловый кэш System File Protection;
/CACHESIZE=X — устанавливает размер файлового кэша Windows File Protection (в мегабайтах). С помощью этой опции можно уменьшать или увеличивать объем дискового пространства, выделяемый для хранения кэшированных версий защищаемых системных файлов в папке %SystemRoot%\system32\dllcache.

Чтобы иметь возможность работы с утилитой sfc.exe, необходимо зарегистрироваться на компьютере как администратор или как пользователь, являющийся членом группы Administrators.
Если содержимое папки %SysfemRoot%\system32\dllcache окажется поврежденным, то вы сможете восстановить его, запустив команду sfc /scannow, sfc /scanonce или sfc /scanboot.

Регулярное выполнение профилактических процедур

Регулярное выполнение профилактических процедур


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

Довольно часто причиной некорректной работы системы или даже проблем с ее загрузкой может быть перезапись системного файла или же несовместимый драйвер. Обычно это происходит во время установки дополнительного программного обеспечения, несовместимого с операционной системой. Эта проблема существовала в Windows NT 4.0 и во всех более ранних версиях Windows NT. С выходом Windows 2000 были введены дополнительные средства защиты системных файлов и драйверов с помощью цифровой подписи, которая гарантирует их совместимость с операционной системой и корректную работу. В Windows XP и Windows Server 2003, в дополнение к существующим средствам защиты драйверов и системных файлов, появились новые функциональные возможности, такие как Driver Rollback. Во избежание возникновения проблем рекомендуется пользоваться этими средствами, которые будут подробно описаны далее в этой главе.

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

Рекомендуется ежедневно просматривать журналы системных событий (как минимум, журналы system и application). В особенности обращайте внимание на ошибки, генерируемые драйвером Ftdisk и драйверами жестких дисков, т. к. они могут указывать на возможные повреждения файловой системы. Если эта рекомендация не выполняется, то ошибки файловой системы могут остаться незамеченными до тех пор, пока программа Chkdsk не укажет на их существование. Стоит отметить, что при этом возможна даже такая ситуация, когда поврежденные данные попадут и на резервную копию, поскольку программы резервного копирования (в том числе и встроенная программа Backup, включенная в состав Windows 2000, Windows XP и Windows Server 2003) не могут распознавать ошибки и повреждения в пользовательских данных.

Регулярно выполняйте проверку дисков для своевременного обнаружения ошибок файловой системы. Кроме того, рекомендуется регулярно проводить и дефрагментацию дисков, что позволит избежать проблем с низкой производительностью. Стоит дать отдельное предупреждение о том, что для дефрагментации следует применять только встроенные средства операционной системы или утилиты сторонних производителей, имеющие статус "designed for Windows". Информацию о программном обеспечении, тестировавшемся на совместимость с Windows XP и Windows Server 2003, в том числе и об утилитах дефрагментации дисков, можно найти по адресу http://www.microsoft.com.

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

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


Помимо множества новых и чрезвычайно удобных функций программа Backup позволяет выполнить процедуру резервного копирования всех системных файлов. Чтобы упростить процедуру восстановления после сбоев, резервное копирование рекомендуется выполнять регулярно. Сделать это можно двумя различными способами. Первый способ заключается в использовании мастера Backup wizard (Мастер резервного копирования), который можно вызвать, выбрав переключатель Back up files and settings во втором окне программы Backup, работающей в режиме мастера, или выбрав команду Backup Wizard из меню Tools. Пользоваться этим методом рекомендуется начинающим пользователям, не имеющим достаточного опыта в работе с системой.
Помимо использования мастера, процедуру резервного копирования можно выполнить и вручную. Для этого вызовите программу Backup в расширенном режиме (Advanced Mode), перейдите на вкладку Backup и вручную выберите из списка дисков, файлов и папок, подлежащих резервному копированию, опцию System State (Состояние системы) (Рисунок 23.11).

Способы запуска Recovery Console

Способы запуска Recovery Console


Существуют следующие способы запуска Recovery Console.

Если вы не можете выполнить загрузку Windows XP/Windows Server 2003 с жесткого диска, запустите Recovery Console с дистрибутивного компакт-диска (если на вашем компьютере установлено устройство CD-ROM, с которого можно выполнять загрузку операционной системы). Если загрузка с компакт-диска невозможна, загрузите компьютер с загрузочной дискеты и запустите программу Setup из командной строки (необходимую информацию по данному вопросу можно найти в главе 1 "Планирование и установка системы").

Recovery Console можно установить на жестком диске вашего компьютера и включить ее как одну из доступных опций в меню загрузки.

Удаление Recovery Console

Удаление Recovery Console


Если требуется удалить Recovery Console из списка опций, доступных в меню загрузки, выполните следующие операции:
1. Из корневого каталога системного раздела удалите папку \cmdcons и файл cmldr.

Папка \cmdcons и файл cmldr имеют атрибуты Hidden и System, а это значит, что они принадлежат к числу файлов, защищаемых операционной системой, и по умолчанию не отображаются графической оболочкой Windows. Поэтому не забудьте настроить опции отображения папок с помощью значка Folder Options на панели управления.
2. Откройте для редактирования файл Boot.ini, найдите в его составе строку, соответствующую опции запуска Recovery Console, и удалите ее. Пример, иллюстрирующий, как может выглядеть такая строка, приведен ниже.
С:\CMDCONS\BOOTSECT.DAT="Microsoft Windows Recovery Console" /cmdcons

Установка Recovery Console на жесткий диск

Установка Recovery Console на жесткий диск


Чтобы установить Recovery Console на жесткий диск и указывать ее в качестве одной из опций меню загрузки, выполните следующие операции:
1. Зарегистрируйтесь в Windows Server 2003 как администратор или пользователь, принадлежащий к группе Administrators.
2. Вставьте дистрибутивный компакт-диск в устройство CD-ROM.
3. В режиме командной строки перейдите на дистрибутивный диск и введите команду \I386\winnt32.exe /cmdcons
4. Следуйте инструкциям, появляющимся на экране.

Уведомление о невозможности отката драйвера

Рисунок 23.9. Уведомление о невозможности отката драйвера


4. Менеджер устройств предложит вам подтвердить намерение выполнить откат драйвера. Нажмите кнопку Yes. Если старая версия драйвера недоступна, функция Driver Roll Back выведет окно с уведомлением (Рисунок 23.9) и предложит воспользоваться другими средствами устранения неполадок.

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

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


Как уже упоминалось, аварийные ситуации необходимо предвидеть, и на случай их возникновения жизненно важно иметь точную и достоверную информацию об аппаратной конфигурации компьютера и установленном на нем программном обеспечении. Администраторам сетей, в чьи обязанности входит обеспечение работоспособности всех подключенных к сети компьютеров, рекомендуется завести специальный журнал, в котором будет фиксироваться вся информация об аппаратной и программной конфигурации каждого из компьютеров.
Сопроводительную документацию, полученную от поставщика в комплекте с вашим компьютером, храните таким образом, чтобы в нужный момент она всегда была под рукой. Эта документация может оказаться неоценимым подспорьем при устранении проблем, возникающих уже на стадии самотестирования при включении (POST).
В отношении программной конфигурации Microsoft официально рекомендует регистрировать следующую информацию:

сведения о конфигурации жестких дисков, в том числе расположении и размерах каждого раздела и каждого логического диска;

информацию обо всех установленных на компьютере операционных системах и разделах, на которых они установлены;

информацию о дополнительном программном обеспечении, установленном на компьютере.

Верификация цифровой подписи файлов

Верификация цифровой подписи файлов (File Signature Verification)


Как уже говорилось, в некоторых случаях установка нового программного обеспечения приводит к замещению системных файлов некорректными или несовместимыми версиями (которые, естественно, не имеют цифровой подписи). Такая замена, как уже неоднократно упоминалось, как раз и может послужить источником возможных проблем с нестабильностью системы (в том числе ошибок типа "синий экран" и проблем с загрузкой Windows XP/ Windows Server 2003).
Во избежание такого рода проблем все системные файлы, устанавливаемые в процессе инсталляции Windows XP или Windows Server 2003, снабжены цифровой подписью Microsoft. Если системный файл имеет такую подпись, это может служить гарантией его совместимости с операционной системой и указывает на то, что данный файл либо представляет собой оригинальную версию, разработанную Microsoft, либо прошел тестирование и признан пригодным для использования с Windows XP/Windows Sewer 2003. Использование средства верификации цифровой подписи файлов позволяет идентифицировать все установленные на проверяемом компьютере файлы, не имеющие цифровой подписи, и получить об этих файлах следующую информацию:

имя файла и точный путь к нему;

дату модификации файла;

тип файла и точный номер его версии.

Чтобы запустить средство верификации цифровых подписей файлов, нажмите кнопку Start, из раскрывшегося меню выберите команду Run и введите команду sigverif.
Максимальную практическую пользу при устранении проблем, связанных с заменой системных файлов некорректными версиями, можно получить, регистрируя информацию, собранную программой Sigverif, в файле журнала. Для этой цели проделайте следующее:
1. Запустите программу Sigverif, и в появившемся на экране окне File Signature Verification (Верификация подписи файлов) (Рисунок 23.5) нажмите кнопку Advanced (Дополнительно).
2. В раскрывшемся диалоговом окне Advanced File Signature Verification Settings (Дополнительные параметры верификации подписей файлов) перейдите на вкладку Logging (Журнал) (Рисунок 23.6) и установите флажок Save the file signature verification results to a log file (Сохранять результаты проверки в файле журнала).
3. Перейдите в группу Logging options (Опции журнала), где имеется возможность установить по выбору следующие опции ведения файла журнала:

Append to existing log file (Добавлять новые записи в конец существующего файла) — если установить этот переключатель, то результаты новой операции поиска будут добавлены в конец существующего файла журнала;

Overwrite existing log file (Перезаписывать существующий файл) — если выбран этот переключатель, то результаты новой операции сканирования заместят существующий файл журнала;

В поле Log file name (Имя файла журнала) можно вручную ввести имя файла журнала.

Вкладка Driver диалогового окна

Рисунок 23.8. Вкладка Driver диалогового окна свойств аппаратного устройства (на примере сетевого адаптера)

Вкладка Hardware диалогового окна System Properties

Рисунок 23.1. Вкладка Hardware диалогового окна System Properties

если установлен переключатель Warn - Prompt me each time to choose an action (Предупреждать — запрашивать подтверждения при каждой попытке установки неподписанного файла), то система будет выводить предупреждающие сообщения при попытке установить драйвер или системный файл, не имеющий цифровой подписи (Рисунок 23.3). Обратите внимание, что, несмотря на вывод предупреждения, драйвер, тем не менее, будет установлен. Стоит отметить, что возможны и такие ситуации, когда Microsoft еще не имеет программы сертификации для устройств, которые вы попытаетесь установить (Рисунок 23.4). В особенности это относится к новым типам устройств, появившимся на рынке относительно недавно и еще не получившим широкого распространения. Тем не менее, практически все такие устройства (портативные накопители, инфракрасные порты, цифровые фотокамеры, Bluetooth-адаптеры и т. д.) устанавливаются без проблем и прекрасно работают — проверено личной практикой;

если установлен переключатель Block - Never install unsigned driver software (Блокировать — никогда не устанавливать драйверов, не имеющих цифровой подписи), то драйверы, не имеющие цифровой подписи, устанавливаться не будут.

Вкладка Logging окна Advanced

Рисунок 23.6. Вкладка Logging окна Advanced File Signature Verification Settings


4. Нажмите кнопку ОК. Вы вернетесь в окно File Signature Verification. Чтобы начать операцию сканирования, нажмите в этом окне кнопку Start. Степень завершенности процесса сканирования будет отражаться индикатером Scanning files (Сканирование файлов). Для отмены сканирования нажмите кнопку Stop. По завершении процесса сканирования на экране появится окно Signature Verification Results (Результаты сканирования) (Рисунок 23.7), в котором будет отображен список всех обнаруженных файлов, не имеющих цифровой подписи.

Вкладка Tools диалогового окна

Рисунок 23.10. Вкладка Tools диалогового окна свойств диска позволяет быстро выполнить резервное копирование всех файлов, расположенных на этом диске

Воссоздание отсутствующей дискеты ASR

Рисунок 23.18. Воссоздание отсутствующей дискеты ASR

Воссоздание утерянной дискеты ASR

Воссоздание утерянной дискеты ASR


В заключение обсуждения процесса ASR давайте рассмотрим одну неприятную, но весьма вероятную ситуацию. Предположим, что вам необходимо выполнить процедуру ASR, и вы вдруг обнаруживаете, что потеряли дискету ASR. Значит ли это, что все потеряно? Нет, ничего еще не потеряно, поскольку если ваш носитель с резервной копией ASR пригоден к использованию, то вы имеете возможность воссоздать недостающую дискету ASR.
Если вы изготовили хотя бы одну дискету ASR, то практически наверняка поинтересовались, какие же файлы на нее сохраняются (а файлы asr.sif, asrpnp.sif и setup.log представляют собой текстовые файлы формата ASCII, которые можно просмотреть с помощью любого текстового редактора, например, Notepad.exe). И, наконец, самая хорошая новость заключается в том, что эти файлы не только копируются на дискету ASR, но и включаются в состав резервной копии ASR, откуда их без особого труда можно извлечь с помощью все той же программы Backup (причем для этой цели годится не только версия Backup, входящая в состав Windows XP или Windows Server 2003, но и программа Backup, поставляемая в составе Windows 2000).
Итак, для воссоздания отсутствующей дискеты ASR проделайте следующее:
1. Отформатируйте дискету емкостью 1,44 Мбайт и вставьте ее в дисковод любого компьютера, работающего под управлением одной из перечисленных выше систем.
2. Запустите программу Backup и перейдите на вкладку Restore and Manage Media (Windows XP/Windows Server 2003) или на вкладку Restore (Windows 2000). Вставьте свой носитель с резервной копией ASR в устройство резервного копирования и выберите команду Catalog a backup file из меню Tools. В следующем окне укажите путь к резервной копии (при необходимости можно нажать кнопку Browse).
3. Выберите носитель, содержащий копию ASR и в левой части окна программы Backup разверните архив, соответствующий диску ASR, который требуется воссоздать.
4. Разверните папку %SystemRoot%\Kpair и пометьте для восстановления следующие файлы: asr.sif, asrpnp.sif и setup.log (Рисунок 23.18). В списке Restore files to выберите опцию Alternate location, а в поле Alternate location укажите путь к корневому каталогу дискеты ("А:\").
5. Нажмите кнопку Start Restore. Выбранные файлы будут скопированы на дискету. Извлеките дискету из дисковода и используйте ее в ходе восстановления ASR.

Восстановление системных данных

Восстановление системных данных


Если все ваши попытки восстановить поврежденную систему завершатся неудачей, и не останется другого выхода кроме переинсталляции, работеспособная копия системных конфигурационных данных вам очень и очень пригодится.
Чтобы восстановить системные конфигурационные данные (System State data), вызовите программу Backup в режиме Advanced Mode, перейдите на вкладку Restore and Manage Media (Восстановление и управление носителями) и в окне Expand the desired media item, then check the box for the items to restore (Разверните узел нужного носителя, затем установите флажки около тех объектов, которые требуется восстановить) установите флажок System State. Затем нажмите кнопку Start Restore, и через некоторое время будут восстановлены системные файлы, а также любые другие запрошенные данные.

Если при выполнении процедуры восстановления системных данных не указан альтернативный каталог для их восстановления, то программа Backup удалит все системные данные, используемые на текущий момент, и заменит их данными с резервной копии. Вследствие взаимозависимости всех компонентов, образующих системные конфигурационные данные, они включаются в процедуры резервного копирования и восстановления только как единое целое.
Тем не менее, восстановление компонентов системных данных можно выполнять в другой (альтернативный) каталог, и в этом случае текущее состояние (том SYSVOL, файлы базы данных кластера и файлы, необходимые для загрузки системы, база данных Active Directory, база данных сервера сертификатов и информация классов СОМ+) останется неизменным.
Кроме того, выполняя восстановление системных конфигурационных данных, необходимо помнить о следующих факторах:

для выполнения восстановления системных конфигурационных данных необходимо иметь в локальной системе права администратора или оператора резервного копирования;

если восстановление системных конфигурационных данных выполняется на контроллере домена, то пользователь, осуществляющий процедуру восстановления, должен будет выбрать режим выполнения этой операции. По умолчанию программа Backup выполняет восстановление данных о конфигурации системы в так называемом непринудительном (nonauthoritative) режиме, при использовании которого все реплицируемые данные (например, базы данных Active Directory или содержимое тома SYSVOL) после восстановления с резервной копии будут обновляться данными, поступающими с других контроллеров домена. Если требуется изменить это положение вещей, необходимо выполнять восстановление в так называемом принудительном (authoritative) режиме, с обязательным использованием системной утилиты Ntdsutil, которую следует запускать сразу же после восстановления данных, но до перезагрузки контроллера домена. Утилита Ntdsutil позволяет помечать объекты для принудительного восстановления, что гарантирует их правильную репликацию после восстановления данных;

перед выполнением восстановления системных конфигурационных данных на контроллере домена необходимо выполнить загрузку компьютера в режиме, называемом режимом восстановления службы каталогов (directory services restore mode), который представляет собой одну из опций меню режима безопасной загрузки. Этот режим позволит восстановить том SYSVOL и базу данных Active Directory;

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

Восстановление системы

Восстановление системы


Несмотря на то, что Windows Server 2003 по надежности и отказоустойчивости превосходит все предшествующие версии Windows, давайте посмотрим на веши реально: поскольку проблемы с загрузкой возможны при работе с любой операционной системой, то и Windows Server 2003 не является исключением из общего правила. Несмотря на новое название, эта операционная система является логическим продолжением семейства операционных систем Windows NT/2000/XP, и по этой причине в процессе загрузки Windows Server 2003 могут возникать некоторые проблемы, с которыми сталкивались пользователи этих операционных систем. В частности, возникновение проблем может быть вызвано:

сбоями в работе жесткого диска или ошибками в работе контроллера жесткого диска;

сбоями в подаче электропитания;

некорректно работающими приложениями и плохо написанными драйверами устройств;

вирусной атакой;

ошибками пользователей (человеческий фактор никогда не следует сбрасывать со счетов).

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

Возможности отката драйверов (Driver Rollback)

Возможности отката драйверов (Driver Rollback)


В дополнение к средствам обеспечения отказоустойчивости, появившимся в Windows 2000, системы Windows XP и Windows Server 2003 предлагают еще одно удобное новшество — возможности отката драйверов (Driver Rollback). Довольно часто такие проблемы, как аппаратные конфликты, нестабильное поведение системы, неправильная работа устройств и даже ошибки STOP бывают вызваны некорректным драйвером. Стоит ли говорить, что в такой ситуации весьма желательно было бы иметь возможность быстрой замены проблемного драйвера на предыдущую версию без переустановки системы.
Функция Driver RollBack оказывается просто незаменимой при устранении неполадок, а также при отладке бета-версий драйверов. Например, если после установки обновленного драйвера при загрузке появляется сообщение STOP, вы имеете возможность попытаться загрузить систему в безопасном режиме и произвести откат драйвера.
Чтобы воспользоваться функцией отката драйверов, проделайте следующее:
1. Вызовите опцию System на панели управления, перейдите на вкладку Hardware и нажмите кнопку Device Manager (Менеджер устройств).
2. Выполните щелчок правой кнопкой мыши, указав на устройство, обновленный драйвер которого вызывает проблему, и выберите из контекстного меню команду Properties.
3. В раскрывшемся диалоговом окне свойств выбранного устройства перейдите на вкладку Driver (Драйвер) (Рисунок 23.8). Нажмите кнопку Roll Back Driver (Откат драйвера).

Выполнение процесса аварийного

Выполнение процесса аварийного восстановления с помощью резервной копии ASR


Процесс аварийного восстановления поврежденной системы с использованием процедуры ASR запускается из программы установки операционной системы — Windows Server 2003 Setup. Таким образом, для его выполнения вам, помимо резервной копии ASR и дискеты ASR, потребуется также дистрибутивный компакт-диск. Фактически этот процесс очень похож на процедуру автоматической установки операционной системы. Процедура ASR восстановит вашу конфигурацию дисковой подсистемы с использованием данных, сохраненных на дискету ASR, переформатирует раздел %SystemDrive% (тот, на котором установлена копия ОС, подлежащая восстановлению), затем переустановит на этот раздел Windows Server 2003 и восстановит конфигурационную информацию системы с резервной копии.

Следует понимать, что подготовка к ASR не является заменой регулярных процедур резервного копирования. Так, она не исключает риска потери данных, поскольку не выполняет резервного копирования файлов приложений и пользовательских данных. Как уже было сказано, в ходе выполнения процесса восстановления поврежденной системы процедура ASR выполняет переформатирование раздела %SystemDrive%, не восстанавливая при этом файлов приложений и пользовательских данных, которые могут находиться на этом диске (например, в папке Program Files). Таким образом, если вы устанавливаете на этот диск приложения и храните на нем пользовательские данные, то после выполнения процедуры ASR вся эта информация будет уничтожена. Следовательно, прежде, чем прибегать к такому радикальному средству восстановления, как ASR, необходимо попытаться использовать другие опции восстановления, например, System Restore или Recovery Console (установка, запуск и использование Recovery Console будут подробно описаны далее в этой главе).
Чтобы провести процесс аварийного восстановления с помощью ASR, выполните следующую последовательность шагов:
1. Подготовьте все необходимое для процесса ASR, в том числе:

дискету ASR с конфигурационной информацией, соответствующей конфигурации вашего компьютера на тот момент, когда вы в последний раз выполняли процедуру подготовки ASR;

дистрибутивный компакт-диск Windows Server 2003;

носитель с резервной копией данных ASR (как правило, это съемный носитель, например, магнитная лента).

2. Запустите программу Setup. Самый простой способ заключается в перезагрузке компьютера с дистрибутивного компакт-диска.
3. Нажмите любую клавишу, когда на экране появится сообщение Press any key to boot from the CD....
4. Когда запустится программа Windows XP Setup, дождитесь появления сообщения Press F2 to run Automated System Recovery (ASR) И нажмите клавишу .
5. Вставьте в дисковод дискету ASR, когда программа Windows Server 2003 Setup предложит вам сделать это.
6. На экране появится сообщение следующего содержания: Preparing to ASR, press to cancel
Обратите внимание, что на данном этапе вы еще имеете возможность передумать и отказаться от выполнения ASR, нажав клавишу .
Если вы не сделаете этого, то процедура ASR запустится и в качестве первого шага сразу же начнет форматирование вашего раздела %SystemDrive%.
7. Если вы намерены продолжать процедуру, не реагируйте на предложение нажать клавишу для отмены. Программа Setup отобразит следующие сообщения:

Setup is starting the ASR... Setup is loading files Setup is starting Windows
После этого процесс ASR начнет переформатирование раздела %SystemDrive% и проверку остальных разделов с целью определить, не нуждаются ли они в восстановлении.

Обратите внимание, что помимо переформатирования раздела %SystemDrive%, процедура ASR может также выполнить инициализацию других томов (если она определит, что они также нуждаются в восстановлении). Поскольку ASR восстанавливает только данные системы, то существует риск потери данных, хранящихся и на этих томах.
8. После форматирования и завершения проверки всех разделов ASR построит список файлов для копирования и предложит вам вставить носитель с резервной копией ASR. Если при подготовке к ASR резервное копирование выполнялось в файл, то этот шаг будет пропущен. Далее процедура ASR фактически выполнит автоматическую установку Windows Server 2003, а затем восстановит системную конфигурацию.

Следует учесть, что процедура ASR не поддерживает восстановления данных с общих сетевых ресурсов. Поэтому при восстановлении следует указывать только локальные устройства (например, локально подключенные ленточные устройства, съемные носители или локальные жесткие диски). Если при подготовке к ASR вы выполняли резервное копирование в файл на жестком диске, то следует иметь в виду, что ASR поддерживает тома FAT16 объемом не более 2,1 Гбайт. Если резервная копия ASR находится на разделе большего объема, то процесс ASR завершится неудачей. В этих случаях перед запуском ASR следует сначала преобразовать раздел FAT16 в формат NTFS.
Стоит отметить, что если кроме всех компонентов, необходимых для выполнения процедуры ASR, в вашем распоряжении имеется полная резервная копия всех данных, то ASR в сочетании с последующим восстановлением этих данных предоставляет довольно надежный способ восстановления поврежденной системы. Тем не менее, общая рекомендация заключается в следующем: прежде чем прибегать к процессу ASR, попытайтесь сначала воспользоваться другими средствами восстановления поврежденной системы, например такими, как загрузка в безопасном режиме (Safe Mode).

Запуск Recovery Console из программы

Запуск Recovery Console из программы Windows Server 2003 Setup


Как уже говорилось, Recovery Console можно запустить из программы Windows Server 2003 Setup. Разумеется, для этой цели вам потребуется загрузочное устройство CD-ROM или загрузочная дискета и доступ к дистрибутивным файлам для запуска программы Setup. Независимо от того, каким образом будет запущена программа Setup, в этом случае ^ам придется затратить некоторое время на ожидание (ждать придется до [тех пор, пока не завершится процесс начального копирования базовых драйверов). При появлении экрана, где программа Setup предлагает на выбор установить Windows Server 2003, восстановить поврежденную копию ОС или завершить программу установки, нажмите клавишу (Рисунок 23.19).
После этого программа Setup выполнит просмотр жестких дисков компьютера в поисках существующих копий Windows, которые могут нуждаться в восстановлении. Обнаружив несколько таких копий, Setup предложит вам выбрать ту, которую вы собираетесь восстанавливать, а затем — ввести пароль пользователя Administrator. Успешно зарегистрировавшись в выбранной системе Windows, вы получите в свое распоряжение мощный набор административных средств восстановления, предоставляющий вам самые широкие возможности.

Защита системных файлов (Windows File Protection)

Защита системных файлов (Windows File Protection)


Все версии Windows, предшествовавшие Windows 2000, имели один общий недостаток — при установке дополнительного программного обеспечения практически любые совместно используемые системные файлы, в том числе *.dll и *.ехе, могли быть изменены. Последствия замены этих файлов некорректными или несовместимыми версиями могли быть непредсказуемыми: от снижения производительности операционной системы до некорректного поведения остальных приложений, периодического появления ошибок STOP и даже проблем с загрузкой.
В Windows 2000 впервые за всю историю Windows была сделана попытка исправления этой ситуации. Разумеется, эта же функциональная возможность присутствует и в Windows ХР, а также в продуктах из семейства Windows Server 2003. Функция защиты системных файлов Windows (Windows File Protection, WFP) включает в свой состав следующие два компонента:

сервис защиты системных файлов (Windows File Protection service);

утилиту командной строки System File Checker (Sfc.exe).

Сервис Windows File Protection (WFP) работает по принципу определения цифровых подписей защищенных системных файлов (в их число входят файлы с расширениями sys, dll, ocx, ttf, fon и ехе), не позволяя произвольно модифицировать и замещать эти файлы. Сервис Windows File Protection работает в фоновом режиме и защищает все системные файлы, установленные программой Setup при инсталляции операционной системы. Выявив попытку изменения или перемещения защищенного файла, WFP проверяет измененный файл на наличие у него цифровой подписи. В случаях, когда версия, предназначенная на замену, не является корректной, Windows File Protection замещает этот файл резервной копией из папки %SystemRoot% \system32\dllcache и регистрирует попытку замещения файла в журнале системных событий.

Папка %SystemRoot%\System32\Dllcache может быть достаточно объемной и занимать до 300 Мбайт дискового пространства. По этой причине некоторые пользователи, в целях освобождения дополнительного дискового пространства, удаляют эту папку вместе со всем ее содержимым. Если дополнительный объем дискового пространства для вас актуален, вы тоже можете поступить таким образом. Однако при этом следует иметь в виду, что если сервис WFP не сможет обнаружить надлежащей версии файла в папке %SystemRoot%\system32\dllcache, то вам будет предложено вставить дистрибутивный компакт-диск в устройство CD-ROM или указать путь к каталогу, из которого такая версия может быть скопирована.
По умолчанию функция WFP всегда активизирована и позволяет выполнять замену системных файлов только в случае установки следующих видов программного обеспечения:

сервисных пакетов Windows 2000/XP и Windows Server 2003 (с использованием программы Update.exe);

дистрибутивных пакетов типа Hotfix (с использованием Hotfix.exe);

обновлений версии операционной системы (с помощью Winnt32.exe);

программного обеспечения с сайта Windows Update.

Защита системных файлов

Защита системных файлов


Все системные файлы и драйверы в Windows XP и Windows Server 2003 защищены с помощью цифровой подписи. Это сделано, чтобы гарантировать их совместимость с операционной системой. Цифровая подпись Microsoft гарантирует, что файл, подписанный ею, тестировался на совместимость с Windows XP или Windows Server 2003 в лабораториях WHQL (Windows Hardware Quality Labs) и не был модифицирован или переписан во время установки дополнительного программного обеспечения.
Windows XP и Windows Server 2003 выполняют проверку наличия цифровой подписи для драйверов следующих типов устройств:

клавиатуры

сетевых адаптеров

контроллеров жестких дисков

принтеров

модемов

адаптеров SCSI

мыши

устройств чтения смарт-карт

мультимедийных устройств

видеоадаптеров

В зависимости от установленных опций настройки, Windows может либо игнорировать драйверы, не имеющие цифровой подписи, либо выводить предупреждение при обнаружении таких драйверов (эта опция используется по умолчанию), или же просто не допускать их установки. Чтобы установить опции защиты системных файлов в Windows XP и продуктах из семейства Windows Server 2003, проделайте следующее:
1. Вызовите опцию System на панели управления и в раскрывшемся диалоговом окне System Properties перейдите на вкладку Hardware (Рисунок 23.1).
2. Нажмите кнопку Driver Signing. На экране появится диалоговое окно Driver Signing Options (Опции подписанных драйверов), показанное на Рисунок 23.2. В этом окне имеется группа переключателей What action do you want Windows to take? (Какие действия в отношении неподписанных драйверов должна предпринимать Windows?), позволяющая установить следующие опции:

если установлен переключатель Ignore - Install the software anyway and don't ask for my approval (Игнорировать — устанавливать программное обеспечение, не запрашивая подтверждения), то система даст возможность устанавливать любые драйверы и системные файлы, игнорируя наличие или отсутствие у них цифровой подписи. Как уже упоминалось, отсутствие у драйвера или системного файла цифровой подписи указывает на то, что его совместимость с Windows XP/Windows Server 2003 официально не подтверждена, и он, возможно, станет источником проблемы;

Internet Information Services 6.0

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

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


Непосредственное редактирование реестра, даже в тех случаях, когда оно необходимо, при условии неумелого выполнения может привести к большим неприятностям. Поэтому, если вы чувствуете себя неуверенно или просто не можете позволить себе затратить значительное время для проведения восстановительных работ, не ставьте смелых экспериментов над реестром своей операционной системы (будь то Windows NT 4.0/Windows 2000, Windows XP или Windows Server 2003). Вполне возможно, что единственная ошибка приведет к необходимости переустановки операционной системы.

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

Диалоговое окно Add to Favorites

Рисунок 24.11. Диалоговое окно Add to Favorites

Диалоговое окно Export Registry File

Рисунок 24.4. Диалоговое окно Export Registry File


3. Если требуется сохранить часть реестра, выбирайте опцию сохранения только выделенной ветви реестра. Для этого установите переключатель Selected branch из группы Export range. Однако, если вы часто модифицируете реестр, то экспорт всего реестра целиком — неплохая идея. Это даст вам дополнительные гарантии восстановления в случае ошибки.
4. Нажмите кнопку Save.
Сохраненный файл можно просмотреть в текстовом редакторе, чтобы убедиться в правильности сохранения. Экспортированные файлы реестра содержат текст ASCII без каких-либо символов форматирования.

Нужно помнить, что файлы с расширением гед по умолчанию ассоциированы с приложением Regedit.exe. По умолчанию над такими файлами выполняется операция merge (слияние), которая импортирует содержимое данного файла в реестр. Чтобы избежать случайного импорта в реестр экспортированного файла, будьте внимательны и осторожны при обращении с такого рода файлами.
Обращаясь с экспортированными файлами реестра, следует соблюдать осторожность, особенно в том случае, если экспорт производится с целью экспериментов. Например, опытные администраторы, хорошо знакомые с реестром, экспериментируют над своей системой или решают некоторые проблемы путем редактирования экспортированного файла реестра, а затем импортируют его обратно в систему. Однако перед тем, как вносить такие изменения, рекомендуется принять следующие меры предосторожности:
1. Предварительно создайте резервную копию экспортированного файла, который требуется редактировать. Если при редактировании будет допущена ошибка, которая приведет к возникновению проблем, можно будет импортировать в реестр резервную копию этого REG-файла.
2. Если вы часто экспериментируете с реестрами различных операционных систем, то экспортированные файлы реестров каждой из этих операционных систем рекомендуется держать отдельно друг от друга, в различных каталогах, специально выделенных для этой цели. Это поможет избежать случайного импорта в систему несовместимого файла реестра.
Команды Load Hive (Загрузить улей) и Unload Hive (Выгрузить улей) действуют по аналогии с одноименными командами, существовавшими в редакторе реестра Regedt32.exe. Они позволяют загрузить в реестр ранее сохраненный файл улья или выгрузить ранее загруженный файл улья соответственно. Следует отметить, что эти команды меню File действуют только применительно к ключам HKEY_USERS И HKEY_LOCAL_MACHINE и будут эфективны только в том случае, когда выбран один из этих ключей. Во всех остальных случаях эти команды будут недоступны. Улей, будучи загружен в реестр, станет вложенным ключом одного из упомянутых выше ключей.
Команда Connect Network Registry (Подключить сетевой реестр) позволяет выполнить редактирование реестра на другом компьютере, работающем в составе сети.
Чтобы отключиться от реестра, расположенного на удаленном компьютере, используется команда Disconnect Network Registry (Отключить сетевой реестр). Если вы на текущий момент не подключены к сетевому реестру, эта опция будет недоступна.

Для выполнения таких процедур, как загрузка и выгрузка ульев, а также подключение к реестру удаленного компьютера, необходимо иметь права администратора или пользователя из группы Administrators. Если компьютер подключен к сети, то параметры настройки сетевой политики также окажут влияние на возможность выполнения этих процедур.
Команду Print из меню Registry можно использовать для распечатки выбранной ветви реестра (которая может потребовать довольно большое количество листов бумаги).
Команда Exit закрывает окно Regedit и завершает сеанс работы с этой программой.

Диалоговое окно позволяющее задать

Рисунок 24.6. Диалоговое окно, позволяющее задать права доступа к ключам реестра


4. Чтобы установить аудит на доступ к реестру и задать комбинацию прав доступа типа Special Permissions, нажмите кнопку Advanced (Дополнительно). Раскроется диалоговое окно Advanced Security Settings for , где — имя ключа, для которого требуется задать расширенные права доступа (Рисунок 24.7). Выберите имя пользователя или группы из списка Permission entries и нажмите кнопку Edit. Раскроется следующее окно (Рисунок 24.8), в котором вам будут предоставлены опции по расширенному редактированию прав доступа к ключам реестра. Типы прав доступа, которые вы сможете установить в этом окне, перечислены в табл. 24.8.

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

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


В Windows NT/2000/XP и Windows Server 2003 элементы реестра хранятся в виде атомарной структуры. Реестр подразделяется на составные части, которые разработчики этой операционной системы назвали ульями (hives) по аналогии с ячеистой структурой пчелиного улья. Улей представляет собой дискретную совокупность ключей, вложенных ключей и параметров, берущую начало в вершине иерархии реестра. Отличие ульев от других групп ключей состоит в том, что они являются постоянными компонентами реестра. Ульи не создаются динамически при загрузке операционной системы и не удаляются при ее остановке. Таким образом, ключ HKEY_LOCAL_MACHiNE\Hardware, который строится динамически распознавателем аппаратных средств при запуске операционной системы, ульем не является.
Данные ульев реестра хранятся в файлах, которые находятся в каталогах %SystemRoot%\system32\Config и %SystemRoot'%\Profiles\%Username% (Windows NT 4.0) и %SystemRoot%\system32\Config, и %SystemDrive%\ Documents and Settings\%Username% (Windows 2000, Windows XP и Windows Server 2003).
Каждый улей реестра ассоциирован с набором стандартных файлов. В табл. 24.3 перечислены стандартные ульи реестра Windows NT/2000/XP и Windows Server 2003 и поддерживающие их файлы.

Иллюстрирует иерархическую структуру

Рисунок 24.1 иллюстрирует иерархическую структуру реестра.

Интерфейс программы Regedit

Интерфейс программы Regedit


Окно редактора реестра Regedit.exe состоит из четырех основных областей (Рисунок 24.3).

Строка меню. В этой строке содержатся основные пункты меню: File, Edit, View, Favorites (этот пункт меню впервые был введен в Windows 2000) и Help.

Левая панель (левое подокно). Отображает иерархию реестра, организованную в виде ключей (в литературе они часто обозначаются термином "разделы") и вложенных ключей (другие часто встречающиеся термины — "подключи" или "подразделы").

Правая панель (правое подокно). Показывает текущие параметры выбранного ключа реестра, известные также как значимые элементы (value entires). Каждый параметр реестра характеризуется именем, отображаемым в столбце Name правой панели, типом данных, отображаемым в столбце Туре (на тип данных указывает и небольшой значок, расположенный чуть левее имени), и значением, отображаемым в столбце Data.

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

Использование редактора реестра

Использование редактора реестра


Большинство операционных систем Windows имеет в своем составе утилиты, предназначенные для просмотра и редактирования реестра, так называемые редакторы реестра. В Windows NT/2000 существует два таких редактора. Традиционная программа редактирования реестра Windows NT носит название Regedt32.exe. Эта программа наследуется от предыдущих версий Windows NT и позволяет редактировать реестр Windows NT/2000 с помощью методов, которые не поддерживаются в Windows 9x/ME. Более новая программа, Regedit.exe, была первоначально написана для Windows 95. Она обладает многими из возможностей Regedt32.exe и снабжена интерфейсом Windows Explorer. Версия Regedit.exe, которая имеется в составе Windows NT/2000, почти полностью идентична аналогичному приложению, имеющемуся в составе Windows 9x/ME. По сравнению с Windows NT/2000, Windows XP и продукты из семейства Windows Server 2003 и в этой области предлагают усовершенствование. Теперь все задачи по редактированию реестра могут выполняться только с помощью редактора реестра Regedit.exe, который в дополнение к своим традиционным возможностям предоставляет и все функции, которые ранее были доступны только через редактор Regedt32.exe (установка разрешений на доступ к ключам реестра, импорт и экспорт поддеревьев реестра и др.).

Стоит, правда, отметить и то, что Regedit.exe в Windows XP и Windows Server 2003 не реализует одной, но очень важной функции, которая была присуща Regedt.32.exe. Речь идет о возможности использования редактора реестра в режиме "только для чтения". Этот режим позволяет защитить реестр от случайных непреднамеренных изменений в процессе его просмотра и знакомства с его структурой. Именно наличие команды Read Only Mode в меню Options и делало Regedt32.exe предпочтительным средством, с помощью которого новички могли безбоязненно начинать знакомство со структурой реестра.

Ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\

Рисунок 24.16. Ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\BackupRestore\AsrKeysNotToRestore




Рисунок 24.18. Ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters

EnablePMTUDiscovery (тип данных REG_DWORD). Значение, по умолчанию устанавливаемое для данного параметра, позволяет TCP/IP определять максимальный размер передаваемого фрагмента (maximum transmission unit, MTU), который может быть передан системе. В принципе, это опасно, поскольку дает возможность обойти систему защиты или вывести ее из строя путем передачи фрагментированного трафика (например, многие системы обнаружения атак не умеют правильно восстанавливать фрагментированные IP-пакеты). Если для этого параметра установить значение 0, то MTU всегда будет установлено на значение 576 байт.

KeepAlive (тип данных REG_DWORD). Этот параметр указывает, насколько часто будет осуществляться проверка и верификация активности открытых соединений. Для этого параметра рекомендуется установить значение 300 000.

synAttackProtect (тип данных REG_DWORD). Создание этого параметра позволяет защититься от атак SYN Flood, препятствующих нормальному процессу установления соединения между клиентом и сервером. При нормальных условиях, этот процесс протекает в три этапа.

Клиент отправляет серверу запрос на установление соединения (SYN).

Сервер отвечает отправкой подтверждения (SYN-ACK).

Клиент подтверждает прием, отправляя сообщение АСК.

Если сервер стал мишенью для атаки SYN Flood, он будет получать огромное количество запросов на соединения, что создаст препятствия в получении подтверждений от клиентов и, таким образом, не позволит легальным пользователям устанавливать соединения. Рекомендуемое значение для этого параметра — 2 (можно также установить значение 1, но оно действует менее эффективно).

Команда New позволяет добавлять

Рисунок 24.5. Команда New позволяет добавлять в реестр новые ключи, а также строковые и двоичные параметры


Опции Rename (Переименовать) и Delete (Удалить) меню Edit позволяют, соответственно, переименовать или удалить значимый элемент реестра. Удалить значимый элемент можно и другим способом: выделите нужный элемент, выполнив на нем щелчок мышью, а затем нажмите клавишу . Аналогичным образом, для быстрого переименования значимого элемента можно указать на него курсором, выполнить щелчок правой кнопкой мыши, выбрать из контекстного меню команду Rename и ввести новое имя.

Удаление параметров и ключей реестра с помощью утилиты Regedit — это необратимая операция. Regedit не имеет команды Undo, поэтому при удалении параметров и ключей следует соблюдать осторожность.
Команда Copy Key Name (Копировать имя раздела) позволяет скопировать в буфер обмена имя ключа, выделенного на текущий момент. Впоследствии скопированное имя можно вставить в любой текст с помощью команды Paste (Вставить), имеющейся в любом текстовом редакторе. Поскольку реестр представляет собой сложную иерархическую базу данных, пути к нужному элементу могут оказаться очень длинными и сложными для запоминания. Поэтому многие по достоинству оценили удобство этой функции. Команду Copy Key Name очень удобно использовать в сочетании с командами Find и Find Next.
Команды Find (Найти) и Find Next (Найти далее) используются для поиска конкретных элементов или данных (включая строки и слова) в реестре. Можно выполнять поиск ключей, параметров, данных или любой их комбинации. Искомые значения могут быть как текстовыми, так и числовыми. Наконец, особого внимания заслуживает команда Permissions (Разрешения), которая позволяет управлять правами доступа к ключам реестра и осуществлять аудит действий в отношении ключей реестра. Здесь необходимо упомянуть, что в Windows NT/2000 эти возможности были доступны только в Regedt32.exe, где для их установки требовалось использовать опции меню Security. В Windows XP и Windows Server 2003 все эти функциональные возможности были интегрированы в состав редактора реестра Regedit.exe. Права доступа к ключам реестра можно назначать вне зависимости от типа файловой системы на разделе, где содержатся файлы операционной системы.

Изменение прав доступа к ключу реестра может иметь серьезные последствия. Например, если вы установите права доступа типа No Access на ключ, необходимый для конфигурирования сети с помощью опции Network Connections из Control Panel, то это приложение работать не будет. Права полного доступа (Full Control) к ключам реестра должны иметь, как минимум, члены группы Administrators и сама операционная система (Operating System). Такая установка прав доступа позволяет гарантировать возможность восстановления ключа реестра администратором при запуске системы.
Поскольку установка ограничений по правам доступа к ключам реестра может иметь серьезные последствия, зарезервируйте эту меру для ключей, добавляемых вами с целью настройки отдельных индивидуально разработанных приложений или иных видов индивидуальной настройки. Изменив права доступа к ключам реестра, обязательно установите в системе аудит, а затем проведите наблюдения за различными видами системной активности, регистрируясь в системе с использованием различных пользовательских и административных учетных записей.

Для того чтобы получить возможность выполнить эти действия, необходимо зарегистрироваться в системе от имени пользователя, имеющего административные права.
В Regedit.exe команды из меню Permissions по назначению ключам реестра прав владельца и прав доступа работают по такому же принципу, как и аналогичные команды Windows Explorer по установке прав доступа к файлам и каталогам на разделах NTFS. Чтобы установить права доступа к конкретному ключу реестра, проделайте следующее:
1. Перед внесением изменений выполните резервное копирование тех ключей реестра, на которые будут устанавливаться права доступа.
2. Выделите ключ, на который собираетесь установить права доступа. После этого выберите команду Permissions меню Edit.
3. В открывшемся диалоговом окне (Рисунок 24.6) выберите имя нужного пользователя или группы в поле Group or user names (Группы или пользователи) и установите для них нужный тип прав доступа в поле Permissions for . Типы прав доступа, которые вы сможете установить, перечислены в табл. 24.7.

Команды меню Edit

Команды меню Edit


Команда Modify (Изменить) используется для изменения данных, содержащихся в составе параметров реестра. Эта опция будет доступна только в том случае, если выбрать один из параметров, перечисленных в правой панели окна Registry Editor. Команда Modify Binary Data (Изменить двоичные данные) позволяет редактировать любые данные (в том числе и данные других форматов) в окне двоичного редактора. Эта команда также будет доступна только в том случае, если выбран один из параметров реестра, перечисленных в правой панели окна редактора реестра.
Команда New (Создать) позволяет добавлять в реестр новые ключи и параметры строковых типов, двоичные параметры и параметры типа REG_DWORD (Рисунок 24.5). Выбирать тип параметра можно в подменю New в контекстном меню, раскрывающемся по нажатию правой кнопки мыши на выбранном ключе.

Команды меню File

Команды меню File


Команда Import (Импорт) позволяет импортировать в реестр предварительно экспортированные REG-файлы и файлы ульев реестра.
Команда Export (Экспорт) позволяет сохранить весь реестр или его часть в виде REG-файла или файла другого типа, например, файла улья реестра или текстового файла формата ASCII.
Чтобы экспортировать ветвь реестра, выполните следующие действия:
1. Выделите ветвь реестра, затем выберите в меню File (Файл) команду Export.
2. В поле File name открывшегося диалогового окна Export Registry File (Рисунок 24.4) введите имя файла. По умолчанию файлу будет присвоено расширение reg. Чтобы сохранить экспортируемый файл в другом формате, выберите нужную опцию из списка Save as type, расположенного непосредственно под полем File name. Обратите внимание, что, несмотря на все внешнее сходство, утилиты Regedit.exe, поставляемые в составе Windows 9x, Windows NT 4.0, Windows 2000, Windows XP и Windows Server 2003, представляют собой разные версии этого приложения. Поэтому версия Regedit.exe из Windows XP или Windows Server 2003 позволяет сохранять экспортированные файлы реестра как в формате Windows XP/ Windows Server 2003 (для этой цели служит опция Registration Files (*.reg)), так и в формате файлов реестра Windows 9x/NT 4 (для этой цели служит опция Win9x/NT 4 Registration Files (*.reg)).

Команды меню View

Команды меню View


Команда Status Bar (Строка состояния) меню View (Вид) позволяет при желании отключить строку состояния. Поскольку строка состояния помогает быстрее ориентироваться в реестре, отображая путь к текущему ключу, ее рекомендуется постоянно держать включенной.
Опция Split (Разделить) перемещает курсор мыши на разделитель левой и правой частей окна Registry Editor, после чего остается только переместить мышь влево или вправо, чтобы найти удобную позицию для разделителя, и выполнить щелчок левой кнопкой мыши.
Команда Display Binary Data (Вывод двоичных данных) из меню View, впервые появившаяся в Windows XP, становится доступной только после того, как вы выберете один из параметров реестра, отображаемых в правой панели окна Registry Editor. Эта команда позволяет вам просматривать значение параметра, используя один из следующих трех форматов: Byte, Word или Dword (Рисунок 24.9). Обратите внимание, что эта команда не позволяет вам выполнять редактирование данных (если вам требуется выполнить именно эту операцию, следует выбрать команду Modify Binary Data из меню Edit).
В меню View имеется еще одна команда — Refresh (Обновить). При внесении изменений в реестр не все они могут отображаться в окне редактора реестра немедленно после внесения модификации. Обновить окно Registry Editor можно с помощью команды Refresh или нажатием клавиши .

Как правило, в Windows NT 4.0 многие изменения (в том числе и внесенные путем редактирования реестра) входят в силу только после перезагрузки системы. В Windows 2000 впервые (для операционных систем Windows NT) была введена полноценная поддержка Plug and Play, которая была расширена и усе- вершенствована в Windows XP и Windows Server 2003. Поэтому перезагрузок потребуется меньше. Тем не менее, ряд модификаций все же входят в силу только после перезагрузки операционной системы.

Меню Favorites

Меню Favorites


Одним из полезных новшеств, впервые появившихся в Windows 2000, является то, что пункт меню Favorites (Избранное) присутствует теперь повсюду, и редактор реестра Regedit.exe — не исключение (Рисунок 24.10).
Все, кто часто выполняет поиск ключей и значимых элементов в реестре, а также интенсивно занимается его редактированием, по достоинству оценят эту удобную функциональную возможность. С помощью меню Favorites можно создать список наиболее часто редактируемых ключей реестра (и не повторять затем громоздкую процедуру поиска).
Чтобы добавить ключ реестра в список Favorites, проделайте следующее:
1. Выделите ключ реестра, который требуется добавить в список Favorites.
2. В меню Favorites выберите команду Add to Favorites (Добавить в избранное).
3. В раскрывшемся диалоговом окне Add to Favorites (Рисунок 24.11) согласитесь с именем ключа, предложенным по умолчанию, или введите новое имя в поле Favorite name. Нажмите кнопку ОК, и ключ появится в списке Favorites.
Теперь вы в любой момент сможете быстро перейти к нужному ключу, выбрав его имя из списка Favorites. Удалить ключ реестра из списка Favorites очень просто — для этого достаточно выбрать в меню Favorites команду Remove Favorite (Удалить из избранного), а затем в раскрывшемся диалоговом окне выделить ключ, который требуется удалить из списка Favorites, и нажать кнопку ОК.

Назначение реестра

Назначение реестра


Реестр пришел на смену конфигурационным файлам (INI-файлам) и призван был снять неудобства и ограничения, связанные с их использованием. В виде, более или менее напоминающем его нынешнюю структуру, реестр появился в Windows NT 3.5 (тогда он имел 4 корневых ключа: HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CLASSES_ROOT и HKEY_USERS). Новый компонент операционной системы был предназначен для того, чтобы заменить собой многочисленные инициализационные и установочные файлы, разбросанные по различным каталогам на жестком диске и сетевом сервере. Эти файлы требовались для обеспечения корректной работы операционной системы, приложений и аппаратных устройств, но управление ими было задачей сложной, трудоемкой и неудобной. Реестр как централизованная база данных представляет собой источник конфигурационной информации, где все параметры сведены воедино, что обеспечивает возможность эффективного управления операционной системой.
Перечисление компонентов Windows Server 2003, использующих реестр, и краткое описание их взаимодействия с этой базой данных приведено ниже.

Программы установки (Setup). Каждый раз при запуске программы Setup или других установочных программ (для аппаратных и программных средств) происходит добавление в реестр новых конфигурационных данных. Начиная свою работу, все грамотно разработанные программы уста-новки считывают информацию реестра, чтобы определить, присутствуют ли в системе компоненты, обязательные для успешного завершения установки. Наконец, централизованный реестр позволяет приложениям совместно использовать конфигурационную информацию и предоставляет им больше возможностей взаимодействия между собой. Чтобы приложение могло получить статус "Designed for Windows", оно должно активно и правильно использовать реестр, а также содержать утилиту, позволяющую корректно выполнить удаление этого приложения (uninstall utility), не удаляя компонентов, которые могут использоваться другими программами (.dll, .ocx и т. д.). Эта утилита использует информацию, хранящуюся в реестре.

Распознаватель (Recognizer). Каждый раз при запуске компьютера распознаватель аппаратных средств (hardware recognizer) помещает в реестр список обнаруженных им устройств. На компьютерах с процессорами Intel распознавание аппаратных средств осуществляется программой Ntdetect.com и ядром операционной системы (Ntoskrnl.exe).

Ядро системы (Ntoskrnl.exe). При старте системы ядро извлекает из реестра сведения о загружаемых драйверах устройств и порядке их загрузки. Кроме того, программа Ntoskrnl.exe передает в реестр информацию о себе (примером такой информации может служить, например, номер версии).

Драйверы устройств. Драйверы устройств обмениваются с реестром параметрами загрузки и конфигурационными данными. Эти данные аналогичны строкам DEVICE=, которые можно найти в файле config.sys для запуска компьютера под управлением MS-DOS. Драйвер устройства должен сообщить об используемых им системных ресурсах, включая аппаратные прерывания и каналы DMA, чтобы система могла включить эти данные в реестр. Приложения и драйверы устройств могут считывать эту информацию реестра, предоставляя пользователям интеллектуальные программы инсталляции и конфигурирования.

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

Пользовательские профили (user profiles). Windows NT/2000/XP, а также продукты из семейства Windows Server 2003 обеспечивают возможность создания множества пользовательских профилей. Вся информация, относящаяся к конкретному пользовательскому имени и ассоциированным с ним правам, хранится в реестре. Более подробная информация о пользовательских профилях будет приведена далее в этой главе, здесь же отметим, что пользовательский профиль определяет индивидуальные параметры настройки дисплея, параметры сетевых соединений, принтеры и многое другое. Пользовательские профили бывают следующих типов: локальные (local user profile), создаваемые автоматически при первой регистрации пользователя на локальном компьютере, "блуждающие" или перемещаемые (roaming user profile), создаваемые администратором и хранящиеся на сервере, и обязательные (mandatory user profile) — "блуждающие" профили, обязательные для применения. Информация о пользовательских профилях также хранится в реестре.

Обязательные пользовательские профили (mandatory user profiles) поддерживаются в Windows XP и Windows Server 2003 только в целях обеспечения обратной совместимости с существующими доменами Windows NT 4.0. Если же в вашей сети уже применяются домены на базе Windows 2000 или Windows Server 2003, и необходимость обеспечения обратной совместимости отсутствует, то вместо обязательных пользовательских профилей рекомендуется использовать групповую политику (Group Policy).

Аппаратные профили (hardware profiles). Реестр, в отличие от INI-файлов, позволяет хранить множественные аппаратные конфигурации. Так, например, можно создать профили для dock-станций (что актуально для пользователей портативных компьютеров), а также профили для съемных устройств. Аппаратный профиль представляет собой набор инструкций, с помощью которого можно указать операционной системе, драйверы каких устройств должны загружаться при запуске компьютера. В процессе установки системы создается стандартный аппаратный профиль, который содержит информацию обо всех аппаратных средствах, обнаруженных на компьютере на момент инсталляции.

Некоторые методы решения проблем

Некоторые методы решения проблем путем редактирования реестра


Теперь, после рассмотрения общих концепций реестра и его усовершенствований, введенных с выходом Windows XP и Windows Server 2003, средств и методов его редактирования, резервного копирования и восстановления, рассмотрим пару примеров настройки и конфигурирования Windows, а также решения проблем и устранения неполадок с помощью редактирования реестра. Цель этих примеров — продемонстрировать на практике методы модификации системного реестра, рассмотренные в предыдущих разделах данной главы.
Стоит также отметить, что некоторые из приведенных методов специфичны для Windows Server 2003, в то время как некоторые другие применимы также и к Windows NT/2000.

Окно Add or Remove Programs

Рисунок 24.12.Окно Add or Remove Programs


Однако, несмотря на все улучшения, в работе этого мастера могут возникать неполадки, вызванные некорректно или не полностью удаленными приложениями. В частности, если одно из приложений удалено некорректно, то ссылка на него по-прежнему будет фигурировать в списке Currently installed programs. При этом любая попытка воспользоваться мастером установки и удаления приложений (путем нажатия на кнопку Change/Remove) будет приводить к появлению сообщений об ошибке, информирующих пользователя об отсутствии файлов, требующихся для корректного удаления приложения и невозможности завершить процедуру удаления. Несуществующие приложения по-прежнему останутся в списке. Возникновение данной проблемы возможно как в Windows 9x/ME, так и в Windows NT/2000/XP и Windows Server 2003.
Чтобы устранить эту проблему и удалить несуществующие приложения из списка установленных программ, проделайте следующее:
1. Запустите редактор реестра (Regedit.exe) и раскройте ключ HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows\CurrentVersion\Uninstall.
2. В составе этого ключа найдите вложенный ключ, соответствующий приложению, которое требуется удалить из списка установленных программ. Если наименование программы не следует с очевидностью из имени вложенного ключа, просмотрите содержимое всех вложенных ключей списка. В составе каждого из вложенных ключей имеется параметр DispiayName, значение которого представляет собой строки, отображаемые мастером установки и удаления программ.
3. Обнаружив ключ, в составе которого имеется параметр DispiayName, задающий имя приложения, которое должно быть удалено из списка установленных программ, удалите этот ключ вместе со всем его содержимым.
Никогда не удаляйте ключ Uninstall целиком!
4. Закройте редактор реестра и убедитесь в том, что мастер установки и удаления программ больше не отображает несуществующего приложения.

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

Окно Advanced Security Settings for Winlogon

Рисунок 24.7. Окно Advanced Security Settings for Winlogon

Окно Binary Data позволяет просматривать

Рисунок 24.9. Окно Binary Data позволяет просматривать значение выбранного параметра реестра в одном из трех возможных форматов — Byte, Word или Dword

Окно предоставляющее расширенные

Рисунок 24.8. Окно, предоставляющее расширенные опции по редактированию прав доступа к ключам реестра


Как системный администратор, вы можете присвоить себе права владельца на ключ реестра и ограничить доступ к этому ключу. Заменить права владельца можно на вкладке Owner, а установить аудит — на вкладке Auditing.
Пользователь, зарегистрировавшийся на компьютере с правами администратора, может присвоить себе права владельца на любой ключ реестра. Однако, если администратор будет иметь права владельца на ключ без прав доступа типа Full Control, то ключ не может быть возвращен первоначальному владельцу, а в журнале аудита появится соответствующее сообщение.
Аудит действий в отношении реестра
Чтобы установить аудит на действия в отношении реестра, необходимо выполнить следующие действия:
1. Активизировать в системе аудит и задать политику аудита на все события, которые, с вашей точки зрения, подлежат аудиту.
2. Указать пользователей и группы, за действиями которых в отношении выбранных ключей реестра требуется установить аудит. Воспользуйтесь для этого вкладкой Auditing (Аудит) окна, показанного на Рисунок 24.7.
3. Результаты аудита можно просматривать в системном журнале Security с помощью оснастки Event Viewer.
Чтобы иметь возможность выполнить любое из указанных выше действий, необходимо зарегистрироваться на компьютере с использованием учетной записи из группы Administrators. Политика аудита задается для каждого компьютера индивидуально. Прежде чем задавать политику аудита в отношении избранных ключей реестра, необходимо активизировать на компьютере аудит событий, имеющих отношение к системе безопасности.

Как минимум, при установке аудита необходимо выбрать опцию Failure (Отказ) для событий типа File and Object Access. Если выбрать опцию Success (Успех), то в системном журнале может появиться большое количество записей, не имеющих большой практической значимости.

Окно редактора реестра Regedit

Рисунок 24.3. Окно редактора реестра Regedit.exe с обозначением основных областей


В окне редактора реестра Registry Editor отображаются ключи только верхнего уровня иерархии реестра, ответвляющиеся от значка My Computer. Это — имена корневых ключей, базовая информация о которых была приведена в начале этой главы.
Если выполнить щелчок мышью, указав курсором на значок [+], расположенный левее значка любой из папок, то развернется соответствующий ключ, в котором отобразится иерархия содержащихся в его составе вложенных ключей. Эта операция разворачивает дерево ключа реестра до следующего уровня вложенности и во многом напоминает аналогичную операцию раскрытия папок и вложенных папок в Explorer.
Если в составе вложенных ключей имеются другие вложенные ключи, то слева от них тоже будут находиться значки [+], которые можно в свою очередь развернуть для просмотра следующего уровня иерархии. Этот послойный метод организации реестра известен под названием вложения (nesting) и допускает множество уровней.
По достижении самого нижнего уровня вложения слева от вложенного ключа появится значок [—], который указывает, что дальнейшее раскрытие невозможно. После этого перемещение по иерархическому дереву будет возможно только в одном направлении — вверх. Если рядом с ключом нет ни значка [+], ни значка [—], это означает, что он не содержит вложенных ключей.
В табл. 24.5 приведен список клавиш, используемых для просмотра реестра с помощью Regedit.exe

Удаление недействительных

Пример 1. Удаление недействительных записей из списка установленных программ


Утилита Add/Remove Programs на панели управления предназначена для установки, удаления или модификации приложений, установленных в Windows. В Windows XP и Windows Server 2003 эта программа-мастер обладает существенно улучшенным и интуитивно понятным пользовательским интерфейсом (Рисунок 24.12).

Принудительный показ

Пример 2. Принудительный показ "Синего экрана смерти"


Сразу же следует сказать, что в Windows XP и Windows Server 2003 появление "Синего экрана смерти" (Blue Screen of Death, BSOD) стало гораздо более редким событием, нежели в Windows NT/2000. Как правило, теперь Windows корректно обрабатывает многие ситуации, которые в предыдущих версиях могли вызвать такого рода сбой.
Однако, если вы хотите в ознакомительных целях посмотреть, что же представляет собой пресловутый "Синий экран" (который более подробно будет рассмотрен в следующей главе), вы можете это сделать путем несложного редактирования реестра. Данный совет применим как к Windows 2000/XP, так и к операционным системам из семейства Windows Server 2003. Дело в том, что все перечисленные операционные системы имеют возможность искусственной генерации ошибки ядра (сообщения STOP) с последующим созданием аварийного дампа памяти (Memory.dmp). Экран сообщения STOP, который при этом появится, будет содержать следующее сообщение:

*** STOP: 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000) The end-user manually generated the crashdump.
По умолчанию эта функция блокирована. Для ее активизации следует открыть реестр, найти ключ HKEY_LOCAL_MACHINE \SYSTEM\CurrentcontrolSet\ Services\i8042prt\Parameters, добавить В его состав параметр CrashOnCtrlScroll(тип данных REG_DWORD) и установить его равным 1.
После перезагрузки вы сможете вручную создать аварийный дамп и посмотреть на "синий экран". Для этого нажмите правую клавишу и, удерживая ее в этом состоянии, дважды нажмите клавишу

Конфигурирование программы

Пример 3. Конфигурирование программы Backup путем редактирования реестра


Если вы регулярно выполняете резервное копирование вашей системы, то уже наверняка заметили, что встроенная программа Backup, имеющаяся в составе Windows 2000, Windows XP и Windows Server 2003, исключает из резервного копирования целый ряд файлов. Чтобы просмотреть список этих файлов, запустите программу Backup, затем выберите команду Options из меню Tools и перейдите на вкладку Exclude Files (Исключить файлы) (Рисунок 24.13).
В обычных условиях, вероятнее всего, эти файлы действительно должны быть исключены из процессов резервного копирования и восстановления. Однако возможны и такие ситуации, когда системный администратор захочет включить эти файлы в процедуры резервного копирования и восстановления системы.
Все файлы, которые по умолчанию исключаются из процедур резервного копирования и восстановления, перечислены под следующим ключом реестра: HKLM\SYSTEM\CurrentControlSet\Control\ BackupRestore\FilesNotToBackup (Рисунок 24.14).
Несмотря на то, что на вкладке Exclude Files окна Options программы Backup пользователю предоставляется возможность редактирования списка файлов, исключаемых из процессов резервного копирования и восстановления, внесенные изменения будут действовать только применительно к тому пользователю, от имени которого вы зарегистрировались в системе (т. е. они будут записаны в реестре под ключом HKEY_CURRENTJJSER).

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

Пример 4. Конфигурирование регистрации событий, связанных с квотированием диска


Большинство опытных пользователей и администраторов оценили новую весьма полезную возможность квотирования дискового пространства, появившуюся впервые в составе Windows 2000 и, безусловно, присутствующую в Windows XP и Windows Server 2003. События, связанные с квотированием дискового пространства, могут регистрироваться в системном журнале, и вкладка Quota (Квота) окна свойств диска NTFS предоставляет простейшие опции для конфигурирования режима регистрации этих событий (Рисунок 24.17).
По умолчанию регистрация событий, связанных с квотированием дискового пространства, происходит асинхронно (один раз в час). Если вы хотите, чтобы система регистрировала такие события немедленно после того, как пользователь превысит пороговое значение, раскройте редактор реестра, найдите ключ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ Filesystem и создайте параметр NtfsQuotaNotifyRate (тип данных REG_DWORD). Задайте для этого параметра значение, соответствующее требуемой частоте регистрации событий квотирования в системном журнале (временной интервал в секундах).

Снижение вероятности

Пример 5. Снижение вероятности инсталляции "троянских коней"


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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Run

HKEY__LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunServices

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunOnce

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunServicesOnce

HKEYJJSERS\DEFAULT\SOFTWARE\Microsoft\ Windows\CurrentVersion\Run

HKEY_CURRENT_USER\SOFTWARE\Microsoft\ Windows\CurrentVersion\Run

HKEY_CURRENT_USER\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunServices

HKEY_CURRENT_USER\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunOnce

HKEY_CURRENT_USER\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunServicesOnce

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunOnceEx

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

HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths

HKLM\Software\Microsoft\Windows\CurrentVersion\Controls Folder

HKLM\Software\Microsoft\Windows\CurrentVersion\DeleteFiles

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer

HKLM\Software\Microsoft\Windows\CurrentVersion\Extensions

HKLM\Software\Microsoft\Windows\CurrentVersion\ExtShellViews

HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings

НКM\Software\Microsoft\Windows\CurrentVersion\ModuleUsage

HKLM\Software\Microsoft\Windows\CurrentVersion\RenameFiles

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup

HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs

HKLM\Software\Microsoft\Windows\CurrentVersion\Shell Extensions

HKLM\Software\Microsoft\Window-s\CurrentVersion\Uninstall

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Compatibility

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers

HKLM\Software\Microsoft\Windows NT\CurrentVersion\drivers.desc

HKLMXSoftware\Microsoft\Windows NT\CurrentVersion\Drivers32\0

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Embedding

HKLM\Software\Microsoft\Windows NT\CurrentVersion\MCI

HKLM\Software\Microsoft\Windows NT\CurrentVersion\MCI Extensions

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Ports

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

HKLM\Software\Microsoft\Windows NT\CurrentVersion\WOW

Разумеется, приведенные здесь советы и рекомендации не заменят собой ни антивирусного программного обеспечения, ни системы обнаружения атак. Однако они все же смогут обеспечить хотя бы минимальную защиту от неприятных "подарков" и рекомендуются в качестве дополнительных защитных мер.
Итак, чтобы минимизировать риск инсталляции "троянских коней", следует запретить этим программам доступ к реестру путем установки аудита на доступ к перечисленным ключам и редактирования прав доступа к ним. Общая рекомендация сводится к следующему: права типа Full Control к этим ключам должны иметь только пользователи из группы Administrators и встроенная учетная запись SYSTEM. В Windows XP и Windows Server 2003 эта задача выполняется с помощью редактора реестра Regedit.exe.

Редактирование реестра

Пример 6. Редактирование реестра с целью защиты DNS-серверов от DoS-атак


Атаки типа "отказ в обслуживании" (Denial of Service, DoS-attacks) и особенно распределенные атаки (Distributed Denial of Service, DDoS) за последние несколько лет начали представлять собой одну из наиболее серьезных угроз безопасности сетей любого масштаба. При этом количество таких атак с каждым годом растет, и теперь уже практически никто не может считать себя полностью от них застрахованным. Подобно рекомендациям, рассмотренным в предыдущем разделе, советы, приведенные здесь, не дадут полной гарантии защиты от атак сервера DNS. Однако они послужат хорошим дополнением к принимаемым вами мерам защиты.

Перед тем как вносить описанные ниже изменения в конфигурацию сервера, используемого в производственном процессе, рекомендуется испытать их в лабораторных условиях.
Все параметры реестра, описанные в данном разделе, находятся под ключом реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters (Рисунок 24.18).
Краткие описания этих параметров и рекомендуемые значения приведены ниже.

EnableDeadcwDetect (тип данных REG_DWORD). Значение по умолчанию позволяет TCP/IP переключаться на дополнительный шлюз в том случае, когда большое количество соединений начинает испытывать проблемы. Такое поведение нежелательно в случае DoS-атак, поскольку в этом случае трафик может быть перенаправлен на шлюз, который не является объектом постоянного мониторинга. Поэтому установите для данного параметра значение 0.

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

Пример 7. Конфигурирование Windows для очистки файла подкачки при останове системы


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

Эта рекомендация универсальна и применима ко всем версиям Windows NT (начиная с NT 3.51 и заканчивая продуктами из семейства Windows Server 2003). Обратите внимание на то, что очистка файла подкачки при останове системы не является заменой физической безопасности компьютера. Однако она поможет обезопасить вашу конфиденциальную информацию, когда операционная система не загружена (например, компьютер загружен под управлением альтернативной ОС).
Чтобы сконфигурировать Windows для очистки файла подкачки при останове, проделайте следующее:
1. Для Windows XP и Windows Server 2003 запустите редактор реестра Regedit.exe. Для выполнения той же задачи в Windows NT/2000, запустите Regedt32.exe.
2. Найдите ключ реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\Memory Management
3. Создайте параметр ClearPageFileAtshutdown (тип данных — REG_DWORD) и установите его значение равным 1.

Чтобы внесенное изменение вошло в силу, перезагрузите компьютер.

Устранение неполадок при останове системы

Пример 8. Устранение неполадок при останове системы


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

Проблема размера реестра

Проблема размера реестра


Одним из основных недостатков INI-файлов, использовавшихся для управления конфигурацией системы и приложений до введения реестра, являлась проблема, вызванная ограничением по размеру файла Win.ini, использовавшегося в ранних версиях Windows для хранения параметров настройки всех установленных в системе приложений. Каждое вновь устанавливаемое приложение вносило свои параметры в этот файл, вследствие чего он очень быстро рос. Когда размер файла Win.ini превышал установленное ограничение (не более 64 Кбайт), добавление новых записей в его состав создавало проблему, поскольку все дальнейшие изменения, вносимые в последние разделы этого файла (за пределами инициализационной границы), игнорировались.
Казалось, что с введением концепции реестра эта проблема была решена. Однако реестр, при всей своей прогрессивности, все же остался ограниченным по объему (на практике, его размер ограничивался до 80% от объема нерезидентного пула памяти). Поэтому проблема снова начала возникать с появлением приложений, интенсивно использующих реестр (к их числу относятся, например, СОМ и терминальные сервисы). При установке в системе таких приложений значительный объем нерезидентного пула поглощался реестром, оставляя слишком малый объем адресного пространства для других приложений, работающих в режиме ядра. В Windows NT/2000 для решения этой проблемы применяется ограничение по размеру реестра, т. е. существует возможность установить ограничение на размер, до которого может разрастаться реестр.
В отличие от Windows NT/2000, в Windows XP и Windows Server 2003 ограничение по размеру реестра практически снято. Код реестра был переработан таким образом, чтобы переместить реестр из нерезидентного пула и передать управление им диспетчеру кэша. Эта новая реализация позволяет реестру разрастаться до существенно больших размеров, нежели в предыдущих версиях, и фактически ограничивает его размеры только объемом доступного дискового пространства. Таким образом, ни в Windows XP, ни в Windows Server 2003 вы больше не найдете опции, позволяющей задать ограничение по размеру реестра.

Процесс не укладывающийся в отведенный

Рисунок 24.19. Процесс, не укладывающийся в отведенный временной интервал, препятствует корректному останову Windows


Чтобы устранить эту проблему, следует модифицировать значение параметра WaitToKillAppTimeout под следующим ключом реестра: HKEY_CURRENT_USER\Control Panel\Desktop
Значение указывается в миллисекундах. Увеличьте этот интервал (в разумных пределах) и перезагрузите систему, чтобы внесенное изменение вошло в силу.

Как правило, этот интервал не рекомендуется увеличивать слишком сильно, поскольку в случае сбоя в подаче питания UPS может оказаться не в состоянии подавать резервное питание достаточно долго для того, чтобы обеспечить корректный останов ОС.

Работа с системным реестром

Работа с системным реестром


Как и в предыдущих версиях операционных систем из семейства Windows (включая Windows 9x/ME и Windows NT/2000/XP), реестр Windows Server 2003 представляет собой централизованную базу данных параметров настройки системы и работающих в ней приложений. В этом смысле реестр аналогичен разнообразным INI-файлам, а также файлам autoexec.bat и config.sys, которые использовались ранее. Реестр содержит информацию обо всех аппаратных средствах, программном обеспечении, операционной системе и сетевых параметрах компьютера. Эта сложная иерархическая база данных принимает участие во всех аспектах работы Windows. Хорошее понимание принципов работы реестра, выполняемых им задач, а также умение манипулировать реестром необходимо всем: системным и сетевым администраторам, специалистам из групп технической поддержки, а также опытным пользователям из числа программистов. Кроме того, для системных администраторов особенно важны вопросы администрирования и защиты реестра, а также его резервного копирования и восстановления.

Как и в предыдущих системах, в Windows Server 2003 реестр также играет ключевую роль в управлении системной конфигурацией и представляет собой централизованное хранилище всей информации об аппаратных средствах, операционной системе и установленных приложениях, а также данных, управляющих пользовательской средой. Реестр по-прежнему хранится на диске в виде файлов ульев, в состав которых внесены лишь незначительные изменения. Однако в код реестра Windows XP/Windows Server 2003 были внесены изменения, направленные на повышение производительности системы за счет ускорения доступа к реестру и на снятие ограничений по размеру реестра, существовавших во всех предыдущих версиях, включая Windows 2000. Усовершенствования, внесенные в реестр, будут подчеркиваться далее по ходу изложения материала данной главы.
Как было показано в главе 3 "Загрузка операционной системы", реестр становится необходимым уже на начальных этапах загрузки Windows. Проблемы при загрузке могут быть вызваны, в том числе, и повреждением реестра. Например, многие пользователи Windows NT/2000 испытывали этот шок, когда в процессе загрузки получали сообщение примерно следующего содержания:

Windows 2000 Could not start because the following file is missing or corrupt: \WINNT\SYSTEM32\CONFIG\SYSTEM You can attempt to repair this file by Starting Windows NT Setup using the original Setup floppy disk or CD-ROM. Select 'r' at the first screen to repair.
Аналогичное сообщение может появиться и в процессе работы с Windows Server 2003. Появление такого сообщения свидетельствует об отсутствии или повреждении важной части реестра — файла улья реестра SYSTEM (речь о принципах хранения реестра пойдет далее в этой главе). Приведенный пример убедительно демонстрирует, что единственная ошибка в системном реестре может не только повлиять на всю конфигурацию, но и сделать невозможным запуск операционной системы. Помимо этого, добиться корректной работы некоторых приложений можно также лишь через редактирование реестра. Таким образом, важность навыка редактирования реестра нельзя недооценивать.

Резервное копирование и восстановление реестра

Резервное копирование и восстановление реестра


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

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

System Restore — функция System Restore создает точки восстановления, фактически представляющие собой "моментальные снимки" системной конфигурации, которая включает в себя и данные реестра. Перед внесением любых серьезных изменений в конфигурацию системы (включая и непосредственное редактирование реестра) рекомендуется вручную создать точку восстановления, которая позволит выполнить быстрое восстановление системы в случае возникновения неполадок и проблем с загрузкой. Что особенно важно, System Restore может применяться как при нормальном режиме загрузки, так и в безопасном режиме (safe mode). Следует, однако, отметить, что данная функция имеется только в Windows XP.

Процедура автоматического восстановления поврежденной системы (Automated System Recovery, ASR). Никогда не пренебрегайте подготовкой к процедуре ASR перед внесением серьезных изменений в конфигурацию системы. Процедуры подготовки и выполнения ASR были подробно рассмотрены в главе 23 "Восстановление системы".

Резервное копирование системных конфигурационных данных (System State). Подобно предыдущим двум опциям, этот вариант резервного копирования реестра подробно рассматривался в главе 23. Здесь же стоит отметить один факт, весьма важный с точки зрения резервного копирования и восстановления реестра, а именно: при выполнении резервного копирования системных конфигурационных данных система сохраняет резервные копии файлов реестра в каталоге %SystemRoot%\repair. Если ульи реестра получат повреждения, то вы можете воспользоваться этими резервными копиями для восстановления системы, не прибегая к громоздкой процедуре переустановки системы и последующего восстановления системных конфигурационных данных. Однако пользоваться этим методом могут только опытные пользователи, которые отлично понимают, что именно они делают.

Ручное резервное копирование реестра. Чтобы выполнить ручное резервное копирование и восстановление реестра Windows NT/2000/XP или Windows Server 2003, скопируйте на съемный носитель следующие файлы, хранящиеся в каталоге %SystemRoot%\system32\config:

Appevent.evt

Secevent.evt

Sysevent.evt

Default

Security

System

Default.log

Security.log

System.alt*

Default.sav

Software

System.log

Sam

Software.log

System.sav

Sam.log

Software.sav

Userdiff

* Файл, присутствующий только в Windows NT/2000.

Использование этого метода резервного копирования и восстановления реестра сопряжено с некоторыми сложностями. Так, весьма логично было бы использовать для резервного копирования дискету емкостью 1,44 Мбайт, но отнюдь не всегда ее объема хватит для копирования всех файлов. Далее, если раздел, на котором установлена поврежденная копия Windows XP или Windows Server 2003, отформатирован для использования NTFS, то вы столкнетесь с некоторыми трудностями при загрузке с дискет MS-DOS или Windows 9x/ME (хотя эта трудность легко преодолима, если вы воспользуетесь утилитой NTFSDOS, которую можно загрузить, посетив сайт http://www.sysinternals/com). Помимо этого, в данной ситуации могут помочь загрузочная дискета Windows Server 2003, параллельная установка операционной системы, а также Recovery Console.

С выходом Windows 2000 в Regedit

Рисунок 24.10. С выходом Windows 2000 в Regedit появился пункт меню Favorites

Содержимое ключа HKLM\SYSTEM\CurrentControlSet\Control\

Рисунок 24.14. Содержимое ключа HKLM\SYSTEM\CurrentControlSet\Control\ BackupRestore\FilesNotToBackup


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

Содержимое ключа реестра HKLM\SYSTEM\CurrentControlSet\Control

Рисунок 24.15. Содержимое ключа реестра HKLM\SYSTEM\CurrentControlSet\Control \BackupRestore\KeysNotToRestore


Обратите внимание на то, что в составе ключа реестра HKLM\SYSTEM\ CurrentControlSet\Control\BackupRestore В Windows XP И Windows Server 2003 появился новый вложенный ключ — HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\BackupRestore\AsrKeysNotToRestore (Рисунок 24.16). Как видно из приведенной иллюстрации, этот ключ содержит параметр Plug & Play, указывающий на базу данных критических устройств. Редактировать этот параметр не следует, поскольку эта база данных содержит устройства, для которых программа Windows Setup должна произвести повторную энумерацию в ходе процесса ASR.

Структура реестра

Структура реестра


Как и реестры систем Windows NT/2000/XP, реестр Windows Server 2003 состоит из пяти так называемых корневых ключей (root keys):

HKEY_CLASSES_ROOT

HKEY_CURRENT_USER

HKEY_LOCAL_MACHINE

HKEY_USERS

HKEY_CURRENT_CONFIG

Каждый отдельный ключ может содержать элементы данных, которые называются параметрами (value entries), а также дополнительные вложенные ключи (subkeys). Для понимания этой концепции можно провести аналогию с файловой системой. Ключи в структуре реестра аналогичны каталогам, а значимые элементы — файлам.

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

Таблица 24.10. Список параметров ключа HKLM\SYSTEM\Current ControlSet\Control\BackupRestore\KeysNotToRestore

Параметр	Значение
Active Directory Restore	CurrentControlSet\Services\NTDS\Restore In Progress \CurrentControlSet\Services\NTDS\Parameters \New Database QUID
ASR Information	CurrentControlSet\Control\ASR\
Fault Tolerance	Disk\
Installed Services	CurrentControlSet\Services\*
LDM Boot Information	CurrentControlSet\Services\dmio\boot info\
LDM Boot Information (dmboot)	CurrentControlSet\Services\dmboot\
Mount Manager	Мои nted Devices\
NtFrs	CurrentControlSet\Services\NtFrs\Parameters\Backup/Re store\Process at Startup\
Pending Rename Operations	CurrentControlSet\Control\Session Man-ager\PendingFileRenameOperations
Plug and Play	CurrentControlSet\Enum\CurrentControlSet \Control\CriticalDeviceDatabase\
Removable Storage Manager	CurrenlControlSet\Control\NTMS\lrnporlDatabase
Session Manager	CurrentControlSet\Control\Session
Windows Setup	Setup\SystemPartition

Типы данных для параметров реестра

Таблица 24.2. Типы данных для параметров реестра

Тип данных	Описание
REG_BINARY	Двоичные данные. Большинство аппаратных компонентов используют информацию, которая хранится в виде двоичных данных. Редакторы реестра отображают эту информацию в шестнадцатеричном формате
REG_DWORD	Данные представлены в виде значения, длина которого составляет 4 байта. Этот тип данных используют многие параметры драйверов устройств и сервисов. Редакторы реестра могут отображать эти данные в двоичном, шестнадцатеричном и десятичном формате
REG_EXPAND_SZ	Расширяемая строка данных. Эта строка представляет собой текст, содержащий переменную, которая может быть заменена при вызове со стороны приложения
REGJMULTI_SZ	Многострочное поле. Значения, которые фактически представляют собой списки текстовых строк в формате, удобном для восприятия человеком, обычно имеют этот тип данных. Строки разделены символом NULL
REG_SZ	Текстовая строка в формате, удобном для восприятия человеком. Значениям, представляющим собой описания компонентов, обычно присваивается именно этот тип данных
REG_DWORD_ LITTLE_ENDIAN	32-разрядное число в формате "остроконечников" (little-endian). Представляет собой эквивалент REG DWORD. При использовании метода "остроконечников" самый младший байт ("little end") хранится в памяти первым в числе. Например, шестнадцатеричное число A02Bh по методу "остроконечников" сохраняется как 2ВАО. Метод "остроконечников" используется в микропроцессорах Intel
REG_DWORD_BIG_ ENDIAN	32-разрядное число в формате "тупоконечников" (big-endian). В противоположность методу "остроконечников", при использовании метода "тупоконечников" самый старший байт ("big end") оказывается первым байтом числа
REG_LINK	Символическая ссылка Unicode. Этот тип данных предназначен для внутреннего использования. Тип данных REG LINK особенно интересен тем, что он позволяет одному элементу реестра ссылаться на другой ключ или параметр. Например, если элемент реестра \Rootl\Link имеет параметр типа REG LINK со значением \Root2\RegKey, а ключ RegKey содержит параметр RegValue, то этот параметр идентифицируется двумя путями: \Rootl\Link\RegValue И \Root2 \ RegKey \RegValue. Windows NT/2000/XP и Windows Server 2003 активно использует этот метод — некоторые из корневых ключей реестра, перечисленных в табл. 24.1, являются ссылками на вложенные ключи других корневых ключей
REG_NONE	Параметр не имеет определенного типа данных
REG_QWORD	64-разрядное число
REG_QWORD_LITTLE_ ENDIAN	64-разрядное число в формате "остроконечников". Эквивалент REG QWORD
REG_RESOURCE_LIST	Список аппаратных ресурсов, применяется только в ветви HKEY_LOCAL_MACHINEXHARDWARE
REG_FULL_RESOURCE_ DESCRIPTOR	Дескриптор (описатель) аппаратного ресурса. Применяется только в ветви HKEY_LOCAL_MACHINE\HARDWARE
REG_RESOUECE_ REQUIREMENTS_LIST	Список необходимых аппаратных ресурсов. Применяется только в ветви HKEY_LOCAL_MACHINE\HARDWARE

Стандартные файлы

Таблица 24.3. Стандартные файлы, обеспечивающие поддержку ульев реестра Windows NT/2000/XP и Windows Server 2003

Ветвь реестра	Имена файлов
НКЕ Y_LOCAL_MACHINE\SAM	Sam, Sam. log, Sam.sav*
HKEY_LOCAL_MACHINE\Security	Security, Security.log, Security. sav*
HKEY_LOCAL_MACHINE\Software	Software, Software.log, Software. sav
HKEY_LOCAL_MACHINE\System	System, System.alt**, System.log, System. sav
HKEY_CURRENT_CONFIG	System, System.alt**, System.log, System. sav
HKEY_USERS\.DEFAULT	Default, Default.log, Default.sav
(Файлы, не ассоциированные ни с одним ключом)	Userdiff, Userdiff.log, Userdifr***, Userdifr.log***
HKEY_CURRENT_USER	Ntuser.dat, Ntuser.dat.log

* Файлы, появляющиеся в системе лишь при определенных обстоятельствах.
** Файлы, исключенные из Windows XP и Windows Server 2003.
*** Файлы, присутствующие только в Windows XP.

Как видно из приведенной выше таблицы, некоторые из файлов реестра в Windows XP и Windows Server 2003 больше не используются. Это является следствием усовершенствований, внесенных в их реестр.
Все файлы ульев реестра, за исключением HKEY_CURRENT_USER, находятся в подкаталоге %SystemRoot%\system32\config.
Поддержку улья HKEY_CURRENT_USER выполняют файлы Ntuser.dat и Ntuser.dat.log. В файлах Ntuser.dat хранятся пользовательские профили; файл Ntuser.dat.log отслеживает изменения, которые вносились в файл Ntuser.dat. В Windows NT 4.0 (а также в системах Windows 2000/XP и Windows Server 2003, установленных как обновление версий Windows NT 4.0) эти файлы располагаются во всех подкаталогах каталога %SystemRoot%\Profiles (за исключением подкаталога \Аll Users). В Windows 2000/XP и Windows Server 2003 эти файлы располагаются в каталогах %SystemRoot%\Documents and Settings\ % Username%.
Файлы Ntuser и Userdiff были впервые введены в Windows NT 4.0:

файл Ntuser.dat, в котором хранится пользовательский профиль, заменил собой файлы usernamejcet и admiruco: из предыдущих версий Windows NT;

файл Ntuser.dat из каталога %SystemRoot%\Profiles\DefaultUser заменил собой файл Userdef из предыдущих версий Windows NT. Этот профиль используется для построения улья HKEY_CURRENT_USER, когда новый пользователь впервые регистрируется в системе;

файлы UserdifF, которые находятся только в каталоге %SystemRoot% \system32\config, не ассоциируются ни с одним ульем. Они служат для обновления существующих профилей пользователей, использовавшихся в предыдущих версиях Windows NT, таким образом, чтобы эти профили могли применяться в Windows NT 4.0 и последующих версиях (Windows 2000, Windows XP и Windows Server 2003).

С ульями ассоциируются файлы четырех типов. Все эти типы файлов (с соответствующими расширениями имен файлов) перечислены в табл. 24.4.

Типы файлов ассоциированных

Таблица 24.4. Типы файлов, ассоциированных с ульями реестра Windows NT4.0Windows 2000/Windows XP/Windows Server 2003

Тип файла	Описание
Без расширения имени файла	Содержит копию улья
ALT*	Содержит резервную копию жизненно важного улья HKEY LOCAL MACHlNE\System. Только ключ System имеет соответствующий файл с расширением alt. Файлы ульев с таким расширением существуют только в Windows NT/2000. В Windows XP и Windows Server 2003 они больше не используются вследствие того, что в этой операционной системе для хранения и доступа к реестру применяются усовершенствованные алгоритмы
LOG	Содержит журнал транзакций, в котором регистрируются все изменения, внесенные в ключи и значимые элементы улья
SAV	Содержит копии файлов улья в том виде, который они имели на момент завершения текстовой фазы процесса установки. Файлы с расширением sav появляются для ключей Software, System, SAM, Security И Default. Подобно Windows NT/2000/XP, Windows Server 2003 выполняет резервное копирование содержимого ульев в процессе инсталляции. Процедура инсталляции состоит из двух стадий: стадии текстового режима и стадии графического режима. Когда установка в текстовом режиме завершается, выполняется копирование ульев в файлы с расширением sav. Это делается для того, чтобы защитить ульи от ошибок, которые могут произойти в случае сбоя на графической стадии установки. Если процедура установки даст сбой на графической стадии, то после перезагрузки компьютера будет производиться повтор только графической стадии установки. SAV-файлы используются для перестройки ульев реестра

*Файлы, исключенные изWindows XP иWindows Server 2003

Клавиши используемые в Registry Editor

Таблица 24.5. Клавиши, используемые в Registry Editor

Клавиша	Действие
<+>	Разворачивает выбранный ключ на один уровень, показывая вложенные подключи
<- >	Сворачивает выбранный ключ на один уровень
вверх	Перемещает вверх к следующему ключу
вниз	Перемещает вниз к следующему ключу
<- >>	Разворачивает выделенный ключ на один уровень, показывая его подключи; если подключен нет, то перемещает вниз к следующему ключу
<<->	Сворачивает выделенный ключ, если он был развернут; в противном случае перемещает вверх к следующему ключу
<Таb>	Перемещает в другое подокно окна Registry Editor

В правой панели окна Registry Editor располагаются параметры реестра, каждый из которых характеризуется именем, типом данных, и собственно данными.
Каждый параметр реестра характеризуется именем. Многие параметры, предоставляемые Microsoft, используют имя Default (вы убедитесь в этом, когда начнете интенсивно работать с Registry Editor). Имена параметров располагаются в столбце Name правой панели окна Registry Editor. Эти имена присваиваются значимым элементам разработчиками приложений и физических устройств.
Типы данных, характеризующие параметры реестра, отображаются в столбце Туре.
Утилита Regedit.exe для удобства применяет также специальные значки, отображаемые чуть левее имен параметров и позволяющие быстро отличать двоичные данные от текстовых. Краткое описание значков, отображаемых в окне редактора реестра Regedit, приведено в табл. 24.6.

Значки соответствующие

Таблица 24.6. Значки, соответствующие типам данных в окне Registry Editor

Тип данных	Описание

Означает, что данные имеют двоичный формат (типы данных REG_BINARY И REG_DWORD)

Означает текст и символы, которые вы можете прочесть, например, "On The Microsoft Network" (строковые типы данных - REG_EXPAND_SZ, REG_MULTI_SZ И REG_SZ)

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

Типы прав доступа к ключам реестра

Таблица 24.7. Типы прав доступа к ключам реестра

Тип доступа	Описание
Read	Позволяет пользователям, внесенным в список Permissions, просматривать содержимое ключа реестра, не позволяя сохранять изменения
Full Control	Позволяет пользователям, внесенным в список Permissions, получать доступ к ключу, редактировать его содержимое и изменять к нему уровень прав доступа
Special Permissions	Предоставляет пользователям, внесенным в список Permissions, индивидуально назначаемые комбинации прав доступа и редактирования к избранному ключу. Подробное описание типов и комбинаций Special Permissions можно найти далее в этой главе

Флажки диалогового окна Permission entry for

Таблица 24.8. Флажки диалогового окна Permission entry for

Флажок	Назначаемые права
Query Value	Дает право чтения значимых элементов из ключа реестра
Set Value	Дает право установить значимый элемент в ключе реестра
Create Subkey	Дает право создавать подключи в выбранном ключе реестра
Enumerate Subkey	Дает право идентифицировать подключи выбранного ключа реестра
Notify	Дает право установить аудит на ключи реестра
Create Link	Дает право создавать символические ссылки в конкретном подключе реестра
Delete	Дает право удаления выделенного ключа
Write DAC	Дает право получать доступ к ключу и создавать/модифицировать для него список контроля доступа (Access Control List, ACL)
Write Owner	Дает право присвоения прав владельца данного ключа
Read Control	Дает право просматривать параметры безопасности, установленные для данного ключа

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

Таблица 24.9. Список параметров реестра ключа FilesNotToBackup

Параметр	Значение
ASR error file*	%SystemRoot%\repair\asr.err
ASR log file*	%SystemRootf%\repair\asr.log
Catalog database*	%SystemRoot%\sysiem32\CatRoot2\ * /s
Client Side Cache	%SystemRoot%\csc\* /s
ComPlus	%SystemRoot/%\Registration\*.crrnlog /s
Digital Rights Management (DRM) folder*	%SystemDrive%\Documer\te and SettingsW/ l/sers\DRM\* /s
Internet Explorer	%UserProfile%\mdex.dai /s
Memory Page File	\Pagefile.sys
Microsoft Writer (Bootable state)*	%SystemRoot%\Registration\*.clb \ *. crmlog /s
Microsoft Writer (Service state)*	%SystemRoot%\system32\NtmsData\*
MS Distributed Transaction	%SystemRoot%\system32\DTCLog\MSDTC.LOG
Netlogon*	%SystemRoot%\netlogon.chg
NTDS**	%SystemRoot%\NTDS\*
NtFrs	%SystemRoot%\ntf rs\jet\* /s %SystemRoot%\debug\NtFrs* %SystemRoot%\sysvol\domain \DO_NOT_REMOVE_NtFrs_Prelnstall_Directory\*/s %SystemRoot%\sysvol\domain \NtFrs_PreExisting __ See_EventLog\* /s %SystemRoot%\sysvol\staging\domain\NTFRS_*
Power Management	\hiberfil.sys
Registry Writer**	%SystemRoot%\system32\NtmsData\*
Task Scheduler**	%SystemRoot%\Jasks\sc hed Ig u . txt
Temporary Files	%TEMP%\* /s
VSS Default Provider*	\System Volume lnformation\*{3808876B-C176-4e48-B7AE-04046E6CC752} /s
VSS Service Alternate DB**	\System Volume lnformation\*.{7cc467ef-6865-4831-853f-2a4817fd1bca}ALT
VSS Service DB**	\System Volume lnformation\*.{7cc467ef-6865-4831-853f-2a4817fd1bca}DB
Winlogon debug**	%W//VD/R%\debug\*

* Параметры, новые для Windows XP.
** Параметры, новые для Windows Server 2003.
Еще более сложная ситуация возникает с ключами реестра, которые должны исключаться из процесса резервного копирования. Эти ключи даже не перечисляются на вкладке Exclude Files окна Options; следовательно, пользовательский интерфейс не предоставляет возможности их редактирования. Сам этот список хранится в реестре под ключом HKLM\SYSTEM\ CurrentContrоlSet\Control\BackupRestore\KeysNotToRestore (Рисунок 24.15).
Список параметров реестра, по умолчанию исключаемых из процесса резервного копирования в Windows Server 2003, приведен в табл. 24.10.

Усовершенствования в структуре реестра

Усовершенствования в структуре реестра


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

Ускоренная обработка обращений к реестру. В Windows NT/2000 на производительность реестра влияла его фрагментация. Взаимосвязанные ячейки были разбросаны по всему файлу улья, вследствие чего попытки доступа к такой информации (например, поиск атрибутов ключа) могли приводить к генерации большого количества страничных прерываний и существенно снижали общую производительность системы. В Windows XP и Windows Server 2003 при выделении памяти для ячеек реестра применяется улучшенный алгоритм, при котором взаимосвязанным ячейкам реестра выделяется пространство в пределах одной и той же или близких страниц памяти, что снимает эту проблему.

Улучшенные механизмы для работы с данными большого объема. Во всех версиях, предшествующих Windows XP, неэффективно работающее приложение могло создавать разреженные файлы реестра большого объема за счет постоянного увеличения значения параметра реестра малыми приращениями. В Windows XP и Windows Server 2003 эта проблема решена за счет реализации разбиения крупных ячеек на цепочки ячеек размером по 16 Кбайт.

Вкладка Exclude Files окна Options

Рисунок 24.13. Вкладка Exclude Files окна Options встроенной программы Backup

Вкладка Quota окна свойств раздела NTFS

Рисунок 24.17. Вкладка Quota окна свойств раздела NTFS

Запуск Regedit

Запуск Regedit


По умолчанию утилита Regedit.exe в процессе установки операционной системы копируется в каталог %SystemRoot% (например, C:\Windows). Обычно редактор реестра запускается с помощью команды Run (Выполнить) меню Start (Пуск).
Редактор реестра можно также запустить из командной строки с ключом /s. В этом случае Regedit.exe не будет предоставлять графического пользовательского интерфейса и не будет запрашивать подтверждения пользователя на выполнение указанной ему операции. Эта опция позволяет использовать редактор реестра в командных файлах. Например, чтобы выполнить импорт файла реестра MyRegSettings.reg в состав реестра без запроса подтверждения, дайте следующую команду: Regedit /s MyRegSettings.reg

Internet Information Services 6.0

Целевой компьютер

Целевой компьютер


Термин "целевой компьютер" (target computer) относится к компьютеру, на котором происходит ошибка ядра STOP. Именно этот компьютер и является отлаживаемым. Он может располагаться где угодно — как в нескольких шагах от компьютера, на котором работает отладчик, так и на достаточно большом расстоянии (связь можно поддерживать через модем).

Диалоговое окно Startup and Recovery

Рисунок 25.7. Диалоговое окно Startup and Recovery


Системный журнал событий Windows — хороший источник информации, помогающей выяснить причину возникновения ошибки. Именно поэтому в любом случае рекомендуется установить флажок Write an event to the system log (Записать событие в системный журнал) — тогда при каждом возникновении ошибки STOP в системном журнале событий будет делаться соответствующая запись. Пример такой записи приведен ниже:

Event ID:1001 Source: Save Dump Description:
The computer has rebooted from a bugcheck.
The bugcheck was :Oxc000021a (0xel270188,0x00000001,0x00000000,0x00000000).
Microsoft Windows NT (vl5.1381).
A dump was saved in: C:\WINDOWS\MEMORY.DMP.
Если установить флажок Send an administrative alert (Отправить административное оповещение), то в случае возникновения ошибки STOP на компьютер сетевого администратора будет отправляться административное уведомление.
Наконец, если компьютер, на котором происходит такая ошибка, необходимо как можно скорее привести в рабочее состояние, возможно, вы захотите, чтобы он автоматически перезагружался в случае возникновения ошибок STOP. Для этого установите флажок Automatically reboot (Выполнить автоматическую перезагрузку).
Если ошибки, приводящие к появлению "синего экрана", появляются систематически, то наилучшим источником информации о причине их возникновения будет отладочный дамп. Для конфигурирования системы таким образом, чтобы при ее крахе содержимое физической памяти записывалось в файл на жестком диске, используются опции группы Write debugging information (Сохранять отладочную информацию). Поле Dump file (Файл дампа) предназначено для ввода имени файла, в который будет сбрасываться эта информация, а установленный флажок Overwrite any existing file (Заменять существующий файл дампа) определяет, что содержимое существующего файла дампа каждый раз будет замещаться новой информацией.
Начиная с Windows 2000, в процедуру сохранения отладочного дампа были внесены усовершенствования. В системе Windows NT 4.0 в отладочный дамп можно было записать только содержимое физической памяти компьютера. Объем файла, который при этом генерирует система, всегда несколько больше, нежели объем физической памяти, установленной на компьютере, и при этом значительная часть данных в файле дампа практически бесполезна. Как в Windows NT 4.0, так и в последующих системах ошибки STOP представляют собой ошибки ядра. Следовательно, именно информация ядра (состояние системы на момент возникновения ошибки, сведения об активных приложениях, загруженных драйверах устройств и т. д.) и представляет практический интерес при анализе дампа. Данные о режиме пользователя обычно просто увеличивают размер файла дампа и не предоставляют полезной информации.
Именно поэтому в Windows 2000 в диалоговом окне Startup and Recovery появилась новая опция, позволяющая регулировать размер файла аварийного дампа. Первый список в группе Write debugging information (Запись отладочной информации) позволяет выбрать режим сохранения дампа. Наряду с возможностью сохранения полного дампа (как в Windows NT 4.0) в нем есть опция Kernel memory dump (Дамп памяти ядра), при выборе которой в файле дампа будет сохранена только информация ядра. Средства анализа аварийного дампа, совместимые с Windows 2000, в том числе dumpexam и WinDbg, будут интерпретировать этот файл корректно. Экономия дискового пространства, которой можно добиться, выбрав эту опцию, может отличаться в разных системах (и даже зависеть от типа возникающих ошибок). Тем не менее, на основании практического опыта авторов можно сказать, что на компьютерах с объемом оперативной памяти 128 Мбайт полный дамп составит чуть более 128 Мбайт, а дамп ядра — около 40 Мбайт.
Windows XP и Windows Server 2003 предоставляют еще одну дополнительную возможность при сохранении аварийного дампа — компактный дамп памяти, задаваемый опцией Small memory dump (64 К) (Малый дамп памяти). Если выбрана эта опция, то система сохранит только минимально необходимый объем информации, требующейся для идентификации ошибки STOP и составления отчета. Компактные дампы чрезвычайно полезны в том случае, когда объем доступного дискового пространства ограничен, а также в случае использования медленных каналов связи при отправке отчетов об ошибках.

Дополнительные источники информации

Дополнительные источники информации


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

http://msdn.microsoft.com/windowserver2003 — масса полезной информации для разработчиков, в том числе можно загрузить версию Windows Server 2003 Device Driver Kit;

http://www.microsoft.com/windows/reskits — информация о продуктах Resource Kit;

http://www.microsoft.com/ddk/debugging/ — ссылки на дополнительные источники с информацией по отладке. Полный справочник по отладке, начиная с установки отладочного режима и заканчивая подробным списком всех команд отладчика ядра;

http://support.microsoft.com — статьи Microsoft Knowledge Base, содержащие полную и подробную информацию об устранении ошибок STOP.

к перечисленным возможностям, операционные системы

Функция Error Reporting в Windows Server 2003


В дополнение к перечисленным возможностям, операционные системы нового поколения - Windows XP и продукты из семейства Windows Server 2003 — включают еще одно нововведение — сервис сообщений об ошибках (Error Reporting service). В соответствии с политикой Microsoft, направленной на повышение качества поддержки пользователей, этот сервис предназначен в помощь пользователям, выполняющим устранение неполадок в работе операционной системы. Одновременно с этим, данная функциональная возможность призвана помочь разработчикам в улучшении качества последующих версий операционной системы. Сервис Error Reporting ведет мониторинг операционной системы, включая ошибки режима пользователя и ошибки режима ядра.
Так, в случае возникновения ошибки режима пользователя (например, ошибка в работе одного из приложений), сервис Error Reporting отображает сообщение, информирующее пользователя о возникновении проблемы (Рисунок 25.1). При этом пользователю предоставляется возможность отправить отчет об ошибке на адрес Microsoft, отказаться от отправки отчета или просмотреть техническую информацию о возникшей проблеме (Рисунок 25.2).
При возникновении ошибок режима ядра (например, сообщений STOP, кратко обсуждавшихся в предыдущем разделе) Windows запишет на диск компактный файл аварийного дампа, отобразит "синий экран", а после перезагрузки в нормальном или безопасном режиме отобразит сообщение, подобное приведенному на Рисунок 25.3. При этом, как и в предыдущем случае, пользователю предоставляется возможность отправить отчет о возникшей ошибке на адрес Microsoft, отказаться от отправки отчета и просмотреть дополнительную техническую информацию.

Если пользователь, обладающий правом останова

Рисунок 25.6. Функция Shutdown Event Tracker в Windows Server 2003


Если пользователь, обладающий правом останова системы (shutdown privilege), выполняя останов, сбрасывает флажок Planned (см. Рисунок 25.6), указывая тем самым на то, что данная операция является незапланированной, то система регистрирует данные об этом событии в файле журнала, который сохраняется в каталоге %SystemRoot%\system32\LogFiles\Shutdown\. Просматривать эти данные и составлять на их базе отчеты могут только пользователи с административными правами.

Функция Shutdown Event Tracker

Функция Shutdown Event Tracker


Системы Windows XP и Windows Server 2003 дают администраторам возможность отслеживать причины перезагрузок и остановов компьютеров (Рисунок 25.6). Эта возможность обеспечивается с помощью функции Shutdown Event Tracker, которая регистрирует причину каждой перезагрузки и каждого останова в системном журнале (System log). Анализируя эту информацию (Event Type: Information; Event Source: USER32; Event ID: 1074), системный администратор может выяснить наиболее распространенные причины перезагрузок и остановов системы, а также разработать меры, которые позволят минимизировать время простоя.

В Windows Server 2003 функция Shutdown Event Tracker no умолчанию активизирована; в Windows XP — не активизирована. Ее поведением можно управлять с помощью групповых политик (см. узел Computer Configuration | Administrative Templates | System)

Хосткомпьютер

Хост-компьютер


Термин "хост-компьютер" (host computer) в данной главе относится к компьютеру, на котором вы запускаете отладчик. Этот компьютер должен работать под управлением версии Windows, по крайней мере такой же (или более новой), как и отлаживаемый компьютер.

Экран сообщения STOP

Экран сообщения STOP


Как уже говорилось, сообщения STOP появляются, когда ядро операционной системы выявляет противоречивое состояние, из которого оно не может выйти самостоятельно. Такие сообщения всегда отображаются в полноэкранном текстовом режиме, а не в окне Windows (Рисунок 25.8). Каждое такое сообщение уникальным образом определяется шестнадцатеричным числом, идентифицирующим возникшую ошибку, и символьной строкой. Кроме того, за шестнадцатеричным числом, идентифицирующим сообщение STOP, как правило, следуют заключенные в круглые скобки шестнадцатеричные числа, каждое из которых указывает один из параметров возникшей ошибки. Число таких параметров может достигать четырех, как показано в примере:

*** STOP: 0x000000lE (0x00000005,0xFDE38AF9,0x00000001,0x7E8BOEB4) KMODE_EXCEPTION_NOT_HANDLED ***

Наиболее распространенные ошибки STOP

Наиболее распространенные ошибки STOP


Этот раздел содержит краткую информацию и инструкции по устранению наиболее часто встречающихся ошибок STOP. Представленные здесь материалы собраны на основании статей Microsoft Knowledge Base, а также документации, входящей в состав программных продуктов из серии Resource Kit. Если, несмотря на все предпринятые вами меры, ошибка продолжает появляться, обратитесь в службу технической поддержки.

Общая методика

Общая методика


В этом разделе дается общая методика, которой рекомендуется следовать при появлении экранов сообщений STOP, не содержащих конкретных инструкций по устранению возникшей ошибки. Выполняйте эти рекомендации поочередно, приступая к следующему шагу в том случае, если предыдущие не помогли решить проблему. Более подробные инструкции по устранению конкретных ошибок STOP приведены далее в этой главе.
Шаг 1. В первую очередь попробуйте перезагрузить компьютер. В некоторых случаях, когда ошибка возникла случайно, этого достаточно.
Что делать, если в процессе загрузки Windows постоянно появляется "синий экран", после чего компьютер автоматически перезагружается, и ошибка появляется снова? Это может происходить, если в процессе подготовки к устранению последствий ошибок STOP вы установите в окне Startup and Recovery (Загрузка и восстановление) опцию автоматической перезагрузки компьютера при крахе системы, а ошибка STOP, делающая невозможной дальнейшую работу компьютера, будет возникать вновь и вновь. Легко догадаться, что каждый раз после ее появления компьютер будет перезагружаться, и цикл перезагрузок будет бесконечным. Как же выйти из этого порочного круга и хотя бы получить возможность исследовать возникающую ошибку STOP?
Данную проблему можно решить, установив на другом разделе жесткого диска этого компьютера еще одну копию Windows 2000/XP или Windows Server 2003 (одна из официальных рекомендаций Microsoft, которая приводится, например, в главах по обеспечению отказоустойчивости системы в продуктах Resource Kit):
1. Загрузите вторую копию Windows, вызовите редактор реестра (в Windows 2000 следует использовать приложение Regedt32) и раскройте ключ HKEY_LOCAL_MACHINE.
2. Загрузите улей System той копии Windows, в которой возникла проблема (хотя подробная информация о местоположении ульев реестра приведена в главе 24 "Работа с системным реестром", напомним, что они располагаются в папке %SystemRoot^\system32\config,).
3. Когда вам будет предложено указать имя для загружаемого улья, введите любую строку, например, oldsystem.
После этого под ключом HKEY_LOCAL_MACHINE будет содержаться список следующих ульев:

HARDWARE oldsystem SAM SECURITY SOFTWARE SYSTEM
4. Раскройте улей oldsystem, найдите в составе ключа HKEY_LOCAL_MACHINE\ SYSTEM\ControlSetxxx\Control\CrashControl параметр AutoReboot и установите его значение в 0 (эту операцию надо проделать для всех наборов ControlSetxxx).
5. Сверните ключ HKEY_LOCAL_MACHINE и выгрузите улей.
Теперь, когда опция автоматической перезагрузки при крахе системы блокирована, вы получили возможность исследовать сообщение STOP.
Шаг 2. Если после перезагрузки "синий экран" больше не появляется, то проблема решена (хотя бы временно). Не забудьте после запуска Windows просмотреть журнал системных событий. (Возможно, именно там вы обнаружите сообщения об ошибках, которые позволят идентифицировать источник проблемы.) Для этого запустите оснастку Event Viewer.
Шаг 3. Если ошибка STOP появилась при первой же перезагрузке компьютера после установки нового оборудования или дополнительного программного обеспечения, и вы еще не регистрировались в системе, то попробуйте перезагрузить компьютер, и при появлении списка доступных операционных систем нажмите клавишу . В появившемся меню выберите опцию Last Known Good Configuration. Перезагрузка компьютера с использованием последней успешно загруженной конфигурации удалит все конфигурационные изменения, внесенные с момента последней успешной загрузки Windows.
Шаг 4. Если Windows все же не может нормально стартовать, попробуйте выполнить загрузку в безопасном режиме (safe mode), а затем блокировать или удалить вновь установленные программы и драйверы (подробная информация об опциях отладочного меню, выводимого при загрузке Windows при нажатии клавиши , приведена в главе 23 "Восстановление системы"). Просмотрите последнюю версию списка совместимых аппаратных средств (Hardware Compatibility List, HCL) и проверьте, все ли аппаратные средства, установленные на компьютере, присутствуют в этом списке. Убедитесь в правильности подключения всех вновь установленных устройств. Попробуйте отключить новые устройства или заменить их (возможно, именно это и решит проблему), а также запустить диагностическое программное обеспечение, полученное от поставщика данного компьютера. Особое внимание следует уделить тестированию памяти.
Шаг 5. Выполните сканирование компьютера на вирусы с помощью новейшей версии антивирусного программного обеспечения, совместимого с Windows. Вирусы могут повреждать как тома FAT, так и тома NTFS, и эти повреждения могут проявляться как ошибки STOP.
Шаг 6. Просмотрите базу знаний Microsoft, выполнив поиск по ключевым словам winnt и конкретному коду ошибки. Более подробная информация о Microsoft Knowledge Base приведена в последнем разделе данной главы, в списке источников дополнительной информации.

Окно Error Reporting

Рисунок 25.4. Окно Error Reporting


2. В этом окне вы можете установить следующие опции:

Полностью блокировать сервис Error Reporting, установив переключатель Disable error reporting (Отключить отчет об ошибках). Обратите внимание, что в этом случае вы можете установить опцию, которая позволит сервису все же сообщать вам о возникновении серьезных ошибок (например, ошибок ядра). Для этого следует установить флажок But notify me when critical errors occur (Но уведомлять о критических ошибках) расположенный непосредственно под переключателем Disable error reporting.

Активизировать сервис Error Reporting, установив опцию Enable error reporting (Включить отчет об ошибках) и сконфигурировать типы ошибок, о которых сервис будет информировать пользователя. Так, если вы установите флажок Windows operating system, сервис будет всегда сообщать о проблемах в работе компонентов режима ядра. Помимо этого, вы сможете активизировать уведомления о проблемах в работе программ, установив флажок Programs. Нажатием кнопки Choose Programs (Выбор программ) вы можете выполнить дальнейшее конфигурирование сервиса Error Reporting, сформировав список программ, для которых следует выводить подобные извещения.

По сравнению с Windows XP, в операционных системах из семейства Windows Server 2003 сервис Error Reporting обладает дополнительными возможностями. Так, например, при его конфигурировании вы имеете возможность задать опцию отслеживания незапланированных остановов системы (Рисунок 25.5), установив флажок Unplanned machine shutdowns. Также обратите внимание на флажок Force queue mode for program errors, при установке которого сервис Error Reporting будет выводить извещения об ошибках в режиме очереди. В случае множественных ошибок в работе приложений, сервис отобразит извещения о 10 последних ошибках, когда пользователь с административными правами зарегистрируется в системе. Каждое из сообщений будет отображено в отдельном окне, что предоставит администратору возможности выбора действий.

Окно содержащее подробности о

Рисунок 25.2. Окно, содержащее подробности о произошедшей ошибке в работе приложения


Вы можете вручную сконфигурировать сервис Error Reporting. Для этого выполните следующие операции:
1. Запустите утилиту System на панели управления, перейдите на вкладку Advanced (Допольнительно) и нажмите кнопку Error Reporting (Отчет об ошибках). На экране появится окно Error Reporting (Рисунок 25.4).

Отладчик ядра

Отладчик ядра


Программный продукт Windows DDK содержит графический отладчик WinDbg, применяемый для отладки драйверов и приложений, работающих как в режиме пользователя, так и в режиме ядра. Подробная информация об использовании и конфигурировании отладчика содержится в файле справочной системы, поставляемом в комплекте с отладчиком.
Отладчик можно использовать как для локальной, так и для удаленной отладки ядра. Если вы применяете локальную отладку, то хост-компьютер находится в нескольких шагах от целевого и взаимодействует с ним через нуль-модемный кабель. Если вы используете удаленную отладку, то хост-компьютер может находиться на любом расстоянии от целевого, поскольку они взаимодействуют через модемы.
Оба компьютера обмениваются отладочной информацией через коммуникационные порты. Порты на обоих компьютерах должны быть сконфигурированы на одну и ту же скорость передачи данных, выраженную в битах в секунду (бит/с).
После появления "синего экрана" запишите всю важную информацию, которая была выведена в сообщении, и перезагрузите компьютер. Возможно, вам потребуется сконфигурировать целевой компьютер для локальной или удаленной отладки и перезагрузить систему еще раз. После этого вы можете работать с Windows до тех пор, пока сообщение не появится снова. Когда "синий экран" появится еще раз, обратитесь к местному специалисту технической поддержки за помощью. На этом этапе можно решить, как будет проводиться отладка (локально или удаленно). Специалисты технической поддержки могут проинструктировать вас по вопросам конфигурирования системы для отладки.

Отладка ядра

Отладка ядра


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

Подготовка к устранению проблем

Подготовка к устранению проблем


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

Причиной возникновения многих ошибок STOP может быть перезапись системного файла или некорректно работающий драйвер. При этом, как правило, ничего не подозревающий пользователь сам создает проблему, устанавливая программное обеспечение или драйверы, не совместимые с операционной системой. Эта проблема существовала во всех предыдущих версиях Windows NT. Начиная с Windows 2000, в состав операционной системы были введены дополнительные средства защиты системных файлов и драйверов с помощью цифровой подписи, которая гарантирует их совместимость и корректную работу в Windows. Во избежание возникновения проблем рекомендуется пользоваться этими средствами, подробно описанными в главе 23 "Восстановление системы". Так вы существенно снизите риск появления ошибок STOP.

Если даже вы сами никогда не будете выяснять причину возникновения ошибки — предположим, за вас это сделает специалист службы технической поддержки, — рекомендуется хотя бы сконфигурировать систему так, чтобы облегчить ему эту задачу. Вызовите утилиту System из Control Panel, в раскрывшемся диалоговом окне System Properties (Свойства системы) перейдите на вкладку Advanced (Дополнительно) и нажмите кнопку Startup and Recovery (Загрузка и восстановление). На экране появится окно Startup and Recovery (Рисунок 25.7).

Группа опций System startup (Загрузка операционной системы), расположенная в верхней части окна, позволяет задать операционную систему, загружаемую по умолчанию (в случае, когда на компьютере установлено несколько операционных систем), и временной интервал, в течение которого на экране будет отображаться меню загрузки.
Группа, которая интересует нас в данном случае — System failure (Отказ системы), позволяющая определить поведение системы в случае возникновения ошибок STOP. Рассмотрим ее опции более подробно.

Пример экрана сообщения STOP

Рисунок 25.8. Пример экрана сообщения STOP



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

Сервис Error Reporting отображает

Рисунок 25.1. Сервис Error Reporting отображает сообщение, информирующее пользователя о произошедшей ошибке в работе приложения




Рисунок 25.3. Сервис Error Reporting отображает сообщение, информирующее пользователя о произошедшей серьезной ошибке

Символы и деревья символов

Символы и деревья символов


Как правило, при компиляции кода могут быть созданы две версии исполняемого файла — отладочная версия (debug version, известная также под названием checked version) и обычная (nodebug или free). Отладочная версия содержит дополнительный код, который позволяет разработчику отлаживать программу. Файл отладочной версии имеет больший размер и исполняется медленнее. Обычная версия исполняемого файла компактнее и исполняется быстрее, но не позволяет осуществлять отладку.
Все исполняемые файлы, DLL, драйверы и другие программы представляют собой обычные (не-отладочные) версии. Каждому программному файлу ставится в соответствие символьный файл, который содержит отладочный код. Отладочная версия Windows, а также инструкции по ее установке входят в состав программного продукта Windows Device Driver Kit (DDK). Отладочная версия находится в подкаталоге Symbols, который содержит подкаталоги для файлов каждого типа (exe, dll, sys). Эта структура называется символьным деревом (symbol tree).
Утилитам, используемым для отладки или для интерпретации файлов дампа памяти, требуется символьное дерево, в котором содержатся символьные файлы соответствующей версии Windows NT/2000/XP или Windows Server 2003 (на момент, когда имеет место ошибка ядра STOP). Некоторые утилиты требуют, чтобы подкаталог \Symbols находился на жестком диске в каталоге %SystemRoot%. Некоторые утилиты допускают указание пути к подкаталогу \Symbols в качестве одной из опций командной строки (в режиме командной строки или в диалоговом окне).
Отладка ядра требует наличия двух компьютеров — так называемого целевого компьютера (target machine) и хост-компьютера (host machine).

Сообщение о незапланированном останове системы

Рисунок 25.5. Сообщение о незапланированном останове системы


Когда в системе возникает состояние ошибки STOP, Windows всегда создает компактный файл дампа памяти. Таким образом, сервис Error Reporting всегда может отправить отчет о проблеме, приложив этот файл дампа, даже если вы сконфигурировали систему таким образом, чтобы она создавала дамп ядра или даже полный дамп памяти.

Сообщение STOP "синий экран" или прерывание

Сообщение STOP, "синий экран" или прерывание


Когда операционная система сталкивается с аппаратными проблемами, противоречивостью данных, необходимых для ее работы, или иными подобными ошибками, она обрабатывает эту ситуацию на основании информации, введенной в диалоговом окне Startup and Recovery.
Если пользователь в этом диалоговом окне не указал опцию Automatically Reboot, Windows отображает синий экран, на который выводится информация об ошибке, после чего работа операционной системы останавливается.
В Microsoft Knowledge Base и другой документации по Windows это состояние часто называется "синим экраном" (blue screen), ошибкой ядра (kernel STOP error) или программной ловушкой (software trap). Все эти термины используются для обозначения таких состояний операционной системы, когда ядро, обнаружив ошибку, может выполнить запись в файл дампа памяти (эта процедура может являться частью процесса обработки ошибки).

Сообщения системы и отладчик

Сообщения системы и отладчик


Поговорим о грустном... чтобы, столкнувшись с неприятной неожиданностью — "синим экраном смерти", вы не погрустнели вдвойне. Возможно, вы уже достаточно хорошо знакомы с продуктами из семейства Windows Server 2003, а также с предыдущими версиями Windows NT/2000/XP, но во время работы еще не попадали в такую ситуацию. Хотя эта система и надежнее предыдущих версий линейки Windows NT/2000, это не значит, что "синий экран смерти" — следствие серьезных ошибок — не возникнет никогда. Если даже такие ошибки и не появятся, вы все равно должны быть готовы устранить их!
Итак, "синий экран" можно увидеть и в Windows Server 2003. Когда система выявляет серьезную ошибку, которую не может самостоятельно устранить, она, в зависимости от типа ошибки, генерирует соответствующие системные сообщения, которые и известны под собирательным названием "синий экран".
Как и в Windows NT/2000/XP, исполняющая подсистема Windows Server 2003 (модуль Executive) представляет собой часть операционной системы, работающую в режиме ядра. Режим ядра (kernel mode) — это привилегированный режим работы процессора, в котором поток (thread) имеет доступ к системной памяти и к аппаратным средствам. Режимом пользователя (user mode) называется непривилегированный режим работы процессора, выполняясь в котором поток не имеет прямого доступа к системной памяти и аппаратным средствам, для получения такого доступа он должен обратиться к сервисам операционной системы. Модуль Executive обеспечивает структуру процессов, диспетчеризацию потоков, межпроцессную коммуникацию, управление памятью, управление объектами, безопасность и защиту объектов, обработку прерываний и ввод/вывод.
Ядро Windows (Ntoskrnl.exe) представляет собой часть модуля Executive, управляющую процессором. Ядро выполняет диспетчеризацию потоков, обработку исключений и прерываний, а также мультипроцессорную синхронизацию. Кроме того, ядро поставляет модулю Executive объекты-примитивы, из которых он создает объекты режима пользователя.
Итак, существуют два типа системных сообщений Windows 2000/XP и Windows Server 2003.

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

Сообщения о неисправности аппаратуры (Hardware malfunction messages). Как и сообщения STOP, эти сообщения также генерируются в символьном режиме. Их появление указывает на то, что система обнаружила аппаратную ошибку, после которой продолжение работы невозможно.

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

Сообщения STOP появляющиеся при

Сообщения STOP, появляющиеся при инициализации исполняющей подсистемы (Executive)


Некоторые из сообщений STOP могут появляться только в течение относительно краткого периода инициализации модуля Executive (это — четвертая фаза загрузки Windows). Исполняющая подсистема Windows (модуль Executive) — это набор программных компонентов, предоставляющих базовые сервисы операционной системы. Как и при загрузке Windows NT 4.0, загрузку модуля Executive можно разделить на два этапа (этап 0 и этап 1). Во время этапа 0 прерывания блокированы, инициализированы лишь немногие компоненты модуля Executive, такие как уровень аппаратных абстракций (HAL). Во время выполнения этапа 1 система становится полностью работоспособной, и все компоненты Windows проходят инициализацию.
Если вы получите одно из сообщений STOP, появляющихся только на этапе 0 инициализации модуля Executive, запустите программу диагностики аппаратных средств, полученную от поставщика аппаратных средств. Сообщения STOP, появление которых возможно только на этапе 0 инициализации модуля Executive, перечислены в табл. 25.1.

Аппаратные сбои в Windows 2000/XP и Windows Server 2003 часто проявляются как ошибки, генерирующие сообщения STOP. Если при диагностике аппаратных средств не будет обнаружено никаких проблем, попытайтесь переустановить Windows. Если сообщение появится вновь, обратитесь в службу технической поддержки.

Сообщения STOP появляющиеся в процессе работы с Windows

Сообщения STOP, появляющиеся в процессе работы с Windows


Наиболее распространенные сообщения STOP генерируются во время выполнения стандартных повседневных операций. Даже в такой отказоустойчивой операционной системе, как Windows Server 2003, может произойти зависание системы с невозможностью продолжения работы, и появляется "синий экран" (сообщение STOP). В Windows NT/2000/XP и Windows Server 2003 появление сообщения STOP может быть вызвано необрабатываемой ошибкой (unhandled exception) в коде драйвера или файловой системы или выполнением недопустимой инструкции.

Информацию по конкретному сообщению STOP проще всего получить, выполнив поиск в Microsoft Knowledge Base и указав код ошибки.

Сообщения STOP, появляющиеся в процессе установки Windows


Одним из вероятных вариантов исхода неудачной попытки установки Windows может быть появление сообщения STOP. Если это произойдет, в первую очередь проверьте все периферийные устройства компьютера на совместимость с Windows. Для этого возьмите последнюю версию списка совместимых аппаратных средств (HCL). Все компьютеры и устройства, включенные в этот список, тестировались Microsoft в жестких условиях и были признаны совместимыми с Windows. Список совместимости постоянно обновляется по мере того, как тестирование проходят все новые и новые устройства; его последнюю версию всегда можно найти на веб-сервере Microsoft.
Если используемое вами устройство не указано в HCL, обратитесь к поставщику устройства, т. к. только он может предоставить информацию о вновь тестируемых аппаратных средствах и/или доступных обновлениях BIOS. Кроме того, это сотрудничество позволит свести к минимуму трудозатраты при выявлении инсталляционных конфликтов.

Сообщения STOP вызванные программными прерываниями

Сообщения STOP, вызванные программными прерываниями


Эта группа сообщений STOP вызывается программными (или внутренними) прерываниями, или ловушками (software trap). Такие прерывания появляются при возникновении программных ошибок, после которых нормальное продолжение программы невозможно: например, при наличии в команде недопустимых операндов, при попытке деления на ноль, в случае выхода индекса массива за пределы допустимых значений или при обращении к памяти, находящейся за пределами стека.
Пример первой строки сообщения STOP, отображаемой для подобных сообщений STOP:

*** STOP: 0x000000TF (0x0000000n,00000000,00000000,00000000) UNEXPECTED_KERNEL_MODE_TRAP
Ошибка UNEXPECTED_KERNEL_MODE_TRAP указывает на то, что программная ошибка слишком серьезна и не позволяет продолжать работу. Примерами таких ошибок могут быть, например, деление на ноль или ошибка, возникающая в процессе обработки другой ошибки (так называемая двойная ошибка).
Получив одно из таких сообщений, запишите информацию о коде ошибки STOP и перезагрузите компьютер. Если сообщение появится повторно, для устранения проблемы вы можете принять следующие меры.

Выполнить диагностику проблемы, используя информацию и рекомендации, отображенные на экране сообщения STOP (в разделе рекомендаций пользователю). Дополнительная информация по наиболее распространенным сообщениям STOP, методам диагностики и устранения проблем, вызвавших их появление, приведена в сопроводительной документации к программному продукту Microsoft Windows Server 2003 Resource Kit.

Обратиться в службу технической поддержки.

Сообщения свидетельствующие о

Сообщения, свидетельствующие о неполадках в работе аппаратных средств


Сообщения, свидетельствующие о неполадках в работе аппаратных средств, вызываются тем, что процессор выявляет ошибочные состояния устройств.
Первые две строки таких сообщений могут различаться (в зависимости от типа HAL (Hardware Abstraction Layer), загруженного при запуске системы). Типичный пример первых строк такого сообщения приведен ниже.

Hardware malfunction Call your hardware vendor for support
Информация, следующая за этими строками, предназначена для технического персонала, который будет выполнять диагностику аппаратных средств компьютера.

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

Составные части сообщения STOP

Составные части сообщения STOP


В отличие от предыдущих версий Windows NT, где экран сообщения STOP состоит из пяти основных частей, экран сообщения STOP в Windows 2000, Windows XP и Windows Server 2003 (см. Рисунок 25.8) содержит только три части.

Информация кода ошибки (bugcheck information).

Рекомендации пользователю (recommended user action).

Информация отладочного порта (debug port information).

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

STOP 0х0000000А IRQL_NOT_LESS_OR_EQUAL

STOP 0х0000000А - IRQL_NOT_LESS_OR_EQUAL


Это сообщение STOP, известное также под названием STOP OxOA, указывает на то, что процесс режима ядра пытался получить доступ к участку памяти на слишком высоком уровне запроса прерывания (Interrupt Request Level, IRQL), в то время как такие процессы могут получать доступ только к процессам с IRQL не более высоким, чем их собственный.
Рекомендации. Чаще всего эта ошибка бывает вызвана некорректно работающим драйвером устройств, системным сервисом или BIOS. Чтобы попытаться быстро выполнить восстановление после такой ошибки, попробуйте перезагрузить компьютер, при появлении списка доступных операционных систем нажмите клавишу и выберите опцию Last Known Good Configuration.

Использование этой опции наиболее эффективно, если установка драйверов, сервисов и устройств производится по одному за раз.
Если сообщение появляется во время установки Windows, просмотрите HCL и убедитесь в том, что все установленные на компьютере периферийные устройства перечислены в этом списке.
Более подробная информация о диагностике ошибок STOP 0x0A приведена в Microsoft Knowledge Base в статье Q314063 "Troubleshooting a Stop 0x0000000A Error in Windows XP".

STOP 0х0000002Е DATA_BUS_ERROR

STOP 0х0000002Е - DATA_BUS_ERROR


Появление сообщения STOP 0x2E обычно указывает на ошибку четности в системной памяти. Эта ошибка всегда вызывается проблемами с аппаратными средствами, ошибками, допущенными при их конфигурировании, а также несовместимыми или дефектными аппаратными средствами.
Рекомендации. Если ошибка возникла после установки нового аппаратного компонента, попробуйте удалить вновь установленное оборудование. Запустите диагностические утилиты, полученные от поставщика аппаратных средств. Иногда ошибка может быть вызвана повреждением жесткого диска, и в этом случае воспользуйтесь консолью восстановления (Recovery Console).

STOP 0х0000007А KERNEL_DATA_INPAGE_ERROR

STOP 0х0000007А - KERNEL_DATA_INPAGE_ERROR


Это сообщение (STOP 0x7А) указывает на то, что запрошенная страница данных ядра не могла быть считана в память из файла подкачки. Обычно ошибка вызвана появлением плохих блоков в файле подкачки, вирусами, ошибками контроллера жесткого диска или дефектной RAM.
Рекомендации. Выполните сканирование системы на вирусы, проверьте правильность подключения дисков и запустите диагностические утилиты, полученные от поставщика аппаратных средств. В случае необходимости проведите восстановление системы с помощью Recovery Console.

STOP 0x00000024 NTFS_FILE_SYSTEM

STOP 0x00000024 - NTFS_FILE_SYSTEM


Это сообщение, известное также как STOP 0x24, указывает на проблему с драйвером Ntfs.sys, позволяющим системе выполнять чтение информации с томов NTFS и запись на такие тома.
Рекомендации. Чаще всего ошибка вызвана повреждением файловой системы NTFS или сбойными кластерами на жестком диске. Поврежденные драйверы SCSI и IDE также вызывают эту ошибку.
Рекомендации, позволяющие избежать ошибки такого рода, приведены в начале главы 23 "Восстановление системы". Если ошибка все же возникла, запустите программу chkdsk /f /r для устранения повреждений файловой системы.

STOP 0x00000050 PAGE_FAULT_IN_NONPAGED_AREA

STOP 0x00000050 - PAGE_FAULT_IN_NONPAGED_AREA


Эти сообщения (STOP 0x50) появляются, когда запрошенные данные не найдены в памяти. Система при этом генерирует так называемую страничную ошибку или страничное прерывание (page fault), которая при обычных условиях означает, что система ищет данные в файле подкачки (paging file). В этом случае, однако, искомые данные идентифицируются системой как находящиеся в резидентном пуле (nonpaged pool), а это значит, что они ни при каких обстоятельствах не могли быть сброшены на диск. Таким образом, система не может найти требуемые данные и, следовательно, не может продолжать работу. Этот тип ошибки может быть вызван дефектными аппаратными средствами, некорректно работающим системным сервисом, резидентным антивирусным программным обеспечением, несовместимым с операционной системой, и повреждениями файловой системы NTFS.
Рекомендации. Если ошибка произошла сразу же после установки нового устройства, попробуйте удалить его, чтобы проверить повторяемость ошибки. Чтобы исключить отказ уже установленных аппаратных средств, запустите диагностическую утилиту, полученную от поставщика компьютера (чаще всего эта ошибка генерируется дефектными микросхемами RAM).
В случае несовместимых или некорректно работающих системных сервисов можно попытаться использовать последнюю успешно загруженную конфигурацию (см. главу 23 "Восстановление системы"). Если проблема вызвана повреждением тома NTFS, ее поможет решить запуск программы chkdsk /f /r. Иногда помогает блокирование кэширования памяти в BIOS,

STOP 0x00000077 KERNEL_STACK_INPAGE_ERROR

STOP 0x00000077 - KERNEL_STACK_INPAGE_ERROR


Сообщения STOP (STOP 0x77) указывают, что ядро не может прочесть запрошенную страницу из файла подкачки.
Рекомендации. Чаще всего причину возникновения этой ошибки можно определить по второму параметру сообщения (значение этого параметра следует записать). Список наиболее распространенных кодов приведен ниже.

0хС000009А — STATUS_INSUFFICIENT_RESOURCES. Недостаточный объем нерезидентного пула.

0хС000009С — STATUS_DEVICE_DATA_ERROR. Чаще всего является результатом появления плохих блоков на жестком диске.

0xC000009D — STATUS_DEVICE_NOT_CONNECTED. Чаще всего указывает на неправильное подключение жесткого диска.

0хС000016А — STATUS_DISK_OPERATION__FAILED. Чаще всего вызывается плохими блоками на жестком диске.

0хС0000185 — STATUS_IO_DEVICE_ERROR. Чаще всего возникает при неправильном подключении устройств SCSI или при попытке двух устройств использовать одно и то же прерывание.

Это наиболее распространенные коды, полный список можно найти в файле Ntstatus.h, входящем в состав продукта Windows Server 2003 Device Driver Kit (DDK).

STOP 0x00000079 MISMATCHED_HAL

STOP 0x00000079 - MISMATCHED_HAL


Эти сообщения (STOP 0x79) появляются при несовпадении уровня аппаратных абстракций (HAL) и ядра или типа компьютера, в основном, при смешении конфигурационных файлов однопроцессорной и многопроцессорных систем в пределах одной системы.
Рекомендации. Чаще всего эта ошибка возникает после ручной модификации или переписывания файлов Ntoskrnl.exe и Hal.dll. Эта ошибка может также указывать на несовпадение версий этих файлов (например, версия HAL предназначена для одной ОС, а версия ядра — для другой). Возможно также, что на компьютере по ошибке используется мультипроцессорный HAL и однопроцессорное ядро (или наоборот).
Для устранения этой проблемы необходимо использовать диск автоматического восстановления (ASR) или консоль восстановления (Recovery Console).

STOP 0x0000007B INACCESSIBLE_BOOT_DEVICE

STOP 0x0000007B - INACCESSIBLE_BOOT_DEVICE


Это сообщение (STOP 0x7B) появляется в процессе запуска системы и указывает на то, что в процессе загрузки система потеряла доступ к загрузочному диску.
Рекомендации. Причиной возникновения ошибки могут быть сбой загрузочного диска, поврежденный драйвер загрузочного устройства, повреждение системного раздела, установка нового адаптера SCSI или контроллера жесткого диска.
Возможно, проблема может быть решена редактированием файла Boot.ini. Более подробную информацию по данному вопросу можно найти в Microsoft Knowledge Base в статье "BOOT.INI and ARC Path Naming Conventions and Usage"
Если такая ошибка возникает в процессе установки системы, возможно, используется несовместимый жесткий диск или контроллер SCSI. Если программа Setup автоматически распознала контроллер, возможно, при установке системы следует пропустить фазу детектирования (поиска оборудования) и вручную указать драйвер, который должен быть загружен. Для этого: когда система на текстовой фазе инсталляции предложит нажать клавишу , чтобы указать драйвер накопителя вручную, следует нажать клавишу и вставить дискету с драйвером, полученным от поставщика этого устройства.
Если в системе недавно было установлено новое устройство (особенно жесткие диски или контроллеры), поможет использование опции Last Known Good Configuration в меню, выводимом после нажатия клавиши .
Наконец, эта ошибка может быть следствием повреждения жесткого диска. Если ошибка появляется раньше, чем вы можете зарегистрироваться в системе, запустите консоль восстановления и выполните команду chkdsk /f /r.

STOP 0X0000007F UNEXPECTED_KERNEL_MODE_TRAP

STOP 0X0000007F - UNEXPECTED_KERNEL_MODE_TRAP


Сообщения STOP 0x7F указывают на фатальную ошибку, вызванную программным прерыванием. Иногда эти ошибки могут быть вызваны программным обеспечением, но в большинстве случаев они являются следствием аппаратного сбоя.
Рекомендации. Первый и самый главный параметр этого сообщения (0х0000000х) принимает различные значения в зависимости от типа ошибки (полный список всех кодов можно найти в Windows Server 2003 Device Driver Kit).
Если ошибка происходит после установки нового устройства, и после установки этого устройства вы еще не регистрировались в системе, положение может исправить использование опции Last Known Good Configuration.
Убедитесь в том, что все жесткие диски, контроллеры и адаптеры SCSI перечислены в HCL и установлены правильно. Чтобы исключить аппаратный сбой одного из устройств, которое раньше работало нормально (особенно это относится к памяти), запустите диагностические утилиты, полученные от поставщика компьютера. Следует отметить, что эта ошибка может также быть вызвана неумелым разгоном процессора (в этом случае верните процессор к его штатной тактовой частоте).

STOP 0x000000IE KMODE_EXCEPTION_NOT_HANDLED

STOP 0x000000IE - KMODE_EXCEPTION_NOT_HANDLED


Это сообщение STOP, известное также как STOP 0xlE, указывает на то, что процесс режима ядра пытался выполнить недопустимую инструкцию.
Рекомендации. Проблема может быть вызвана несовместимыми аппаратными средствами, некорректно работающим драйвером или системным сервисом. Как правило, второй параметр этого сообщения идентифицирует проблемный драйвер или устройство его адресом (иногда может указываться имя этого драйвера). Попробуйте загрузить компьютер в безопасном режиме и блокировать указанный драйвер. Если это не поможет, то, как правило, проблему можно решить с помощью консоли восстановления (Recovery Console), см. главу 23 "Восстановление системы".
В ряде случаев может помочь блокирование кэширования памяти через программу BIOS Setup.

STOP 0x0000021 А STA TUS_SYSTEM_PROCESS_ TERMINA TED

STOP 0x0000021 А - STA TUS_SYSTEM_PROCESS_ TERMINA TED


Редкий случай, когда сообщение STOP вызвано сбоем сервиса, работающего не в режиме ядра, а в режиме пользователя. Это сообщение (STOP OxC2lA) появляется, когда одна из подсистем (например, Winlogon или CSRSS), настолько повреждена, что операционная система не может гарантировать безопасности и переключается в режим ядра с генерацией этой ошибки.
Рекомендации. Подробную информацию о кодах статуса этой ошибки (первый из трех параметров) можно найти в файле Ntstatus.h, входящем в состав программного продукта Windows Server 2003 Device Driver Kit (DDK).
Поскольку ошибка STOP OxC21A происходит в режиме пользователя, наиболее вероятной ее причиной являются плохо работающие приложения третьих фирм. Воспользуйтесь опцией Last Known Good Configuration.

STOP 0x00000221 STATUS_IMAGE_CHECKSUM_MISMATCH

STOP 0x00000221 - STATUS_IMAGE_CHECKSUM_MISMATCH


Это сообщение STOP (STOP 0xC221) указывает на повреждение драйвера или системного файла DLL. Как правило, в сообщении STOP указывается имя файла, вызвавшего проблему.

Сообщения STOP появляющиеся

Таблица 25.1. Сообщения STOP, появляющиеся только на этапе О инициализации исполняющей подсистемы Windows

Код сообщения	Символическое имя
0x0031	PHASEO_INITIALIZATION_FAILED
0x0050	HAL_INITIALIZATION_FAILED
0x0050	HEAP INITIALIZATION_FAILED
OxOOSE	OBJECT INITIALIZATION FAILED
OxOOSF	SECURITY INITIALIZATION FAILED
0x0060	PROCESS_INITIALIZATION_FAILED

Сообщения STOP, которые могут появиться на этапе 1 инициализации модуля Executive, перечислены в табл. 25.2. Получив одно из таких сообщений, попытайтесь переустановить Windows, и если сообщение появится снова, обратитесь в службу технической поддержки.

Сообщения STOP появляющиеся

Таблица 25.2. Сообщения STOP, появляющиеся только на этапе 1 инициализации исполняющей подсистемы Windows

Код сообщения	Символическое имя
0x0032	PHASE1_INITIALIZATION_FAILED
0x0061	HAL1_INITIALIZATION_FAILED
0x0062	OBJECT1_INITIALIZATION_FAILED
0x0063	SECURITY1_INITIALIZATION_FAILED
0x0064	SYMBOLIC_INITIALIZATION_FAILED
0x0065	MEMORY1 INITIALIZATION FAILED
0x0066	CACHE INITIALIZATION FAILED
0x0067	CONFIG INITIALIZATION FAILED
0x0068	FILE_INITIALIZATION_FAILED
0x0069	I01_INITIALIZATION_FAILED
ОхООбА	LPC_INITIALIZATION__FAILED
ОхООбВ	PROCESSl INITIALIZATION FAILED
ОхООбС	REFMON_INITIALIZATION__FAILED
0x0060	SESSION1_INITIALIZATION_FAILED
ОхООбЕ	SESSION2 INITIALIZATION FAILED
ОхООбР	SESSION3_INITIALIZATION_FAILED
0x0070	SESSION4_INITIALIZATION FAILED
0x0071	SESSIONS INITIALIZATION FAILED

Типы сообщений STOP

Типы сообщений STOP


Сообщения STOP можно классифицировать по следующим категориям:

сообщения, появляющиеся в процессе работы Windows;

сообщения, появляющиеся во время установки Windows;

сообщения, появляющиеся в процессе загрузки Windows;

сообщения, вызванные программными прерываниями (software trap).

Установка отладочного сеанса

Установка отладочного сеанса


Если принято решение использовать отладчик ядра для анализа ошибки ядра STOP, вам потребуется установить хост и соединить целевой и хост-компьютеры. Для этого необходимо использовать нуль-модемный кабель (в случае проведения локального отладочного сеанса) или модемный кабель (в случае удаленной отладки).
Прежде чем начинать отладку, выполните подготовительные действия:
1. Установите соединение между двумя компьютерами через модем или нуль-модемный кабель.
2. Сконфигурируйте целевой компьютер для отладки.
3. Установите в хост-системе символьное дерево.
4. Установите в хост-системе отладчик.
5. Запустите отладчик в хост-системе.
Установка сеанса удаленной отладки. Если вы активизируете отладчик ядра на целевом компьютере, он будет отправлять отладочную информацию на хост-компьютер, чтобы ее смог анализировать удаленный пользователь. Выполнение этой процедуры часто требуют специалисты из группы поддержки, чтобы собрать информацию, необходимую им для анализа фатальной ошибки, особенно если эту информацию невозможно получить из файла дампа или файл дампа не создается.
Чтобы сконфигурировать систему для удаленной отладки, необходимо изменить загрузочные опции операционной системы таким образом, чтобы на этапе загрузки выполнялась загрузка отладчика ядра. На платформах х86 это делается путем редактирования файла Boot.ini. Кроме того, необходимо подключить внешний модем к соответствующему СОМ-порту целевого компьютера и соединить его с входным (inbound) телефонным каналом.
Установка модема на целевом компьютере. Чтобы установить сеанс удаленной отладки, необходимо подключить к целевому компьютеру внешний модем и переконфигурировать параметры модема таким образом, чтобы они соответствовали требованиям отладчика ядра. Чтобы сконфигурировать модем, необходимо иметь возможность запустить программу Terminal.exe или другую подобную коммуникационную утилиту. Если запуск таких программ на целевом компьютере невозможен, сконфигурируйте модем на другом компьютере, имеющем близкие конфигурационные параметры. Подключите сконфигурированный модем к целевому компьютеру и убедитесь, что он работает. Использование внутренних модемов в данном случае невозможно, т. к. при перезагрузке система сбрасывает изменения, внесенные в их конфигурацию.
Модем необходимо подключить к свободному СОМ-порту и установить конфигурационные параметры:

Auto answer mode	On
Hardware compression	Disabled
Error detection	Disabled
Flow control	Disabled
Рекомендуются скорости nepef.	\ач\л данных: 9600 бит/с для систем х86

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

/Debug	Приводит к загрузке отладчика на этапе загрузки системы. Отладчик остается в памяти компьютера в течение всего времени работы. Это означает, что специалист из группы поддержки может через модем вмешаться в работу отладчика, даже если система не зависла и сообщение STOP не появилось
/Debugport	Указывает последовательный порт, который должен использоваться отладчиком ядра. Если последовательный порт не указан, отладчик по умолчанию будет использовать порт COM2 на компьютерах х86 и СОМ1 в системах с RISC-процессорами
/Crashdebug	Отладчик загружается при загрузке системы, но остается неактивным до тех пор, пока не произойдет сбой. Это позволяет другим приложениям использовать указанный СОМ-порт (по умолчанию используется СОМ1) в течение всего времени, пока система еще работает
/Baudrate	Задает скорость передачи данных, которую будет использовать отладчик ядра. По умолчанию задается скорость 19 200 бит/с, которая является нормальной при удаленной отладке через модем

Чтобы сконфигурировать отлаживаемый компьютер на платформе х86, отредактируйте файл Boot.ini с использованием стандартного текстового редактора и добавьте в этот файл соответствующие опции отладчика.



    Работа с информацией: Безопасность - Защита - Софт - Криптография

• Информационная безопасность
  
• Аспекты информационной безопасности
  
• Системы информационной безопасности
  
• Софт и информационная безопасность
  
• IInternet Information Services
  
  
• Защита и безопасность
  
• Защита с Firewall
  
• Атаки и информационная безопасность
  
• Информационная безопасность в интернет
  
  
• Борьба с вирусами
  
• Антивирусы против вирусов
  
• Хакеры и информационная безопасность
  
  
• Криптография
  

---

---